View unscoped variables in a log file

[Saurav_Ghosh]

Document history

• 04/10/2024: The following are the changes to the log file:
  • The log files contain the name of the scope in which the variable exist.
  • Files included using cfinclude tag will be logged.

In the last security updates of ColdFusion (ColdFusion (2023 release) Update 7 and ColdFusion (2021 release) Update 13), Adobe released hotfixes that addressed scope injection vulnerabilities. See the tech notes for more information.

New patch update

Adobe has released a patch for ColdFusion (2023 release) and ColdFusion (2021 release) to help identify the unscoped variables in a log file, and take corrective actions.

The patch applies to ColdFusion (2023 release) Update 6 and higher, and ColdFusion (2021 release) Update 12 and higher. Adobe recommends you to be on Update 6 or higher and Update 12 or higher.

View the tech note for more information.

Please send us your feedback.

[rickmaz]

Gosh Adobe just messed this whole thing up. So complicated and never had to be. Now i am totally confused. To be clear, can someone please verify i have the right informatoin.

1. UP until version 13 the default for searchimplicitscopes was TRUE?

2. once you apply 13 it flips to false as default so if there was nothing set in jvm or application stuff could break.

3. I i add the variable to application and set it to TRUE and upgrade to 13 my stuff should work exactly as needed and as before ?

4. This new patch confused me but i think i understand now. If i am on update 12 in 2021 they say set variable to true in application and install and view the logs. But isn't it already true by default? if someone had it set to false wouldn't their stuff already break? is the patch just to see what errors would happen in 13 if you do not set variable to TRUE? i just don't see the reason in their instructions if i am on 12 to set things to true. I am doing that anyway because that is how it needs to be for 13? just so confusing

[Charlie Arehart]

Yes, to all 4 questions. And yep, the discussion of this new capability can be confusing...and it's not an April fools joke. 

The way I read it is that this Hotfix can be added to update 12 OR HIGHER of cf2021 (or update 6 OR HIGHER of cf2023), but it was indeed the next update of each (in March) that changed the default for searchimplicitscopes to false.

And I suspect the point with this hotfix is that if searchimplicitscopes is true (whether by default or as set), then the hotfix will cause cf to log use of unscoped vars in a request. If set to false, the request would fail instead. (So we need to set it true, if on the March updates, to get this new reporting.) That's how I read it, at least. 

That mostly makes sense to me, though if it does this logging of added to the previous updates, it begs the question that perhaps Adobe was already working on this scope search issue then, but had not completed it to change the default until the March updates. 

I'm reading all this while out, on a phone, so will check things later and report anything new (or perhaps others will). 

[satyam-mishra]

If i reply in a single line, for this patch to work, we need searchImplicitScope = true.

CF-Version	Default Value of searchimplicitscope	Application Value of searchimplicitscope
2021 update below 13 or 2023 update below 7	TRUE	Your application value might override default value by Application.cfc or Application.cfm	if you have not overriden default value.Patch can be applied directly.But If you are overriding default value to make it false, before applying patch need to make searchimplicitscope=true
2021 update 13 or 2023 update 7	FALSE	Application default  value can be overriden by jvm.args and Application.cfc and Application.cfm	It is mandatory to override the default value and make searchimplicitscope=true by using jvm.args or application.cfm or application.cfc for this patch to work.

[Charlie Arehart]

And by not saying "or higher" for the second line in the table I suppose that's because it's expected that this fix would be rolled into the next update. But we should still expect this logging to happen going forward, if searchimplicitscopes is true (by setting or by default), right?

And there's no way to disable the logging, right? But before people lament that, this log (like application.log, mail.log, and others) will be limited by the cf admin logging settings max and rotation settings, right? 

[satyam-mishra]

@Charlie Arehart 
I don't think we have intentions to keep this logging feature in Cf going forward. For as many updates older(this may work with older updates ,but we have not tested) and upcoming , this patch works,  we are happy. 
We don't intent to include this as part Cf server codebase. It impacts performance of widely used scope search.
I think all admin settings for logs are still applicable.

[Charlie Arehart]

Thanks for that clarification, Satyam. Bad news/good news, I think.

First, I hope that decision may be reconsidered (about whether this logging will work in future updates). Many people who are not yet on these recent updates (or indeed are still on older cf versions) will trip over this issue in the future, when updating/upgrading. If tthey can't get this logging help then, they'll need to be told to first stop at this update as an intermediary step, to do testing, which will be awkward in time.

Some good news on this fix: I tested this hotfix with the current update and previous two (from Jan and Oct), and it worked with them (on both Cf2023 and cf2021). It did not work with the prior update (from Aug). 

I also confirmed the hotfix only reports on unscoped vars that are NOT resolved in the local scopes, which means it won't overreport on EVERY unscoped var. Good to see that, and thanks. 

[rickmaz]

I recently installed Update 12 and the log patch, and I was able to see the logs and fix most issues. Although there were a few outstanding items, I planned to revisit them later. After updating to 13, the code appeared to work fine, and now, with Update 14, everything seems good overall. However, I’ve noticed that the unscoped log has disappeared. I’m certain I had it installed before.

My JVM arguments are the same, but there’s no evidence of the patch. I still have it in my downloads folder, and I’m sure it was installed. How can I verify if the patch is still active? It’s possible my code is fixed and just not logging issues, but I would expect some indication that the patch is present.

I want to avoid assuming everything is resolved only to have problems resurface later. Could you assist with this?

[Dave Watts]

Create and run a test page with an unscoped variable in the application, and see what happens!

[Charlie Arehart]

Rick, it's that you need to add the patch in again after every update.

Sadly, this "patch" is unlike those from the past experience most have: where the "patch" was just something needed "until Adobe rolled it into the next update". Like ALL updates (since CF10 introduced the new update process), when you implement an update it REMOVES ALL FILES from the lib/update folder (where such a patch is to be put), replacing it only with the new update's "chf" jar. The problem is that Adobe has not bundled (and seemingly will not be bundling) this "patch" into any updates.

As such, you either need to a) download it again from the technote pointed to here, b) save it before doing an update, or c) copy it out of the "backups" folder created for each update (in the hf-updates folder for that specific update), where it is within its lib/updates subfolder. Then just put it in place again in the lib/updates folder for your instance and restart CF.

Let us know how it goes (and direct any dismay to Adobe, of course. I'm just a messenger.)

[rickmaz]

Thank you very much fo this. I will try that. And is there any way to know like in CF admin or anything after i put that .jar in lib/updates and restart if it actually took the patch?

[Charlie Arehart]

Rick, as is often the case, there's what may seem a "simple answer" but then more to it, which some will want to be aware of.

To be clear there is no "feature" or "setting" in the CF Admin which will reflect if you have implemented this "patch"--in the sense that an admin page will refer to enabling this logging, if that's what you may mean. But there IS at least a way to know if this (or any such special hotfix) has been applied.

1) If you look at either the "system information" page (via the "i" icon in the top right of the admin) or the "settings summary" page (via the first "server settings" section on the left), those pages report dozens of things, one of which is the "CF Server Java Class Path" for CF--and it lists what jars were found IN the variously defined class paths, as found by CF at its startup.

And if you do a browser "find" on either of those pages for the string "8888", that is how name of the jar begins, as downloaded from the Adobe technote about the patch (like the hf202300-8888889.jar filename for the CF2023 version of the file.  If it's found, it's been loaded by CF; otherwise, it has not. (And note that these will NOT show the file if you have placed the jar file in the lib/updates folder but have not yet restarted CF.)

You should also see in that list the chf*.jar that corresponds to whatever CF update level you're on. BTW, it's a bit odd that the Adobe technote referred to this hotfix as a "patch". All past such things were called "hotfixes", as indeed is indicated by the hf in front of the name of the jar here. (And the "chf" means "cumulative hotfix".)

2) One last thing: some may want to point out that the two pages above also offer an "update level", which some argue is "how you can know what update has been applied". That is not a complete statement: this reported value only ever shows ONE jar of any found in that lib/updates folder. If you have two or more, you will only see ONE. Granted, you MAY see this special hf file there, but it's just not reliable as what I proposed above (because in fact this WILL list files found in that lib/updates folder--even if you have NOT yet restarted CF!).

FWIW, the challenge of this listed "update level" is not new.  I had blogged about it back in 2012 in a post on helping people determine what update level they were on--which was all the more challenging for those then still on CF9 or earlier. I also reiterated it in a 2019 post I did on dealing with such "special hotfixes" as this one. And that's also where I warned how they are REMOVED during any subsequent update, but can be reclaimed from the hf-updates "backup" folder for the applied hotfix. 🙂

Hope that's helpful.

[Dave Watts]

I doubt that Adobe intended to drop a bomb on CF developers with this change. My guess is that someone found a serious security vulnerability with unscoped variables and reported it to the vendor (Adobe? Oracle?), and that left vendor(s) scrambling to fix it as quickly as possible. The best fix would be a magic wand that immediately converts unscoped variables to scoped ones. Sadly, that isn't available. The second best fix would be something that logs unscoped variable use so you can fix your applications without getting tons of error messages, and that's what Adobe just released. My understanding is that's all this latest update does - it causes these variables to be logged. So, you could set searchImplicitScopes to true, run the application, find the unscoped variables, and fix them more quickly. If you're on an older version of CF, there might not be a need to set searchImplicitScopes to true, except maybe that's what tells the logger to do what it does. I don't know if that's the case.

Dave Watts, Eidolon LLC

[Charlie Arehart]

Adding to Dave's helpful comment, I can confirm the hotfix does indeed do its logging if (and only if) the searchimplicitscopes is true, whether by default or by config at the app or jvm level. And it will log any variables that are unscoped and which would not be resolved in the scopes local to the request. 

If instead the setting is false (by default or by config), then any use of unscoped vars (that would search beyond the local scopes) will simply fail, as intended by the use of that false setting. 

[rickmaz]

So again confused

i installed the page i am on 2021 update 12 now i do see unscoped.log

for example one line

xxxxxxxxxxx\transaction.cfm:PAGE,scope:FormScope

so what exactly does this mean? no line item of the error? how would i even know where to look this code was not written by me and there are tons of lines in it.

[satyam-mishra]

@rickmaz 
xxxxxxxxxxx\transaction.cfm:PAGE,scope:FormScope 
this says: transaction.cfm which is located at xxxxxxxxxxx\transaction.cfm has an un-scoped variable PAGE.
With searchImplicitScope = true the value for variable variable PAGE was found in scope : Formscope.

This is a helper patch.This logs all un-scoped variable.
Because we recommend searchImplicitScope = false and un-scoped variables will start failing with this setting.
All variable needs to be scoped. Intentionally line-number is not mentioned, so that you search all the instances of variable PAGE in 
transaction.cfm and make it scoped.

[rickmaz]

And one more issue -- ingoing through my servers i have a client that has a shopping cart. He bought it a long time ago but the admin area folders to access the admin use application.cfm however since he did not purchase the unencrypted version there is some sort of encryption when i try to view the code?  so is there any way for me to put the searchimplicitscopes=true in there? if not what are my options? i assume use JVM flag but if so how long will that be good for? Please advise. 

[Dave Watts]

Wow, you have a lot going on here! First, yes, you can use the JVM flag, but no one can tell you how long that'll be around, and every day you use it your site - or your client's site - will be in danger. Second, there are ways to decrypt CF code, but Adobe doesn't like to publicize that too much for obvious reasons, and the shopping cart vendor might not like you decrypting the application either. If your customer buys an encrypted application and puts it on your server, you should let him know that it's no longer supported, and why. You shouldn't put yourself in a legal situation for something your client did.

My recommendation here would be to isolate the application in a separate CF server using that JVM flag and give the customer a set amount of time to get things sorted, maybe two weeks. Of course, I know next to nothing about the specifics here, so keep that in mind if you decide to go that way.

Dave Watts, Eidolon LLC

[satyam-mishra]

you can try jvm flag. This will work only if Application.cfm does not has searchimplicitscopes attribute.
jvm flag is a server level configuration but if Application.cfc or Application.cfm is present and has key searchimplicitscopes , jvm flag will be suppressed (Higher priority to application files.).

The other way would be to replace Application.cfm file with a newer file.

Third option is to get file decrypted.

[rickmaz]

Thank you 3rd option wins 🙂