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 attachment 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.
