What is this about? and why is it important? Read on below, as the document itself and current links from Adobe don't quite convey its significance, I think. For more perspective, I discuss below both what has happened to many folks after applying ColdFusion security hotfixes in recent years, and how this document helps.
Update: If you may prefer to listen/watch rather than read, I did a video for this in the Adobe CF channel on YouTube. Watch the 6-minute video.
The problems caused by certain hotfixes, as security holes were closed
Have you perhaps found your ColdFusion 9 or 10 apps broken after applying one or more recent CF security fixes? I mean, has certain specific functionality on some pages suddenly "broken"? Like do you find that people can't submit certain forms? or users can't stay logged in?
(If instead all of CF is failing, or the CF Admin is failing, that could instead be because of a mis-application of the hotfixes, or updating of the wrong directories. That's a separate problem entirely, which I discuss in another blog entry, CF911: Are you finding CF (or CF Admin) busted after applying a hotfix? A few possible reasons.)
But what often happens after applying some of the security hotfixes is that certain particular pages break. The issue is that a given security hole in CF was closed by the given security hotfix. And while the goal from Adobe was to close that hole to block bad guys causing problems, sometimes your existing code could be ill-affected.
Maybe your code was doing something inadvertent, or intentional, that was working before but now breaks because of the hole closed by the hotfix.
Why is this document important and so very much needed?
Now, the good news is that Adobe did report in the technote for each security hotfix a set of notes if that specific hotfix introduced such a breaking change, and they showed you how you could "undo" that one protection, if needed.
The problem is that they generally only documented it in the one technote that added the protection! So if you applied a later hotfix (which was cumulative, and WOULD include the earlier ones), it was then incumbent upon you to go back and review all the previous security hotfix technotes to find all these little "notes"--which hardly anyone ever did!
So this new single document listing all the notes in one place makes it possible to find them all in one place, to refer to when (or after) applying one of the later hotfixes. That's why I think it's required reading.
Some examples of what I mean, and why they're critical to understand
For instance, that issue of forms suddenly breaking was generally caused by APSB12-06, from March 2012. In that fix (as explained in its technote) Adobe closed a vulnerability where bad guys could post lots of form fields causing a security breach. What the fix did was limit CF pages to being able to accept only 100 form fields at most.
While that was a helpful protection, it broke your code if it intentionally (or inadvertently) posted more than 100 form fields. (You may say, "who would do that?", but people did, and their apps broke.)
So when Adobe introduced the fix, they also documented (in that technote for APBB12-06) that they'd added a new postParametersLimit XML entry which you could put in the neo-runtime.xml file, to raise the limit. (Thankfully, in CF10, it can be raised in the CF Admin.) They did mention it one more time, in APSB12-26, but not again.
So if you applied one of the later hotfixes, you'd never have known about this change and the "tweak" to undo it if needed, unless you went back and reviewed each hotfix. Again, who did that?
Another example that frequently tripped up some folks
Another prominent examples was the "session fixation" protection that was introduced in APSB11-04, from Feb 2011.
Some people found after applying this hotfix (or one of the later ones which, being cumulative, included it) that with some (or all) their CF apps, users started "losing their sessions". They'd log in, and then click a link and find they were "logged out". The problem had to do with a change in the cookies that CF creates (CFID/CFTOKEN, or JSessionID if using CF's "J2EE sessions" feature).
But Adobe had anticipated that problem, an din the technote for that hotfix, they explained (only briefly) in a note near the top that they had added a new JVM arg, -Dcoldfusion.session.protectfixation="false", which could "undo" that protection.
Granted, doing that opened up that specific vulnerability again, but for some people it was more important to get their app running again after applying the hotfix (which of course fixed other things as well, so they didn't just want to back out the whole hotfix.)
But if you missed that technote, and applied a later one and didn't go back to read the earlier ones, you might never have known of this option--unless someone else who DID know about it perhaps connected the dots for you, whether in a mailing list, forum, or on twitter.
But again, you can see why I so value this new single document. And there are about a dozen such "notes" that are gathered from several security hotfix technotes into this one new document.
So glad to see this finally done
This sort of a single document listing all such possibly needed "tweaks" for each security hotfix is in fact something that I've lamented the need of for a couple of years, as I would help people solving such problems in CF server troubleshooting consulting practice and would point out these various tweaks as needed.
And I'd been been meaning to create just such a list them all myself. I'd done the analysis of all the past technotes rather recently, but I've just been so busy that I'd not yet gotten to it.
So I really want to spread the word about this new Adobe document.
Some opportunities for improvement
All my glowing praise aside, there are a couple of opportunities for improvement regarding this document (and its promotion).
For one thing, it's easily missed for now. As far as I can find, it's linked to ONLY from the the latest security fix (APSB13-13), in the technote for APSB13-13.
And even there, it's listed as a relatively subtle "point 2", which I think some readers would easily miss, especially if they might get in a habit of looking for only certain specific information in each hotfix technote, like the "steps to follow". (Indeed, I think some folks who may have read the original technotes for the hotfixes above may also have missed these "notes" there as well.)
Perhaps they could make more prominent the comment pointing to the document. Indeed, hopefully they will link to the document in all future hotfix technotes, and can make it more prominent there too. And of course I really hope they keep it updated!
One thing missing, I think
Indeed, I'd argue there is just one thing missing from the document. For hotfix APSB12-25 (which applied only for CF10 on IIS), the notes on the new summary page don't indicate (as the technote for the hotfix did) that after applying that hotfix, one needed to rebuild the CF web server connector.
Again, since someone may reasonably skip to a later hotfix (and indeed, someone installing CF for the first time may jump only to the latest security hotfix at the time), they need to know that if they do implicitly implement that hotfix along with others they are skipping, that it's important that they rebuild the connector. I've seen more than a few shops tripped up by that one. (And while the recent CF10 auto hotfix page displays have reminded people of the need to rebuild the connector, again I find that many miss that. So if it was at least listed in this document, folks seeing this document would at least know about the need.)
Could stand to have more detail
Lastly, the document is quite brief. There's something to be said for brevity (fancy me saying that!) but sometimes there may be only a single sentence about a given tweak in that document, and so you need to follow the link (as offered) back to each original technote, to see if it may show more detail.
Then again, even the technote doesn't always say as much as it might. For instance, the one about session fixation (APSB11-04) does list a little more info, but even then I've never felt it was quite enough. It didn't help discuss what the problem was, and how to spot it (the cookie issue). Of course, it's a security technote, so there's always a balance about not sharing too much info that could then be used by the bad guys.
But I do fear that some people will see this new document and be inclined to feel that it could benefit from showing some more detail.
Too bad there are no comments accepted there
Sadly, there is no commenting feature on such Adobe technotes. I don't know why that is so, when we can comment on the docs, the blog entries, and more. I certainly welcome comments here.
So there you go. I hope the info above is helpful. While there was a lot to say, at least those not inclined to read all this could at least take the link to the document which i offered in my first sentence. I'm learning! :-)
Finally, please spread the word about this new Adobe document, as it would be easy for it to be lost in the shuffle.