DoS vulnerability via flood of logins

The bug

A denial-of-service vulnerability exists in the server due to the lack of rate limiting of logins.
A disconnection during login appears to be handled, at least in part, by the main server thread, so the server can lag and possibly crash (killed by the watchdog).

Banning the attacker's IP address does not mitigate the issue. (However, it could presumably be blocked with a firewall.) Exploiting the bug does not even require any kind of login or authentication.

How to reproduce

1. Start a local server.
2. Download and extract mc122903-compiled.zip (source code is in mc122903.zip)
3. Run the jar with java -jar mc122903.jar localhost 25565 protocol-version-number.
4. The server will crash (or experience a large lag spike) after about a minute. If it doesn't crash, try doing step 3 again.

Notes:

• A beefy computer may give better results. This also might work better on certain operating systems; I've been testing this on Linux.
• If you get "Too many open files" errors in the program and/or the server, try raising the limit before running them (requires root):

  # ulimit -Hn 65536

  Then run the program/server in that root shell. Note that the limit is high enough by default on most Linux distros, so usually you will not need to do this.

• If you see "Took too long to log in" in the server log, then this usually signals that the server is about to lag or crash.

info: data: 17 (0x11) bytes
info: -----------------------------------------------------
info: 0000: 10 00 ba 04 09 6c 6f 63 61 6c 68 6f 73 74 63 dd
info: 0010: 02
info: -----------------------------------------------------
info: starting
info: 14,708 connections made
info: 15,684 connections made
info: 16,658 connections made
<<snip>>
info: 24,874 connections made
info: 25,938 connections made
info: 26,946 connections made

<<lots of timed out messages and thread dumps>>
[21:14:04] [Server thread/INFO]: /127.0.0.1:41592 lost connection: Timed out
[21:14:04] [Server thread/INFO]: /127.0.0.1:41608 lost connection: Timed out
[21:14:04] [Server thread/INFO]: /127.0.0.1:40986 lost connection: Timed out
[21:14:04] [Server thread/INFO]: Disconnecting /127.0.0.1:40998: Took too long to log in
[21:15:04] [Server Watchdog/FATAL]: A single server tick took 60.00 seconds (should be max 0.05)
[21:15:04] [Server Watchdog/FATAL]: Considering it to be crashed, server will forcibly shutdown.
[21:15:04] [Server Watchdog/ERROR]: This crash report has been saved to: /home/jtai/BugServer/./crash-reports/crash-2019-12-05_21.15.04-server.txt

How the program works

1. Initiate connection to server.
2. Send the Handshake packet.
3. Without closing the connection, create another connection and repeat.

How this could be fixed

This could be fixed by simply rate limiting logins. Since sending too many logins clearly causes bad things to happen, logins could simply be rate limited, for example 10 logins per minute per IP. As far as I could tell, there is currently no rate limiting of logins — I was able to start tens of thousands.