Moresteck

Issue also affects Windows 10, confirmed by screenshots posted in MC-280311

Can confirm on macOS 15.3.1, aarch64 (M1 mac mini 2020). Additionally, joining the world causes the game to crash with:

java.lang.IllegalStateException: Couldn't perform copyTobuffer for texture 2: GL error 1282
    at fiu.a(SourceFile:352)
    at fiu.a(SourceFile:319)
    at frl.a(SourceFile:66)
    at grq.a(SourceFile:644)
    at grq.b(SourceFile:637)
    at java.base/java.util.Optional.ifPresent(Optional.java:178)
    at grq.o(SourceFile:632)
    at grq.a(SourceFile:520)
    at frd.c(SourceFile:1351)
    at frd.f(SourceFile:935)
    at net.minecraft.client.main.Main.main(SourceFile:265)

> 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.

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

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.

It literally just takes to redirect requests coming to:
{color:#FF0000}www{color}.minecraft.net/game/joinserver.jsp
{color:#FF0000}www{color}.minecraft.net/game/checkserver.jsp
to:
{color:#FF0000}session{color}.minecraft.net/game/joinserver.jsp
{color:#FF0000}session{color}.minecraft.net/game/checkserver.jsp

I guess that's too hard to do for Mojang...

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)