Announcing ColdFusion update released Jul 19 2023: a third Priority 1 security update
Just days after two P1 CF security updates were released on Jul 11 and 14, Adobe has released yet another on Jul 19, for CF2023 update 3, CF2021 update 9, and CF2018 update 19.
Yes, this is shocking. Yes, unless there's a good explanation, I can understand how many would feel "someone on the CF team should be flogged". Don't shoot me: I'm just the messenger. I don't work for Adobe.
But I will add that in this post, besides just sharing news about the update (and more than JUST pointing to the update), I also offer an ADDITIONAL "fix" some will want to consider, to go BEYOND what this update addresses. See the discussion on "blocking the _cfclient query string".
Read on for more, where I cover:
- Finding more info on this update
- A suggestion on blocking the _cfclient query string
- News for those doing manual offline installs: this update DOES have a zip
- As for doing a Java update along with this update
- CF2018 WAS indeed also updated
It should be:
https://cfdownload.a...
If anyone has a faster method of letting Adobe know than I do, feel free to reach out to them & let them know.
Cheers,
Danny
And note that while the link in step 1 of the offline install has it wrong :
https://cfdownload.a...
The link in step 2 is right (has 2023 vs 2021 in the url):
https://cfdownload.a...
I've never understood why they offer the link in both steps there.
Anyway, you should report it either in the Adobe forum post I'd linked to above, or at tracker.adobe.com, or by emailing [email protected] or [email protected].
This is me "teaching to fish", so I'll leave it to you, given your sincere (and correct) concern about the matter. Trust me, I have no inside track, and often paying customers get better response to some things than I do.
That is correct. I was referencing the "link" to download. I didn't even notice the "Unzip" one LOL.
I emailed CF support per your suggestion.
Thanks for teaching me to fish!
Cheers,
Danny
Sadly, some folks really don't take kindly to even a sincere effort to teach them, if they've not asked--and that could be a root of some wider societal problems, I think.
Anyway, such people's heads must explode with my posts (and replies in the community), so they probably don't follow my blog. I write for everyone else. :-)
First, you COULD extract the zip, and find the jar in its bundles/updateinstallers folder, then run that via java -jar.
Or what you regard as file permissions issues may instead be simply that you set the cf service to run as a limited user (like "cfuser", rather than the default of local system), but then the update process (launched from the admin) can't stop cf...so the update fails.
I've been meaning to do a post about this, though it's not new. The solution is to get the free Service Security Editor tool (from Core Technologies) and use it to tell Windows that this cfuser CAN stop/start all the cf services. Then run the update.
Look for a post to come with more details. Hope those help in the meantime.
As for your last point, well, that's what the update technotes DO say (at least for today's updates, like u9 of CF2021), saying "Update "packagesurl" in cfusion/lib/neo_updates.xml of cfusion and all its child instances to point to"..."bundlesdependency.json present inside the downloaded folder."
default value
<defaultpackagesurl>https://www.adobe.co...</defaultpackagesurl>
local file
<defaultpackagesurl>c:\downloads\bundles\bundlesdependency.json</defaultpackagesurl>
would that be correct? or does the XML tag need to change as well?
But I would agree those docs could be improved, in many ways, some of which I've mentioned in past posts.
I didn't see anything suspicious before Update 6, so naturally I assumed that this issue was fixed in Update 6.
Now there's no way to tell if our servers have been compromised?
INSTALL THE UPDATE IN OFFLINE MODE MANUALLY
Download the hotfix installer from the link.
Unzip the repository to a place where all ColdFusion server instances can access it.
Update "packagesurl" in cfusion/lib/neo_updates.xml of cfusion and all its child instances to point to <InstallerReposityUnzippedPath>/bundles/bundlesdependency.json present inside the downloaded folder.
Has anyone experienced issues with CF2018 Update 19 and using JVM 11.0.20? I tried upgrading from CF 2018 Update 13 and JVM 11.0.13...
When I tried the manual .jar install using 11.0.20, I received the this error:
Error: An unexpected error occurred while trying to open file hotfix-019-330149.jar
Using the 11.0.13 JVM worked.
Once installed (with no errors), now my sites are just showing blank pages, however the CF Admins work fine.
Thanks in advance,
Shaun
To be clear, it worked fine with 11.0.19, so no need to go back to 11.0.13. And if that's where you WERE, go up to 11.0.19 and you'll at least be on what was the latest as of MONDAY of this week. :-) And again, it WILL work to download the CF updates.
Hope to have news soon on solving this. I've found and documented similar problems in past JVM updates, such as 11.0.11 and 11.0.17. I'm sure there's a similar explanation and solution. When I find it, I'll mention it here and in my post on the new JVM update from Tuesday.
What I can say I do know is this: when Adobe has been asked (directly, by clients of mine), the answer has been "yes, reinstall it". But of course that's a PITA, and it's unclear if doing that "improves" anything. Would it cause the new CF (and Java) update to be applied if it was not already? Sure. But one could (and some would) install that separately, even if they had applied the autohotfix tool.
So one could ask Adobe to consider two shops. Shop 1 had installed the most recent prior autolockdown tool and chooses not to reinstall with the updated version), so they ONLY apply the latest CF and Java update. Shop 2 goes ahead and reinstalls the new autolockdown tool. How will the two differ? What will Shop 2 get by their effort that Shop 1 does not?
If anyone may do testing, folks would love to hear.
The few times in the last 10 years that Adobe said otherwise, it was merely because of technical challenges downloading/installing in the cf admin ui. None of these have that, to be clear.
All CF versions that deserialize WDDX are probably vulnerable -- so that would include something very old and unsupported like CF10. Any accessible CFC with a remote method is a pathway to exploitation of the WDDX deserialization vulnerabilities, since all you need to do is reach the GetArgumentCollection() call in coldfusion.filter.FilterUtils.class. I've done some testing and code review, and haven't found any other user-accessible ways to hit GetArgumentCollection() and control the WDDX object to be deserialized, such as calling a UDF with a user-controlled variable from a CFM or a via cfinvoke. Not a guarantee, as I certainly could have missed something.
Exploiting CVE-2023-26360 (from APSB23-25/March 2023) *does* require the _cfclient parameter, as the vulnerable code path is only reachable by a very flow that does require CF Client functionality. When creating the exploit for CVE-2023-29300 (CVE-2023-38203, really) ProjectDiscovery based some of their work on Rapid7's analysis of CVE-2023-26360 -- which is why I think the PoC for CVE-2023-29300 included _cfclient.
And to your point here, I'll add first that I've tried to clarify (where I mentioned the _cfclient querystring) that the references to that (from resources other than Adobe) may relate to only SOME specific one/s of the many vulns addressed by the 3 July CF updates.
It's a tough situation. You helpfully mention the relationship of one or some of the vulns to wddx deserialization, and that may seem tempting to folks, who'd wonder "how can we just turn that off?" Well, no, sadly we can't. There's not even a means in the cf security sandbox feature (which is used by a scant percentage of folks).
And even if we could, the entire cf admin and other features rely on reading and writing cf config files which are xml files saved in wddx format (an xml schema created by Adobe 25 years ago). All the neo*.xml files in the cfusion/lib folder are an example of this.
So again, we can't just "turn off wddx", but then it's not clear if we would have to: as you note, it's exploitation via remote method calls that's at the heart of what's happening. Can we somehow block just that? That's not yet clear.
I will add that I've been given some additional information (from a source asking to remain anonymous) that MAY be at least one MORE thing that folks on cf2016 and earlier could do, related to this matter of wddx deserialization. Again, it's not yet clear what might be "broken" by adding this new block. (Even if it may too wide-impacting for some, others may accept it as their "only choice".) That's why I've not yet shared word of it. I want to be careful how I present it, and I'm doing more testing.
It is all a very unfortunate situation. Of course, it's understandable that Adobe may hold firm to saying "we stopped supporting cf2016 in 2021,and cf11 in 2019, and cf10 in 2017". I don't see them creating a new out of band update for those. But perhaps they MAY come out with more clarity of what can be done for such folks, given the severity of this. Though even that is risky (for various reasons) and unlikely. I mean, look how little info they offer even for those on the supported versions.
As you know, of course, Brian--and others should keep in mind--it's dicey for a vendor to offer public info on vulnerabilities. They have to be VERY careful, and it's a fine line between too little and too much info. So it's a blessing we have folks like you and Pete (and others) stepping in to fill that void.
Let's see what the next steps may be, whether announced here or elsewhere. BTW, folks may be interested to hear that Brian has a blog where he writes (sometimes uniquely and extensively) on cf security matters at https://hoyahaxa.blo..., though as of this writing there are no posts since early July, before the 3 recent cf updates. And of course Pete Freitag has long been the cf community security maven, though he too has not blogged on this (last post in May, at https://www.petefrei...), though Pete HAS of course kept users of his https://hackmycf.com... service informed about the cf updates.
As far as advice or what can be done for older (unsupported) versions of CF, I'll share here what I tweeted two weeks ago in the midst of this -- https://twitter.com/...
"You should *not* expose any unsupported versions (i.e., no security patches) of CF to the public Internet. Migrate to a supported CFML platform *now*. Many of these vulns affect older, unsupported versions of CF too. CF2018 was EOL on 7/13, but it received APSB23-47 patches.
ColdFusion can be secured, but you actively need to take the steps to secure it. Patches are step zero. ColdFusion (like many other platforms) is not alone in being nearly impossible to secure if you do not have access to the latest security patches. Run the lockdown tool, remove unnecessary components, restrict access to sensitive components.
History has shown that some critical CF vulns have had very long tails. Internal exploitation and lateral movement is always possible too, but the high volume of activity makes Internet compromise against vulnerable systems an almost-certainty."
And lest any reader think I don't share his admonition to "get off old, unsupported cf versions", I do indeed.
But I'm like a doctor in an er. I can say "if we don't amputate that infected foot you'll die of sepsis", but some people will refuse. We all know what's inevitable.
Some may liken it instead to the doc telling people not to smoke, but a person points out their 99-year old granny who smoked to her last days. OK, they may want to take their chances--like someone who feels their server's not been hacked in all these years, so why go through the hassle/expense of getting off that unsupported cf version now (even if to Lucee, so "zero cost")?
Of course, if we did exploratory surgery we may find the "cancer" (result of an exploit) IS there, and has gone undetected for days, months, nor years. But some people won't want to pay for/go in for that exploratory surgery. And just like in medicine, even such exploratory efforts may not readily spot all cancers/results of exploits. Some take far more effort to find, diagnose, and cure--even for someone willing to undertake the needed efforts.
Again, most of us can see what's almost certainly inevitable in this case, but all we can do is counsel folks--and even then only those who seek or find our counsel--or help those who seek additional assistance.
Put another way, we can only "lead the horse to water,but can't make it drink". But you've certainly fired the warning shot that may get the attention of some of the more stubborn bucks in the herd, if folks will forgive the stretched analogy. :-)