We are pleased to announce that we have released the updates for the following ColdFusion versions:
In this release, we’ve addressed some security vulnerabilities and added the following jvm flags to that effect.
For more information, see the tech notes below:
These updates fix security vulnerabilities that are mentioned in the security bulletin, APSB23-25.
The Docker images will be hosted shortly on Docker Hub.
Please update your ColdFusion versions and provide us with your valuable feedback.
I’ve finally gotten done the blog post I had planned on this update and the vuln/hack, including what could happen, what to do about it, and lots more.
For developers that host on IIS that don’t have direct access to the console to add the request filter rule using IIS Manager, here’s an IIS Rewrite 2.x rule that can be added to web.config.
To folks reading this: I will say that in my own opinion this security fix is far more important than the wording of this blog post suggests and even that the update technotes would suggest. To be clear, I HAVE personally seen both the “ arbitrary code execution” and “arbitrary file system read” vulnerabilities having been perpetrated on multiple servers, and it IS grave (I am one of the folks listed on the APSB as having reported the issues).
I will have a blog post soon with more: not on how to perpetrate the hack, but what was possible, how to determine if someone may have performed it successfully on your server(s), and finally how folks on CF2016 and 11 can defend against it (as it affects them as well, but Adobe no longer offers updates for them. And of course, I always warn them also to get OFF those old unsupported versions.)
When I do offer that post (hopefully later today), I will add a link here.
I will indeed. It’s just not done yet. I’ve been working on it in spare hours yesterday, last night, and today. (Any who have read my blog posts may not be surprised to hear they take more than a few mins to put together.)
If you’re desperate and want to “throw up a hail mary”, use your web server’s features to block any incoming requests with the phrase _cfclient in the query string.
In my post, I will explain far more, including a) what that’s about, b] how to implement that block in IIS and Apache (the most common web servers) as well as c) how to (carefully) search your web server access logs to make sure there’s been neither any legit use of that value in the querystring (which you may then be worried about blocking) and also no illegitimate use of it (which could indicate that the hack was attempted) over recent weeks and months.
I will also show d) still more evidence to seek, e) explain what the hack enabled, and f) clarify how despite what the Adobe resources say, you should NOT conclude “oh, we don’t use cfclient, so we’re not affected“. Everyone is at risk of being affected.
Sorry I couldn’t get the post out more quickly. As you can see, there’s a lot more to this than most realize (or would be inferred from what Adobe has shared so far). And of course I need to walk a fine line of sharing enough info to help people but not anything that would enable someone to then perpetrate the hack–that’s a key challenge in these situations.
Finally, to be clear I don’t work for Adobe–and when there’s an update (or a hack) I am often then VERY busy helping many clients deal with it. Some consolation is that each such interaction refines what I would then share in the blog post, but I realize that’s little consolation to someone who “just wants to see the blog post” and whatever I may have to share. That’s why I gave you that bit above to perhaps “tide you over”.
You must be logged in to post a comment.