Moresteck
- Moresteck
- moresteck
- Europe/Stockholm
- Yes
- No
2 issues
Key
Summary
Status
Reporter
Assignee
Created
MCL-14918
MCPE-159935
MC-245918Added Affects Versions: 2.2.7264 (NEW Windows App) 2.2.7266 (Linux) 2.2.7268 (Mac) 2.2.7265 (Windows) 2.2.2040 (macOS - 10.9 only)
Added Affects Versions: 2.2.7450 (NEW Windows App) 2.2.7449 (Mac) 2.2.7448 (Linux) 2.2.7447 (Windows)
The hashes of the client jars are identical, meaning both versions are identical. The differences in dependencies and name given in the launcher 4 YEARS after this version came to existence do not change the fact that rd-161348 and the so called rd-20090515 are the same version.
About the dependencies: rd-161348 runs just fine without launchwrapper and asm-all, because it simply doesn't require both of them, so it's not a surprise that the so called rd-20090515 doesn't need them to run.
TL;DR the additional dependencies declared in the rd-161348's json are redundant.
I suggest to finally fix this issue and remove the duplicate rd-20090515 from the launcher.
Not only is its name misleading (it's not a version from 15th May), but also the name's format is not universal (rd-yyyyMMdd instead of rd-ddHHmm)
It literally just takes to redirect requests coming to:
www.minecraft.net/game/joinserver.jsp
www.minecraft.net/game/checkserver.jsp
to:
session.minecraft.net/game/joinserver.jsp
session.minecraft.net/game/checkserver.jsp
I guess that's too hard to do for Mojang...
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.
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
> Legacy auth, Mojang auth, and Microsoft auth work in dramatically different ways, but rather than debating that point here and flooding inboxes in the process, I'm just going to wait for a Mojang employee to respond to my question. I highly doubt either of you have more info than I do considering the announcement was made only 2 days ago.
I can assure you, that it doesn't really matter if you use a legacy, Mojang or Microsoft account, their APIs are in fact very much tied. session.minecraft.net which is used for client-server authentication can be served access tokens obtained from Mojang, as well as from Microsoft. I can't say for sure about legacy accounts, but I bet it's the same for them, as they also use the Mojang's sessionserver to work. So unless that endpoint's behavior changes, it's all going to work. Perhaps Mojang accounts could no longer give you access tokens upon login since March 10th, but I don't think a discussion like this fits into the issue's topic.