Copy link to clipboard
Copied
Since applying the latest security patch I am receiving the below events and it has broken two of our apps.
03/15 11:54:38 error ROOT CAUSE:
coldfusion.filter.FormScope$PostParametersLimitExceededException: POST parameters exceeds the maximum limit specified in the server.
at coldfusion.filter.FormScope.parseQueryString(FormScope.java:397)
at coldfusion.filter.FormScope.parsePostData(FormScope.java:346)
at coldfusion.filter.FormScope.fillForm(FormScope.java:296)
at coldfusion.filter.FusionContext.SymTab_initForRequest(FusionContext.java:377)
at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:33)
at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)
at coldfusion.filter.CachingFilter.invoke(CachingFilter.java:62)
at coldfusion.filter.RequestThrottleFilter.invoke(RequestThrottleFilter.java:126)
at coldfusion.CfmServlet.service(CfmServlet.java:200)
at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89)
at jrun.servlet.FilterChain.doFilter(FilterChain.java:86)
at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:42)
at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46)
at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)
at jrun.servlet.FilterChain.service(FilterChain.java:101)
at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106)
at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)
at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:286)
at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543)
at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203)
at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428)
at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)
javax.servlet.ServletException: ROOT CAUSE:
coldfusion.filter.FormScope$PostParametersLimitExceededException: POST parameters exceeds the maximum limit specified in the server.
at coldfusion.filter.FormScope.parseQueryString(FormScope.java:397)
at coldfusion.filter.FormScope.parsePostData(FormScope.java:346)
at coldfusion.filter.FormScope.fillForm(FormScope.java:296)
at coldfusion.filter.FusionContext.SymTab_initForRequest(FusionContext.java:377)
at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:33)
at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)
at coldfusion.filter.CachingFilter.invoke(CachingFilter.java:62)
at coldfusion.filter.RequestThrottleFilter.invoke(RequestThrottleFilter.java:126)
at coldfusion.CfmServlet.service(CfmServlet.java:200)
at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89)
at jrun.servlet.FilterChain.doFilter(FilterChain.java:86)
at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:42)
at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46)
at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)
at jrun.servlet.FilterChain.service(FilterChain.java:101)
at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106)
at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)
at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:286)
at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543)
at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203)
at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428)
at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)
at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:70)
at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46)
at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)
at jrun.servlet.FilterChain.service(FilterChain.java:101)
at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106)
at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)
at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:286)
at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543)
at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203)
at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428)
at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)
03/15 11:54:38 error (JRun Service: ProxyService [jrun.servlet.jrpp.JRunProxyService@4c27d5bc]) JRunPRoxyServer.invokeRunnable:
java.lang.IllegalStateException
at jrun.servlet.JRunResponse.getWriter(JRunResponse.java:205)
at jrun.servlet.JRunResponse.sendError(JRunResponse.java:597)
at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:328)
at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543)
at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203)
at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428)
at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)
Copy link to clipboard
Copied
Two things to check: 1) make sure that you followed the installation instructions properly, there are a few jar files that you need to delete from the updates dir - if you missed that step you might see that error. 2) Is the page where you get this the result of a large form post, eg over 100mb or over 100 form fields? If so then you need to adjust settings, this is described in the KB article associated with the hotfix. Hope that helps
--
Pete Freitag
http://hackmycf.com/ - Is your ColdFusion Server Secure?
Copy link to clipboard
Copied
Followed the installation to the letter. I am very careful of that. The error is from the logs folder cfusion-event.log.
Copy link to clipboard
Copied
But the key question was: is the page that’s failing doing a post? And does the size exceed the limits? That’s the change that fix introduces.
/charlie
Copy link to clipboard
Copied
Given that the error message you've posted includes "PostParametersLimitExceededException" you might try editing your neo-runtime.xml file adding the line below:
<var name='postParametersLimit'><number>100.0</number></var>
See: http://helpx.adobe.com/coldfusion/kb/coldfusion-security-hotfix.html
Copy link to clipboard
Copied
I am getting reports from users about this problem as well, andI have verified that this line is also in our xml files, per the hotfix article:
<var name='postParametersLimit'><number>100.0</number></var>
First of all, I assume this number means "100MB." There's no way the form being submitted is submitting 100MB worth of data; there's no file upload and there's not that much data entered into the form.
I am going to be rebooting all affected servers and will report back with my findings, but I may need to resort to rolling back this hotfix.
Copy link to clipboard
Copied
Ah wait... I bet you're going to tell me that the number is NOT representing "100MB" but "100 form field parameters" (like the var name says) in which case this form may very well have over 100 fields. I've adjusted upwards accordingly, we'll see if that's what the deal is.
Copy link to clipboard
Copied
Folks, there is talk among some that seems to be concluding that this security hotfix presumes to rely on elements implemented in Cumulative hotfix 3 (for 8.0.1. Have not heard similar discussions for other versions yet.) If you have not added that, consider it. If you have previously added it, make sure you didn’t delete the CFH3 jar (while deleting other jars, per the technote.)
For more on this issue, as well as some thoughts on the hope for hotfix challenges to perhaps be fixed in the future (even in CF 8 and 9, separate from what’s coming in CF10), see my discussion in another thread on the same topic (of problems with this security hotfix) that I just posted:
http://forums.adobe.com/message/4282942#4282942
/charlie
Copy link to clipboard
Copied
this kind of worked for me,
1. i redid the update follwing the steps closely, it worked just when posting forms to db resulted in the error
2. changing the neo-runtime.xml didnt do any good.
3. deleting the .jar files int the /li/updates/ folder did the trick,
The thing is in the instructions by adobe, it states a few files to delete the .jar files from the updates folder but it specifically spcifies the names of them so i had left my hf801-005.jar in there since it was not on the list specified by adobe.
After deleting this, its working so far.
Copy link to clipboard
Copied
Bear in mind that the hf801-*.jar files are the hotfix patch files. If you delete the hf801-00005.jar file you are removing the hotfix.
Message was edited by: JR \"Bob\" Dobbs
Copy link to clipboard
Copied
JR/"Bob" - is right. You need to modify the "post parameters limit" variable in the neo-runtime.xml file:
<var name='postParametersLimit'><number>100.0</number></var>
But increase it from 100.0 to something "much" bigger. I increased mine to 5000 due to my form processing requirements.
This is the "number" of input parameters being posted from the form not the size.
The post "size" variable is also in the neo-runtime.xml file as:
<var name='postSizeLimit'><number>100.0<number></var>
The post Size limit variable can be set from the Coldfusion Admin GUI but the post Parameters limit has to be change in the xml and Coldfusion restarted.
It appears that the APSB12-06 patch started enforcing the post Paramters limit setting.
This corrected my problem but I am also probably going to redesign my page to use JQuery to reduce the number of input parameters on the form.
Copy link to clipboard
Copied
Still no luck for me. I modified the neo-runtime.xml file as instructed. I also did as Charlie suggested and made sure I had Cummulative Hotfix 3 installed, which actually fixed some other problems I had, but I still have the "POST parameters exceeds the maximum limit specified in the server" error.
Copy link to clipboard
Copied
Just tried installing Cumulative Hotfix 4 to see if it fixed it, it didn't.
Copy link to clipboard
Copied
Noticed the server I was working on didn't have either CHF 1 or 2 installed, so installed those as well. Still didn't solve the problem. Not feeling very lucky today.
Copy link to clipboard
Copied
tmessier - Do you get the "POST parameters exceeds the maximum limit" on every web page?
The defaut size is 100 input parameters. You can view the source of your page, right click on page - view source, and see how many "<input" parameters are on the page. Remember you should have two "post" variables in the neo-runtime.xml file. One specifies the size in MB of the page (or file being uploaded) and the other specifies the number of parameters that can be posted. Make the "postParametersLimit" variable very big "9999.0" and see if this corrects the problem.
As a side not can someone tell me how to "paste" text into this forum reply box. My "paste" button is grayed out.
Copy link to clipboard
Copied
I got it working, it was totally my fault. I searched my neo-runtime.xml file for postParametersLimit and found nothing so I added it after postSizeLimit per the instructions. Turns out my file did have a postParametersLimit in it, but it didn't come right after postSizeLimit so I didn't notice it and I must have searched for the wrong thing (probably forgot the "s" in "Parameters"). So after removing the duplicate entry, everything worked fine. Felt stupid wasting an hour on this, but it could have been worse if I hadn't spotted the duplicate!
Copy link to clipboard
Copied
Good to hear you resolved it. But you should now remove those CHF1 and 2 jar files you added (per your note in this thread at http://forums.adobe.com/message/4297879#4297879), when you had CHF 3 already. They are cumulative. You do not need the earlier ones if you install the later ones. And in that you also said in another message that you added CHF 4, you should remove the CHF 3 jar. But be careful to ONLY remove those that start with chf (for 1, 2, and 3), not any for HF (individual hotfixes) unless a technote tells you to remove them.
/charlie
Copy link to clipboard
Copied
One other thought on this: one other conclusion from this is that people should not “just add” the line about postParametersLimit if they are finding this thread to solve the problem.
They should first check if the string is already in the neo-runtime.xml file. To be clear, it’s not there unless and until someone reads the technote (for the hotfix) and adds it. (the postsizelimit has been there at least since CF7, and is controlled via a setting on the CF Admin Settings page).
But it could be that you (dear reader of this thread) may be finding this thread in order to “solve” the problem of your now getting an error when trying to post a form submission. And someone else on your server may have applied the HF which imposed the new limitation (of number of form fields that can be posted, as a security fix). That person applying the fix may not have raised the postParametersLimit value high enough for your specific application’s needs.
So again, don’t “just add the lines” for postParametersLimit. That’s what the technote says to do when you are applying the hotfix. The lesson to be learned from the experience of some others in this thread is that if you are NOT the one applying the hotfix, don’t mistakenly “add the lines” for postParametersLimit. Check first if it’s there (from someone having applied the hotfix), and if so, update the value instead.
Finally, I’m pretty sure changing that value in that file will require a restart of CF for it to take effect, at least until Adobe updates the Admin so that you change it instead in the interface, where they could cause the xml file to be reloaded.
/charlie
Copy link to clipboard
Copied
I have a form designed by one of our partners that has exactly 101 form elements.
Something I am running into is that after editing neo-runtime.xml & performing a restart, all seems ok, until... Until I make a change via the CF Admin. After that, the <var name='postParametersLimit'><number>xxx.0</number></var>
line is removed.
According to http://helpx.adobe.com/coldfusion/kb/coldfusion-security-hotfix.html, "We are not exposing this setting in ColdFusion Administrator console, but this limit can be easily changed in neo-runtime.xml file." Thus, I believ by not exposing it via the CF admin console, that setting is ignored upon any console cahnges/updates. Not very helpful at all. Tie another string around my finger for things to remember to do when I perform task xyz.
Copy link to clipboard
Copied
It may be possible that the reason it’s not written when you edit is that it’s possible that they changed the Admin code to write it (even without exposing it in the interface), but perhaps while applying this or another update you did not properly update the CFIDE directory that underlies your CF Admin. I see this happen often, as people sometimes have more than one CFIDE, and might pick the “wrong” one. Start by checking what’s defined in the CF Admin Mappings page.
But that’s not enough, sadly. What matters more is where the docroot is for the website in the web server you use to run the CF Admin. If using a port (like 8300, 8500, etc) then you’re likely using CF’s built-in web server, and its docroot (and place to find and update the CFIDE) is generally \wwwroot. If using IIS or Apache, then it’s wherever the docroot is for the website you’re using there.
Some people have duplicated their CFIDE and placed copies in different docroots, whether for use by the code that their CFML creates (some of which calls back to the server for some subdirs of CFIDE) or simply because they wanted be able to access the CFAdmin in different web sites. Sure, they could have created virtual directories instead, but many go the simple route. And so when hotfixes are applied that require updating the CFIDE, the person doing that may do only the “one” they think is in use by CF, when in fact it could be many.
And that then could leave you in the state you’re in. Just a guess. Could be wrong. Just an idea, if it may help.
/charlie
PS If anyone would wonder, “well if they CF Admin is accessed by way of different CFIDE dirs in different web sites, then wouldn’t that mean I’d see different results saved in the CF Admin if accessed these different ways”, the answer is “no”. The CF Admin writes its results back to the server, typically in \lib\neo-*.xml files. It does not write back to the CFIDE dir itself. So, again, some people can be suffering from this problem of different sites using subtly different CFIDE codebases, and they may not readily notice it at all, until quirky things like the below might happen.
Copy link to clipboard
Copied
Charlie,
Thnx for the reply, and I think you nailed it on your opening statement. "It may be possible that the reason it’s not written when you edit is that it’s possible that they changed the Admin code to write it (even without exposing it in the interface)". I failed to heed the warning of an earlier post and there may have already been an entry with a value of 100. I placed mine directly after the postSizeLimit and later found it missing. Knowing that the file is written in whatever order the server wants to place the elements, I went searching for 'postParametersLimit
' and discovered '<var name='postParametersLimit'><number>100.0</number></var>
'.
This sort of demosntrates that the Admin code does placed it with a default value of 100, but not neccessarily where I expected to find it. I reset the value to what I wanted, restarted the server, and then made several edits via the CF Admin, thus proving I was expeiencing an ID 10 T error.
Without derailing the topic: With regards to the whole /CFIDE/ topic, my practice has been to create two folders for each server instance. One that is a target for the sites served by said instance that does not contain the adminapi and similar folders, thus not exposing the admin api, that is a virtual fodler target for said sites. The other folder is targeted by an internal only web site for administering each server instance, thus only exposing the CF Admin thru a site that can only be reach by LAN clients. This makes managing updaets a bit easier. Curious what others do.
Copy link to clipboard
Copied
Glad to hear that you solved it.
As for your approach to managing the CFIDE directory for various uses, there are lots of ways to solve things, each with their pros and cons in terms of maintainability, security, etc. Not really any one right way. It would be a useful blog entry for someone to outline the many approaches and their implications, in both the near and long term (meaning with respect to applying updates, etc.)
/charlie
Copy link to clipboard
Copied
This hotfix is causing crazy problems and I think part of the issue is the description of the fix for the forms. It tends to imply that the default value is 100 and if you need more, feel free to change it. The default value is in fact 15, so I think everybody will need to change this.
Copy link to clipboard
Copied
I just went and looked at a fresh isntall withonly the update applied and no changes to neo-runtime.xml
<var name='postSizeLimit'><number>100.0</number></var>
<var name='webserviceLimit'><number>5.0</number></var>
<var name='queueTimeout'><number>60.0</number></var>
<var name='timeoutRequestTimeLimit'><number>60.0</number></var>
<var name='slowRequestTimeLimit'><number>30.0</number></var>
<var name='flashRemotingLimit'><number>5.0</number></var>
<var name='postParametersLimit'><number>100.0</number></var>
I'm lost as to where you came up with 15, but curious. My biggest problem was haste, oversight, not paying attention to the previous warnings in this thread. The docs mention to jump to Section 2 if certain conditions apply. This caused me to not pay attention to the Notes section. The notes also mention that you want to place the 'postParametersLimit' right below 'postSizeLimit'. Thus, not finding it there, I believed it wasn't yet in the file.
-Dan
Copy link to clipboard
Copied
If the setting has been there, it was set at 15. I am finding many of our servers don't have the setting at all. Just seems a bit odd.