[NT] MP3 Files can Cause Code Execution under Winamp
From: support@securiteam.comDate: 04/29/02
- Previous message: support@securiteam.com: "[UNIX] PHP-Survey Global.INC Information Disclosure Vulnerability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Date: Mon, 29 Apr 2002 09:19:42 +0200 (CEST)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
MP3 Files can Cause Code Execution under Winamp
------------------------------------------------------------------------
SUMMARY
It is possible to modify an existing MP3 file in such a way that it can
carry a virus. The virus is activated when the MP3 file is played in
Winamp and can then infect other MP3 files found on hard drives or network
shares. In order to protect yourself you need to upgrade to Winamp 2.80 or
disable the minibrowser.
DETAILS
Vulnerable systems:
Nullsoft Winamp version 2.79
Immune systems:
Nullsoft Winamp version 2.80
An MP3 file can contain the ID3v2 tag. It is a newer version of the ID3v1
tag and carries information like title, artist, and album. The tag is
parsed by Winamp when an MP3 file is loaded.
If the minibrowser is enabled, Winamp will try to query a script on
http://info.winamp.com for extra information about the song, based on data
from the ID3v2 tag. The buffer overflow condition occurs when the URL
string intended to be sent to the minibrowser is created. That means the
buffer overflow occurs before any actual internet connection to
info.winamp.com is being made.
The easiest way to test the buffer overflow condition is to apply at least
159 "?" characters in the title field of the ID3v2 tag. When playing the
MP3 file in Winamp 2.79 the following error log was created:
Access violation - code c0000005 (first chance)
eax=00000021 ebx=00000000 ecx=0012bd00 edx=00000032 esi=00000113
edi=00000113
eip=32253132 esp=00129c08 ebp=25313225 iopl=0 nv up ei pl zr na po
nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010246
32253132 ?? ???
If we debug Winamp, we notice that the created URL to be sent to the
minibrowser looks something like this:
http://info.winamp.com/winamp/WA.html?Alb=
&Art=%21%21%21%21%21%2...(alot)...%21Cid=winamp&
Tid=&Track=%21%21%21%...(alot)...
We also understand that the buffer is overwritten by maximum one NULL
character, making the register ESP change to 0x129c00. The ESP is then
incremented by 0x4 and a RET is done, sending the program to the address
found in 0x129c04.
We need the stack pointer 0x129c04 to be in a data space we are in control
of. The URL string is stored from 0x1298d8 to 0x129cd8, thus it seems like
we can control the EIP. Simply check the EIP of the error log. It displays
EIP=0x32253132, that is hex for "2%12". Seems like the stack pointer is
located somewhere in our URL string containing "...%21%21%21%21...".
(Remember that memory addresses are retrieved backwards!)
So how do we exploit this thing? Well normal buffer overflow exploit is to
return to anywhere in memory where we can find JMP ESP (op-code 0xFFE4) in
order to get back to the string that caused the buffer overflow. This
method is used because normal buffer overflows are only limited to the
fact that they cannot insert 0x00 in the return address because of string
operations.
The problem we face is we can only use characters a-z, A-Z, 0-9, ".",
because all others will be escaped to %HEX. That means the addresses
containing the JMP ESP instruction we need to find are a bit limited (but
of course in most cases not impossible to find as we only need one
location). Since the versions of the system .DLL files Winamp import at
launch is OS and system dependent, it really depends on the system if we
are able to find an available address containing the JMP ESP assembler
instruction.
Once we control the EIP, we have to do something useful. Since we still
are limited in what kind of op-codes we can construct, it's better to try
to get somewhere in memory where our URL is not escaped (ex. ! to %21).
When debugging we notice the register ECX is 0x12bd00 and points to a copy
of our URL partly un-escaped. Therefore, if we somehow can increase the
ECX and change the memory to do JMP ECX we are on a address where we can
create any op-code we want. This can be done with op-codes like:
0x66335142 ("f3QB") XOR DX,[ECX+0x42]
0x4A ("J") DEC EDX
0x665A ("fZ") POP DX
0x6652 ("fR") PUSH DX
It is not an easy task to perform the above and on some OS, it has to be
done differently, but still it is possible.
ADDITIONAL INFORMATION
The information has been provided by <mailto:sandblad@acc.umu.se> Andreas
Sandblad.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: support@securiteam.com: "[UNIX] PHP-Survey Global.INC Information Disclosure Vulnerability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
