Adrian Siekierka
- asie
- asie
- Europe/Stockholm
- Yes
- No
MC-106713Note: This affects every Minecraft version >=1.10.
Since Minecraft 1.10.0, the information that the Snooper sends from the game to http://snoop.minecraft.net includes a field called "uuid". The code which generates it
looks (roughly - I do not have access to the exact form) as follows (itcan be found in the class called by Main, commonly called "Minecraft", by looking for the string "uuid" with quotes):final GameProfile v2 = this.currentProfileData.getGameProfile();
if (v2 != null && v2.getId() != null)
snooper.addInitialInfo("uuid", Hashing.sha1().hashBytes(v2.getId().toString().getBytes(Charsets.ISO_8859_1)).toString());As you can see, the field's value is a SHA1 hash of the player's UUID. The hash is not salted in any way, which means that an entity which has access to both the snooper data and a list of all UUIDs can create a list of SHA1->UUID mappings, and - due to the very low probability of hash collisions in normal conditions - effectively be able to map said SHA1 hash to the player UUID and de-anonymize the information contained in the snooper data.
This isn't really a vulnerability in the practical sense, perhaps a theoretical one, as prior knowledge of the UUID is still necessary to de-anonymize a packet - and the pool of potential UUIDs is far too large to efficiently compare them, unless you have a list of actually existing UUIDs (which is far smaller). However, the Snooper communications happen over unencrypted HTTP, which means that snooping on the Snooper is possible and a third party knowing your UUID (which is, indeed, unlikely) can become aware of additional details about the machine you're playing from.
One important step to take would be to prevent snooping on the Snooper data by third parties by using HTTPS (or, at the very least, prevent proxying the snooper domain by using some kind of verification).
However, why is the "uuid" field even sent? The Snooper window in Options claims the data is "completely anonymous", which is clearly false and has been since 1.10. I believe that it should be, at the very least, replaced with a token which is not easily mappable to a specific player without additional information about their behaviour that cannot be gathered from the snooper data alone.
My proposed workaround for all affected users is to disable the Snooper in the Options menu until this is resolved.
Note: This affects every Minecraft version >=1.10.
Since Minecraft 1.10.0, the information that the Snooper sends from the game to http://snoop.minecraft.net includes a field called "uuid". The code which generates it can be found in the class called by Main, commonly called "Minecraft", by looking for the string "uuid" with quotes.
Another way to check it is to use SHA1 to hash your UUID, with separators, as a string, and compare it to the "uuid" string shown in the Snooper Options.
As you can see, the field's value is a SHA1 hash of the player's UUID. The hash is not salted in any way, which means that an entity which has access to both the snooper data and a list of all UUIDs can create a list of SHA1->UUID mappings, and - due to the very low probability of hash collisions in normal conditions - effectively be able to map said SHA1 hash to the player UUID and de-anonymize the information contained in the snooper data.
This isn't really a vulnerability in the practical sense, perhaps a theoretical one, as prior knowledge of the UUID is still necessary to de-anonymize a packet - and the pool of potential UUIDs is far too large to efficiently compare them, unless you have a list of actually existing UUIDs (which is far smaller). However, the Snooper communications happen over unencrypted HTTP, which means that snooping on the Snooper is possible and a third party knowing your UUID (which is, indeed, unlikely) can become aware of additional details about the machine you're playing from.
One important step to take would be to prevent snooping on the Snooper data by third parties by using HTTPS (or, at the very least, prevent proxying the snooper domain by using some kind of verification).
However, why is the "uuid" field even sent? The Snooper window in Options claims the data is "completely anonymous", which is clearly false and has been since 1.10. I believe that it should be, at the very least, replaced with a token which is not easily mappable to a specific player without additional information about their behaviour that cannot be gathered from the snooper data alone.
My proposed workaround for all affected users is to disable the Snooper in the Options menu until this is resolved.
Note: This affects every Minecraft version >=1.10.
Since Minecraft 1.10.0, the information that the Snooper sends from the game to http://snoop.minecraft.net includes a field called "uuid". The code which generates it can be found in the class called by Main, commonly called "Minecraft", by looking for the string "uuid" with quotes.
Another way to check it is to use SHA1 to hash your UUID, with separators, as a string, and compare it to the "uuid" string shown in the Snooper Options.
As you can see, the field's value is a SHA1 hash of the player's UUID. The hash is not salted in any way, which means that an entity which has access to both the snooper data and a list of all UUIDs can create a list of SHA1->UUID mappings, and - due to the very low probability of hash collisions in normal conditions - effectively be able to map said SHA1 hash to the player UUID and de-anonymize the information contained in the snooper data.
This isn't really a vulnerability in the practical sense, perhaps a theoretical one, as prior knowledge of the UUID is still necessary to de-anonymize a packet - and the pool of potential UUIDs is far too large to efficiently compare them, unless you have a list of actually existing UUIDs (which is far smaller). However, the Snooper communications happen over unencrypted HTTP, which means that snooping on the Snooper is possible and a third party knowing your UUID (which is, indeed, unlikely) can become aware of additional details about the machine you're playing from.
One important step to take would be to prevent snooping on the Snooper data by third parties by using HTTPS (or, at the very least, prevent proxying the snooper domain by using some kind of verification).
However, why is the "uuid" field even sent? The Snooper window in Options claims the data is "completely anonymous", which is clearly false and has been since 1.10. I believe that it should be, at the very least, replaced with a token which is not easily mappable to a specific player without additional information about their behaviour that cannot be gathered from the snooper data alone.
My proposed workaround for all affected users is to disable the Snooper in the Options menu until this is resolved.
Note: This affects every Minecraft version >=1.10, however, it has been fixed in 16w35a.
Since Minecraft 1.10.0, the information that the Snooper sends from the game to http://snoop.minecraft.net includes a field called "uuid". The code which generates it can be found in the class called by Main, commonly called "Minecraft", by looking for the string "uuid" with quotes.
Another way to check it is to use SHA1 to hash your UUID, with separators, as a string, and compare it to the "uuid" string shown in the Snooper Options.
As you can see, the field's value is a SHA1 hash of the player's UUID. The hash is not salted in any way, which means that an entity which has access to both the snooper data and a list of all UUIDs can create a list of SHA1->UUID mappings, and - due to the very low probability of hash collisions in normal conditions - effectively be able to map said SHA1 hash to the player UUID and de-anonymize the information contained in the snooper data.
This isn't really a vulnerability in the practical sense, perhaps a theoretical one, as prior knowledge of the UUID is still necessary to de-anonymize a packet - and the pool of potential UUIDs is far too large to efficiently compare them, unless you have a list of actually existing UUIDs (which is far smaller). However, the Snooper communications happen over unencrypted HTTP, which means that snooping on the Snooper is possible and a third party knowing your UUID (which is, indeed, unlikely) can become aware of additional details about the machine you're playing from.
One important step to take would be to prevent snooping on the Snooper data by third parties by using HTTPS (or, at the very least, prevent proxying the snooper domain by using some kind of verification).
However, why is the "uuid" field even sent? The Snooper window in Options claims the data is "completely anonymous", which is clearly false and has been since 1.10. I believe that it should be, at the very least, replaced with a token which is not easily mappable to a specific player without additional information about their behaviour that cannot be gathered from the snooper data alone.
Note: This affects every Minecraft version >=1.10, however,
ithas been fixed in 16w35a.Since Minecraft 1.10.0, the information that the Snooper sends from the game to http://snoop.minecraft.net includes a field called "uuid". The code which generates it can be found in the class called by Main, commonly called "Minecraft", by looking for the string "uuid" with quotes.
Another way to check it is to use SHA1 to hash your UUID, with separators, as a string, and compare it to the "uuid" string shown in the Snooper Options.
As you can see, the field's value is a SHA1 hash of the player's UUID. The hash is not salted in any way, which means that an entity which has access to both the snooper data and a list of all UUIDs can create a list of SHA1->UUID mappings, and - due to the very low probability of hash collisions in normal conditions - effectively be able to map said SHA1 hash to the player UUID and de-anonymize the information contained in the snooper data.
This isn't really a vulnerability in the practical sense, perhaps a theoretical one, as prior knowledge of the UUID is still necessary to de-anonymize a packet - and the pool of potential UUIDs is far too large to efficiently compare them, unless you have a list of actually existing UUIDs (which is far smaller). However, the Snooper communications happen over unencrypted HTTP, which means that snooping on the Snooper is possible and a third party knowing your UUID (which is, indeed, unlikely) can become aware of additional details about the machine you're playing from.
One important step to take would be to prevent snooping on the Snooper data by third parties by using HTTPS (or, at the very least, prevent proxying the snooper domain by using some kind of verification).
However, why is the "uuid" field even sent? The Snooper window in Options claims the data is "completely anonymous", which is clearly false and has been since 1.10. I believe that it should be, at the very least, replaced with a token which is not easily mappable to a specific player without additional information about their behaviour that cannot be gathered from the snooper data alone.
Note: This affects every Minecraft version >=1.10, however, part of it (not informing the user about sending UUID information) has been fixed in 16w35a.
Since Minecraft 1.10.0, the information that the Snooper sends from the game to http://snoop.minecraft.net includes a field called "uuid". The code which generates it can be found in the class called by Main, commonly called "Minecraft", by looking for the string "uuid" with quotes.
Another way to check it is to use SHA1 to hash your UUID, with separators, as a string, and compare it to the "uuid" string shown in the Snooper Options.
As you can see, the field's value is a SHA1 hash of the player's UUID. The hash is not salted in any way, which means that an entity which has access to both the snooper data and a list of all UUIDs can create a list of SHA1->UUID mappings, and - due to the very low probability of hash collisions in normal conditions - effectively be able to map said SHA1 hash to the player UUID and de-anonymize the information contained in the snooper data.
This isn't really a vulnerability in the practical sense, perhaps a theoretical one, as prior knowledge of the UUID is still necessary to de-anonymize a packet - and the pool of potential UUIDs is far too large to efficiently compare them, unless you have a list of actually existing UUIDs (which is far smaller). However, the Snooper communications happen over unencrypted HTTP, which means that snooping on the Snooper is possible and a third party knowing your UUID (which is, indeed, unlikely) can become aware of additional details about the machine you're playing from.
One important step to take would be to prevent snooping on the Snooper data by third parties by using HTTPS (or, at the very least, prevent proxying the snooper domain by using some kind of verification).
However, why is the "uuid" field even sent? The Snooper window in Options claims the data is "completely anonymous", which is clearly false and has been since 1.10. I believe that it should be, at the very least, replaced with a token which is not easily mappable to a specific player without additional information about their behaviour that cannot be gathered from the snooper data alone.
Snooper information may be de-anonymized by a third party
Note: This affects every Minecraft version >=1.10, however, part of it (not informing the user about sending UUID information) has been fixed in 16w35a.
Since Minecraft 1.10.0, the information that the Snooper sends from the game to http://snoop.minecraft.net includes a field called "uuid". The code which generates it can be found in the class called by Main, commonly called "Minecraft", by looking for the string "uuid" with quotes.
Another way to check it is to use SHA1 to hash your UUID, with separators, as a string, and compare it to the "uuid" string shown in the Snooper Options.
As you can see, the field's value is a SHA1 hash of the player's UUID. The hash is not salted in any way, which means that an entity which has access to both the snooper data and a list of all UUIDs can create a list of SHA1->UUID mappings, and - due to the very low probability of hash collisions in normal conditions - effectively be able to map said SHA1 hash to the player UUID and de-anonymize the information contained in the snooper data.
This isn't really a vulnerability in the practical sense, perhaps a theoretical one, as prior knowledge of the UUID is still necessary to de-anonymize a packet - and the pool of potential UUIDs is far too large to efficiently compare them, unless you have a list of actually existing UUIDs (which is far smaller). However, the Snooper communications happen over unencrypted HTTP, which means that snooping on the Snooper is possible and a third party knowing your UUID (which is, indeed, unlikely) can become aware of additional details about the machine you're playing from.
One important step to take would be to prevent snooping on the Snooper data by third parties by using HTTPS (or, at the very least, prevent proxying the snooper domain by using some kind of verification).
However, why is the "uuid" field even sent? The Snooper window in Options claims the data is "completely anonymous", which is clearly false and has been since 1.10. I believe that it should be, at the very least, replaced with a tokenwhichisnoteasily mappable to a specific player without additional information about their behaviour that cannot be gathered from the snooper data alone.Note: This affects every Minecraft version >=1.10, however, part of it (not informing the user about sending UUID information) has been fixed in 16w35a.
Since Minecraft 1.10.0, the information that the Snooper sends from the game to http://snoop.minecraft.net includes a field called "uuid". The code which generates it can be found in the class called by Main, commonly called "Minecraft", by looking for the string "uuid" with quotes.
Another way to check it is to use SHA1 to hash your UUID, with separators, as a string, and compare it to the "uuid" string shown in the Snooper Options.
As you can see, the field's value is a SHA1 hash of the player's UUID. The hash is not salted in any way, which means that an entity which has access to both the snooper data and a list of all UUIDs can create a list of SHA1->UUID mappings, and - due to the very low probability of hash collisions in normal conditions - effectively be able to map said SHA1 hash to the player UUID and de-anonymize the information contained in the snooper data.
This isn't really a vulnerability in the practical sense, perhaps a theoretical one, as prior knowledge of the UUID is still necessary to de-anonymize a packet - and the pool of potential UUIDs is far too large to efficiently compare them, unless you have a list of actually existing UUIDs (which is far smaller). However, the Snooper communications happen over unencrypted HTTP, which means that snooping on the Snooper is possible and a third party knowing your UUID (which is, indeed, unlikely) can become aware of additional details about the machine you're playing from.
One important step to take would be to prevent snooping on the Snooper data by third parties by using HTTPS (or, at the very least, prevent proxying the snooper domain by using some kind of verification).
I believe that the token usage should also be reconsidered, and ways of counting players to a reasonable degree of certainty which do not involve breaching their privacy (salting with the MAC address? It's possible in Java) considered.
Low priority, probably, but should be simple to fix.
There's a class in Minecraft 18w43b which seems to provide number ranges, with integer and float subclasses. ("bc" obfuscated, you can probably find it by the "argument.range.empty" SimpleCommandExceptionType).
In that class, there's a method which outputs a JsonElement ("d"). Said method's logic can be modeled roughly as follows:
final JsonObject v1 = new JsonObject(); if (this.min != null) { v1.addProperty("min", (Number)this.min); } if (this.max != null) { v1.addProperty("max", (Number)this.min); }The second addProperty call seems to be setting "max" to this.min, whereas this.max is probably correct judging by context.
Essentially, a bit of code looking like
v1.addProperty("max", (Number)this.min);should probably look more like
v1.addProperty("max", (Number)this.max);
Adrian Siekierka: I think you should create a new bug report on this. I'm don't have much knowledge of these things, so you probably can create a lot better description than I can.
Indeed, which could be deemed a working, if disappointing, solution. However, the second part of the issue (parties who are not Mojang potentially being able to capture the data) is still present. Once you're sending data which can potentially identify a user, you should take extra care to ensure it's transmitted in a safe manner.
(Also, I do believe ways of uniquely identifying users without compromising their privacy should be looked into as well.)
Two important preceding cases:
In other words, Minecraft has had cases of both bugs becoming features and bugs not becoming features.
FoamFix developer here; that is, the mod that's causing the crash. Please update Forge to latest (latest!, not recommended) and let me know on https://github.com/asiekierka/FoamFix/issues if the issue persists.
In general, one of the workarounds we have employed locally is to use lwjgl-jemalloc 3.2.1 with the rest of lwjgl being at 3.1.6 on Linux - this hasn't caused any issues so far, and may be a consideration-worthy option.
Generally speaking, there are multiple places in the Minecraft codebase where "invalid namespaced string" exceptions are not being caught, causing the rest of the loading process to crash and burn horribly.
As of 1.14.2 Pre-Release 2 (not sure if earlier), this seems to be once again/still an issue.
As copies are made in the S->C "data" "getter", a quick fix would be to use the same release() call for the original "data" object as is used in the C->S packet processing method.
I've been doing extensive testing with an user "creeper123123321" as part of hooking the networking system; I am very confident that, while the copy itself is fine (and probably a good idea!), the underlying ByteBuf being copied is never freed in S->C (whereas it is in C->S), and this causes a leak.