Security Vulnerabilities in <= 0.2.7.0

News, what's going on with... Anything...
User avatar
Tank Program
Forum & Project Admin, PhD
Posts: 6711
Joined: Thu Dec 18, 2003 7:03 pm

Security Vulnerabilities in <= 0.2.7.0

Post by Tank Program »

There recently have been some vulnerabilities discovered in Armagetron and Armagetron Advanced which have been made public. We are workingon putting together an 0.2.7.1 release to addresses these bugs as well as whatever else came to z-mans mind when he made the source package. The CVS code of both games have been updated with fixes. Attached is a patch against the 0.2.7.0 source. If I've left anything out, I'm sure someone will correct me :).
Attachments
armagetronad-0.2.7.0-security.patch.gz
Patch fixing vulnerabilities.
(713 Bytes) Downloaded 589 times
Image
User avatar
/dev/null
Shutout Match Winner
Posts: 819
Joined: Sat Sep 04, 2004 6:28 pm
Location: Chicago-ish

Post by /dev/null »

this fixin that packet problem?
User avatar
Tank Program
Forum & Project Admin, PhD
Posts: 6711
Joined: Thu Dec 18, 2003 7:03 pm

Post by Tank Program »

yes (i think)
Image
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

/dev/null wrote:this fixin that packet problem?
You should clarify your question if you want a useful answer :)
The problems fixed are:
- A packet with a fake sender ID caused a crash
- A message with a fake message ID caused a crash
- < Another silly error Edited away because it is easy to exploit once you know it's there >

All these problems probably only affect internet servers. LAN server admins can slap the attacker over the head, it's the guy who is chuckling while the server goes down. Clients are only vulnerable if their IP and Armagetron sender port are known, and they are kept secret by the server. So, unless the server is corrupted, you should be safe.
Last edited by Z-Man on Tue Mar 01, 2005 10:30 am, edited 1 time in total.
User avatar
/dev/null
Shutout Match Winner
Posts: 819
Joined: Sat Sep 04, 2004 6:28 pm
Location: Chicago-ish

Post by /dev/null »

yeah, those were what I was referring to, but I wasnt trying to be detailed as most the servers are not running CVS.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

Ah. Thanks for the concern, then.
To calm everyone ( mostly myself :) ) down who thinks that by my more detailed exploit description the risk of exploits being used has been increased: Everyone with the capability of writing exploit code would have gotten the same information from the patch itself. And they still have to find out HOW to build a packet with forged information.
Edit: Except for the last one. You don't need too much skill to exploit it.
hacim
Posts: 2
Joined: Thu Mar 17, 2005 5:36 am

Post by hacim »

z-man wrote:
/dev/null wrote:this fixin that packet problem?
You should clarify your question if you want a useful answer :)
The problems fixed are:
- A packet with a fake sender ID caused a crash
- A message with a fake message ID caused a crash
- < Another silly error Edited away because it is easy to exploit once you know it's there >
It looks like these fixed all the holes, except for the one "fake players temporary freeze (CAN-2005-0371)" the details of which are located here:

http://marc.theaimsgroup.com/?l=bugtraq ... 206052&w=2

Any chance there will be a fix for this one any time soon?

Thanks for getting on these quickly!
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

The freezes caused by the fake player attack are the same that are caused by exuberant ping real clients, they happen between rounds. They can't be fixed that easily, but they are far less severe now in 0.2.7.1.
User avatar
n54
MVP
Posts: 1587
Joined: Sun Dec 21, 2003 12:40 pm

Post by n54 »

Welcome to the forum hacim :)
User avatar
iceman
Reverse Adjust Outside Corner Grinder
Posts: 2448
Joined: Fri Jan 09, 2004 9:54 am
Location: Yorkshire, England. Quote: Its the fumes, they make one want to play
Contact:

Post by iceman »

z-man wrote: Clients are only vulnerable if their IP and Armagetron sender port are known
if this info was know is there anything more than just a crash possible or is there a more serious exploit to the client ?
Image He who laughs last, probably has a back-up
Image
Image
sorry about the large animated gif
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

iceman wrote:if this info was know is there anything more than just a crash possible or is there a more serious exploit to the client ?
Good question. There client does put a bit more trust into the server than vice versa. The attacker would at least have to spoof the sender IP to match that of the server, otherwise the packet will get rejected right at the start. Not especially a difficult task with UDP packets, I must add. Once this hurdle is passed, he can seriously mess with the internal state of the client. Since most things in AA are stored in safe containers ( esp. the network objects that get sent as "pointers" in network messages ), it should be as hard to crash the client as it is to crash the server, but it will be possible to create and delete walls and cycles locally or provoke a network error that causes connection loss or your virtual death.
Selective connection loss provoking is also possible by sending the server fake messages spoofed to come from your machine apparently.
Against both kinds of attacks, only strong encryption of all messages will help. The attacks are only possible if the attacker can manipulate an already established connection.
User avatar
blane
Project Advisor
Posts: 78
Joined: Tue Jun 08, 2004 3:26 pm
Location: Timbuktu
Contact:

Post by blane »

According to Auriemma it's only Denial of Service:

> Bugs: A] crash caused by big descriptor ID
> B] crash caused by big claim_id
> C] socket unreacheable through empty packet
> D] fake players temporary freeze

I also would assume that code injection will not work by these methods. however, i have not looked into the corresponding code but i know Luigi a bit and he knows what he is doing. So if there even was the possibility of code execution, he would have mentioned it.

Different thing: Is anyone aware of actual exploits for these bugs? Cause I am not and I would think it's rather unlikely...
/* I have the heart of a small child. It sits on my desk in a jar. */
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

blane wrote:Different thing: Is anyone aware of actual exploits for these bugs? Cause I am not and I would think it's rather unlikely...
They exist. I don't know whether they are actually in use, though.
A+B can theoretically be used for code injection, but it would require some more intermediate steps than usual. Usually, you just send more data than fits in a buffer and put code in the extra bits that gets executed directly.
To exploit B for code insertion, you'd have to forge at least two pointer lookups. You'd need to know an offset between a static array and one on the stack and fit the offset divided by 4 into an unsigned short to forge one of the lookups. At least on my system, stack and static storage are way too far apart from each other for this to be possible. Given that usually virtual memory management is used to allow the stack to grow almost infinitely downwards, this is likely to be the case everywhere.
In the A bug, you forge the sender client ID. A lot of data lookups are done with that, but they are just data lookups and are likely to simply crash. However, if you manage to get a complete network message with the fake, too large ID through, you can get it to almost any system. I'm pretty sure that the ID is always only used for data lookup on the heap or for comparisons and never to select code to be executed, though.

Short version: A is exploitable if the stack memory is close to the static storage area which is system dependent, but highly unlikely. B may be exploitable, but a lot of research would be needed to determine it. C and D are certainly purely DOS.
User avatar
blane
Project Advisor
Posts: 78
Joined: Tue Jun 08, 2004 3:26 pm
Location: Timbuktu
Contact:

Post by blane »

Aye, thank you.. that's what i call detailed information (rather too detailed, shouldn't that be in the dev forum? ;)

however, i was hoping that skilled enough people would not waste their time coding exploits for a game with such a small userbase (compared to other games like WoW, ET, etc...)
/* I have the heart of a small child. It sits on my desk in a jar. */
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

blane wrote: (rather too detailed, shouldn't that be in the dev forum? ;)
No, I don't think it's a problem. In B, I left out the steps of thought and analysis you have to make before you bump into that offset problem. And for A, I have not said anything not obvious after the first five minutes of vulnerability analysis once you know where the vulnerable code is, and that's already disclosed.
And the exploits come from Luigi himself. They just crash and DOS, of course.
Post Reply