Big change was noted in the tech notes for this ColdFusion Update: _“*Starting with this update*, ColdFusion will default to

searchimplicitscopes=FALSE

and if a variable name is not prefixed with a scope identifier, an error is returned._” - I wrote up a blog entry with some info here: https://www.petefreitag.com/blog/cf-searchimplicitscopes/ but really this is quite a major change, and will require extensive testing for most

I thought that was just for URL/Form scope stuff? I'm assuming it's going back to the CVE that was posted

Is there some documentation on what Adobe considers "implicit" scopes?

Still searching, but so far I have found a small bit in this post. https://helpx.adobe.com/coldfusion/using/language-enhancements.html

I would assume they've targeted scope-hunted scopes which can be influenced by the client • form • url • cgi • etc

Agreed. It sounds like "implicit" refers to things outside scopes that the code should be modifying/affected by the web server in some way.

The CVE I remember seeing allowed for poorly formatted WDDX submitted via the URL or FORM scope that allowed it to read files off the filesystem... (kinda stretching here, it was a while since I read it)

Possibly even scopes like query, assuming their list of things was exhaustive.

I did find it interesting about the section for the cfdocument, I mean if you put a file:// into an iframe and render a pdf, it could put the file contents into the PDF

+1 @Chad Norris. I have not looked at the patches at all, but that caught my eye as the possible source of CVE-2024-20767. And/or maybe something related to CKEditor/file uploads

Seems a little heavy handed to make such a drastic change to scoping if the vuln requires you to have some sort of arbitrary code using variables in a certain way. I mean, CF still supports

evaluate()

for crying out loud, with just a note saying, "Hey idiots, don't pass random stuff into this". The same sort of general warning always applied to unscoped variables IMO.

I know in the past Adobe has released patches/changed functionality to address the potential of user-supplied vulnerable code constructs -- which could be the case here, for a user-controlled

<iframe>

in a

<cfdocument>

Yeah, I don't tend to use most of those scopes directly since ColdBox abstracts them into the rc, but I can't help but think this could be a major sticking point for anyone with legacy code that uses a lot of url/form scoped stuff.

I bet it's related to this : https://blog.projectdiscovery.io/hello-lucee-let-us-hack-apple-again/ Scenario 3.. While this was written about Lucee, they mimicked behavior that was in ACF.

Unscoped vars are always something you have to think about. Years ago we had some code in the ColdBox core that use an unscoped refence to a variable which could be null in some cases. Setting the var in

url

would allow you to "inject" it basically. That was just bad code on our part and we fixed it.

yeah, this is confusing to me because I when I read the tech notes I think there must be more than one vulnerability addressed here. But only one CVE is listed, with an impact of arbitrary file system read.

Right, which is still an issue if you have

<cfset variables.name = url.name>
<cfdocument>Hi #name#</cfdocument>

@foundeo or this one... command execution via Lucee Job Scheduler 🙂 - https://www.exploit-db.com/exploits/51333

Lucee could help that if they'd work to lock down their admin better. Adobe has done a good job of this.

Re: implicitScopes -- I have asked for clarification to see if I'm to blame for that one....if so...I'm sorry 😂

Thanks Brian, I’m hoping you get some clarification. It would really help CF developers if Adobe could clarify what the risk of searching implicit scopes is. Does it directly cause the “Arbitrary file system read” issue, or is it indirect (like my example above). If indirect then folks can probably take their time a bit more on updating the code. But if there is a direct risk, then they probably need to get to work on it right away.

And if it is "indirect", I'd rather this sort of breaking change be rolled out in a major release of CF, not in an update for potentially-unrelated security fixes.

Will do. I think it's a very, very slim chance (at best) related to something I reported

Is that the XSLT change that literally renders the XMLTrandform() BIF useless out of the box?

Yup, that's the one

BIF = ? To the uneducated.

Built In Function

cool. I can't see anything in the updates notes about XMLTransform. What have they done? We don't use XmlTransform any more, we've rolled our own Saxon implementation. Would be good to know what they've done (for future and others).

That was a previous update, not today's

gotcha

Back in 2022

Ok cool thanks. Regardless of the massive change (and the baby may have been thrown out unnecessarily, we shall see), it's good to see ACF focusing on security as their #1 priority. And seems bug fixing is becoming their #2. Internally we have about a months worth of changes to our monolith to deal with unscoped vars. We see it as a time to tidy up our codebase (and reap some performance gains).

Didn't see any mention in the release notes of the SQL server breakage issue we've been hung up on with Update 12, possibly earlier, but @priyank_adobe said it was. Anyone have a read on that? @Sid Wing maybe?

It's in there

In the release notes, or in the patch?

It's in the "Bugs fixed in this update" section of the release notes

Yeah, just not in the quick summary version. Have you applied this anywhere yet?

Not yet - we have a scheduled outage for thursday night for windows updates - I hafta get through THAT first

Kind of is a drag that we have to deal with the implicit scope stuff to try this, even if it's just to shut that off.

THAT is the main reason I didn't immediately start testing it today

Yeah.

@Dave Merrill @Sid Wing You can skip the implicit scope change by passing in the jvm.config arg for now. Just can't do that in CF2024 when it comes out ...

Will the ability to override this in Application.cfc be removed too?

Adobe would need to confirm, but I'm guessing it would be completely nuked going forward.

Agree

the jvm arg was added in this update

For 2023 as well as 2021 I assume?

Yep it was added in this update: https://helpx.adobe.com/coldfusion/kb/coldfusion-2021-update-13.html Search for -Dcoldfusion.searchimplicitscopes=true

@Dave Merrill the new jvm flag that was added in this update will be removed in the next release.The application variable searchimplicitscopes will remain unchanged

@foundeo, As majority of the fixes in this update have been done for internally discovered vulnerabilities, CVEs have not been filed for them, nor can we mention all of these vulnerabilities, as doing so could create opportunities for exploitation. However, one CVE that was raised and is included in this update has been mentioned. Additionally, the iframe issue, which was a known problem, has been addressed is separate from the scoping issue. Arbitrary file system reads cannot be directly performed using unscoped variables. However, unscoped variables did contribute to exposing variables that could be manipulated. We have removed many folders and files, as detailed in the release notes, which could potentially aid in arbitrary file read, write, or update. @Dave Merrill, We are considering discontinuing support for unscoped variables entirely due to the significant threat they pose. While we are not certain of the team's direction at present, we anticipate revoking support for such variables sooner rather than later.

@Satyam Mishra Can you confirm if CVE-2024-20767 is the iframe issue, or are those two separate vulnerabilities?

Note: Adobe has updated the recent patch posts with further details on the scope variable and cfdocument changes. https://helpx.adobe.com/coldfusion/kb/coldfusion-2023-update-7.html https://helpx.adobe.com/coldfusion/kb/coldfusion-2021-update-13.html

Thank you @Satyam Mishra for jumping in here. I've been dealing with this stupid virus I got last weekend and just saw this. To generally answer the questions raised here, yes it really is serious enough to warrant this change. Once I can add more details I will.