[Looking for Charlie's main web site?]

ColdFusion March 2023 emergency update, and what to do about it

If you've not heard, a new update has been released (March 14, 2023) for ColdFusion 2021 and 2018. Despite what you may hear, this is an URGENT (rated "Priority 1" by Adobe) update that everyone should apply ASAP, for reasons I will explain in this post. In fact, Hackernews reported yesterday (Mar 16) that the U.S. Cybersecurity and Infrastructure Security Agency (CISA) had issued an urgent warning about this, giving federal agencies a deadline to apply the update.

TLDR; For some folks, the above may be all you need to hear: you may be dropping your coffee and donuts now to get the update applied. Still others will see this "huge post" and think, "crap, I don't have time for this". For you, skip to the bottom and its "concluding key points". You can then decide what you think you do or don't "need to know" and pick and choose from the sections as you like.

Finally, for those who prefer because of the importance of all this to be led more carefully through understanding things (in a way that's worked for the many people I have helped so far this week, and is far more than either Adobe or Hackernews has shared), please do read on.

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

Comments
Hi Charlie, many, many thanks for this comprehensive blogpost. Much appreciated!
# Posted By Jos | 3/17/23 6:42 AM
Thanks Jos. Such feedback is very much appreciated.
Is there any reason that we can not/should not just remove wwwroot\cf_scripts\cfclient folder? I know that I do not know the actual exploit, so I do not know if it is related to the actual code in this folder or something else.

I know ideally everyone would be on current versions of ColdFusion, but we work with multiple different clients that have different upgrade cycles , and some are waiting for 2023 to come out, so I am looking to support those as much as possible.

If it is not this code, and is someplace else in ColdFusion:
1) Does -Dcoldfusion.cfclient.enable=false work on CF 2016? I am guessing not, but just curious
2) Is there a way that if we are not using CFClient to just remove it from old servers?

Thank you.
# Posted By Matt | 3/17/23 9:41 AM
Thanks, Charlie. Your thoroughness is appreciated, as always.

Question...the CF Admin has an option "Enable mobile's server workflow" to turn on/off. If this is turned off, is the server still vunerable?
# Posted By Paul | 3/17/23 11:26 AM
Many thanks to Charlie for finding this hack and this extensive blog with all the details! As we use IIS, I found using IIS Request Filtering to block the query string was simple, quick, and effective.
# Posted By John D | 3/17/23 2:12 PM
Charlie, I can't imagine being so confident in CF without all of the amazing insights and work that you do to support the community. Thank you!
# Posted By Rich | 3/17/23 2:14 PM
As always Charlie, thank you for taking your time and sharing all this invaluable information with the community! My servers are all good now :-).
# Posted By Giancarlo Gomez | 3/17/23 2:23 PM
Wow, lots of questions, and too many for me to answer at once. Let me take them one at a time, and it will be between client engagements, so apologies for the delay that there will be.

Matt, no, removing cf_scripts is NOT the solution to this problem and it would not help. And yes, I mean even if you or someone you know found evidence that that was used to perpetrate that "specifically crafted URL" I hinted at.

Let me be clear: it's NOT the files in that folder that ARE allowing the hack. So no, the bad guys could use other files. I will have to leave it at that.

Bottom line, it's the _cfclient querystring that is the key to the problem, not the files used in referring to it. I know I'm not giving enough detail for folks to figure things out: and that's the point.

As for the jvm arg, no. As I note in the post, that is NOT something you can "just do" in CF2016. It will mean NOTHING to CF 2016 or 11, or to CF2021 or 2018 before the update is applied. The jvm arg is for someone who APPLIES this update and yet DOES want to be able to use cfclient.

Finally, as for you asking how to remove it from old servers, I'm not aware of any way to. Again, this problem is inherent in how CF itself processed that _cfclient querystring, not some page that was called.

So someone on CF2016 (or 11) should use the other approach I offered, of simply blocking that _cfclient query string. I made that clear. I think you're trying to consider some potential corner cases or alternatives that I might have missed. I get it.

But please let me know if you now feel that you have all the info you need to proceed safely.
Paul, great question. I will try that on a server where I have not applied the update (or the block), to see if the bad guy URL would no longer "work". If so, then yes this would seem a helpful alternative solution.

That said, nothing about the alternatives I offer should require an alternative. It would seem this would lead to the same result. I'm about to enter another client call so can't test it now.
John, Rich, and GC, thanks very much for the kind regards! :-)
Thanks Charlie, owe you a pint!
# Posted By Will Mulder | 3/18/23 7:41 AM
We have CF2016 servers so the advice from Charlie is very much appreciated. I'm so glad the "fix" was easy to do. Thank you for providing this info and confirming it works. You're completely right not to give too much away about how exactly the hack works.
# Posted By Gary F | 3/18/23 6:35 PM
Glad to have helped. Thanks, Gary (and Will).
Thank you so much for this blog post. It had just the right amount of information. Did you see that Adobe also released several other updates for other products with similar wording to the coldfusion bulletin? https://helpx.adobe....
# Posted By Dana | 3/20/23 12:54 PM
Dana, thanks first of course for the kind regards. And yep that's interesting about the other products. Perhaps you're wondering if there's maybe some connection among them all--even to the point of wondering how then this contention about "cfclient" can possibly relate to what those other products also addressed.

I can only say this: of all of the products listed as having updates that day, only AEM is "like" CF (in being a Java-based application server). And what it lists are not the same cve's.

I suspect instead this was Adobe's version of a "patch Tuesday", where they released at once many updates for many products.

If somehow time or insights shared here might show that there's indeed some connection among them all, that will be very interesting.
Charlie, thank you as always for keeping us informed on these important updates. We don't see this level of information/detail from Adobe, which really would be helpful. Regardless, we are grateful for you.
# Posted By Lance | 3/20/23 1:44 PM
Thanks, Lance.
Thanks as always Charlie for the helpful information. We immediately put the quick fix into place for IIS and Apache, and installed the 2021 update over the weekend. Appreciate the detailed information.
# Posted By Tony Brandner | 3/20/23 4:28 PM
Great to hear, Tony, and glad to have helped,
I want to add an update that Rapid7 came out with a blog post/announcement today about a CF vuln:

https://www.rapid7.c...

...but they don't connect it readily to this one. Even so, I am fairly confident that what they are finding is the RESULTING bad-guy file that I discussed in this post as the second aspect of the vuln (the "arbitrary code execution", or their ability to cause placement of a bad-guy file on your server.)

Sadly, the Adobe technote and PSIRT/APSB bulletin as well as Mitre CVE's don't give enough detail to readily allow Rapid7 and others to connect the dots to this vuln and the update from last week. And they likely are unaware of my post here.

But I wanted to point this out in case others finding or following this post may "wonder" if that is some "new hack". I really don't think so. Once those folks dig further they should find that the root cause was this _cfclient querystring and the rest of the "specifically crafted url" (which I can't share, as it would allow perpetration of the hack).

Bottom line: get your CF2021 and 2018 updated to the March updates (6 and 16, respectively), or get the block of the _cfclient querystring var in place, all as discussed above.
Charlie,

This addresses CVE-2023-26360 but not CVE-2023-26359, correct?
# Posted By James | 3/22/23 12:17 PM
I assume the "this" is this post (as the update definitely addresses both). As for your question, I'm afraid I can't really know. There's not enough detail in those CVEs to tell.

I suspect you're asking because in the apsb, my name is associated only with the one CVE. You're likely wondering if perhaps my post only covers SOME of the vulns identified in the apsb.

Again, bottom line: folks should apply the update (which clearly prevents the very serious hack as I'd reported to them days before), or implement at least the block I'd offered--whatever is the cve/s that it relates to. I'm afraid Adobe just didn't offer more to help on your question.
Thank you so much for this blog post,it help me a lot.
I notice Adobe rate this cve as CVSS 8.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N), the Integrity and Availability Impact are None.If this vulnerability can lead to arbitrary code execution, i think the Integrity and Availability Impact should be High.So I wonder if the official patch actually fixes this vulnerability(CVE-2023-26360)
Look forward to your reply, thank you again.
It absolutely does. I also don't understand their scoring or attribution. But I can say with 100% confidence that this update prevents the vulnerability I describe, including both the arbitrary file read and the arbitrary code execution.
Thank you for your reply.In addition, You mentioned that if I were attacked, i will see .log or .xml in my cfclasses folder, What is the reason for this? Can I defend against this vulnerability by prohibiting the generation of .xml and .log under this directory? It's easier for me.
The class files are evidence of the hack having been perpetrated, they are NOT the MEANS of the attack, anymore than a fingerprint should be defended against in a crime.

The thing to defend against is the _cfclient in the query string, as discussed (to death) in the post. Here again, the mere presence of that string is not THE HACK, but it's the WAY it's used: just like how a gun in a robbery alone will not kill or wound anyone, but can be USED to do so.

Since these questions remain for you, I think you'd find value in reading the post again, from the top. It was a LOT to take in. I'd hope on second reading any questions would be more completely answered.
A detailed analysis of the vulnerability and the underlying vulnerable components has been published here -- https://attackerkb.c...
# Posted By Brian | 3/30/23 9:59 AM
It's certainly an interesting effort they've done. They're concluding attack effort is indeed something quite different from what the hackers I saw did, though what they shown is bad enoug).

Some will benefit from their effort, sure, but of course some will also use it to effect perpetration.

I was careful NOT to show the "how", but we can't control what others may say and do. Anyway, thanks for the heads up.
Charlie, you've done it gain. Thanks so much for such detailed response to this; in my case helped me to not just shrug shoulders and say we are on CF2016, not much we can do! And yes I know, my client IS looking to upgrade asap.
# Posted By Bill Tudor | 4/6/23 9:36 AM
Thanks, Bill, and glad to have helped! :-)
Charlie - thanks for the thorough document - very much appreciated like everyone else.

We've added the Request Filtering in IIS to deny the _cfclient query string on all of our servers and applied the patch to most of them. We are running Java 11.0.11 in most cases but the Security Bulleting mentions:

Adobe recommends updating your ColdFusion JDK/JRE to the latest version of the LTS releases for JDK 11. Applying the ColdFusion update without a corresponding JDK update will NOT secure the server. See the relevant Tech Notes for more details.

To your knowledge, is it a requirement to update Java to 11.0.18 to be fully patched?

Thanks in advance.
# Posted By Mike Pelant | 4/12/23 5:53 PM
Thanks, Mike. And to that verbiage you quote, it's an understandable question/confusion.

It's simply there in every CF update--because SOMETIMES an update they do MAY presume to leverage also some aspect of a latest JVM version. But note they are not specific about that (ever), and I am not aware of this fix having anything to do with Java.

That said, given that CF runs on Java it is indeed always wise to run on the latest update of the JVM version which your CF version supports (for the sake of its own security and bug fixes). And for CF2021 and 2018, that is currently (only) Java 11: and the latest 11 is 11.0.18 which came out in January. (11.0.19 will come out next week, FWIW.)

Before you may update the JVM, note that I did a blog post on that 11.0.18 update where I mentioned 3 related issues: one for people moving to 11.0.17 or above, one for people moving to 11.0.11 or above (but you're already there), and one for anyone running the JDK installer for 11.0.18 or above. See that post here:

https://www.carehart...

I would plan to do another post when the next JVM updates come out next week.
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting