Security Vulnerabilities in <= 0.2.7.0
- Tank Program
- Forum & Project Admin, PhD
- Posts: 6711
- Joined: Thu Dec 18, 2003 7:03 pm
Security Vulnerabilities in <= 0.2.7.0
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 598 times
- Tank Program
- Forum & Project Admin, PhD
- Posts: 6711
- Joined: Thu Dec 18, 2003 7:03 pm
You should clarify your question if you want a useful answer/dev/null wrote:this fixin that packet problem?
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.
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.
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.
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:z-man wrote:You should clarify your question if you want a useful answer/dev/null wrote:this fixin that packet problem?
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 >
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!
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.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 ?
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.
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...
> 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. */
They exist. I don't know whether they are actually in use, though.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...
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.
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...)
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. */
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.blane wrote: (rather too detailed, shouldn't that be in the dev forum?
And the exploits come from Luigi himself. They just crash and DOS, of course.