Folks here will want to know of an extended post offered today on the ProjectDiscovery blog, elaborating on a Lucee vuln–an RCE or remote code exploit. While the Lucee team has indeed addressed it, you’ll want to be sure you’re on the update that’s fixed. Once news like this is publicized, hackers go nuts seeing who they can break into. The blog post has all the details.
And don’t be misled by the blog title and its reference to “Apple”: it’s NOT about Lucee running on MacOS. It’s about their breaking into Lucee as they found it running some apps on servers at Apple, the company (on Linux, in their case, as indicated in the previous post they link to). Of course, it’s compelling to be reminded Apple runs Lucee.
For those who don’t know, that projectdiscovery site is where hacks are discussed and dissected by responsible security researchers, after vendors have been notified and given time to respond. (They’ve dealt with ACF ones also, of course.) And those who read to the end will see they made US$20,000 from Apple for their efforts this time, and a whopping $50k for the previous one. Nice payday, if you’re looking to try to make some coin doing such research–and you’ll help the community at the same time.
Thanks, Charlie! Which versions of Lucee are vulnerable? From what I can tell it seems like the answer is “all of them”, unless you’re running Lucee 6 and have tightened some security settings.
It’s kind of confusing because the blog post mentions several different vulnerabilities, some of which are in Lucee, some of which are in Mura CMS, and all of which seem to depend upon specific server/application configs.
The one that concerns me most is the cookie parsing vulnerability discussed in the “Attempt 3” section of the post. That one looks like it’s a Lucee vulnerability that is only addressed as of Lucee 6.0.1.59-SNAPSHOT, and then only if you’ve taken active measures to disable the dangerous behavior. See the referenced commit:
and the response from the Lucee team describing the countermeasures:
Oh yes. The old “backwards compat is more important than automatically protecting ppl from a critical vuln” thing.
I’d forgotten about that.
Yeah TBH I checked our code and we’re never looking at cookie values beyond “does it equal this static value”, and never passing anything outwith our control to any of those functions, so figured we’d be OK.
But yer question - in general - is def a good one. I’ll shaddup and let someone who knows definitively answer
It should be back ported to 5.x per-policy, not withheld to 6.x surely ?
It also sucks we have to add boiler plate to every single CFML project we have, instead of Lucee being secure by default and allowing people to opt in to the old, rare, insecure behaviour if they need it and can’t migrate their code.
I’ve posted a blog entry on this: Lucee RCE Vulnerabilities February 2024 with some info on how to identify / fix the vulnerable isDefined, structGet, empty calls, as well as some other info to help defend against this.
That’s wonderful, Pete. Thanks. And Pete’s post does a great job not only answering some of the questions asked here, but also offers still more examples of code to test things than were offered in that original projectdiscovery post last week.
I must say I was a little surprised by the lack of response to it back then. No replies until Leon’s yesterday. I thought it would have generated such discussion, as it seemed pretty serious. I was just getting that initial news out ASAP, hoping to spur further discussion. So I’m really glad that since then both Pete and Brian (referenced in Pete’s reply) have since offered more info, in addition to replies here so far.
And some questions remain, so I hope folks in positions of responsibility may reply (such as to Drew’s last question). I do appreciate that security issues are SO sensitive, and some feel reluctant to speak up without careful consideration. (I was assuming that was some of the reason for the silence the past week. Glad to see others calling for more discussion/clarifications.)
One more little tidbit: if you read any of the 3 blog posts, you’ll see mention of an aspect of this vuln having to do with a cookie that Lucee uses (and per the vuln, processes in a surprising way), whose cookie name starts with cf_client_ followed by the name of your app. See the posts for more on that.
I just want to clarify here (for any who may be interested) that this is WHOLLY UNRELATED to the vuln that CF had last year, regarding instead an _cfclient query string, used by bad actors to hack the stupid cfclient mobile feature (which few used, but this querystring could start a hack even if you didn’t use the feature).
My point is that while these are similarly named, they are not at all related. I discuss that and a bit more in a blog post I just did, pointing out the vuln, this this thread, those other 3 posts, and this last point of clarification. No, that “clarification” is not “important” to Lucee folks…unless they may talk to CF folks or somehow read about that other matter. I just thought it worth mentioning as another datapoint in this discussion.
Am I correct in believing that the Cookie RCE only works if the Client Storage is set to “cookie” (this.clientStorage = "cookie";) and Client Management is enabled (this.clientManagement = true;)
I tried to reproduce it, but I’m only able to trigger it if both conditions are met.
