This is a multi-part message in MIME format.
--------------020504080803080507050900
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Please find attached a detailed advisory of the vulnerabilities.

Alternatively, the advisory can also be found at:
http://www.trapkit.de/advisories/TKADV2009-002.txt 

--------------020504080803080507050900
Content-Type: text/plain;
 name="TKADV2009-002.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="TKADV2009-002.txt"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Advisory:               Amarok Integer Overflow and Unchecked Allocation 
                        Vulnerabilities
Advisory ID:            TKADV2009-002
Revision:               1.0              
Release Date:           2009/01/11 
Last Modified:          2009/01/11
Date Reported:          2009/01/05
Author:                 Tobias Klein (tk at trapkit.de)
Affected Software:      Amarok < version 2.0.1.1
Remotely Exploitable:   Yes
Locally Exploitable:    No 
Vendor URL: http://amarok.kde.org/ 
Vendor Status:          Vendor has released an updated version
Patch development time: 7 days


=====================Vulnerability Details: 
=====================
Amarok contains several integer overflows and unchecked allocation 
vulnerabilities while parsing malformed Audible digital audio files. 
The vulnerabilities may be exploited by a (remote) attacker to execute 
arbitrary code in the context of Amarok.


=================Technical Details:
=================
Source code file from Amarok 2.0: 
  amarok-2.0\src\metadata\audible\audibletag.cpp

[...]
140 bool Audible::Tag::readTag( FILE *fp, char **name, char **value)
141 {
142        quint32 nlen;
143 [1]    if ( fread(&nlen, sizeof(nlen), 1, fp) != 1 )
144            return false;
145 
146        nlen = ntohl(nlen);
147        //fprintf(stderr, "tagname len=%x\n", (unsigned)nlen);
148 [2]    *name = new char[nlen+1];
149 [4]    (*name)[nlen] = '\0';
150 
151        quint32 vlen;
152 [5]    if ( fread(&vlen, sizeof(vlen), 1, fp) != 1 )
153        {
154            delete [] *name;
155            *name = 0;
156            return false;
157        }
158 
159        vlen = ntohl(vlen);
160        //fprintf(stderr, "tag len=%x\n", (unsigned)vlen);
161 
162 [3]    if ( fread(*name, nlen, 1, fp) != 1 )
163        {
164            delete [] *name;
165            *name = 0;
166            return false;
167        }
168 
169 [6]    *value = new char[vlen+1];
170 [8]    (*value)[vlen] = '\0';
171 
172 [7]    if ( fread(*value, vlen, 1, fp) != 1 )
173        {
174            delete [] *value;
175            *value = 0;
176            return false;
177        }
178 
[...]

Description of integer overflow #1 that leads to a heap buffer overflow:

[1] A user defined value is extracted from the media file and stored in 
    the unsigned int variable "nlen".
[2] In this line a heap buffer of "nlen+1" bytes is allocated. By supplying
    a value of 0xffffffff for "nlen" an integer overflow happens resulting 
    in the allocation of a very small heap buffer. 
[3] The user controlled value of "nlen" is used as a length specifier to 
    copy user controlled data from the media file into the previously 
    allocated (small) heap buffer pointed to by "name". As "nlen" has a 
    very large value (0xffffffff) the heap buffer is overflowed with user 
    controlled data of the media file. The exact number of bytes that get 
    written beyond the heap buffer can be controlled by the length of the 
    media file. This leads to a controllable heap overflow vulnerability.  

Description of the unchecked allocation vulnerability #1 that may result in
an exploitable memory corruption condition:

[2] + [4] This code fails to check for a NULL pointer returned from a new 
          [] statement. The resulting pointer is then dereferenced by the 
          user controlled value of "nlen" and a 8-bit value of 0x00 is 
          assigned to the dereferenced location. This issue can be 
          exploited to overwrite an arbitrary memory location with the 1-
          byte value 0x00. A malicious party may exploit this issue to 
          execute arbitrary code by overwriting a sensitive memory location
          (such as a buffer length or boolean variable).

Description of integer overflow #2 that leads to a heap buffer overflow:

[5] A user defined value is extracted from the media file and stored in 
    the unsigned int variable "vlen".
[6] In this line a heap buffer of "vlen+1" bytes is allocated. By supplying
    a value of 0xffffffff for "vlen" an integer overflow happens resulting 
    in the allocation of a very small heap buffer. 
[7] The user controlled value of "vlen" is used as a length specifier to 
    copy user controlled data from the media file into the previously 
    allocated (small) heap buffer pointed to by "value". As "vlen" has a 
    very large value (0xffffffff) the heap buffer is overflowed with user 
    controlled data of the media file. The exact number of bytes that get 
    written beyond the heap buffer can be controlled by the length of the 
    media file. This leads to a controllable heap overflow vulnerability. 

Description of the unchecked allocation vulnerability #2 that may result in
an exploitable memory corruption condition:

[6] + [8] This code fails to check for a NULL pointer returned from a new 
          [] statement. The resulting pointer is then dereferenced by the 
          user controlled value of "vlen" and a 8-bit value of 0x00 is 
          assigned to the dereferenced location. This issue can be 
          exploited to overwrite an arbitrary memory location with the 1-
          byte value 0x00. A malicious party may exploit this issue to 
          execute arbitrary code by overwriting a sensitive memory location
          (such as a buffer length or boolean variable).

In Amarok versions < 2.0 the source code of the vulnerable function is 
slightly different but suffers from the same vulnerabilities.


========= 
Solution: 
========
  Upgrade to Amarok version 2.0.1.1


======== 
History: 
=======
2009/01/05 - KDE Security notified using security@kde.org (no response) 
  2009/01/08 - KDE Security notified a 2nd time 
  2009/01/09 - Response of the Amarok maintainers. Patch developed.
  2009/01/11 - New Amarok version released and public disclosure of 
               vulnerability details by Amarok maintainers
  2009/01/11 - Release date of this security advisory


======== 
Credits: 
=======
  Vulnerability found and advisory written by Tobias Klein.


=========== 
References: 
==========
[1] http://amarok.kde.org/de/node/600 
[2] http://www.trapkit.de/advisories/TKADV2009-002.txt 


======== 
Changes: 
=======
  Revision 0.1 - Initial draft release to the vendor
  Revision 1.0 - Public release


==========Disclaimer:
==========
The information within this advisory may change without notice. Use
of this information constitutes acceptance for use in an AS IS
condition. There are no warranties, implied or express, with regard
to this information. In no event shall the author be liable for any
direct or indirect damages whatsoever arising out of or in connection
with the use or spread of this information. Any use of this
information is at the user's own risk.


================== 
PGP Signature Key: 
=================
http://www.trapkit.de/advisories/tk-advisories-signature-key.asc 

  
Copyright 2009 Tobias Klein. All rights reserved.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG

iD8DBQFJai8ikXxgcAIbhEERAra6AKDtjwwMGj9l0epKrPTfiFzN5NdNnACeIxHL
Ga1AKITh9usybkQgwJTyNoA=X9Mk
-----END PGP SIGNATURE-----

--------------020504080803080507050900--