Security issue in Java based server

[Jammet]

Seems like this old problem was never fixed, and there was news on heise.de that it's currently being used to target servers and force shut them down remotely:

http://blog.ammaraskar.com/minecraft-vul...-advisory/

Heise link (sorry, it's all german) http://heise.de/-2610963

MC-Server is not affected by this at all, right?

[xoft]

Unfortunately it is, since it uses the same protocol. I expect the PoC crasher to seriously affect MCS as well. Thanks for bringing this up, we should have this fixed, too.

[Jammet]

Okay, thanks so much and - heh - I feel kind of sorry anyway . Nobody wants extra work like that. Hope you'll find fixing this to be a quick, simple and stress-free process.

[xoft]

I'm trying the PoC crasher but it doesn't run on my machine

[xoft]

Ah, so we're not as much vulnerable I finally managed to get the PoC code running this is the result in MCS console:

Code:

[135d500f|14:55:15] Player xoft has joined the game
[affdd2ca|14:55:15] Adding player xoft to world "world.flat".
[affdd2ca|14:55:57] Too much data in queue for client "xoft" @ <redacted IP>, kicking them.
[affdd2ca|14:55:57] Sending a DC: "Server busy"
[affdd2ca|14:55:57] cClientHandle::Destroy: client 09282F98, "xoft"
[affdd2ca|14:55:57] Too much data in queue for client "xoft" @ <redacted IP>, kicking them.
[affdd2ca|14:55:57] Too much data in queue for client "xoft" @ <redacted IP>, kicking them.
[affdd2ca|14:55:57] Too much data in queue for client "xoft" @ <redacted IP>, kicking them.
[affdd2ca|14:55:57] Too much data in queue for client "xoft" @ <redacted IP>, kicking them.
[affdd2ca|14:55:57] Too much data in queue for client "xoft" @ <redacted IP>, kicking them.
[affdd2ca|14:55:57] Too much data in queue for client "xoft" @ <redacted IP>, kicking them.
[affdd2ca|14:55:57] Too much data in queue for client "xoft" @ <redacted IP>, kicking them.

So basically the packet is too large, so MCS kicks the player. We have a limit of 32 KiB of unprocessed incoming data.
I'll try modifying the PoC code to generate packet under 32 KiB.

[xoft]

Oh well, reducing the payload a bit resulted in the server spitting out 110 MiB of output into the log and dying because of a deadlock detection false positive. So we are indeed vulnerable, although at least not to the unmodified generally available attack.

[xoft]

So now the question is, how do we fix it in our codebase? Should we limit the amount of data in a single packet? Should we limit the amount of data being parsed in the NBT parser? What should the limits be? Or some different solution, perhaps?

[Jammet]

Sadly, I know nothing John Snow, er I mean, of how to work it. Hope you all on the team find it's not too much hassle.

[jan64]

How about creating a time limit instead?
The server could abort processing a packet after 0.01 s (or 0.05 s) of work.

[worktycho]

I think we need to do to things to mitigate this attack. First limit the size of uncompressed packets. This also helps mitigate against compression bombs. Then we need to add limits to the recursion depth of the NBT parser as it can cause a stack-overflow as it is a recursive descent parser. I think we've avoided a code execution vulnerability because we don't create large stack based buffers to store the data, but I still think this is a potentially very dangerous attack.