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."
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
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
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 :
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]
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.
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...
Fixed in CVS. This one is ready for GLSA update.
GLSA update sent.