Bug: Amarok Integer Overflow and Unchecked Allocation Vulnerabilities ( Ascii Version )

Search:
WLB2

Amarok Integer Overflow and Unchecked Allocation Vulnerabilities

Published
Credit
Risk
2009.01.19
Tobias Klein
High
CWE
CVE
Local
Remote
CWE-119
CVE-2009-0135
CVE-2009-0136
Yes
No

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

See this note in TXT Version

Bugtraq RSS
Bugtraq
 
REDDIT
REDDIT
 
DIGG
DIGG
 
LinkedIn
LinkedIn
 
CVE RSS
CVEMAP

Copyright 2014, cxsecurity.com
Ascii Version