Vulnerability

    WinAMP

Affected

    WinAMP

Description

    Pauli  Ojanpera  found  following.   There  is  a  buffer overflow
    security  vulnerability  in  Winamp's  M3U  playlist  parser.  The
    overflow happens when an M3U extension called "#EXTINF:" is  being
    handled.  The size of the parameter following that keyword is  not
    checked.  Real world  example (cut here and  paste to a file  with
    m3u extension):

        #EXTM3U
        #EXTINF:AAAAAAAAA....AAAAAAAAA<cr><lf>

    There should be at least 280 A's.

    The overflow allows total control over ones computer.  For example
    one could embedd an M3U file to a web page several ways:

        - <A HREF="ATTACK.M3U">
        - <BGSOUND SRC="ATTACK.M3U">
        - <EMBED SRC="ATTACK.M3U">

    Pauli tested the  first one but  he has Media  Player installed on
    this computer and his browser  uses its components for the  latter
    two so he cannot confirm..

    The only  problem is  some structure  (FILE *?)  after the  buffer
    because  it  has  a  zero  in  it  and  it  must not be crafted to
    successfully return from  the function.   Pauli had to  apply some
    trial and error to get  code executed.  Currently the  code crafts
    Winamp's MOD file format support until restarted.

    The  attached  .M3U  file  should  crash  Winamp at 0000:41414141.
    This was  tested it  with Windows  98 and  Windows 95  with Winamp
    versions 2.62 and 2.64.

    #EXTM3U
    #EXTINF:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ĄPPPPAAAA

    The faulty function in question starts at memory address 0x411FE5.
    The function  has a  local variable  stored in  stack right  after
    the buffer  to be  overflowed and  right before  the stored  frame
    pointer (EBP).  This way:

        [Return address]                          = 4 bytes
        [Stored frame pointer (EBP)]              = 4 bytes
        [FILE *fp]                                = 4 bytes
        [Buffer to overflow (#EXTINF: parameter)] = 269 bytes

    In order  to get  the function  to successfully  return, the  file
    pointer in between  the buffer and  the stored frame  pointer MUST
    point to a  valid FILE record.   Because the FILE  pointer pointer
    contains a zero in it, it cannot be overwritten right to hold  the
    same old value it had.  Pauli however found out a valid address in
    IN_MOD plugin address space that he could use to fool the function
    to believe  the pointer  points to  a valid  record.  That address
    doesn't have values that couldn't be embedded in the string.

    The  ATTACK.M3U  above  has  this  value (0x1111A1A0) in the right
    position (bytes 270-273) in the parameter string.  After that,  it
    has a dummy  frame pointer value  ('PPPP') and next  is the return
    address to  jump to  ('AAAA').   With a  runtime debugger  (not to
    mention one) you can breakpoint at 0x411FE5 and inspect the  stack
    frame to see how things are stored there.

Solution

    Nothing yet.