Lucee is not affected by the Log4j JNDI exploit CVE-2021-44228

news
1

The Lucee team did testing and code reviews on Friday and Lucee is not affected

  • Lucee uses an older Log4j 1.2.17
  • In general, OSGI also mitigates/minimises these vulnerabilities
  • if you’re using an old JVM you have other problems to worry about
  • Tomcat is not affected either

image
image800×359 31.2 KB

the basic version of the POC is pretty straight forward

<cflog text="${jndi:ldap://127.0.0.1:1389/cflog}">
<cfscript>
    systemOutput("${jndi:ldap://127.0.0.1:1389/systemOutput}");
</cfscript>

then you can use a command line tool (or GUI) like nc on unix to monitor connections to that port

nc -v -l 127.0.0.1 1389

(use a different port if you are running a local LDAP server!)

to test the port monitoring is working, run curl http://127.0.0.1:1389/curl which will show you in via nc any attempted connections to port 1389

Then run the above cfml script, if Lucee was vulnerable you would see connections to port 1389, all that happens is you will see the raw JNDI strings in the logs / console

Lucee 6.0 will be updated to the latest log4j 2.x release

Obviously you are going to be getting a lot of spam traffic trying to test for this, don’t do this, however tempting it maybe!

Also note any basic WAF rules are easily bypassed

9 Likes
9

Given that Log4j security vulnerabilities are being examined and exploited, does Lucee recommend anything with regard to this CVE: CVE-2019-17571 : Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be explo

10

Lucee OOTB doesn’t listen on a socket for logging data…

2 Likes
11

Got it.

Thanks @Zackster! Just trying to cover all my bases. Really appreciate the clarification.

1 Like
12

It’s worth noting that Log4J 1.x is EOL and known to be vulnerable to multiple RCE exploits. Using it as cover from Log4Shell is a pretty terrible strategy.

Further, the way I read it, this report indicates that ALL versions prior to 2.15 (which includes 1.x) are affected. Remote code injection in Log4j · CVE-2021-44228 · GitHub Advisory Database · GitHub

Any Log4J version prior to v2.15.0 is affected to this specific issue.

The v1 branch of Log4J which is considered End Of Life (EOL) is vulnerable to other RCE vectors so the recommendation is to still update to 2.15.0 where possible.

I can’t find any references to it at the moment but I feel like I’ve also seen some people using the java version as cover, and apparently that is also not good enough:

https://twitter.com/Laughing_Mantis/status/1470412026119798786

1 Like
13

Not sure if this is a silly question – can we update the version of Log4j that is currently shipped with our install of Lucee? Or, will that break other Lucee core code?

8 Likes
14

It does read that way, but I don’t think it can be right given that the JNDILookup functionality was only added in version 2.0-beta9 according to this admirably clear CloudFlare article.

3 Likes
15

Thanks for clearing that up. I don’t think it changes my point that we should not just relax knowing that 1.x is not vulnerable to log4shell. If anything, this event has shined a spotlight on log4j and now the frequency of attempts using known old exploits are likely to increase because of new awareness.

Just to make sure that it doesn’t get buried by these replies, I want to echo that I too would like to know the answer to @bennadel’s question:

can we update the version of Log4j that is currently shipped with our install of Lucee? Or, will that break other Lucee core code?

4 Likes
16

I’ve also read in this adobe thread, in which @carehart mentions, that ACF uses log4j for cflog/writelog, and that would probably limit the surface of attack in a certain way to those tags. Would that apply also to Lucee?

I know that is not a big relief for most of the admins, but for those who run their servers alone with their own code, wouldn’t it help to just not use those tags for now (until we can get the lib updated)?

17

I have a concern that we may be using 3rd-party Fat JARs that may have a problematic version of log4j internally. A “fat jar” / “uber jar” is essentially (as I understand it) a JAR file that has all its dependencies baked into it. I’m trying to inspect some of the JAR files using:

jar tf /path/to/jar/file

Which gives me a massive manifest of entries. The problem is, I’m not really a “Java guy” and I don’t really know what I’m looking for. Has anyone thought to do something like this? Any tips on what I might keep my eye open for?

18

@bennadel This tool (recommended on Slack by Tom King) seems good and simple to use.

2 Likes
19

Thank you. I will look at how it works, and I will also pass on to my SEC team!

20

@Julian_Halliwell @bennadel That Logpresso scanner is nice. Requires VC Redist 14 x64. (Link to download that from MS here: https://www.microsoft.com/en-us/download/details.aspx?id=52685)

I ran this on our Lucee dev instance against c:\lucee, found 0 vulnerable – as expected, since it’s log4j1.2 and not the 2.9 > version > 2.15 vulnerable versions.

I’m looking at the Lucee Admin > Bundles (Jars) and see jog4j 1.2 is active and located C:\lucee\tomcat\lucee-server\bundles\log4j-1.2.17.jar

Wondering about manually upgrading this – how can I tell Lucee to use the 2.15 if I drop that JAR in that directory? Is there a specific Lucee config file to edit to load that jar instead, or in place of? Perhaps like the automated scanner, renaming the 2.15 version to match the expected filename, but I would rather not do that.

Anyone have an actual update process to share?

2 Likes
21

@bennadel There is also another tool here

which I have wrapped up inside a nice standalone CommandBox Task Runner which will download what it needs and scan any folder of jars recursively for vulnerable jars. (It scans the folder resursivley and then scans each jar it finds recursively as well)

Run the task like so in CommandBox. You can just point it to an entire server home if you like.

task run :scanPath="D:\path\to\jars"

Plus, if you run your Adobe ColdFusion or Lucee servers via CommandBox you can apply the JVM arg to mitigate against this vuln globally like so (For ACF servers, make sure you’re on the latest updater to ensure this JVM arg will get picked up. Lucee doesn’t bundle a version of Log4j new enough to use this JVM arg, so it would be if you had your own Log4j jars on the classpath.)

config set server.defaults.jvm.args='-Dlog4j2.formatMsgNoLookups=true'

And then restart any running servers.

2 Likes