Note: This blog post is from 2013. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

In brief, a VERY common problem is that while they MAY WELL have applied the provided "updates" for CF, folks often do NOT notice that they may have to (and generally must) "update" the web server "connector" (if they are using an external web server, like IIS or Apache) as a separate manual step, after applying the update.

I explain here what that means, how do to it, and why you may miss that you need to.

Update in 2019:

Since writing this entry, I did one in 2019 on When and how to upgrade CF web server connector, easier since CF2016, which at least makes it EASIER to upgrade, though much of what I write here still applies. I also updated this post since originally writing it, in ways discussed below.

(Or if you'd rather just have me help you quickly help you analyze and rectify your situation, whether with regard to the connectors or any other CF server troubleshooting, I can do that in a brief consulting session, likely less than an hour, remotely and securely. I provide all the detail here for those who prefer to "go it on their own". For more on my consulting services, including rates, approach, satisfaction guarantee, and more, see the consulting page at carehart.org.)

[....Continue Reading....]

Note: This blog post is from 2013. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

As an update since I first wrote this, it turns out this issue may or may not affect you depending on a couple of variables, which I will discuss, with a prefix of "update:" below. But don't dismiss this thinking you are not affected. I would propose that still far more CF servers may be exposed than not, as I will explain.

The CF Admin has (for several releases) offered an option called, "Use UUID for cftoken" (in the "Settings" section), and it's been intended as a security measure. Its purpose is to cause CF to use a UUID value (a long, complex string of numbers and letters) for the CFTOKEN cookie (and session variable) that CF generates, versus what used to be a simple, 8-digit value. This cookie, along with the simpler and incrementing CFID, is used to connect users to the session and/or client scope values created for that user in CF code.

Some may be surprised to learn, though, that while this setting DOES cause CF to *create* such UUID-formatted CFTOKEN values for requests that do not already present a CFTOKEN cookie, it does NOT necessarily cause CF to block any continued use of such simple, 8-digit cftoken cookies.

In other words, browsers which had visited your site before you turned on "use uuid for cftoken" would still send the 8 character cftoken they already had, not a uuid, and that could be accepted as valid by CF, even with that setting on, under certain conditions. (And the user will not be sent any new cftoken cookie in a UUID format, in CF's response, in those conditions.)

There's good and bad news related to this fact, which I will elaborate on below.

Update: Since writing this entry, I learned of a couple of factors that influence if and when this is a problem.

1. It turns out that if you are using CF10, or CF9 or 8 with the "session fixation" hotfix (APSB11-04), then the problem only happens until you restart CF. The Admin does not currently warn you of this, so beware that you will have the exposure below until you do restart. (If you have added one of the later security hotfixes or cumulative hotfixes that came out since then, then you have gotten the fix.) This fix causes CF to create a new UUID-based CFTOKEN, if you turn on this feature at least (and after a restart) when a browser presents a previously created 8-digit cftoken.
2. On the other hand, even if you are running CF 10, or running 8 or 9 and HAVE applied that hotfix, note that if you TURN OFF that fixation protection (by adding the -Dcoldfusion.session.protectfixation=false value to your jvm.config, as discussed in that technote), then you are back to the state that I discuss below.
3. And of course, if you are on CF 8 or 9 and have NOT yet applied that APSB11-04 hotfix (or a later cumulative one that includes it), then you are indeed still vulnerable.

So that leaves still many people who could be affected by this. Even if it seems you may not be, you may want to continue reading this entry to understand what the issue is about, for you and others who may be impacted by it.

[....Continue Reading....]

Note: This blog post is from 2013. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Important hotfix-related notes for ColdFusion 9 and ColdFusion 10

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.

[....Continue Reading....]

Note: This blog post is from 2013. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

At first I was adding these as updates to the previous entry, but I fear that some who may have read it earlier in the day may then miss some of this new info, thus this "Part 2". You will definitely want to read part 1 before proceeding here.

[Update: And since writing this entry 2 weeks ago, Adobe has indeed now come out with a hotfix. I have more to say about that in the new Part 3: Adobe hotfix released for "Serious security threat for #ColdFusion servers". While you should proceed to get that fix in place, you'll likely benefit from reading parts 1, 2, and 3, as there's more discussed than just the thread and fix, itself, which could benefit you down the road.]

Among the new information shared below are such things as how the hack worked (not too much detail, though), how to determine what the exploit may have exposed, how to handle resolving things for many sites via scripting, how to lock down the /adminapi, /administrator, and /componentutils directories, and most important, why you should not skip all this just because "we already block all access to the CFIDE/adminapi" (and /administrator and /componentutils)". There may be exposure you're not considering.

[....Continue Reading....]

Note: This blog post is from 2013. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

And note that it's NOT one that you're protected against by having applied CF security hotfixes. (Updated Jan 15 2013, as Adobe now has a hotfix for this. More below.)

There's quite a bit for you to consider regarding this recent threat, as I discuss here.

[....Continue Reading....]

Note: This blog post is from 2012. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

But have you ever wondered which jvm.config is used by a given instance? Or perhaps found multiple jvm.configs in your [jrun4]\bin directory and wondered which instance each went with? The answer isn't as straightforward as it may seem, when you're running CF as Windows Services. There's no single CF feature that reports this, but I do offer a solution here.

The simple answer is that one can find the information in the registry. The longer answer, including how to find that, as well as how to get that info more easily from the command line if you may prefer, follows.

[....Continue Reading....]

Note: This blog post is from 2012. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

The common answer offered is that one should use the "system info" page in the CF Admin, and its available "update level" field.

But I will assert that's not the "right answer" after all, or certainly not the "best answer" to really know what hotfixes (plural) have been applied. Know why? If not, I'll explain here, and I'll show what I would say is the "right" answer to "what hotfixes have you applied?"

[....Continue Reading....]

Note: This blog post is from 2012. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Such folks may be using the CFIMAGE action="resize" tag, or the imageResize() or ImageScaleToFit() functions to do resizing. (Or they may be also processing images using ImageRotate, ImageShear, or ImageTranslate, though the defaults for those are not problematic like the resize/scale tag/function processing).

The "problem" (if this is the cause of a slow page) is due to a default "interpolation" setting for CFIMAGE resizing, imageResize, and ImageScaletoFit. The default may not perform well at all. The good news is that the value is configurable, and you can test to compare quality/performance of difference values, as will explained below. There are still some other things to consider also. (If you're currently using CFIMAGE to do resizing, jump to the last section of this entry to see an example of code switching from the "slow" approach to the faster one. But really, you ought to read the rest of this entry to understand what's being proposed.)

While I offer all the info here for your consideration, if you need help implementing the solution, or better understanding how to find and resolve these or other problems affecting your CF server performance, see more on my CF server troubleshooting consulting services.

[....Continue Reading....]

Note: This blog post is from 2012. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

The good news is that you just need to update the one hotfix jar. While it is discussed in the technote for the hotfix, the note about this update is sadly (currently) at the BOTTOM of the technote. I'll repeat what it says here, to give it some more visibility:

Note - Updated on March 29, 2012

Following bug is reported for ColdFusion 801 against this security bulletin hotfix.

java.lang.NoSuchMethodError Exception is thrown while using cffile upload.

We have updated the hotfix files of ColdFusion 801 to include the fix for the above issue. Users who have already applied the hotfix for ColdFusion 801 can just update the hotfix jar.

I'm pretty sure this is fixing what some found to be a reliance in the hotfix on your having applied one of the specific Cumulative hotfixes, but if someone had not, or if they inadvertently removed the CHF during the process of adding this single one, things would break. I'll note that the HF technote above does say very specifically what jars to remove, when applying the hotfix. Some people in haste instead delete all the hf and chf jars, or delete chf hars when it says to remove only hf jars. They so look similar in name.

I cover this issue of being careful about applying hotfixes (there are other mistakes you can easily make) in another blog entry I did, CF911: Are you finding CF (or CF Admin) busted after applying a hotfix? Three possible reasons.

And before someone chimes in to lament, "this is what's so wrong with the CF hotfix process, that mistakes can be easily made", I cover that too. The short answer is that Adobe is addressing this in CF10, and may even offer something to help us later for CF 8 and 9. We shall see.

Note: This blog post is from 2012. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

You can find the recording here. Note that you need to login with an Adobe ID, just like when you download Adobe software or participate in their forums. (I have no control over that.)

Since that link just goes right to the recording, here is the description I'd used for the session, to help decide if the recording may interest you. BTW, I clarify on the session that FR is useful for more than just ColdFusion, in that FusionReactor can be used for Railo, BlueDragon, and OpenBlueDragon, as well as in fact any Java server (Tomcat, JBoss, Jetty, Glassfish, Websphere, etc.), and the session applies just as well to folks using those.

My session: Monitoring ColdFusion with FusionReactor

Recording
Session Description:

[....Continue Reading....]