All 0.2.8.0 testing versions have a severe security vulnerability. By setting a specially prepared MAP_FILE, an attacked system can be convinced to download an arbitrary file to an arbitrary place in the system, provided the destination is not yet occupied and the user running Armagetron has writing rights. An attack can either be a server sending the malicious MAP_FILE to the connecting clients or an ingame admin setting it to attack the server.

Some examples of bad things:
- the attacker can inject commands into the autostart menu or crontab directories where they will be executed later
- the attacker can write a ~/.ssh/authorized_keys and, if you have a SSH daemon running accepting connections, log in to your system
- the attacker can make you download pr0n into an inappropriate folder

To make the word spread fast to those who don't read the forums, 0.2.8.0 servers lock out vulnerable clients by default.

Windows and Linux users should upgrade to 0.2.8.0 or downgrade to 0.2.7.1. Mac users or those who want to keep using a beta or rc should avoid all 0.2.8 servers, but mind that a modified 0.2.7.x server can also send a malicious MAP_FILE to your client.

Server administrators who gave admin rights to users they don't FULLY trust should change ADMIN_PASS until the upgrade to 0.2.8.0 is complete.

Meaningful attacks probably are noticable by map load failures, although a very clever attacker can probably find a way to use a good map file as the injected file that still does harm.

We're sorry for the inconvenience. There was code in place to protect against the exploit, but it was faulty and nobody noticed it.

Tank: Maybe you can move this to the News forum?

Mac builds for 0.2.8.0 are on sourceforge.

Wow, that was fast. Thanks a lot, nemo!

The 32 bit Linux and Windows builds of 0.2.8.0 can be found on AABeta. The release list there is a bit slow to update today, AMD64 linux builds are on SourceForge

Any way for a non-geek to check whether he or she may have been attacked?

Not quite.

What happens when you get attacked is that you get disconnected from the server with an error message about and invalid map file, at least if the attacker tries to put a file onto your machine that's not a map (valid maps should be harmless, although, as z-man said, there might be cases in which a valid map can be harmful).

The only server which is known to have exploited this hole is a test server by me which was not on the master list, and it was harmless.

Thank you for finding it before no telling how many people got exploited because of it.

Credit for finding it goes to wrtl, credit for fixing to Luke.

Some more notes on "how to spot you've ben pwnd", the impatient can jump to the conclusions:
Real haxor skills are required to use this attack in a way that a) isn't traceable back to you and b) is unnoticed by the victim.

First, you want to work around a). If you set up a server with a malicious MAP_FILE, you've just given the good guys an IP to send to the authorities. So you need to inject the MAP_FILE into a server or a client without giving away your IP: you need to spoof the packet source. We're not using encryption to secure client-server connection, so you have a chance of sending a packet to the client that appears to come from the server and vice versa. You need to know the client's IP for that, a master server browser ping harvester (like I was running for some days) can get you a preselection. You need to guess the port the client is using. All these are not terribly hard problems, but each one, apart from source IP spoofing and port guessing, isn't available to a skript kiddie.
What you get: a way to modify MAP_FILE on every client currently playing, and a way to modify MAP_FILE on servers where an ingame admin is currently logged in. In each variant, there are witnesses, and you need to hide what you're doing from them. Which leads us to problem b.

Your MAP_FILE injection must not trigger an immediate error. So, it must be a valid map file along with doing the evil you want it to do. Unfortunately, our forward map file compatibility helps here: the map parser ignores everything it does not understand, so all valid XML files that contain a map are accepted. You need to create such an XML file that looks like the map played on the server.
And you need to piggy back your harmful whatever to it. This is the tough part; the two attack possibilities I mentioned, injecting an autostart entry or .ssh/authorized_keys probably won't work as non-XML files are expected here, at least on the systems I know. Also, .ssh usually is a write protected directory (on sensible setups). I guess it takes quite a lot of ingenuity to work around the problems here.

The two hack attackers we saw up to now (and I remember now) weren't even smart enough to mask their IP address for regular DOS attacks. Well, or they were and we banned the wrong guys I don't think any of our regular evildoers would be able to do a full stealth attack.

On top of that, what you get from the attack directly is only the rights of the user that runs the game. On a default Unix server setup, that's a special user created only for that purpose. So unless there was an unpatched rights escalation bug at the time of the attack, the Unix systems running servers were safe. The server running user is created without a home directory and can't create one on his own, it has only writing rights to the AA configuration directories. The most the attacker can do is mess with your game server's settings, AFAIK there is no way to get you to execute arbitrary code by dropping something into one of our directories. Luckily, we don't have a shell command execution console command.
If you run your server as root, of course, you're doomed.

There still may have been stupid non-stealth attacks on clients. They'd be noticeable by map load failure errors. The distinguishing features of an attack rather than a normal configuration error: there would have been no mention of "404: file not found", but rather a map validation failure error.

conclusions: Unix servers running the default configuration via the init scripts under a user ID without home directory (for the .ssh attack) and without published ways to get shell commands to execute by dropping a file somewhere were safe.

Servers without ingame admins were safe.

Clients that never saw an odd map error message without "file not found" probably haven't been attacked. Errors on well respected servers accessed via a bookmark, like Lucifer's maze, wrtl's or iF's race, or wejp's planet servers were probably harmless as well.

Possible, of course, still is everything. But usually, there are better know and easier ways to break into your machine than this attack.