Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
|
|
|
|
|
|
|
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
|
|
|
|
Become a Partner and License Our Database or Notification Service
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SoX Buffer Overflow in st_wavstartread() Lets Remote Users Execute Arbitrary Code
|
|
SecurityTracker Alert ID: 1010800
|
|
SecurityTracker URL: http://securitytracker.com/id?1010800
|
|
CVE Reference: CAN-2004-0557
(Links to External Site)
|
Date: Jul 28 2004
|
Impact: Execution of arbitrary code via network, User access via network
|
Version(s): 12.17.2, 12.17.3, and 12.17.4
|
Description: Some buffer overflow vulnerabilities were reported in SoX in the processing of WAV files. A remote user can create a WAV file that, when played by SoX, will execute arbitrary code.
Ulf Harnhammar reported that there are two buffer overflows in the 'sox' and 'play' commands. The flaws reside in the st_wavstartread()
function in 'wav.c', where the function reads data based on a user-supplied size variable into a buffer without checking to see
if the specified amount of data will fit into the buffer.
The report indicates that older versions, including 12.17.1, 12.17
and 12.16, are not affected.
Vendors were reportedly notified on July 18, 2004.
|
Impact: A remote user can create a WAV file that, when processed by the target user, will execute arbitrary code on the target system with the privileges of the SoX process.
|
Solution: No vendor solution was available at the time of this entry.
The author of the report has provided the following unofficial patch:
---
wav.c.old 2002-12-31 04:19:22.000000000 +0100
+++ wav.c 2004-07-18 19:25:46.000000000 +0200
@@ -917,6 +917,10 @@
} else if(strncmp(magic,"ICRD",4)
== 0){
st_readdw(ft,&len);
len = (len + 1) & ~1;
+ if (len > 254) {
+ fprintf(stderr, "Possible buffer overflow
hack attack (ICRD)!\n");
+ exit(109);
+ }
st_reads(ft,text,len);
if (strlen(ft->comment) + strlen(text) < 254)
{
@@ -926,6 +930,10 @@
} else if(strncmp(magic,"ISFT",4) == 0){
st_readdw(ft,&len);
len = (len + 1) & ~1;
+ if
(len > 254) {
+ fprintf(stderr, "Possible buffer overflow hack attack (ISFT)!\n");
+ exit(110);
+ }
st_reads(ft,text,len);
if (strlen(ft->comment) + strlen(text) < 254)
{
|
Vendor URL: sox.sourceforge.net/ (Links to External Site)
|
Cause: Boundary error
|
Underlying OS: Linux (Any), UNIX (Any)
|
Reported By: Ulf Harnhammar <Ulf.Harnhammar.9485@student.uu.se>
|
Message History:
This archive entry has one or more follow-up message(s) listed below.
|
Source Message Contents
|
Date: Wed, 28 Jul 2004 20:53:13 +0200
From: Ulf =?iso-8859-1?b?SORybmhhbW1hcg==?= <Ulf.Harnhammar.9485@student.uu.se>
Subject: [VulnWatch] SoX buffer overflows when handling .WAV files
|
---MOQ1091040793b8d6f18df737723e8f5a0a25e57e509c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
SoX buffer overflows when handling .WAV files
I have found two buffer overflows in SoX. They occur when the sox
or play commands handle malicious .WAV files. The overflows have
the identifier CAN-2004-0557.
Versions 12.17.4, 12.17.3 and 12.17.2 are vulnerable to these
overflows. Vulnerable versions of the program are included in many
Linux distributions and *BSD Port/Package Collections. Older versions
including 12.17.1, 12.17 and 12.16 are not vulnerable.
SoX may not be the most security critical program, but it is possible
to exploit this. Some attack vectors are social engineering (I have
used play to play .WAV files from untrusted sources several times
before I found this), programs that use SoX to play data from the net
(examples include JiveAudio and vmail), and people who put play in
their mailcap files (so it plays sound files in MIME messages as
soon as the messages are opened). It is also interesting to note
that xmms can play .WAV files with this type of data just fine.
Both overflows occur in wav.c in the function st_wavstartread().
In both cases, the program first reads 4 bytes from the .WAV file
into a variable. Then it reads as many bytes as that variable says
from the .WAV file into a 256 bytes long char array, without checking
if the data from the .WAV file fits in that array. This leads to a
stack-based buffer overflow with control over EIP, as you can see
in this session capture:
$ play buffy.wav
playing buffy.wav
/usr/bin/play: line 1: 4990 Segmentation fault sox $volume
$fopts $fopts2 "$filename_0" $arch_defines $device $effects
$ sox buffy.wav -t ossdsp /dev/dsp
Segmentation fault
$ gdb /usr/bin/sox
GNU gdb 6.1-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-linux"......Using host libthread_db
library "/lib/libthread_db.so.1".
(gdb) r buffy.wav -t ossdsp /dev/dsp
Starting program: /usr/bin/sox buffy.wav -t ossdsp /dev/dsp
Program received signal SIGSEGV, Segmentation fault.
0x55555555 in ?? ()
(gdb) i r
eax 0x0 0
ecx 0x0 0
edx 0x0 0
ebx 0x55555555 1431655765
esp 0xbffff940 0xbffff940
ebp 0x55555555 0x55555555
esi 0x55555555 1431655765
edi 0x55555555 1431655765
eip 0x55555555 0x55555555
eflags 0x10282 66178
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x0 0
(gdb) bt
#0 0x55555555 in ?? ()
#1 0x55555555 in ?? ()
#2 0x55555555 in ?? ()
#3 0x55555555 in ?? ()
#4 0x55555555 in ?? ()
#5 0x55555555 in ?? ()
#6 0x55555555 in ?? ()
#7 0xbffff900 in ?? ()
#8 0x08072fa2 in _IO_stdin_used ()
#9 0x00008572 in ?? ()
#10 0x45564157 in ?? ()
#11 0x002a5550 in ?? ()
#12 0x0807d0b8 in ?? ()
#13 0x0807d3c4 in ?? ()
#14 0x080a4400 in ?? ()
#15 0xbffff9a8 in ?? ()
#16 0x0804c9b7 in ?? ()
#17 0x08072f56 in _IO_stdin_used ()
#18 0xbffffb74 in ?? ()
#19 0x00000000 in ?? ()
#20 0x00000000 in ?? ()
#21 0x080a4400 in ?? ()
#22 0x00000005 in ?? ()
#23 0xbffff9c8 in ?? ()
#24 0x0804ad4b in ?? ()
#25 0x080a3cd8 in ?? ()
#26 0x00000001 in ?? ()
#27 0xbffff9c8 in ?? ()
#28 0x0804a42b in ?? ()
#29 0x080a4400 in ?? ()
#30 0x000005b4 in ?? ()
#31 0x76000001 in ?? ()
#32 0x00000005 in ?? ()
#33 0x080a4400 in ?? ()
#34 0x00000005 in ?? ()
#35 0xbffff9f8 in ?? ()
#36 0x0804a08b in ?? ()
#37 0x080a4400 in ?? ()
#38 0x00000005 in ?? ()
#39 0xbffffa54 in ?? ()
#40 0x080725bb in ?? ()
#41 0x402a5550 in ?? () from /lib/libc.so.6
#42 0x08072600 in ?? ()
#43 0x00000001 in ?? ()
#44 0x402a5550 in ?? () from /lib/libc.so.6
#45 0x400164a0 in ?? () from /lib/ld-linux.so.2
#46 0xbffffa54 in ?? ()
#47 0xbffffa28 in ?? ()
#48 0x4018bdc6 in __libc_start_main () from /lib/libc.so.6
Previous frame inner to this frame (corrupt stack?)
(gdb) q
The program is running. Exit anyway? (y or n) y
I have attached a .WAV file that causes a buffer overflow, as well
as a patch against 12.17.4 that stops both overflows.
I contacted upstream, the vendor-sec list and naddy (an
OpenBSD/FreeBSD guy) on the 18th of July. I received the CAN/CVE
identifier on the same day. The 28th was agreed upon as the release
date, so I am releasing this now.
Greetings to Sitic, Sanctum Inc, Secunia, OWASP, Gobbles, F-Secure,
Ladytron, Vic Twenty (the band), Naked Ape, Slagsmalsklubben and
everyone from the Debian Security Audit Project.
// Ulf Harnhammar
[ http://www.advogato.org/person/metaur/ ]
for the Debian Security Audit Project
[ http://www.debian.org/security/audit/ ]
---MOQ1091040793b8d6f18df737723e8f5a0a25e57e509c
Content-Type: text/x-patch; name="sox.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="sox.patch"
LS0tIHdhdi5jLm9sZAkyMDAyLTEyLTMxIDA0OjE5OjIyLjAwMDAwMDAwMCArMDEwMAorKysgd2F2
LmMJMjAwNC0wNy0xOCAxOToyNTo0Ni4wMDAwMDAwMDAgKzAyMDAKQEAgLTkxNyw2ICs5MTcsMTAg
QEAKIAkJfSBlbHNlIGlmKHN0cm5jbXAobWFnaWMsIklDUkQiLDQpID09IDApewogCQkJc3RfcmVh
ZGR3KGZ0LCZsZW4pOyAKIAkJCWxlbiA9IChsZW4gKyAxKSAmIH4xOworCQkJaWYgKGxlbiA+IDI1
NCkgeworCQkJICAgIGZwcmludGYoc3RkZXJyLCAiUG9zc2libGUgYnVmZmVyIG92ZXJmbG93IGhh
Y2sgYXR0YWNrIChJQ1JEKSFcbiIpOworCQkJICAgIGV4aXQoMTA5KTsKKwkJCX0KIAkJCXN0X3Jl
YWRzKGZ0LHRleHQsbGVuKTsKIAkJCWlmIChzdHJsZW4oZnQtPmNvbW1lbnQpICsgc3RybGVuKHRl
eHQpIDwgMjU0KQogCQkJewpAQCAtOTI2LDYgKzkzMCwxMCBAQAogCQl9IGVsc2UgaWYoc3RybmNt
cChtYWdpYywiSVNGVCIsNCkgPT0gMCl7CiAJCQlzdF9yZWFkZHcoZnQsJmxlbik7IAogCQkJbGVu
ID0gKGxlbiArIDEpICYgfjE7CisJCQlpZiAobGVuID4gMjU0KSB7CisJCQkgICAgZnByaW50Zihz
dGRlcnIsICJQb3NzaWJsZSBidWZmZXIgb3ZlcmZsb3cgaGFjayBhdHRhY2sgKElTRlQpIVxuIik7
CisJCQkgICAgZXhpdCgxMTApOworCQkJfQogCQkJc3RfcmVhZHMoZnQsdGV4dCxsZW4pOwogCQkJ
aWYgKHN0cmxlbihmdC0+Y29tbWVudCkgKyBzdHJsZW4odGV4dCkgPCAyNTQpCiAJCQl7Cg==
---MOQ1091040793b8d6f18df737723e8f5a0a25e57e509c--
|
|
Go to the Top of This SecurityTracker Archive Page
|
