--------------------------------------- A] crash through an invalid owner value --------------------------------------- A program's termination or a crash happen when a client sends an owner value major than MAXCLIENTS+1. The function which reads this value is the following located in network/nNetObject.cpp: nNetObject::nNetObject(nMessage &m):lastSyncID_(m.MessageIDBig()),refCtr_(0) If the value is not excessively big the server terminates with the following message: Internal Error: Internal error in static nMachine& nMachine::GetMachine (short unsigned int) in network/nNetwork.cpp:3820 : Assertion userID <= MAXCLIENTS+1 failed ----------------------------------------------- B] freeze through invalid num in id_req_handler ----------------------------------------------- A client can freeze the server using a big num value (like 0x7fff or 0xffff) in the id_req_handler function used by the server in network/nNetObject.cpp. The server will be and will remain freezed with CPU at 100%. http://aluigi.altervista.org/adv/atrondos-adv.txt
Anything upstream ?
====================== 0.2.8.2.1 - August 5th, 2006 This version of Armagetron Advanced fixes some security flaws. It is recommended that you update to this version as soon as possible. Available on the download page as usual. ====================== games team, please bump.
Lovely... upstream has completely whacked out the build system (which is why we aren't on 0.2.8, at all)... we'll need to look into it a bit... I'm hoping to start looking into it tomorrow, but the 0.2.8 series hasn't been added for some time now, on purpose. See bug #102615 for more information.
Patches for 0.2.7.1 here: http://sourceforge.net/tracker/index.php?func=detail&aid=1534859&group_id=110997&atid=657950
Games please patch.
Fixed in 0.2.7.1-r1... PPC still needs to test...
ppc stable
Against game server so I'd say yes.
I'll vote YES as well so we're going to have a GLSA.
Tavis made me change my mind:-) Back to voting.
Ok, my feeling also says this doesn't merit a GLSA. BUT you'd have to back that up with something from policy, and I doubt you can. There's only "DoS" as a criteria, and "stable tree". If we let this one slip (well, actually in any case) we should definitely clarify what will be covered by GLSAs and what not. Arbitrariness is not going to lead us anywhere :)
We already have the vote in Policy. If a vote on games most often turns out to be a NO I see no reason to update Policy.
Hmm, probably bad wording on my part. If we feel that game server DoSes (and other stuff we might encounter) are not worth issuing a GLSA (and I personally think that's a good idea) I think we should make that clear somehow, or at least a bit clearer so people are able to understand it better. Transparency is always good.
i'm late but i would have voted no.
vote NO, impact is too minor (more of an annoyance than a DoS, should be fixed but does not warrant a glsa imho).
Closing with NO GLSA. Feel free to reopen if you disagree.
