We are pleased to announce that we have released the updates for the following ColdFusion versions:
IMPORTANT:
If you are updating the 2016 and 2018 releases of ColdFusion to updates 12 and 5 respectively via the ColdFusion Administrator, ensure that Update 4 of ColdFusion (2018 release) and Update 11 of ColdFusion (2016 release) are installed.
These are mandatory pre-requisites before updating.
The following are links to the tech notes for each update:
The releases address security vulnerabilities, which are documented in the bulletin APSB19-47.
The following are the highlights of these updates. For more information, we recommend you to see the tech notes.
- Language enhancements – New Query, Array, and Struct functions, and other changes.
- Arrow functions – Write functions using the Arrow operator.
- Regex – Use Java as Regex engines for your regular expressions.
- ColdFusion Administrator – Server and application setting, useJavaAsRegexEngine.
- Server Auto-Lockdown – There is a new installer for Solaris OS.
- Application server support – Updated versions of WildFly and Tomcat are supported.
- OEM upgrades – Updated versions of JDK, ZingChart, MySQL, etc. are supported.
- OS support – Updated versions of RHEL, Ubuntu, and CentOS are supported.
Also, for the security fixes to take effect, we recommend users to be on the latest JDK/update level.
For a list of the bugs fixed in these updates, see the following:
Please update your ColdFusion versions today. Let us know if you face any issues while installing the updates. Your feedback is essential to further enhancing the product.
We thank you for your continuing support.
.png)
.png)
.png)
Added https://tracker.adobe.com/#/view/CF-4206219, CFwindow appears off-screen when using center=”true” on long pages.
Can you file a CFB bug for this in the public tracker – https://tracker.adobe.com/#/add_bug?
In a response to an open ticket (https://tracker.adobe.com/#/view/CF-4205271) regarding Server responsiveness (or lack thereof) after applying Patch 5 for CF 2018, it is suggested to have the client do the following:
Vikram,
Can you pls ask the customer to try using the following flag in JVM config
-Dcoldfusion.http.usepooling=false
Comment by Piyush K.
Two questions:
- Is this suggestion applicable to 2016 Patch 12 as well?
- What is the implication of applying this to a server? Seems dangerous and can’t find anything on the web about that particular setting.
Mike, since two Adobe tickets recommend it, I don’t know that we should regard it as “dangerous”. Have you tried it? Or will you not until you get an clarification (understandable)? You will see I have asked in the ticket for clarification.
We have not tried it nor am I willing to until I get a better explanation as to what that does.
Mike, I understand your stance.
To anyone else in Mike’s boat, you may want to consider some thoughts I share in replies to Dave Cordes who created another comment below on seemingly the same issue a week earlier. If that link doesn’t work, see his comment starting “has anyone noticed hanging http transactions” (sadly, we can’t create links to replies to comments).
I’m just trying to help people move the ball down the field, given that the “coach” (Adobe) has gone silent on the matter.
Michael, some are happy with the update, at least after addressing additional post-update fixes required, as discussed in comments here. Some still have problems even after doing that. For now, the “jury is still out”, in the minds of many. For others, they have applied the update and have no issues.
Has anyone noticed hanging CFHTTP transactions after updating to patch 5 on ColdFusion 2018? I just added a bug report outlining our issues on 5 different production servers.
https://tracker.adobe.com/#/view/CF-4205439
Maybe this is a connector issue as well?
Dave, have you tried the JVM argument offered in that tracker ticket? Did it help you?
No I have not because I don’t even know what that flag does. No one from Adobe has explained it.
I do realize no one from Adobe has “explained it”. And as you saw (and now also commented), I have asked for more clarification from Adobe about it in the ticket (4205271). But I asked if you’d applied it because you’d made no comment here or there since writing your comment here a week ago. I just wanted to make sure you knew of the option.
Even without an explanation from them, I would just point out that since two tickets from Adobe propose it as a fix for that specific cfhttp hangup problem, it seems worth at least trying if you feel “stuck and unable to update” because of this one issue.
Still, if you are preferring to wait for that explanation, I understand. Again, I just wanted to help readers of these comments know where things stood, as you’d raised the issue.
Yes I was aware of the option, but again, just because someone from Adobe says to do something, I’m not going to do it just to see if it works. I don’t want to be the guinea pig here. I want a solution.
Well, they are offering it as “a solution”, so I don’t think it’s right to assume you’d be a “guinea pig”. This is not a workaround some community member is proposing. Still, I understand you are saying you want to know more (as I said in my previous comment).
Folks taking Dave’s stance (and Mike’s elsewhere here) can certainly wait for them to respond (though they may not), or you can apply the workaround to fix the problem (and be able to move on to the update), and then determine/report if the workaround has some unintended consequence.
You basically have to decide which fear is more important: the fear that the workround has some unintended consequence (or one they failed to document), or the fear that not being updated leaves you open to the known vulns that it fixes.
But if you really still err on the side of “I need more info”, I’d propose that rather than wait for it here or in the ticket, you should email cfinstal@adobe.com, where they have said they are wanting to hear from people having issues with the update or fixes offered for it. (And if you learn more, I hope you will offer it here.)
As always, just trying to help.
@alkane7354022, can you please share the connector log (mod_jk.log file present in [CF Home]/config/wsconfig/[Magic folder for your connector]) to kalv@adobe.com? This is regarding the issue you are reporting on Solaris and Apache
For people experiencing problems with IIS or Apache after the recent updates, note that Adobe has come out with a new blog post, where they offer an updated .dll (for IIS) or .so (for Apache), that addresses connector issues.
I do realize that the title of the blog post may lead some to think that it does not apply to them, but it is the only connector update I’ve seen offered so far for the Sept CF updates, so it’s worth giving it a shot to see if it solves your problems. (Of course, getting to the Sept. updates is important for the security fixes they offer.)
If this connector update doesn’t solve your problem, report that to cfinstal@adobe.com (yep, that’s one “L”). Here’s the post with more info:
https://coldfusion.adobe.com/2019/10/error-accessing-coldfusion-administrator-using-connector-port/
Charlie (or Adobe), can anyone clarify if this connector update should be installed for ALL CF systems running the latest patch? Or, is it only for those that are running CF Admin directly through IIS or Apache and not through port 8500 as recommended? We just reverted our production system back to 2016/11 due to major performance issues after updating this weekend. We didn’t see any issues in QA but we also didn’t update the ISAPI_Redirect.dll.
Does this update fix things other than the CF Admin access?
Yes, the updated connector has been reported to address issues other than admin access problems.
Since you didn’t try it, you should, before giving up on the many other important benefits of update 12.
Mike, did you try the connector update? Any news?
Hello Adobe,
where is the Update to fix the issue of Update?
Hi Vamsee and Charlie, please see my comment on CF-4202173. CFFiddle+Tracker _could_ be awesome. Thanks!, -Aaron
I added a vote, Aaron. And yep, Vamsee, I would think it very helpful for the fiddle site to have the two most recent updates for each listed version, so that people can test if something changed since a newer update.
I could have sworn I wrote that somewhere, but I don’t see my having filed a feature request, and if it was a comment elsewhere here, it’s just too hard to find it when I have to manually expend the “replies” button for every comment, one by one. I wish there was a “expand all”. (In fact, I just created a feature request for that: https://tracker.adobe.com/#/view/CF-4205386).
I also just created a feature request for the fiddle to have the current and most recent update for each release: https://tracker.adobe.com/#/view/CF-4205388. Hope folks will add votes for each.
After applying the HF 12 on my Coldfusion 2016 Solaris server running Apache, my devs are complaining of webpage not available.
I am seeing the below in my apache error log every few seconds.
AH00051: child pid xxxxx exit signal Segmentation fault (11), possible coredump in /usr/apache2/2.4
Hi alkane7354022,
Can you send me the connector log (mod_jk.log file present in [CF Home]/config/wsconfig/[Magic folder for your connector]) to bihani@adobe.com?
Thanks,
Kailash
Alkane or Kailash, did this ever get resolved with Alkane?
After applying the HF 12 on my Coldfusion 2016 Solaris server running Apache, my devs are complaining of webpage not available.
I am seeing the below in my apache error log every few seconds.
AH00051: child pid xxxxx exit signal Segmentation fault (11), possible coredump in /usr/apache2/2.4
After apply the HF12 on my Coldfusion 2016 on Solaris server, keep getting the message in my Apache error log every few seconds. “AH00051: child pid xxxx exit signal Segmentation fault (11), possible coredump in /usr/apache2/2.4”. Devs keep getting issue accessing the sites.
I am running Apache on Solaris, keeping getting “AH00051: child pid xxxxx exit signal Segmentation fault (11), possible coredump in /usr/apache2/2.4” every few seconds.
Do I use the mod_jk.so file inside the Solaris folder offered in the dropbox?
We are seeing serious problems with CF 2016.12, see this bug report:
https://tracker.adobe.com/#/view/CF-4205347
We had to downgrade to 2016.11 again, as this bug affected many of our applications.
I was getting the following error in ColdFusion->config->wsconfig->#->isapi_redirect.txt prior to replacing the isapi_redirect.dll uploaded to Bihani. It works now, but maybe we could get away from a connector completely in future releases?
[Sun Sep 29 11:51:57.959 2019] [8700:916] [warn] jk_check_for_path_attack::jk_util.c (2457): Path attack using [/]
Hi Rebecca,
We have a patched isapi_redirect.dll which you can use.
Its placed in: https://www.dropbox.com/sh/q2hv32vuw25oiho/AADpPdNBKC82IXXIxBM60m-ya?dl=0
Please let me know if this solves your issue.
- You need to goto [CF Home]\config\wsconfig\[Magic folder for your connector]
- Make a copy of the isapi_redirect.dll file
- Replace it with the one I shared in the dropbox link
- Restart the Application Pool for your IIS website
Thanks,
Kailash
I was getting the following error in \ColdFusion\config\wsconfig\#\isapi_redirect prior to replacing the isapi_redirect.dll uploaded to Bihani. It works not, but maybe we could bet away from a connector completely?
I’m also not sure about some of the errors mentioned here. Obviously the <cfoutput> using a query would be bad. Test much?
[Sun Sep 29 11:51:57.959 2019] [8700:916] [warn] jk_check_for_path_attack::jk_util.c (2457): Path attack using [/]
Hello Kailash,
Thank you very much for the updated isapi_redirect.dll. I apologize for my slow response. We have been testing this update and so far we have not experienced any of the same issues with false positive “Path attack” being detected / 404 pages being served. I will let you know if we experience any more issues.
After applying the HF 12 on my Coldfusion 2016 Solaris server running Apache, my devs are complaining of webpage not available.
I am seeing the below in my apache error log every few seconds.
AH00051: child pid xxxxx exit signal Segmentation fault (11), possible coredump in /usr/apache2/2.4
Is it the same issue?
Michael and Tighe, Adobe has put the connector updates on Adobe servers, since the old replies you are referring to. See the post of last month:
https://coldfusion.adobe.com/2019/10/error-accessing-coldfusion-administrator-using-connector-port/
While the title of the post may make it seem not to apply, it has connector updates that have helped folks with other issues. Let us know if they may work for you.
Because the comments are moderated, I suspect Tighe repeated this question if it didn’t seem to appear. But it does appear below, and there were answers offered there for this question. (Sadly, I find no way to link to another comment, or I would offer that.)
What I want to understand is why Charlie still promotes the isapi connector for IIS over using the ARR server proxy for IIS to Tomcat’s non-blocking httpIO connector?
Lastly, who dumps updates onto a production server so early without testing in a labratory setting?
“Promote” it? I just pass along info about it, since it’s what Adobe recommends/supports and most will use.
Yes, one can proxy to the built-in web server, and in more ways than ARR, and from more than IIS, as you may know. Some may prefer as well the Boncode IIS-Tomcat connector.
That said, besides the fact that the CF/Tomcat ajp connector is what Adobe provides and supports (and “promotes”), we should acknowledge that there are aspects of processing by that connector which provide long~standing CF features (that some may unknowingly be relying on), which is why Adobe modifies the connector as provided by Tomcat.
There were calls from the community back in cf10 (when cf switched to running on tomcat) to have Adobe clarify what it is that they change, why, and to give us what features. Sadly, that never happened.
If we could know, then yes, people could make an informed decision among the options–and might even get more benefits (than features lost) by switching to such other proxying, and even in switching web servers (such as to nginx).
FWIW, there was also a short term effort in 2016/7 where Adobe provided an AJP connector for nginx, but it never took off. I suspect nginx users were satisfied with just proxying to cf’s built in web server, which is in fact the Tomcat web server (coyote).
Heck, I have blogged in the past about how some may even regard the built-in web server alone as capable–though barely. Again, it is the Tomcat web server, not something Adobe created. (Back in CF 6-9, the JRun web server that served as the built-in web server for CF was of course something Adobe maintained, until they didn’t.) Anyway, the CF built-in/Tomcat web server does lack many features of a “real web server”, but my point in the post was that it was more than just a “development” web server the way the JRun web server was. That said, it’s not the best option.
So to theBLBDan, there you have the full answer about web server connectors, and why I tend to just address use of the CF connector since it’s the default position for most. Many don’t want to bother considering all their options, weighing the pros and cons.
But certainly there are enough challenges with the CF web connector (from the seeming issue with this update’s version, to the need for most to “tune” it–though yes CF2018’s PMT offers an option to “auto-tune” it) to make it more and more likely that people will be considering those options. You’ve presented one, I’ve offered a few more.
Really, this topic is worthy of a blog post on its own. I am taking note of this as a possibility, but can’t do it right now. If I did, I’d want to include more on HOW to use these other options (whether showing it or pointing to resources that do). Now’s just not a good time for me, with the run up to CF Summit and then CF Camp. If someone else does, feel free to post a link as a reply here.
Charlie,
I really appreciate the long and well thought out response. I’ve been neck deep in CF since Alaire’s 4.5. I just recently retired a JRun instance. I’ve been a long time follower of your (and others’) input and appreciate the time you’ve invested into the CF community, so please do not take it as a personal attack. I rather enjoyed seeing just how much of a response it elicited.
I’ve tried the BonCode connector and it helped out a bit, but not enough. In fact, it was from reading your blog posts or comments on Adobe pages like these that helped nudge me into leveraging TomCat’s Http11Nio to my advantage, which is why I even brought it up. I use it strictly as a reverse proxy style connector and let nginx or IIS do the real web service work. Agreeably, TomCat isn’t feature rich as a pure stand-alone web service.
“Really, this topic is worthy of a blog post on its own” <== Agreed, and I think that, honestly, Adobe should own that responsibility. The AJP connector is fine, but we ran into unbearable problems with it; the cause of repeated IIS application pool crashes. Many site owners may never discover these limitations, but for site administrators that need to know, the information seems to be a well hidden secret. Adobe needs to let its customer know that there are options, what they are, and where to learn about them.
We have found out that CF 2016 Update 12 on Windows Server returns nesting errors in cases where CF 2016 Update 11 and lower does not. https://tracker.adobe.com/#/view/CF-4205257
We have found out that CF 2016 Update 12 on Windows Server returns nesting errors in cases where CF 2016 Update 11 and lower does not.
The error occurs on line 15 in our example functions.cfc file (code listed farther below). The error message is:
Invalid tag nesting configuration. A query driven queryloop tag is nested inside a queryloop tag that also has a query attribute. This is not allowed. Nesting these tags implies that you want to use grouped processing. However, only the top-level tag can specify the query that drives the processing.
Our example code consist of two files. An index.cfm and a functions.cfc file that both exist in the same directory. There are no other files in the directory.
INDEX.CFM CODE:
<!— this is simulating a query I would generate from our db —>
<cfset variables.testQuery = QueryNew(“data”,”integer”)>
<cfloop index=”variables.i” from=”1″ to=”100″>
<cfset queryAddRow(variables.testQuery)>
<cfset querySetCell(variables.testQuery,”data”,variables.i)>
</cfloop>
<cfset variables.functions = new functions()>
<cfoutput query=”variables.testQuery”>
<cfset variables.foundNumber = variables.functions.dummyFunction(VAL(variables.testQuery.data))>
#variables.testQuery.data#<br>
</cfoutput>
FUNCTIONS.CFC CODE
<cfcomponent>
<cffunction name=”dummyFunction” returnType=”numeric” access=”remote” returnformat=”plain”>
<cfargument name=”userNumber” type=”numeric” default=”0″>
<!— this is simulating a query I would generate from our db —>
<cfset local.testQuery = QueryNew(“data”,”integer”)>
<cfloop index=”local.i” from=”1″ to=”100″>
<cfset queryAddRow(local.testQuery)>
<cfset querySetCell(local.testQuery,”data”,randRange(1,100))>
</cfloop>
<cfset local.foundNumber = 0>
<cfoutput query=”local.testQuery”>
<cfif VAL(local.testQuery.data) EQ VAL(arguments.userNumber)>
<cfset local.foundNumber = 1>
</cfif>
</cfoutput>
<cfreturn VAL(local.foundNumber)>
</cffunction>
</cfcomponent>
Here’s another problem I am hearing from clients, after applying this update:
Suddenly code breaks if you do a cfoutput query loop in a file called (as a cfc or cfinclude) by another file that has an open cfoutput when that nested file is called. The error is:
“A query driven queryloop tag is nested inside a queryloop tag that also has a query attribute. This is not allowed. Nesting these tags implies that you want to use grouped processing. However, only the top-level tag can specify the query that drives the processing.”
One solution of course could be to to change cfoutput query loop to be a cfloop inside of a cfoutput instead, but that’s annoying.
Clearly, though, this is a bug. And one of my clients has opened a bug report today. Go add your vote if it happens to you:
I want to share here publicly that I have had a couple of clients report to me that they had severe problems when they did this update AND updated the web server connector. To be clear, the update technote indicates that the connector is updated and that one should to do that next step of updating the connector after applying the update.
Perhaps it’s a mixed blessing that many don’t notice the need to do that and so have not. But if you have, and are experiencing 404s, the folks I’ve talked to or worked with have reverted back to the previous connector (in the case of IIS, the isapi_redirect.dll), and restarted the web server (in their cases IIS), and the problem went away. Of course, it means they have an outdated connector, but at least they have a functioning site. (More on Apache in a moment.)
This has happened before. Perhaps Adobe will be hearing from folks via their support channels, and maybe they will issue either a new connector or a new update. (In Feb 2019 they pulled the update entirely and created a new one a week later, as its problems were so severe.)
Let me add that if you are on Apache, I don’t know if you will face the problem. You may. The connector update was not said to be limited to IIS. The file in question would be mod_jk.so.
And the connector (that .so for Apache or that .dll for IIS) is found in the numbered folders of the [cf]configwsconfig folder. Sadly, if you do the “update” feature in the wsconfig tool (new since CF2016), that does NOT take a back up of the file (like would be done if you did a remove and re-add of the connector).
As such, you may find that you don’t HAVE the previous connector to revert to. But look to see if you either have a backup folder in that [cf]configwsconfig. If so, those were again taken when you did any remove of the connector. You may find an older version there.
But this is risky, because it’s hard to tell what version (and how “old”) it really is. Someone may point out that on Windows you can right-click the file and user properties>details, to see the “file version”, but I just worked with a client who found that that number for the DLL created with the latest CF 2016 update 12 was 1.2.46.0, and SO was the version in the DLL from CF2016 update 10, but the file sizes were indeed different. And they put that one from update 10 back in place, restarted the web server (you may have to stop it first to update the file), and again the error went away. (And it would have worked with the connector from update 11, of course. They just didn’t have it.)
Again, all this is dicey stuff to be sharing here. You can get into lots of trouble trying to change such things on your own. I share this for those who are desperate and in case we don’t hear from Adobe for some time. I will add that of course I can help with doing such things (carehart.org/consulting), and I apologize to those who think it’s crass to mention that. If this were a “sales pitch” I wouldn’t have shared all I did above. If you can take the ball and run with it, great. If you’re worried about trying it, that’s understandable.
Best of all, again, if you just have not yet tried to update the connector (using the wsconfig tool after updating CF with these updates of yesterday), maybe you ought to hold off and see if others report the problem (or confirm no problem), or to see if Adobe addresses it.
I have just added a feature request for Adobe to consider adding a backup mechanism to the wsconfig “update” feature. Folks who like that idea should vote on it, and those with concerns about the idea should raise them there:
So I am having this problem with my connector after applying the update. If I refresh a page every 5th- 6th time I will get this error:
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
The requested URL was not found on this server!
If you entered the URL manually please check your spelling and try again.
Tomcat/ISAPI/isapi_redirector/1.2.46
Copyright © 1999-2018 Apache Software Foundation
All Rights Reserved
After installation of this update on CF2018 (Windows, IIS) we’re finding that the CFLOGIN attribute, allowconcurrent, seems to be ‘stuck’ on: FALSE.
According to the docs ALLOWCONCURRENT should default to: TRUE. In our applications it seems to be defaulting to FALSE. In addition, when we include ALLOWCONCURRENT=TRUE in the tag it seems to be ignored.
We are testing by logging into a site in one browser and then logging into the same site using a different web browser. Browser one is kicked out on subsequent page load.
Thankfully, we haven’t installed this on production yet. Can anyone else confirm?
Paul, you should create a bug report for this also, at tracker.adobe.com. Adobe folks may or may not respond to each comment here, but they have already responded to some bug reports filed since the update on the tracker site, so it is worth the effort. (I appreciate that you’re asking here to find if others have seen the problem. I mean that I propose you do the bug report in addition.)
Hi Paul,
Was this working in Hotfix 4 for you (the previous version of the update)?
Can you share a simplified use case if possible at bihani@adobe.com
Thanks,
Kailash
It is unclear if I need to download Java 12 and install it on the server to mitigate Security bulletin APSB19-47. If so does Coldfusion now include licensing for Java SE JDK 12? According to this page licensing extended to Java 11 (as of January).
Can you please address my questions?
I realize you will want to hear from Adobe, but until then let me offer these thoughts if they may be helpful to anyone.
First, as for your question about Java and that APSB, I suspect your referring to this: “The security updates referenced in the above Tech Notes require JDK 8u121 or higher (for ColdFusion 2016)”. That same line has been in the past few APSBs (for instance, https://helpx.adobe.com/security/products/coldfusion/apsb19-27.html).
It is referring to updates from back then (and since CF updates are cumulative and incorporate past updates, I suspect that is why it’s repeated here.) Notice also how it doesn’t refer to later Java versions, while CF2018 came out first on 10, then could run on Java 11 as of update 2, and now can run on Java 12 as of update 5.
Finally, as for the question of whether Adobe’s agreement with Oracle to let us use Java for production, again I know you need to hear from Adobe, but the reason that Jan article didn’t mention anything about Java 12 is that it had not yet come out. (That said, it would have been helpful if it had been worded to say “Java 11 and above”.)
But then since Adobe is saying in this update that Java 12 is supported, it would surely seem that they would have made it clear if that was “supported but no longer licensed”.
Again, you need to hear it from Adobe. Same with Krelek1000’s request below. I will leave it for Adobe to confirm things, but again wanted to offer this until then, for whatever it may be worth to readers.
@TigheLory, Java 12 support isn’t necessary for the security fixes to take effect. As a general recommendation, we always encourage our users to be on the latest JDK/update level. We will be adding support for JDK 13 soon, FYI.
So see this in the admin “ColdFusion 2018 Update 5 introduces support for Java 12.” Awesome, couple questions though. Which Java is required? The Open or Oracle version? Also will you continue to support the Long Term 11 version since 12 will end in a few months regardless?
The version of Java that is bundled with the CF2018 installation should suffice for the security fixes to take effect. BTW, we always certify with Oracle Java.
The latest Java installers can always be picked from the below location in case you want to move to a later version:
https://www.adobe.com/support/coldfusion/downloads.html#additionalThirdPartyInstallers
We will be adding support for Java 13 soon.
Vamsee,
Thank you for the information. I will include the link in my patching notes for my backups.
Thanks again!
Can someone from Adobe let us know how long it will be until the cffiddle.org site is updated to support these new updates? For now, it lists only the previous one (of CF2016 and 2018).
Also, it would be useful if it listed both the newest and the previous update, so that one can test when a problem seems to be due to the new update, so that a test can be made against the previous update just as easily.
I can report that the cffiddle site does now offer the latest updates, thanks. I have also asked if they might consider having both the latest and the previous update for each release, to allow people to do testing of the sort being raised in various issues on the post here.
I don’t see the comment I just posted.
Testing testing 1234.
Okay, I -assume- moderation is in effect. However, I see no UI message stating the same. So.. confusion.
I’d moderate my posts if I were me =D
Yep, Aaron. For some reason, moderation is in effect and sometimes it is days before they are approved. Grr. It seems like something that changed for some reason, and I am hopeful they will get it back to how it was before.
It can be very confusing when multiple posts on a given thread may be moderated and seem then to “step on each other” once they are all approved (since each couldn’t see what the other was writing).
I have my CF 2016 Admin site set up as a site in IIS on Windows (I am not using the built-in webserver.)
After HF 12, when I access pages on my CF Admin site they sometimes return
“The requested URL was not found on this server! If you entered the URL manually please check your spelling and try again. Tomcat/ISAPI/isapi_redirector/1.2.46”.
The isapi_redirect.log contains entries for these requests such as
“[warn] jk_check_for_path_attack::jk_util.c (2457): Path attack using [/CFIDE/Administrator/enter.cfm]”
and
“[warn] jk_check_for_path_attack::jk_util.c (2457): Path attack using [/CFIDE/Administrator/images/arrow_opened.png]”
This issue is affecting both CF pages and static content (such as images). The issue is not entirely consistent; repeating the request multiple times will sometimes succeed in loading the requested element.
My previous HF level was 11. I performed the HF 12 installation manually and it reported success. I then used the Webserver Configuration Tool to update the isapi_redirect.dll for each site’s wsconfig, after which I restarted the server. I have not yet seen this issue occur with the other IIS CF websites on the server, only the CF Admin one.
Rebecca, that’s an odd one. As you may have found yourself, there is no reference on google to “jk_check_for_path_attack”, and none related to CF or Tomcat (or jakarta) referring to the phrase in the error, “Path attack using”. So whatever you are experiencing, it is indeed new and unique.
The question now is whether it’s new to the update (and so affecting potentially anyone using the update), or unique only to you (if something is amiss specifically on your end.)
I will note first that it’s good to see that you acknowledge that you did the connector update. Many miss the need to do that (indicated in the technote, though not in the post above) and so don’t bother to do it. The converse is that because many DO miss it, they may not experience the same problem, if it IS new to that updated connector somehow–and that could be why we don’t see (yet) others reporting it.
While we wait for that or any word from Adobe, you can check a couple of things. First, do make sure there were no errors during the applying of your CF update. See my blog post with details on how to do that, and how to deal with any errors:
https://coldfusion.adobe.com/2019/03/problems-applying-cf-update-check-first/
Another thing is to note that of course you CAN access the CF Admin via the built-in web server (port 8500, by default). That is always enabled in CF2016 and above, by default. In fact, accessing the CF Admin via IIS or Apache is in fact disabled by default. You had to take some extra steps to enable that.
Opening the Admin on the external web server opens it up to access from anyone. Are you saying you took extra precautions in the web server to protect it? And are you saying that your challenge is needing to access the Admin from off the server itself (perhaps because a firewall would by default block port 8500), and that’s why you can’t access it using the built-in web server? And that opening it to the external web server was deemed better than opening your firewall to allow access to port 8500? Just questions, not judgments. And offered as much to help others who may read this and find themselves in your situation.
Of course, we will want to get to the bottom of the errors you see. For now, it’s a new one, so I have nothing more I can offer. I hope Adobe or someone else may.
Adding to Charlie’s reply, you must update the connector after updating to Update 5 or Update 12.
We are seeing similar behavior on IIS 7.5 after installing Update 12 and updating the connector for each individual site, with pages occasionally returning 404s. From my quick checks, it is happening for 5-10% of page loads.
Reverting to the isapi_redirect.dll files from Update 8 and cyling IIS resolved the problem.
Any suggested fixes Adobe?
Hi Rebecca,
From ColdFusion 2016 onwards, we don’t recommend using the ColdFusion Administrator via the webserver. The same is specified in the Lockdown Guide too.
Are you facing the error when you try to access a particular page of ColdFusion Administrator? Or is it happening for all the pages? Can you send us your isapi_redirect.log present in [CF Home]\config\wsconfig directory? You can send it with some details about the issue to cfinstal@adobe.com.
Thanks,
Kailash
Hi Rebecca,
From ColdFusion 2016 onwards, we don’t recommend accessing the ColdFusion Administrator using the webserver. The same is specified in the Lockdown Guide too
Are you facing the issue only while accessing a particular page of the Administrator, or is it happening randomly? Also, can you share your isapi_redirect.log file located at [CF Home]\config\wsconfig\[Connector folder]?
You can share it at cfinstal@adobe.com along with some details about the issue you are facing
Thanks,
Kailash
Hi Charlie,
Thanks very much for your reply and the link to your blog post. I’ve checked the installation log and it reports no errors:
Installation: Successful.
2773 Successes
0 Warnings
0 NonFatalErrors
0 FatalErrors
I went through the HF12 install again on another machine and it had the same successful install and issues with false positive path attacks on the CF Admin site as the first (not surprising as it was configured exactly the same as the first server.)
Good point that using IIS to host the CF Admin site is both not the default and as Kailash mentioned, no longer the recommended configuration in the Lockdown Guide for 2016 (although it is still covered there as an option). I got started with CF9 when it was recommended by the Lockdown Guide for Windows installations, and still prefer to use IIS as we can leverage Windows authentication to control access to the CF Admin site & the IIS logs for the CF Admin site will contain the authenticated AD user account. Although we’re hosting the site with IIS, it is bound only to the localhost and is not externally accessible (an important point for anyone else reading this that may also want to use IIS to host it.)
Ruby Zindler mentioned that there was a CF administrator vulnerability and the security bulletin refers to a “Path Traversal Vulnerability” that was fixed, so that certainly makes me curious if my issue is related to the fix for that vulnerability returning false positives. It is interesting that it is somewhat random, as I can request the same page 5 times and get four HTTP 404 “Path attack” results and one HTTP 200 successful serve without altering anything (same session, cookies, referrer, etc.)
Hi Kailash,
It is happening randomly on all resources on the CF Admin site, both pages and other resources such as images. I will send the isapi_redirect.log, thank you.
For anyone else experiencing this issue, our settings are:
Windows 2012 R2 64bit / IIS 8.5
ColdFusion 2016 HF 12, Standard Edition
Java 11.0.4
And the installation steps I took:
– verified the MD5 hash on hotfix-012-315717.jar
– stopped the CF service
– backed up the \ColdFusion2016\config\wsconfig\ folder contents
– removed any previous .jar files from \ColdFusion2016\cfusion\hf-updates\ and moved hotfix-012-315717.jar there
– Used Java from the \ColdFusion2016\jre\bin folder to run \ColdFusion2016\cfusion\hf-updates\hotfix-012-315717.jar
– After successful install, ran the Web Connector update for each site, then went into each \ColdFusion2016\wsconfig\ subfolder to confirm the .dll for each site was updated. No other files (such as isapi_redirect.properties) were updated, so I did not need to use my backups to restore things such as custom log paths.
– Restarted the server
I’m experiencing this behavior as well – intermittent redirector 404 page responses.
Running on Windows 10, IIS 10, 2 instance cluster, localhost site.
URL Call – http://localhost/
IIS Default Document index.htm, index.cfm
index.htm in wwwroot with IIS redirect to login.cfm
Every 3rd or 4th-ish call to http://localhost/ results in:
The requested URL was not found on this server!
If you entered the URL manually please check your spelling and try again.
Tomcat/ISAPI/isapi_redirector/1.2.46
Connector Log Info:
[Wed Sep 25 14:05:25.969 2019] [21652:17196] [warn] jk_check_for_path_attack::jk_util.c (2457): Path attack using [/]
Connector Log Debug:
[Wed Sep 25 14:29:55.050 2019] [15168:6940] [debug] jk_servlet_normalize::jk_util.c (2295): URI on entering jk_servlet_normalize: [/]
[Wed Sep 25 14:29:55.051 2019] [15168:6940] [debug] jk_servlet_normalize::jk_util.c (2389): URI on exiting jk_servlet_normalize: [/]
[Wed Sep 25 14:29:55.052 2019] [15168:6940] [debug] jk_check_for_path_attack::jk_util.c (2445): Original URI: [/]
[Wed Sep 25 14:29:55.053 2019] [15168:6940] [debug] jk_check_for_path_attack::jk_util.c (2446): Normalized Clean URI: [/]
[Wed Sep 25 14:29:55.054 2019] [15168:6940] [debug] jk_starts_with_prefix::jk_util.c (2416): In prefix method [/]
[Wed Sep 25 14:29:55.055 2019] [15168:6940] [debug] str_lower::jk_util.c (2401): In str_lower [/cfide] [a]
[Wed Sep 25 14:29:55.056 2019] [15168:6940] [debug] str_lower::jk_util.c (2401): In str_lower [/] [/cfide]
[Wed Sep 25 14:29:55.057 2019] [15168:6940] [debug] str_lower::jk_util.c (2401): In str_lower [/] [/cfide]
[Wed Sep 25 14:29:55.057 2019] [15168:6940] [debug] str_lower::jk_util.c (2401): In str_lower [/] [/]
[Wed Sep 25 14:29:55.058 2019] [15168:6940] [warn] jk_check_for_path_attack::jk_util.c (2457): Path attack using [/]
I hope one of you with the above issues will open a bug report, at tracker.adobe.com. That’s the location of record for bugs. We can HOPE that Adobe folks will see these comments and address them, but filing a bug report is always the best best. (They have already responded to some of the other issues with this update, which have been reported there, so it’s not a waste of effort.)
Hi Brian,
We have a patched isapi_redirect.dll which you can use.
Its placed in: https://www.dropbox.com/sh/q2hv32vuw25oiho/AADpPdNBKC82IXXIxBM60m-ya?dl=0
Please let me know if this solves your issue.
- You need to goto [CF Home]\config\wsconfig\[Magic folder for your connector]
- Make a copy of the isapi_redirect.dll file
- Replace it with the one I shared in the dropbox link
- Restart the Application Pool for your IIS website
Thanks,
Kailash
Kailash, thanks for your link. Is this the official Adobe fix for the 404 issue? If so, it would be great if someone from Adobe could acknowledge this in the bug reports CF-4205361 or CF-4205252 by resolving those issues and commenting on how the fix will be distributed to users.
Ruby,
It does. Please check the security bulletin- https://helpx.adobe.com/security/products/coldfusion/apsb19-47.html
Wow, that’s a lot of “new” and “changed” things for this update. Folks should definitely check out the technote for more details.
But note that this is the first time ever that one CF update had such a mandatory requirement that the prior update be installed first. Can anyone explain why this is so? It really makes this one uniquely challenging (for this update and any future ones where people may come from CF2018 update 3 or earlier, or CF2016 update 10 or earlier).
It would really help to know WHY this is uniquely required this time. (I see nothing about that in the cf2018 update 5 technote, nor the bugs fixed or sec bulletin, nor in the release notes doc for all cf2018 updates, https://helpx.adobe.com/coldfusion/kb/coldfusion-2018-update-5.html).
Note from Priyank @Adobe:
Important Note for update: If you are downloading the update from ColdFusion administrator and the server update level below update 11 for ColdFusion 2016 and update 4 for ColdFusion 2018, then it will not allow you to download the update. You will get signature Verification Failed error. There was a change in our certificate and we updated that certificate in update 4 and update 11 respectively.
@Charlie, there was a mandatory code change we had to implement with regards to update download/install workflow. This code change was pushed in the 2018U11 and 2018U4 and would take effect from this update and upwards. If a user is not on the minimum update level and tries to apply the update, he/she would get a Signature Verification Failed error.
Thanks, Ben and Vamsee.
Does this update address the CF Admin vulnerability that was discovered earlier this month (/index.cfm/..;/CFIDE/administrator/index.cfm)? I didn’t see any mention of it in the release notes.
If not, is there an official fix for it?
Ruby,
It does. The details, among others, are listed in https://helpx.adobe.com/security/products/coldfusion/apsb19-47.html
Thanks,
Saurav
Ruby,
It does. Please check the security bulletin- https://helpx.adobe.com/security/products/coldfusion/apsb19-47.html
Does this update address the CF administrator vulnerability identified earlier this month (/index.cfm/..;/CFIDE/administrator/index.cfm)? If not, is there an official fix for it?
Yes it does.
23 Nov
10AM Pacific
Online