How to protect your Minecraft client or server from the log4j exploit (aka CVE-2021-44228 or Log4Shell)

# How to protect your Minecraft client or server from the log4j exploit (aka CVE-2021-44228 or Log4Shell)

asanetargoss, 2022-01-07

CVE-2021-44228 is a Remote Code Execution bug in the log4j library which affects a lot of the internet. It has since been fixed in the latest log4j version, and the fix has been backported to an older version. It is scary for Minecraft because it lets any player on a server instantly hack both the client and server with just a chat message.

There have been lots of efforts by vanilla and modded devs to mitigate this bug. But I will be frank: you are much better off assuming that you are vulnerable to the exploit, unless you can prove otherwise.

Also, modded is more likely to be affected by this bug, but the reasons are nuanced and not the fault of the modded community as a whole. Overall, I think the modded community has done an excellent job of responding to this security issue.

## Scope of vulnerability

Players' games may be affected by CVE-2021-44228 if they are playing multiplayer, or if they are using a mod that adds chat in singleplayer. Certain actions by the player, like pasting commands or other content into the game, may also allow for exploitation of CVE-2021-44228.

Vulnerability is more likely if the player is playing modded Minecraft, using a third-party launcher, or running a dedicated server.

Again, assume you are vulnerable unless you can prove otherwise. See the "Check for vulnerability" section

## Server vulnerability

If you are running a Minecraft server (even a vanilla one), your server is most likely vulnerable. See this article for how to patch your server to mitigate CVE-2021-44228:

https://www.creeperhost.net/blog/mitigating-cve/

I also strongly recommend you whitelist your server, especially if it is on an older version, and only share the server with people you trust.

## Client vulnerability

The best way to protect your client is to use a launcher with an updated version of log4j. The MultiMC website has an excellent article on what to look for to make sure your client is using a fixed version of log4j:

https://multimc.org/posts/log4j-remote-execution.html

The following Minecraft launchers protect players from CVE-2021-44228 in both modded and vanilla, provided they are up-to-date:

- MultiMC [^multimc_security]
- FTB Launcher [^ftb_security]
- ATLauncher [^at_security]
- GDLauncher [^gd_security]
- Curseforge Launcher [^curseforge_security]
- Technic Launcher [^technic_security]

The vanilla launcher only claims to protect you from CVE-2021-44228 if you are playing vanilla, so I do not recommend using it to play Minecraft.

## Check for vulnerability

There is a commonly cited chat message (`${date:YYYY}`) to check for log4j vulnerability, however, as I have unfortunately discovered, it's not correct for all Minecraft versions or software configurations. [^why_not_date] Below is the test I've used.

For this test, you should choose a URL, ideally localhost, that does not exist and is on a domain that you control (such as `localhost:8000/test`). You do NOT need to run an LDAP server to test for vulnerability in this way. [^server]

The steps to test the vulnerability are as follows:

1. Run a Minecraft client and/or a *private* Minecraft server
- You will most likely freeze Minecraft, so use a test world or make a backup
- If you want to test a Minecraft server, I strongly recommend you run a localhost Minecraft server on a non-standard port (ex: 35565) that is not accessible to the outside world (i.e. firewall is running and isn't open on that port). You DO NOT need to connect a Minecraft client to the Minecraft server to test the vulnerability of the server.
2. Make sure your chat log is working by typing something in chat
- If testing the Minecraft client, open up a test world and type in chat `test`
- If testing the Minecraft server, from the server console type `say test`
- Look in your Minecraft log files and check for your chat message
3. Check for the vulnerability
- If testing the Minecraft client, open up a test world and type in chat `${jndi:ldap://localhost:8000/test}`
- If testing the Minecraft server, from the server console type `say ${jndi:ldap://localhost:8000/test}`
- Check your Minecraft log files again and check for that chat message. If you **don't** see a chat log message reporting exactly what you just typed in chat, your Minecraft is most likely vulnerable to CVE-2021-44228, and you need to fix it!

After you are done, close and/or forcefully terminate (kill -9, force quit, etc) the Minecraft client and/or server.

## Techniques to avoid

The security fix for the vanilla launcher, as posted by Mojang, doesn't work for modded Minecraft.

## Version vulnerability

If you're in this camp, perhaps wondering if your older Minecraft version has been fixed, here is my advice to you: Don't trust a spreadsheet! While modding APIs like Forge have released security updates for some versions, other versions (in particular, older versions), have not been updated. Therefore, you'll need to rely on some other fix (such as using an updated version of a Minecraft launcher that protects you). Even if you were told by someone that your particular version or modded configuration is safe, check for the exploit regardless. Better safe than sorry.

## Other options

The [Healer mod](https://modrinth.com/mod/healer/) is a potential option to fix the log4j exploit. I have not tested it yet. It is a version-agnostic mod for Forge for 1.7.10-1.12.2. (I theorize it may also run in 1.6.4, but I have not tested it, so YMMV)

## Mod development environments

Mod development environments can also be vulnerable to the log4j exploit. If you re-run gradle setup scripts, your environment may (or may not) receive a patched version of log4j.

## Further reading

If you are interested in more details of CVE-2021-44228, check out the links below:

[LunaSec blog article on Log4Shell](https://www.lunasec.io/docs/blog/log4j-zero-day/)

[NIST database entry on CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228)

^ Jump to top

[^multimc_security]: https://multimc.org/posts/log4j-remote-execution.html

[^ftb_security]: Mentioned in the [Creeperhost article on server mitigation](https://www.creeperhost.net/blog/mitigating-cve/)

[^at_security]: As of January 3, 2022, their [homepage](https://atlauncher.com/) states the launcher was patched on December 18, 2021

[^gd_security]: A forum user has [screen-captured an announcement from a developer on an instant messaging platform](https://old.reddit.com/r/feedthebeast/comments/rdrsyz/gdlauncher_has_now_fully_fixed_the_critical_log4j/)

[^curseforge_security]: As of January 3, 2022, the Curseforge launcher team has not made an official announcement on CVE-2021-44228 on the Curseforge website's blog or any of their publicly listed social media accounts. However, [hidden deep within their support system](https://support.overwolf.com/en/support/solutions/articles/9000196615-curseforge-known-issues) is a section that says that the Curseforge launcher protects players from the exploit.

[^technic_security]: As of January 3, 2022, [a blog post](https://www.technicpack.net/article/log4j-vulnerability-fixed-in-launcher-build-707.177) says the exploit was fixed "3 weeks ago"

[^why_not_date]: Making Minecraft print the date in the server logs (or worse, a handled exception) is annoying bug, but very importantly, it's *not* a security bug. One of my Minecraft clients, which is mitigated against CVE-2021-44228, is vulnerable to the `${date:YYYY}` bug, but importantly is not vulnerable to the actually serious `${jndi:...}` security bug. What's the likelihood that some Minecraft configuration is not vulnerable to `${date:YYYY}`, but is vulnerable to `${jndi:...}`? The likelihood is certainly not zero. Therefore, I recommend testing `jndi` directly, with caution, and also generally using common sense when considering whether to connect to, or run, a modded Minecraft server.

[^server]: For educational purposes, one may want to run a localhost webserver on a port not allowed through the firewall, on the port that Minecraft will try to talk to. That is what I did, and hence why the port I selected happens to be 8000. :) (by the way, don't run Python 3's http.server on the actual internet, as it is probably not secure)

^ Jump to top