0.2.8.3.5 released

Help test release candidates for the next release
Post Reply
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

0.2.8.3.5 released

Post by Z-Man »

Available through the usual channels:
Main site: http://www.armagetronad.org/downloads.php (links to launchpad)
Launchpad: https://launchpad.net/armagetronad/0.2.8/0.2.8.3.5
Sourceforge: https://sourceforge.net/projects/armage ... 0.2.8.3.5/

No Mac builds, sorry.
The ppa has been partially updated, I think, something changed in the debian build processes that broke us.
ZeroInstall is not yet updated; is anyone apart from me actually using it? Probably not, the link on our website to it has been broken for ages.

The small changes: One more fix of this-dereferencing-even-though-it-is-null undefined behavior, adaption of binreloc to newer linuxes to allow the game to find its data files.
The big change and reason this is a surprise without beta phase: A flaw in the "what is a client allowed to do?" checks was fixed. By nature remotely exploitable. Affects servers only (hence the lack of Mac builds is not as tragic as it sounds).
The details (bad dudes can find them out in the diffs easy enough, so no harm in sharing): Clients are allowed to spawn objects on the server. That's how your player data (name, color etc) gets from the client to the server. But they're only allowed to send specifically marked objects (well, only the ePlayer class in practice). So far, whether a client was allowed to send an object was determined by a virtual function of that class. Well, and to call virtual functions, you need to have an object, so the system had allowed the sent object to be created. The idea was to do the check and if the client was not allowed to send the object, destroy it again before it can do harm.
Two problems, though. The reaction to the test was borked and caused a double deletion of the object and thus most of the time a crash. And already the object creation can do irreversible harm. For example, if the client sends a clock (eTimer), the creation of that clock would destroy the servers original clock, and when the mistake is noticed and the client sent clock is also destroyed, the server is clockless and does not do anything any more in the game. Worse probably would be the game itself (gGame), I haven't tested what happens if that would survive.
So now the license for clients to send objects is determined by a static method of each class, that can be checked right at the start of message processing.

It could be that the bug is already exploited in the wild. Remember when my minitst server crashed? The logs were what lead me to the bug, they look exactly like the effects I got in testing. It might have been an accident, a client somehow dragging an object from the last server over to mine. Or something else entirely that just looked like this bug. But if I had to bet, I'd bet it was a warning shot/strange bug report. Just for the record, I prefer PMs. Advantage for you: You get to properly experience me realizing how stupid I have been.

The fixes are in all main bzr/git branches. Please merge them into the various hack branches and update your servers.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: 0.2.8.3.5 released

Post by Z-Man »

The zeroinstall streams and PPA are now updated.

Ubuntu Trusty users (the statistically 0.27 of you still here): Something went wrong a while ago when I accidentally uploaded a higher version. Thing is, you can delete the accidental upload, but the version sticks and it won't accept anything older, so I can't properly upgrade you. Switch to the armagetronad-beta track, the most recent build there essentially is 0.2.8.3.5.
Post Reply