Tuesday, March 8, 2011

Update on Security Hot-Fix Feb 2011

There is an update on Security Hot-Fix released in Feb 2011.

List of issues addressed are as follows:

  1. Session is lost for an application accessed within same domain *.
  2. Formatting problem for ResponseTime table on debug template.
  3. A minor fix for CFIDE/wizards/common/_logintowizard.cfm

With Session Fixation vulnerability attacker fixate (set) another person's session identifier (SID) and, once the user authenticates, the attacker has access to the authenticated session.

In ColdFusion's affected versions,any given CFID/CFTOKEN values of ColdFusion Session identifiers was used to create a new session. After the fix for the same, Applications being accessed with in same domain and having client cookie based session Management enabled started mis-functioning. This happened as the cookie was overwritten by later application when accessed in same browser.

With the current update to the patch, all above problems are fixed. ColdFusion will still accept such tokens but after validations.

In case someone still wants to completely swtich off the fix for Session Fixation issue  they can add the following JVM property –Dcoldfusion.session.protectfixation=false in the JVM Arguments for the Coldfusion Server.

Latest hotfixes containing the fixes for the above issues are updated in the technote. Instructions to apply the hotfix remain same. All the users should re-apply the hotfixes if they have applied it already. Security Bulletin can be found here.


  1. Shilpi, this update to the HotFix has not solved our problem. As soon as we applied the new version of the HF the same reports of lost sessions started coming in (see comments on your previous post).

    Rather than rolling back we added the JVM argument to switch off the Session Fixation fix, and this stopped the problem, but still leaves us vulnerable.

  2. Hi Julian,

    Can you please help us with some more details from logs about this error. Also some scenarios if there is anything particular. I would also request you if you can raise a bug.

  3. Julian,
    Another thing, Does your application pass CFID/CFTOKEN values in FORM instead of using Cookies for Session?

  4. I can also confirm this is still an issue.

    See me post here:


  5. Hi Shilpi,

    I'm not sure what log details I can give you as there are no server errors - just intermittent behaviour in client browsers. If you can tell me what to log I'm happy to try.

    I have already raised a bug report: http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html#bugId=86494

    None of our apps use FORM or URL to pass CFID/TOKEN. We always use cookies which we set ourselves using cfcookie (with the domain/path attributes as you advised).


  6. Hi Julian,

    Thanks a lot for raising the issue.
    So here is what I would request. If you have re-applied the latest update released on 7th March for Security Hot-fix, if you can try removing the domain/path fix which I suggested, as that was just a temporary solution till we could release the update on Security Hot-fix.

    If still the problem persists, please confirm.

  7. 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 -

    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.

    ColdFusion Team

  8. Julian,

    I request you as well to check/test if the Cookie writing code has a similar blocking condition.


  9. Shilpi, I think I've identified the problem from what you say.

    Prior to the HotFix, when starting a new session ColdFusion would only create new CFID/CFTOKEN values if none already existed in the browser's cookies. If it found cookies from an expired session, then it would use them for the new session.

    This meant that it was not necessary to write new cookies if they already existed, hence the conditional widely used when manually setting session cookies.

    With this HotFix, it seems that ColdFusion will create new CFID/CFTOKEN values to link up a new session REGARDLESS of whether any cookies already exist.

    So with the HotFix applied, if CFID/CFTOKEN cookies exist in the browser, the conditional will, as you say, prevent the new session keys being written, and the session will be lost on the next request.

    This seems to be a critical change of behaviour that is clearly breaking apps. Is it absolutely necessary to fix the Fixation vulnerability?

    I've written a tiny app which demonstrates the changed behaviour: I'll try and write it up as a blog post later on.

  10. Prior to the February hotfix, are there any other bugs that would cause sessions to be dropped? We have experienced this for a while and it's very random. Thanks.

  11. Hi Gary,

    Prior to Feb Hot-fix, there were no such issues. Can you please share if there is any pattern you know of?


  12. Shilpi, I posted a comment here yesterday, but it didn't appear. Tried again but it still hasn't. Hoping this one will.

    I think I understand the issue now. Basically the session fixation patch changes the way CF generates session IDs which will impact on anyone using a widely used technique for creating session-only cookies.

    I've written a blog post with details:


  13. Hi Julian,

    Thanks a lot for confirming. So means the issue is fixed now?

    Yes, with the patch, CF has a different approach to handle session tokens and to generate new ones as well. Hence people not using default client cookie management or setting cookies at their own, might have to revisit the code for the same.

    ColdFusion Team

  14. Shilpi, we've only switched on the protection again in the last hour having had to go through all our code base first, and being Friday there aren't so many people at work to verify. But I'm pretty confident this is the solution. Testing locally has certainly confirmed it.

    It explains the intermittence: if you opened your browser and logged in you wouldn't have had any problem because the cookie would be new. But if you've had your browser open for a while and are logging in for the second time, then the old cookie would have been used with the wrong session ID.

    I'll confirm definitively once we're sure.

    I think it would be good if Adobe could document this in some way as it's sure to catch quite a few of your customers out. Setting session-only cookies is a known good practice and to do this in CF you have to turn off the default cookie management and set your own (unless you use JSessions of course, but we and I'm sure many others don't).


  15. Hi Julian,

    Thanks a lot. Your blog entry was quite descriptive. We will wait for your confirmation and then update the bug logged.

    Also we will take this input and see how we can make this better for customers to have session-only session cookies.


  16. Hi Shilpi

    It's been nearly 3 days since we turned on the Session Fixation protection and we've not had a single report, so I think it's safe to confirm the problem as resolved.

    Thanks for considering making things easier if possible, but I think you perhaps just need to communicate the impact of the change more clearly. It's still possible to set session-only cookies, but the code for doing so needs to take account of this change in the way CF creates sessions.

    Best wishes

  17. Hey Julian,

    Thanks a lot for confirming and feedback.


  18. Shilpi,

    Any update on the issue with this update breaking CF administrator on an 8.0.1 install?

    I get "ESAPIUTILS is undefined in a Java object" on line 30 of the login.cfm template.

  19. Daemon, I think i missed out on this comment. Are you still facing an issue? My apologies for missing this one.

  20. Hi Shilpi

    We are experiencing a serious issue with losing session cookies on our site www.insead.edu and we have multiple applications running under this URL.

    The main URL has an application.cfm

    Subsequent applications have their own application.cfm

    I have been reading your and Julian blog and is looking for a final conclusion on the fix we needed to make.

  21. Hi Thomas,

    I would need some more information to help you on this issue. Is it possible for you to check if certain pieces of code which were discussed above? Also which version of CF you are using?



You can subscribe to the comments by licking on "Subscribe by email".