Isn't it about time they worked out an easier patch routine. The instructions on the tech notes make my head hurt ..

"Note: CFIDE.zip and WEB-INF.zip included in the hotfix contains only part of the CFIDE and WEB-INF files. Do not rename present CFIDE or WEB-INF folders to create a backup as per the instructions. "

then later on ...

"Go to {CFIDE-HOME} and make a backup of CFIDE folder."

Unzipping sub-directories and copying files, you have to be kidding. I did it, but why not an executable installer that did the backups and file copies? I liked the addition of the uploading of the update JAR, but they need to come up with something better for these file updates, very poor.

I haven't had a chance to test this Joshua but I've shared it with other Adobe CF ACPs.

FYI, Shilpi posted a possible workaround on her blog here:
http://shilpikm.blogspot.com/2011/02/security-hot-...
The idea is to explicitely create the CFID and CFTOKEN in the directories that are using another cfapplication in order to "scope by path" the session.
I'll give this approach a try and post my findings here soon.

OK, I tried Shilpi's idea and it seems to work now!

I've set up a test where two folders have their own Application.cfc, with the following:

<cfscript>
   this.name = "#cgi.path_info#"; //this makes the app name unique
   this.applicationTimeout = createTimeSpan(0,1,0,0);
   this.clientmanagement= true;
   this.loginstorage = "session" ;
   this.sessionmanagement = true;
   this.sessiontimeout = createTimeSpan(0,1,0,0);
   this.setClientCookies = true;
   this.setDomainCookies = false;
   this.scriptProtect = "all";
</cfscript>

<cffunction name="onSessionStart" output="false">
   <cfcookie name="CFID" value="#SESSION.CFID#" domain=".#cgi.http_host#" path="#listDeleteAt(cgi.path_info,listLen(cgi.path_info,'/'),'/')#">
   <cfcookie name="CFTOKEN" value="#SESSION.CFTOKEN#" domain=".#cgi.http_host#" path="#listDeleteAt(cgi.path_info,listLen(cgi.path_info,'/'),'/')#">
</cffunction>

When you hit a page in folder_1 and then reload that same page, the SESSION.CFID and SESSION.CFTOKEN remain stable.
The you hit a page in folder_2 and you get a new CFID and CFTOKEN for that second application.
If you go back to folder_1 and reload your page, the original session vars are still there.
So far, so good.

Important note: this ties an application to its root folder: if you try to access the session variables of that application from another folder or from a subfolder, it won't work.

What a mess... This new behavior/bug introduced by the hotfix breaks code that had been running untouched for close to ten years, as well as code written last month.

We've been forced to roll back this hotfix as it's caused too much trouble. Details on Shilip's blog: http://shilpikm.blogspot.com/2011/02/security-hot-...

I've asked on a private list if we can get clarification.

Marc, Ray: any idea if the recently updated modification date means the bug-within-the-corrective-patch has been recognized and fixed?

Official word it was just a minor edit in instructions.

No - you need to ensure you log a bug and if you have a support plan I'd call it in. Be the squeaky wheel.

@Ray, not if it means our users can't log in because the fix is causing their sessions (CFID/TOKENs) to be lost between requests. And yes we have changed to cookies to domain cookies where necessary (not all our domains have multiple apps), and it made no difference: sessions were being intermittently lost. Rolling back the hotfix stopped the problem.

You're right, Raymond, should have done so before.

http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbu...

We applied the HOTFIX in questions and when NESSUS ran its regular scheduled programming, we receivied an errror. NESSES tried to navigate to: \CFIDE\wizards\common\_logintowizard.cfm page.

The following is a snippt from the error message: Element ESAPIUTILS is undefined in a Java object of type class [Ljava.lang.String;.
The error occurred on line 55.

Anyone else out there with this one?

Glad I decided to google ESAPIUTILS, and found this discussion. I got a site-wide exception notice with the same error as Mike Thomas noted. It was on our DMZ server, so it worried me. Even more so when I noticed the cfdump of Error.TagContext that my site-wide handler includes. The first item had ?? as the value for ID, and the path for TEMPLATE is C:\work\ColdFusion\cf9_u1_final_hotfix\cfusion\wwwroot\CFIDE\administrator\styles.cfm:55

There is no c:\work on my server. I would like to know how that could be. In the meantime, I decided to remove the wizards folder altogether. What is it needed for?

I just saw on http://www.petefreitag.com/item/787.cfm that the hotfix has been updated today with fixes and everyone should reapply it! Also Shilpi from the Coldfusion team has posted a blog entry about it http://shilpikm.blogspot.com/2011/03/update-on-sec...

I'm guessing the reason they added the option to completely turn off the fix for Session Fixation is just in case any other unexpected problems show up.

I can also confirm that this problem still exists. Here is the following way I was able to reproduce the problem:

I am using Application.cfm on CF 8 and have the following code in that file:


   <cfapplication
      ...
      applicationtimeout="#CreateTimeSpan(2,0,0,0)#"
      clientmanagement="false"
      sessionmanagement="true"
      sessiontimeout="#CreateTimeSpan(0,1,0,0)#"
      setclientcookies="false"
      setdomaincookies="false"
      scriptprotect="URL,CGI,COOKIE">


<!--- set more secure cookie handeling --->
   <cfif NOT IsDefined("COOKIE.CFID") OR NOT IsDefined("COOKIE.CFTOKEN")>
      <cfheader name="Set-Cookie" value="CFID=#SESSION.CFID#;path=/;HTTPOnly">
      <cfheader name="Set-Cookie" value="CFTOKEN=#SESSION.CFTOKEN#;path=/;HTTPOnly">
   </cfif>


We do this to protect our session cookies as per: http://www.petefreitag.com/item/764.cfm

When i persons session times-out, I this bug still happens and they can't login without having to delete their cookies from their browser.

-J

Hi Jay,

This is because of the following -

1. You have set setClientCookies=false
2. In the code to set Cookies, you have following condition -

<cfif NOT IsDefined("COOKIE.CFID") OR NOT IsDefined("COOKIE.CFTOKEN")>

Now if users don't delete the old cookies and with the above condition, old Cookie value will always be found and if ColdFusion does not find an active session for this request, it will start a new one. However these new values are never set to Cookies.

You can probably change the check before settings the cookies to match the value from Cookie and Session. If the values don't match, then you reset the cookie as well.

Hope this helps.

Shilpi
ColdFusion Team

We are getting the following when trying to get to the cfadmin url. this is on CF 8.0. We've reapplied the hot fix, and it was the the most recent. Any insight into how to get this fixed? Getting the same issue on certain sites when trying to login to secured areas.

java.lang.NoClassDefFoundError: Could not initialize class coldfusion.security.ESAPIUtils

@Michael Kane - were you able to find a fix for your cf9 box?

I am attempting to run the 8.0.1 updater for my Cf installation.
After the update (multiserver) occurs, websites seem to work fine, but I am unable to get to the cf administrator interface.
Just a blank screen shows up.
When I view source on the blank page, I see this root cause listed: applet error.
Element ESAPIUTILS is undefined in a Java object of type class
If anyone has any assistance they can offer, please let me know. I need to get this update and subsequent hot fixes in place before 8/19 (pci check).
The 8.0.0 security hot fix broke my cfgrid from displaying correctly. Worked great before that.
current update level I'm at:
Update Level /C:/JRun4/servers/cfusion/cfusion-ear/cfusion-war/WEB-INF/cfusion/lib/updates/hf800-00002.jar

Yes, posted there also, waiting on some type of response.
As several people posted here, the documentation is lacking a bit. Would be nice if they would just create an upgrade file that really did the upgrade.
I have a cf8 installation, but see at this post, http://www.forta.com/blog/index.cfm/2011/6/14/Cold...,
that even on cf9 installations, the hot fixes busted up the admin interface.
thanks for the response.

I have the same problem. This security update has totally broken the admin interface on a vanilla CF 8.0.1 install.
java.lang.ClassNotFoundException: coldfusion.security.ESAPIUtils

@Lisa: I do agree, it could be better. Just saying it's (eventually) going to get there.

Hi Lisa,Paul,James,

Can you please confirm at what location the hf jar is placed and also in "<cfserver-home>/lib/updates" which all files are present?

We at not seeing this error at our end.

Thanks & Regards,
Shilpi

Thanks a lot for confirming James. We will verify this on our end.

I thought this had been corrected. Your quickest bet is to call Support. I'm checking internally. I see a set of comments from folks when this first came out, which is why I thought it had been corrected already.

Ray, I wish there was more clarity about the hotfixes. Actually, make that the entire install/update process. I upgraded a production CF 8 server a few days ago, and had major problems. It seems that Hotfix 2 broke the install. I had to completely uninstall CF, then install 9.0.0, update to 9.0.1, and left it there until I get time to figure out the problem.

Same problem here with losing access to the Administrator after simple upgrade to 8.0.1 from Coldfusion 8. Coldfusion pages are still loading and working nicely. Has anyone solved this yet? The only hotfix I have applied is hf800-00002.jar which was applied prior to the upgrade. Thanks!

I had the same CF Admin blank screen and in the console found that I had the "Element ESAPIUTILS is undefined" error.

Before this 9.0.1 updater we also had this problem. Someone had fouled up the hotfixes from 9.0 and I reapplied them in the correct order and it was fixed.

After the 9.0.1 updater, the problem resurfaced. So I applied ColdFusion 9.0.1 Cumulative Hotfix 2 (CHF2).

Note that you can skip steps 2-5 in the hotfix instructions and just drop the hotfix jar file directly into {ColdFusion-Home}/lib/updates folder. If you have the admin blank screen problem, you don't really have a choice.

Viewed the response headers in Firebug, it shows 500 Instantiation Exception. So it looks like it might be the same thing. I'll keep trying

Hi Jon, apart from the patch file from hotfix #2, I have the ColdFusion_update_901_WWEJ_linux64.bin file from the update to 9.0.1. I've identified the error to being the "missing" ESAPI class. I added [cf_root]/lib to the class paths in jvm.config, thinking that might have been it, but it still throws the error. I did notice that the esapi jar file ends with _rc10.jar, which means to me that it's a release candidate and not the final file. Is it possible that that file needs to be renamed?

Thanks for the feedback

Mike

Just want to throw out a lifeline to all the people reporting that things broke once they applied one of the hotfixes (notice that different people are reporting the same or different problems after applying different hotfixes).

In my experience (providing CF support to folks as an independent consultant), most such problems are caused by one of 3 mistakes that can be easily made while applying hotfixes. I don't say this to embarrass anyone, but just to say it's not hard to make the mistakes.

I discuss them in more detail here: http://www.carehart.org/blog/client/index.cfm/2011...

But certainly if anyone has a different solution they may have found to resolve the problems, many will certainly want to hear.

Hope that's helpful.