[MC-245918] Update log4j to safe version

Hi there,

on the announcement page for Minecraft 1.18.1 it states

This release fixes a critical security issue for multiplayer servers

which I assume references the recent log4j vulnerabilities.

After upgrading to 1.18.1 I noticed that the vulnerable versions are still being shipped! In %APPDATA%/.minecraft/libraries/org/apache/logging/log4j there are the following files:

log4j-api/2.14.1/log4j-api-2.14.1.jar
log4j-core/2.14.1/log4j-core-2.14.1.jar
log4j-slf4j18-impl/2.14.1/log4j-slf4j18-impl-2.14.1.jar

I manually deleted them, restarted the launcher and game. The game automatically re-downloaded them again. I found that %APPDATA%/.minecraft/assets/log_configs/client-1.12.xml now contains a patched PatternLayout

<PatternLayout pattern="[%d{HH:mm:ss}] [%t/%level]: %msg{nolookups}%n" />

But according to the log4j developers, this setting is NOT SUFFICIENT to mitigate the security problem. So please update log4j to a safe version in order to protect your users.

Attachments

1.7.10-fixed.json

Comments 13

violine1101 2021-12-22T15:04:12Z

If you believe that a security issue still exists, please provide a proof of concept in a private bug report.

The fact that the log4j2 version being outdated is not sufficient for showing that the exploit still affects Minecraft.

At this point we're not aware of any log4j2 exploit that could be used in conjunction with Minecraft.

brian worrell 2021-12-24T23:17:40Z

Per Apache, you have to have log4j version 2.17. Anything lower is vulnerable. Previous mitigations are being seen to be ineffective at this time.

Log4j – Apache Log4j Security Vulnerabilities

Moresteck 2021-12-30T22:18:01Z

DO NOT mark this as resolved, as the issue wasn't even understood by the moderator.

Here I post what in my opinion the developers should do to properly fix the vulnerability in all affected versions:

1. For versions 17w15a and later, bump the log4j version to 2.17.1.

2. For versions 13w39a to 17w14a, bump the log4j version to 2.17.1, add com.mojang.patchy as a library, and change log4j configuration version from 1.7 to 1.12.

I attached a sample of a fixed Minecraft 1.7.10 json in the issue, so that everyone can test it and see for themselves if it works.

tryashtar 2021-12-30T22:24:44Z

And what exploit would be averted by making these changes? Please share a proof of concept

brian worrell 2021-12-30T22:35:27Z

Tryashtar. Why submit a POC, when news stories already showed the POC in action for Minecraft and how it was exploited? Or the fact that the Open source software creator / maintainer is saying that the critical issues are not addressed unless you are at a version of at least 2.17 (The issue resolved in 2.17.1 is important, but is not aC CVSS of 9 or higher like the others).

You risk the safety of your users by not patching this vulnerability.

3 more comments

tryashtar 2021-12-30T22:36:42Z

The only known issue with minecraft has been patched. You can verify that the publicized steps to reproduce no longer have an effect. If you think it has not actually been patched, or think there is an additional issue that is not known, please share different steps to reproduce. We will immediately escalate the issue

Moresteck 2021-12-30T22:48:21Z

I'm just gonna drop a quote from Log4j – Apache Log4j Security Vulnerabilities in regard to the referenced security vulnerability:

— Older (discredited) mitigation measures

— This page previously mentioned other mitigation measures, but we discovered that these measures only limit exposure while leaving some attack vectors open.

— Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.
— [...]
— The safest thing to do is to upgrade Log4j to a safe version, or remove the JndiLookup class from the log4j-core jar.
The highlighted words describe what Mojang has done in that matter - Apache says it's insufficient.
I don't know in what other way this vulnerability can be exploited, but if Mojang claims that the taken measures are enough, I demand proof for that.
Until I get a conclusive response, I'm going to use self-patched jsons to play on multiplayer servers.
If this doesn't convince you, I can only wish that it won't get exploited in any way.

Take care

tryashtar 2021-12-30T23:03:28Z

That sounds quite reasonable to me. I appreciate your genuine care in this matter.

The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.

Hopefully, these code paths cannot be triggered in minecraft. You are very right, upgrading is the ideal solution. That is why I much respect your decision to patch yourself. And though it may seem needlessly risky to wait for a potential disaster to strike before addressing the problem, that is the standard Mojang has chosen with regards to library issues on the bug tracker. Personally, I believe they have looked into the matter thoroughly, and I expect to see more actions taken on this vulnerability. It would be nice to not require users running older versions to patch the issue themselves; to me that is a more pressing matter that likewise would not be valid as a bug on this website.

Anyway thanks again, I'm glad to see such swift action and concern from developers and users alike both here and elsewhere in the software world regarding the vulnerability 🙂

Vegard Bakke 2022-01-20T17:46:38Z

The shipped version of log4j-core-2.14.1.jar may be patched. But I get security alerts and our IT security will remove this file.

Not only is the shipped log4j version listed as a vulnerable version.
It contains org\apache\logging\log4j\core\lookup\JndiLookup.class.
~~If you fingerprint the jar-file, it has even been tampered with.~~ (Oops. Sorry. I crisscrossed)
And the JAR-file still containes the vulnerability, (even if Minecraft may be blocking the exploits).

Lot's a reasons that a security scanner will identify the shipped jar file as a security risk.

I don't understand why we can't upgrade to a known not-vulnerable version og log4j.

Best regards : )

CM 2022-02-19T14:32:34Z

Hopefully this is actually resolved soon...Nessus flags this every time it runs against my (personal) MC server. I'd think that it'd be straightforward to follow Apache's guidance and move up to 2.17.1, as they say that every version older than that has issues.

https://logging.apache.org/log4j/2.x/

CM 2022-02-19T14:38:39Z

@tryashtar, any way to get this reopened?

CM 2022-02-19T14:47:42Z

I'll add as well – you can't just remove the .class file from the log4j jar, because it detects that you modified the jar, and re-extracts it >.<

Expected file libraries/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.jar to have hash ade7402a70667a727635d5c4c29495f4ff96f061f12539763f6f123973b465b0, but got dd6b13ef700b6efff3dbb268a3cd4592f7f2ed4617a6a86e5f4ec988bb500d05

Unpacking org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.jar (libraries:org.apache.logging.log4j:log4j-core:2.14.1) to libraries/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.jar

Vegard Bakke 2022-02-19T20:48:19Z

My solution is to delete the jar file after every time I've played, to avoid being called up by the security next time they scan.

Not ideal, but works