Announcing ColdFusion updates released Mar 12 2024, possible breaking change, solutions
It's very important that people read the technote before "just applying this update". There is a very important (and fundamental) change in how CFML processes variables, with regard to searching for scopes when no scope is indicated on a variable name. It's NOT that you "must scope all your variables", as some are asserting. But it's still almost certainly a BREAKING change in many CF apps, if they use unscoped variables under certain conditions (that I discuss below). The change is for the sake of security, but it's just one aspect of the security fixes in this update.
Anyway, there are 3 things you can consider doing to rectify/work-around this breaking change, as I discuss below (or see the update technote, for this and more). And you may reasonably wonder what the implications would be of using the workarounds. You may also wonder if this scope matter relates to the CVE listed in the APSB (linked to below). That's currently unclear. It does not. As well, note that the Adobe security bulletin (link below) shows the security fix to be only a P3 (priority 3, the lowest severity), not a P1 (priority 1, the highest), though it IS regarded as "critical".1
But then there are still other aspects of the update beyond this scope matter, and you should be aware of those also.
For more, read on.
But to be clear, in my pointing to these workarounds, I'm not saying anything the technote doesn't also.
Those with the concern you raise should ask Adobe. They don't necessarily (and don't see to) read my blog, so we should not necessarily expect them to see this and offer an answer here.
If anyone finds an answer or more detail elsewhere, please do share.
I use CommandBox to do my local development, and it looks like they haven't pushed a new image yet for their `adobe2021` tag. I want to be able to test my sites locally first before I have Hostek apply the update. I suppose I could YOLO it, and just have them update (since I have `searchImplicitScopes` set to `false` everywhere already. But, I see there are Tomcat updates and what not that I would feel better about verifying first.
As always, I'm just a messenger, one person trying help others, as indeed you so ably (and frequently) do. And we appreciate it!
As for Commandbox I can only say that they're always on the ball and a new one may already be in the oven. I don't see an update yet on Docker hub for them or Adobe (Adobe's forum thread said new images were in process).
Until then, yes, folks can just update their images like other folks using cf would (even if it feels icky on a container). Or yep, as I'd noted above, anyone can get a head start BEFORE doing the update by setting searchimplicitscopes=false in their application.cfc/cfm, to force the change in behavior that will become the default with the update. That will help them see if/when unscoped vars would be a problem (again, not ALWAYS).
While they could start updating their apps to use searchimplicitscopes=true as a "workaround", that should be carefully considered. First, the new jvm arg could be used instead (after the update). But EITHER workaround should be weighed against unlocking the very door Adobe was locking for the sake of security.
Here again, convenience (compatibility) vs security needs to be weighed carefully. This is the new reality (secure by default) being imposed on us from many directions: in CF, in IT generally, on our devices, and even in our daily lives.
For now, I'm going to just wait for CommandBox to release an update. I tried to update via the CF Admin (within my Docker container) and it said that this particular update can't be done via the Admin since it changes the underlying engine (I forget the exact wording).
Yep, Commandbox is itself its own environment, and just as doing cf updates might be frowned on in containers, it seems there are times when they're precluded by Commandbox.
Perhaps soon we may hear from Brad or Jon, on either or both matters (issues updating cf ourselves within Commandbox, or news on a new image).
I wasn't sure from the technote which "workaround" would go away so if I read your assessment correctly I will probably try setting "searchimplicitscopes=true" in our main Application.cfc since it seems that that will be support even when the JVM switch is no longer supported.
Thanks again! Always grateful that you have such a great place for CF information since it sometimes feels like a lonely CF world.
Does anyone know of such a tool like that, that could be used now?
Finally, as for your feeling like you're in a "lonely cf world", PLEASE see that last link I offered at the end to several available community help resources: you will find issues like this and many more discussed every day, whether you prefer email lists, web forums, slack channels, facebook discussions, linkedin discussions, and more.
You are definitely NOT alone. You are rarely the only experiencing some problem. And you need NOT rely solely on google searches or AI engines to find answers. And of course, some simply prefer talking to real people (flawed though they may be, in their knowledge and sometimes even in their online personalities!)
So first, yep, for those who pay for Pete's Fixinator tool, that will be a great addition (and certainly yet another reason for folks to consider it).
And FWIW, I can confirm that Adobe's Security Code Analyzer does not currently flag code with unscoped variables. (I just proved it with a test.) We can hope they will consider adding that, if they are not perhaps already working on it. And I've just filed a feature request on it: https://tracker.adob... Interested users of that tool should add a vote there. I'll also update my post to reflect this.
Finally, sure, someone could take the old varscoper (which was looking for a very specific problem) and try to modify it.
But let me note (as I do in that tracker ticket, and above in my post): it's not that ALL unscoped variables will fail with this change in behavior (or by setting searchimplicitscopes=false yourself). Any tool that flags ALL unscoped variables will produce MANY false positives (just like many are overreacting to this change, thinking they must change ALL unscoped variables).
Instead, it's that unscoped variables are still ALLOWED: they will only search those scopes in that first list I gave above (like variables, local, arguments, etc.). The change in behavior (searchimplicitscopes=false) will NO LONGER ALSO SEARCH scopes that can be manipulated from outside the request (like url, form, cookie, etc.)
And a tool deciding to flag that distinction is going to have to be pretty smart. But sure, some will accept just being told of ANY unscoped variables. That's just overkill. Again, lots to juggle here.
That's my current take on things, at least.
And I assume you mean you're setting it to true on the jvm arg, then you're trying to set it to false in an application.cfc, perhaps to tighten things down in apps that don't need to be loosemed?
If so, are you finding that despite being set to false, it acts as if it's true?
As for the setting of this searchimplicitscopes, are you doing that inside or outside of any method in application.cfc? It should be outside.
I plan to do a post tomorrow with more on that. It's not new or unique to this setting, that it does not take affect except when set OUTSIDE of any methods in the application.cfc (the"pseudo-constructor" of the cfc).
But let's have you clarify more before I go further with guesses and solutions. :-)
I also noticed when viewing the Update 13 URL from any other region than US (uk for example), the links to the hotfix installer and zip repository go to hotfix version 12.
UK page - https://helpx.adobe....
When viewed from the US, the links go to version 13 as they should.
US page - https://helpx.adobe....
And sure, it could happen with the package updates specifically since they are a separate file (and url). Something interesting is that they only change in some but not all cf updates; which means the issue of an "old"/stale/cached package update jar happens LESS FREQUENTLY and isn't noticed by as many as the same problem with the primary update jar.
Not sure what any of us can do, as users. Perhaps Adobe could implement some sort of additional checking for/protection against the package jar being found to be out of sync with the version of the update jar when the latter is run.
Until then at least they DO report in the technote what version number to check was implemented, both for the update and the packages (when an update introduces package changes). But most people don't pay attention. So again, good for you to spot it, and good of you to bring it to attention here.
Would you consider opening a ticket at tracker.adobe.com, to report the problem and suggest the possible solution? If you do, please share the link here so folks can add a vote.
Anyway, Adobe has responded there (looking into things). Here's the direct link to his comment there, and the threaded replies from Adobe follow it:
https://tinyurl.com/...
BTW, some may notice he's listed there as Adam36099131ak4s, but the message is the same, so I'll assume he just had that existing Adobe account name but uses a different pseudonym in other places, like this.
By the way, thank you for producing this fantastic CF resource, its helped me greatly over the years!
If I compare the 'bundlesdependency.json' file downloaded on my local server and my live server, the live one has no reference at all to any update 13 packages (searching for "2012.0.13") whereas the local one does.
When viewing the following URL about update 13 (uk version of the page):
https://helpx.adobe....
The manual installation instructions seem to be instructions for installing update 12.
If I view the US version of this page:
https://helpx.adobe....
The links in the manual installation instructions correctly link to files for update 13.
But about the first problem, help us out: did you apply the update via the cf admin, on both servers? Or this manual update?
And in the update install log (within hf-updates), does it show having applied update 12 or 13? With 0 "fatalerrors" reported in that log?
And then in the coldfusion-out.log and coldfusion-error.log, what errors are shown during the first startup of cf after having applied the update? That's when updates to the packages actually happen.
I applied the update on both my local and live copy via the CF admin. Locally it worked fine, on live the CF admin refreshed and then displayed a message about the adminapi module being missing.
After enabling this manually my site still wasn't working, the coldfusion error log showing errors about the 'document' and 'pdf' modules not being enabled.
I apologise for the lack of supporting information in my previous post. If I look at the install log for the update, it shows the following (I think these are the relevant bits of information):
java.class.path:
/opt/ColdFusion/bundles/updateinstallers/hotfix-013-330286.jar
Installed Feature(s) Standard, J2EE of Adobe ColdFusion 2021 Update 13
Install Begin: MARCH 18, 2024 6:15:46 AM GMT
Install End: MARCH 18, 2024 6:16:28 AM GMT
Summary
-------
Installation: Successful.
1625 Successes
0 Warnings
0 NonFatalErrors
0 FatalErrors
If I look at the 'bundlesdependency.json' that was downloaded and used for this update, it contains no mention of "2021.0.13".
The errors shown in my coldfusion-error.log for the first startup of cf afterwards are:
SEVERE: Servlet.service() for servlet [CfmServlet] in context with path [] threw exception [Servlet execution threw an exception] with root cause
coldfusion.server.ServiceFactory$ModuleNotAvailableException: The document package is not installed.
In coldfusion.out I only see this:
Mar 18, 2024 06:16:42 AM Information [main] - ColdFusion started
Mar 18, 2024 06:16:42 AM Information [main] - ColdFusion: application services are now available
Mar 18, 2024 06:16:44 AM Error [ajp-nio-0:0:0:0:0:0:0:1-8120-exec-10] - '' The specific sequence of files included or processed is: /var/www/*redacted*/htdocs/index.cfm, line: 615
Frist, let me note that I have NOT seen it on all the servers I've applied updates to--except one, yesterday. And for them, we did not take time to dig into WHY it happened (they just needed the update applied and their site working ASAP).
Like you, we dropped to the command line (as admin) and went to the cfusion/bin folder and ran cfpm install administrator. With that, despite an message suggesting we'd need to restart, we were able to get into the CF Admin.
Then we went in, and we saw that in the "Package Manager" page (second to last on the bottom left), in its "available packages", there was several which were not installed--including document and pdf, like you. To be clear, all packages should have been installed, since this was a typical full install which includes all of them.
We clicked "install all" and that solved it for them. Their app now worked. (Knowing this now, you could also just do a "cfpm install all" from the command line, instead of just "cfpm install administrator".)
Let us know how it goes. If you struggle and don't want to await back and forth here, I can certainly meet with you via a remote screenshare consulting session (as I mention in the post: more at carehart.org/consulting), and we should be able to get the update in place and working quickly.
Then if you want, we could do more digging into what it is about your setup (and those of some others) that makes things not "just work" as they should. There must be some explanation--especially of how it happens to some but not all of us.
Attempted the update again this morning on our live server - as before just doing it via CF Admin, this time everything worked as expected and we're now happily running Update 13.
This may be an over simplistic view, but it seems to me like the entire problem is that when my server tried to get a copy of 'bundlesdependency.json' during the update process, sometimes it was presented with the correct file and sometimes it was served something completely different.
The day that my server broke, doing a request from my server directly to 'https://www.adobe.co...' resulted in a json file with no mention of update 13 packages. Doing the same request today resulted in the file I was expecting.
To be honest, this is a sufficient enough explanation for me as to why things didn't work first time around. Some kind of caching issue/load balancing issue at the adobe end meant that my server was given a dependencies file that instructed it to uninstall certain packages. This caused my website to stop working. Once the relevant packages were put back in, everything seems fine.
As one of the affected parties, if there is anything you would like from me to help debug/understand the issue then do let me know. Otherwise I think we're happy to press on!
Andrew
I'll note that I've recommended the manual install as an option in both the post and other comments (like to Andrew, most recently), so again yep, I'm with you. :-)
Our live server which had the trouble is located in a Redstation datacentre in Gosport, UK. Our test server which had no issues is located in our offices in Exeter, UK.
Regards,
Charlie, not sure if you'd consider updating your blog post to mention this, but it might be useful for those that don't make it all the way down here to the depths of the comments :-)
Also, we've seen some confusion on if setting searchimplicitscopes key to TRUE in Application.cfc or Application.cfm will continue to be supported once the JVM flag -Dcoldfusion.searchimplicitscopes is removed?
We're trying to understand the timing implications to budget development time to work on this and knowing some deadlines would be good for making that happen.
Your questions are understandable, and I do already address/answer them above after mentioning those two options. See the section above, "Three ways to address the change in implicit scope searching", and the few paragraphs after the 3 bullet points there. The direct link to that section is:
https://www.carehart...
I realize my post here is large, and many will only scan rather than read it, and won't see every word. I've done what I could with sections, bolding, and a summary, to help such folks. But some points simply must be read. :-) I'm always open to feedback.
https://www.carehart...
1) So as Steve notes, I blogged on this problem (which started with CF2021 and remains) when I found it back in Nov 2020 when CF2021 first came out. That first post Steve offered does discuss it in detail. And as that post indicates, I did another when when Adobe offered a solution a couple of weeks later. In that post (https://www.carehart...), I explain how they created a JVM arg that we must add to make CF treat a capital D like in a dateformat mast the way it always did. Again, those using CF2023 and beyond also will need to use that, to get that backward compatibility.
Or see how I mention (in both posts) that some kind souls offered regex searches that one could use to find and correct such uses of D, in many possible variants of dateformat and related functions.
2) Of course, you're bringing this up here on this post about yet ANOTHER breaking change, both of which are surely frustrating. And as in that case, Adobe opted to go with the breaking change and a jvm arg to REVERSE it, rather than the other way around.
And though these happened 40 months apart, you're not alone in only experiencing the first one only now...which is like how I concluded THIS post with how THIS new problem will ALSO plague us as future folks move to CF2021 or 2023 and apply this update, or move to CF2024 and beyond, which will include this change to the default for searchimplicitscopes as a built-in change. A difference is that while Adobe is choosing (for security reasons) to NOT allow the jvm arg reverting that to work in CF2024 and beyond, again this JVM arg for the dateformat issue IS still supported in CF2023 and beyond.
3) Finally, back to the issue in THIS post and since I suspect my comment here may lead someone to ask: no, I can't see any possible regex that could reliably "find all unscoped variables". There are just WAY too many ways that code could name/use variables: with or without pound signs, with or without spaces around it, with or without parens around it, within quotes (as in isdefined), and on and on. More than that, not ALL unscoped vars MUST be changed, as I elaborate on in the post.
But as I noted in a previous comment and an update to the post, Pete Freitag has done the community a solid in having added to his Fixinator tool such scanning (as effectively as possible) for potentially risky unscoped variables.
And maybe someone will offer here or elsewhere a regex they work on which they think helps do the job. If it works well, I will certainly highlight it! :-)
https://community.ad...
2) I am DELIGHTED that one of the sites I inherited in 2007 was very much affected by this breaking change! Budgets are tight so I finally received approval to take it down. Who-hooo!
3)FYI: I found that I can always update via the Admin IF I manually control the server restart. Get the admin page up, get service panel up, stop any extra CF services, kick off the update, stop CF Application service, Start CF Application service, start other CF services, success.
Lastly, on your point of how you can't run the CF updates from the CF Admin, your approach is fine--but there's another solution, which again I've been meaning to blog about. And now I feel compelled to ASAP, lest discussion of the matter here takes us too far off-topic. :-)
And as I noted in the post, this problem may cause trouble for years to come, as people may jump to these or later versions from earlier ones. Oh, well.
Bottom line, it supports the same searchimplicitscopes app-level setting--as well as a related and older scopeCascading setting, which goes back to Railo days and is offered as a setting in the Lucee Server or Web Admin. But it defaults to the relaxed mode CF had before this update, so Lucee folks need to consider this matter as well. It's just that the changed default has not been forced on them as Adobe did with this update.
I may break that discussion into its own post, as I fear many will not see it here, 2 months after the update when I released this post. But I welcome comments from any interested Lucee folks, to refine anything I'd need to before doing that.
https://www.carehart...
And that can be done BEFORE one would apply the update from March or later.
I'd not remembered to post that link in. Here, as a comment let alone an update. I hope to do that also.