Amarok Integer Overflow and Unchecked Allocation Vulnerabilities

2009.01.19
Credit: Tobias Klein
Risk: High
Local: Yes
Remote: No
CWE: CWE-119

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 -----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 (at) kde (dot) org [email concealed] (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-----

References:

https://bugzilla.redhat.com/show_bug.cgi?id=479946
https://bugzilla.redhat.com/show_bug.cgi?id=479560
http://www.securitytracker.com/id?1021558
http://www.securityfocus.com/archive/1/archive/1/499984/100/0/threaded
http://www.frsirt.com/english/advisories/2009/0100
http://websvn.kde.org/?view=rev&amp;revision=908415
http://websvn.kde.org/?view=rev&amp;revision=908401
http://websvn.kde.org/?view=rev&amp;revision=908391
http://trapkit.de/advisories/TKADV2009-002.txt
http://secunia.com/advisories/33505
http://openwall.com/lists/oss-security/2009/01/14/2
http://bugs.gentoo.org/show_bug.cgi?id=254896
http://amarok.kde.org/en/releases/2.0.1.1


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2017, cxsecurity.com

 

Back to Top