Bugzilla Bug 103524

py2play uses python Pickle to send objects over a p2p game network.  Clients   
accept and use objects sent by peers, potentially executing code received from   
the network without any security checks to stop it.   
   
Simply put, it's trivial to modify a game client to send an exploit to other   
players and gain access to their system as their user.  A local root exploit   
could be launched from that point to gain complete access to their system.   
   
py2play was built around the Python Pickle module.  No patch will correct   
this without rewritting it from scratch.  It needs to be removed from the 
portage tree and any ebuilds which depend on it patched to no longer depend on 
it or replace py2play module with a dummy single-user module.

CC'ing kloeri as maintainer

kloeri as already working on the ebuild

"No patch will correct this without rewritting it from scratch."

Hmm.
So kloeri is rewriting it from scratch ? Or removing the thing ?

Reporter: is this vulnerability public ? If it is restricted, did you
communicate with other distributions ? Should/can I forward it to vendor-sec ?

<i>> So kloeri is rewriting it from scratch ? Or removing the thing ?</i> 
 
I hope not, since that is completely unnessesary at this point.  Slune, and 
other packages which require py2play, can either be compiled to no longer need 
py2play or the package installed by the "py2play" ebuild being nothing more 
than a dummy which acts as if it cannot connect. 
 
Honestly, I believe this really should be left to the author of py2play to fix, 
and that the correct response from distributions should be to remove it and any 
package which depends on it until the problem is solved in the official source. 
 
<i>> Reporter: is this vulnerability public ? If it is restricted, did you 
communicate with other distributions ? Should/can I forward it to 
vendor-sec ?</i> 
 
We've had this posted on the Soya wiki for some time 
[ http://soya.literati.org/ ] as this is a place likely to be seen by game 
maintainers who may use py2play, as the maintainer of py2play (Jiba) wrote an 
alternative.   
 
Unfortunetly, either by severe communication failure or testimony to his lack 
of interest in users' security, he repeated this mistake in the replacement 
(called Tofu) and has since refused to do anything more about it since he views 
the risk is "minor" and he believes the easy OO API of py2play/tofu outweighs 
the security risks. 
 
Seeing as the author refused to solve this problem, two weeks ago I began 
alerting the security teams of different distributions.  Some I haven't found 
the correct addresses for, and I'd appreciate it if you forwarded it to them. 
 
I posted it limited to the security team as I didn't want script kiddies to 
pounce on this, turning every player of Slune (etc) into a victim.  As I've 
demonstrated locally, it's trivial to write a worm which exploits this hole, 
and only a bit less trivial to trick victims into launching the game. 

Reporter: so I guess we can open the bug and fix/remove the thing ?
DerCorny/kloeri: let me know what you're up to...

Ok, i guess i was a bit too trigger happy with the "kloeri working on ebuild"
thing. Seems like we really have to hardmask or remove this package, kloeri
might wants to drop a line about what should happen, too?

I believe that py2play simply needs to be removed/hardmasked/etc.  There isn't 
a simple fix, it'd require rewritting py2play as a wrapper around something 
more secure and having some knowledge about the underlaying app. 
 
Slune, however, needs to be modified to remove it's multiplayer capability.  If 
you'll note, it's multiplayer functionality actually executes received network 
data, blowing the py2play security hole 5 magnitudes higher.  At least with 
py2play, a potential exploiter has to be a little clever with module loading to 
exploit it's hole. 
 
Removing py2play as a dependency from Slune and applying a patch to remove all 
instances of it and multiplayer support should allow Slune to still be playable 
and keep it's players secure.  Any other package which uses py2play should have 
the same thing done for it, I believe. 

vapier: masking/removing py2play will break some games, you might want to
comment :)

Talked to MrBones and package.masked py2play + slune.

Opening up the bug.
Looks like we need a masking GLSA here.

We definitely need one. I asked a CAN number to MITRE.

Arc, you can reference the following CAN number on the Soya wiki :

======================================================
Candidate: CAN-2005-2875
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2875
Reference: MISC:http://soya.literati.org/
Reference: CONFIRM:https://bugs.gentoo.org/show_bug.cgi?id=103524
Reference: CONFIRM:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326976

Py2Play allows remote attackers to execute arbitrary Python code via
pickled objects, which Py2Play unpickles and executes.

Mask GLSA 200509-09
Keeping bug opened as enhancement so that we remember to remove the thing sometime.

Should Slune still be hardmasked ?
The readme (http://home.gna.org/oomadness/en/slune/readme.html) seems to say
that they don't use py2play anymore.
That's also what I understand from the changelog
(http://home.gna.org/oomadness/en/slune/change.html) from version 1.0.6 at
least.

(sorry if this isn't the right place ... this is the bug that is pointed to in
package.mask for slune)

Created an attachment (id=86030) [details]
py2play-0.1.9.ebuild

The ebuild I just attached fixes this bug; the author of py2play released a
final version with all networking capabilities removed so that Slune can still
be played.  He said this was easier than removing py2play from Slune.

My recommendation is to remove the mask and the older ebuilds and run with this
until Slune is upgraded to using some other networking library.  The author has
stated he will no longer be working on py2play.

I figured this would be the best place to drop this.

kloeri: your opinion on this ?

I'll see if I can bump py2play in the next few days or so.

Hi,

is the newest version available now ?

Bumped in cvs.

Arches please test and mark stable.

py2play (In reply to comment #21)
> Arches please test and mark stable.
> 

No hurry to stable it on x86, but I guess it won't harm either. Builds fine
here, but no way to test it because:

py2play is only needed by games-action/slune which depends on
dev-python/pyopenal and it doesn't build (wrt bug 102138)

(In reply to comment #21)
> Arches please test and mark stable.
> 

Wanted to mention bug 124200 also blocks testing with slune, after I solved bug
102138 (with an version bump).

x86 is done... once ppc marks this stable, please also remove the mask on
slune/py2play in the tree...

Err... I've unmasked slune since it was only keyworded for x86 anyway...

ppc stable

Fixed in CVS. This one is ready for GLSA update.

Thx everyone.

GLSA update sent.