Lucee Vulnerability Details Published

[timsayshey]

Just received the following email from Foundeo, and CFWheels has at least 2 security issues I noticed right away.

In the processAction function there is a call to isDefined that passes a dynamic value which is concerning. And another one in the cfmlerror.cfm, there may be more but I'm pressed for time so just dropping this here for the community to dig into.

---

Last week a security researcher published details on three Lucee vulnerabilities: https://blog.projectdiscovery.io/hello-lucee-let-us-hack-apple-again/

Please note the following only applies to those running the open source Lucee CFML server, if you are running Adobe ColdFusion this does not apply.

• A Remote Code Execution (RCE) on isDefined, StructGet, Empty functions
• A RCE on CF_CLIENT cookie values, requires clientManagement to be enabled.
• A RCE on REST CFC requests, which was patched in 2023: CVE-2023-38693

Lucee Allows RCE when a variable can be passed to the isDefined, structGet or Empty functions.

Examples of Vulnerable Code:
isDefined(url.x)
isDefined("#url.x#")
isDefined("url.#x#")

The following is not vulnerable, because it passes a static string to the function, and does not pass a variable value:

isDefined("url.x")

I have updated our Fixinator product to scan for this issue in your application code.

You will find that isDefined might be used a lot in your code, but many will not be vulnerable because they are passing a static value, but if you do pass a variable to isDefined, structGet or Empty - you will want to rewrite that code, or upgrade to Lucee >=6.0.1.59 and set the settings:

System Property
lucee.security.limitEvaluation=true

Environment Variable:
LUCEE_SECURITY_LIMITEVALUATION=true

Application.cfc:
this.security.limitEvaluation=true

Fixinator now also looks for the this.security.limitEvaluation setting, and suggests that you add this.

The second issue, pertaining to the CF_CLIENT cookies, I've found that a good mitigation against this is the following:

1. Add this.clientStorage="memory"; and this.clientManagement=false in your Application.cfc or cfapplication tag in Application.cfm

2. You can also attempt to block this at the web server level, by looking for CF_CLIENT in the Cookie header. For example here's how you can do this on NGINX:

if ($http_cookie ~* CF_CLIENT) {
return 404;
}

Something like this might work on Apache (I haven't tested this one yet):

RewriteCond %{HTTP:Cookie} ^.CF_CLIENT.$ [NC]
RewriteRule .* - [F,L]

Finally I've also updated fixinator to look for this.clientStorage in your Application.cfc/cfm, and I've updated FuseGuard to look for this cookie onRequestStart (as of FuseGuard 3.6.0).

If you are running Lucee, you should spend some time looking at your code to see if you may be impacted by this issue.

--
Foundeo Inc.

[timsayshey]

@chapmandu @neokoenig @bpamiri - Should we be concerned about this?

[dbelanger]

Hey Tim, I saw this too and and was looking into how exposed we are in our projects. There was a suggestion on the CF Slack from Brian at HoyaHaxa that MasaCMS did the following to mitigate the attack:

I see that the Masa patch added a check like isValid('variableName',the.var) -- so that may be a way to go here, in terms of fixing any custom code -- in addition to enabling the Lucee setting to limit evaluation

They stuck that command right in front of isDefined() and it seems to do the trick.

The "limit evaluation" option on Lucee was offered after version 5.4.5.8 and some have reported weird effects when enabling it.

[timsayshey]

Thanks David - Yeah, I think Plan A sounds like the way to go. Messing with Lucee settings and requiring Lucee upgrades should be a last resort.

[bpamiri]

Let me reach out to Pete and see if I can get him to do a code review of our codebase. I’ll post more when I have had a chance to speak with him.