Possible mplayer GUI vulnerability just posted on Bugtraq: All versions of MPlayer, including the latest [MPlayer-1.0pre4] when compiled with GUI support are vulnerable to a buffer overflow attack that will provide hostile code execution. A single post regarding buffer overflow in the GUI posted to MPlayer-dev-eng http://mplayerhq.hu/pipermail/mplayer-dev-eng/2004-June/026559.html
Unfortunately, there is no fix upstream, and the Gui component for mplayer isn't very well maintained IIRC... maybe that's changed recently and I didn't notice...
*** Bug 55601 has been marked as a duplicate of this bug. ***
Updating status whiteboard
More news from http://mplayerhq.hu/ : ---------------------------------------- Summary Multiple string vulnerabilities have been found and fixed in the MPlayer GUI code, at least one of which was remotely exploitable. Severity High (arbitrary remote code execution under the user ID running the player) if using the GUI to play certain types of playlist files, none when using only the command line. The MPlayer GUI is optional and not built by default. Solution A fix for the vulnerability with the known exploit was checked into MPlayer CVS on Wed, 2 June 2004 12:40:41 +0000 (UTC). The result of a thorough code audit that uncovered further potentially exploitable bugs was checked into MPlayer CVS on Fri, 25 June 2004 16:49:52 +0000 (UTC). All of this will be included in MPlayer 1.0pre5. Users of affected MPlayer versions should upgrade to latest CVS or MPlayer 1.0pre5 once it becomes available. Alternatively a patch for the main and 0_90 MPlayer CVS versions is available that can be applied to the MPlayer source tree. Affected versions MPlayer 1.0pre4 and beforey MPlayer 0.92.1 and before Unaffected versions none History On Tue, 1 June 2004 MPlayer developers were contacted by c0ntex who had found a string handling vulnerability in the MPlayer GUI code complete with an example exploit and a preliminary fix. That fix was checked into MPlayer CVS on Wed, 2 June 2004 12:40:41 +0000 (UTC). When playing certain types of playlist files with extremely long entries a buffer overflow error occurs. This allows an attacker to overwrite memory with specially crafted playlist files and execute arbitrary code under the user ID running MPlayer. Richard Felker started a general audit of the GUI code for further string handling problems and uncovered a host of potential bugs, some of which were probably exploitable. Nicholas Kain proceeded to do a full audit of the MPlayer code for insecure string handling, which was finished by Alexander Strasser. The result of this audit was checked into MPlayer CVS on Fri, 25 June 2004 16:49:52 +0000 (UTC). Since the first quick review of the GUI code immediately revealed several potentially exploitable bugs we have refrained from publishing this advisory until a thorough audit of the whole code was finished. On Thu, 1 July 2004 11:22:29 (UTC) a simple port of the fixes was committed to the 0_90 stable MPlayer source tree. This was done without a further audit of the 0_90 code base due to lack of resources. We have therefore dropped further support of the 0_90 tree and recommend upgrading to MPlayer 1.0pre5 or latest CVS. Download MPlayer 1.0pre5, 0.93 and CVS snapshots can be downloaded from the MPlayer homepage or one of its many mirrors as soon as they become available. Go to the MPlayer download page to get MPlayer 1.0pre5 source code or a CVS snapshot. -------------------------------------------
0.93 is out, but "The 0.90 branch is long obsolete, there will be no further releases, probably not even security fix releases. Therefore we strongly recommend upgrading to MPlayer 1.0pre5 once it becomes available or a current CVS snapshot." There are multiple issues here : Since the sparc has no 1.0_pre* stable, we either need a 0.93 ebuild for them or that sparc has reasonable confidence they will be able to mark a 1.0_pre5 ebuild stable. The 1.0_pre5 release is not out yet, but the fix is in mplayer CVS, so we can wait a little more or try to apply a patch to a 1.0_pre4-r5. Cc: sparc and media-video to get their opinion on this.
I guess unless the mplayer-1.05 release comes out in the next day or so, we should probably go with 0.93
ebuild in cvs, please mark stable.
Target keywords for media-video/mplayer-1.0_pre5: "alpha amd64 ~hppa ~ia64 ~mips ppc sparc x86" Arches: please test and adjust keywords accordingly.
Stable on ppc.
Stable on sparc.
this still has a few issues on amd64... nothing massive, but issues none the less. chriswhite - i've given you a shell like you asked for, i officially delegate fixing those to you. feel free to keyword the ebuild stable on amd64 afterward ;)
Stable on alpha.
hppa done
i just checked out mplayer CVS and it seems that they're making some progress on fixing things for amd64. mplayer can now use multiple shades of blue instead of just a single solid shade. the error "cast from pointer to integer of different size" also shows up only 37 times while compiling. would it be possible to just shove this security fix into a revision of pre4? otherwise it will take a pretty long time for amd64 to be ready. :/
Myself and lv worked hard on it, mplayer 1.0 pre4-r5 is now in cvs with the appropriate security fixes and is marked stable by him as well. So, as the line goes: Stable on amd64. security: amd64 will use pre4-r5 as its stable release version while everyone else will use pre5 (unless mips and ia64 need pre4-r5 as well).
chris - some time between when you fixed mplayer and the morning mplayer broke. i'm going to remove it from stable, as it doesnt even compile now.
ok, -now- it's fixed. pre4-r5 stable on amd64 :) hopefully pre5 will be fixed at some point, but that's pretty unrealistic at the moment. for now though, pre4-r5 has the security fix. moo
In talking with upstream, I've found the ebuild to be very garbled for mplayer, I'm halting the stable checks until I make sure the ebuild is as clean as possible. This cleanup may help to make pre5 a globally stable version for all archs to utilize. Sorry about any delays this may cause, but I want the ebuild to be as efficient as possible before stable markings occur.
Back to ebuild status until maintainer provides an ebuild that is satisfactory to him.
Updated ebuilds in cvs.
After the commit, there were a couple more cleanup issues. As was such, they were taken care of and it should be as follows: amd64 uses mplayer-1.0_pre4-r6 everyone else mplayer-1.0_pre5-r1 These 2 ebuilds such fix some issues with the previous ones. Thanks for your patience!
OK, so we are back in the stable-ize game. amd64 : please mark mplayer-1.0_pre4-r6 stable. alpha, ppc, sparc, x86 : please mark mplayer-1.0_pre5-r1 stable. mips : please mark one of those two "~mips"
Are you done changing these ebuilds or should we leave it a week or so before stabling them?
amd64, x86: Tested and marked stable. sparc: I've always had some trouble with mplayer on sparc (video is distorted a bit half the time I play something)... but with this version, the distortion seems to be much more apparent. It might be related to my recent changes in toolchain, but I'm not sure. Can another sparc dev please test out the ebuild.
Under eradicator's suggesstion: all archs mark mplayer-1.0_pre4-r7 stable final answer. Updating glsa with that info.
Stable on ppc for _pre4-r7.
sparc: please mark a version >=mplayer-1.0_pre4-r7 stable so that the GLSA can go out. alpha : mark >=mplayer-1.0_pre4-r7 stable to benefit from the GLSA mips : mark >=mplayer-1.0_pre4-r7 "~mips" to benefit from the GLSA
Tested with a couple of vids: dance monkey, creamedgates and the like ;) Marked stable on sparc.
1.0_pre4-r7 marked stable on alpha.
I'm marking pre5-r2 to unstable. I'm still sorting through a few here and there issues (some upstream related) and am not confident enough to call it stable on x86. Pre4-r7 will definately be the stable choice for x86.
Then we still need pre4-r7 marked stable on x86 before releasing the GLSA.
This package should have been marked stable before. I'm guessing it wasn't because of the pre5-r2 stable questioning. Now that it's patched though and works just fine, it should have been x86. It wasn't, and now is. Sorry for any confusion this may have caused.
Now we're ready... Will be sent as soon as cfengine or infra corrects ownership of GLSAMaker August data directory.
GLSA 200408-01 mips : don't forget to mark "~mips" pre4-r7 to benefit from the GLSA.
