[mohaa] Latest mohaa_lnxded binaries - bufferoverflow not fixed?

[Ryan C. Gordon]

> it was easy to do. I downloaded this and no cd key was needed. there
> were no servers which could stop it.

Spearhead was the first one to check CD keys.

> I'll give it about 2 weeks before this program becomes widespread and
> all uk MoH servers get attacked on a daily basis unless something is
> done.

This exploit has been public for months. Let's not get overly dramatic.

> I've submitted some information to EA and Im going to follow up with a
> phone call later. I suspect that if the MoH franchise is of any value
> to them, they will release a new patch for allied assault, spearhead
> and Breakthrough.

I'd say getting further MOHAA patches from EA is unlikely, but I'd love
to be wrong about this. _Maybe_ you'd see a Breakthrough patch.

>  All of which are affected by this exploit which has NOT been patched
> and CANNOT be patched due to its complexity and the need for EA's
> cooperation in developing a patch for this. Otherwise its MoH down the
> pan........ and we can all go back to playing solitaire.....

Again, let's not be overly dramatic about this.

I'm thinking about this, I'd say the easiest fix (which may not be easy
at all, but this is "stuff that sounds good while thinking in the
morning shower"):

As it stands, players are kept in limbo while the server handles the
initial handshake. During this time, they occupy a player slot, even
though they aren't actually "connected". This is the nature of the
exploit...the thing fills the server with players in the initial
handshake so legitimate players are told the server is full when it
isn't. This was a question of convenience in the engine; fill a server
slot under the assumption that players will actually join so you don't
have to manage handshakes seperately (and conveniently avoid a DoS from
thousands of bogus clients...when you get to 16 or 32 or whatnot players
in limbo, just reject everything else. It's an unfortunate tradeoff).

So, what we _could_ do:

1) Have the server keep a timestamp of when every player connected.
2) Allow X connections (defined by the admin via a cvar) from the same
IP without question. "2" is probably a good number.  Maybe 3.
3) If there's more than X connections from the same IP, any new
connections within Y seconds (another cvar) will be told "server is
full" and dropped, which is understood by all existing clients. "30" is
probably a good number here. If the latest connection was more than Y
seconds or there are less than X players from that IP, let the same-IP
client on without any delay.
4) Extra credit: if there's a "connection refused" packet in response to
a handshake, drop the connecting player immediately.

The result is this:
1) Regular people from various IPs around the world connect and play as
usual.
2) Multiple people connecting on a LAN game have unique IPs within the
intranet, so they connect and play as usual.
3) Multiple people on the same LAN connecting to an Internet game could
have the same IP behind NAT. In this case, they all try to connect, some
of them are told "server is full" and can get on in the next Y seconds.
With some fine-tuning from the admin, this effect could be mostly
unnoticed in normal usage (i.e. - two people on a cable modem don't ever
trigger it, five people on a T-1 line notice a small burp for the last
to connect. They try to reconnect and continue without trouble).
4) People flooding the server with said-exploit will fill X slots and
then be denied from filling the rest. The best they can do is keep X
slots filled, which will be legitimately timing out as they try to fill
in new ones. This will eventually require an admin to ban that IP to be
truly useful, but it at least prevents the server from being shut down
to the public during an attack.
5) The next attack is to use multiple spoofed IPs in the connection
packet. This is where the "extra credit" comes in; if they use an
arbitrary address, the handshake packet from the server will get a
"connection refused" (whatever that's actually called in UDP
terminology), in which case we can immediately drop the client, freeing
the slot. The next attack after that is to have zombie machines
coordinate an attack...there's not much to be done about this in any
scenario, but it's beyond most (well, most) script kiddies' resources.
6) As usual, passworded servers are never a bad idea, when you can get
away with it, which I believe removes this exploit entirely. Naturally,
this isn't always practical.

Thoughts?

--ryan.