[mohaa] Latest mohaa_lnxded binaries - bufferoverflow notfixed?

Steven Hartland killing at multiplay.co.uk
Wed Aug 11 08:26:17 EDT 2004


Sounds good I'd suggest the addition of:

1. Max connections per min per ip, which could work hand in hand
with timeout to prevent attackers maintaining a "lock" on X slots.
N.B. No. Connections from an IP would be updated on successful
or unsuccessful connection attempts.
Additionally there could be to also limit connections / attempts
based on network ranges. This would reduce the effect of attacks
from people with access to an address range.
2. Ability to tweak ( cvar ) the general timeout.
3. Ability to tweak ( cvar ) the initial timeout for a client.
The latter being the max time from response to the challenge.
This could be used to help eliminate spoofed address usage
for which the spoofed source did not reply ( e.g. firewall set to ignore,
and doesn't send icmp port unreachable etc response. )

Finally a really important one that could help solve issues is a
banned IP list. This is a piece of major functionality missing
from mohaa and could on its own seriously help prevent this
type of attack but when combined with the other measures would
be great. It could even help implement the above if the player
server full message was sent for an address which is banned
and bans had an optional timeout. So all base check would end
up being:
if ( ipBanned( address ) )
{
    return serverFull();
}
The additional protection would just update the ban lists
with temporary bans where appropriate. Not to mention
giving the admins a sorely missing feature in MOHAA to help
prevent other types of "attacks".

All of the additional settings should be optional ( cvar ) based
which default to the suggest sensible defaults. Might also be a
good idea to have two sets of defaults. One for when running
as an internet server and one for when running as a LAN server.

    Steve / K
----- Original Message ----- 
From: "Ryan C. Gordon" <icculus at clutteredmind.org>
To: <mohaa at icculus.org>
Sent: 11 August 2004 12:47
Subject: Re: [mohaa] Latest mohaa_lnxded binaries - bufferoverflow notfixed?


> 
> > 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.
> 
> 
> 
> 
> 


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
or return the E.mail to postmaster at multiplay.co.uk.




More information about the Mohaa mailing list