+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Discussion (https://forum.cuberite.org/forum-5.html)
+--- Thread: Security issue in Java based server (/thread-1878.html)
Pages:
1
2
Security issue in Java based server - Jammet - 04-17-2015
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-vulnerability-advisory/
Heise link (sorry, it's all german) http://heise.de/-2610963
MC-Server is not affected by this at all, right?
RE: Security issue in Java based server - xoft - 04-17-2015
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.
RE: Security issue in Java based server - Jammet - 04-17-2015
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.
RE: Security issue in Java based server - xoft - 04-17-2015
I'm trying the PoC crasher but it doesn't run on my machine
RE: Security issue in Java based server - xoft - 04-17-2015
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.
RE: Security issue in Java based server - xoft - 04-17-2015
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.
RE: Security issue in Java based server - xoft - 04-18-2015
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?
RE: Security issue in Java based server - Jammet - 04-18-2015
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.
RE: Security issue in Java based server - jan64 - 04-18-2015
How about creating a time limit instead?
The server could abort processing a packet after 0.01 s (or 0.05 s) of work.
RE: Security issue in Java based server - worktycho - 04-19-2015
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.