Bug 1184448 (CVE-2014-9638) - CVE-2014-9638 vorbis-tools: division by zero on crafted WAV file
Summary: CVE-2014-9638 vorbis-tools: division by zero on crafted WAV file
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2014-9638
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=low,public=20150118,reported=2...
: 1185268 (view as bug list)
Depends On: 1184450
Blocks: 1184457 1185273
TreeView+ depends on / blocked
 
Reported: 2015-01-21 12:44 UTC by Martin Prpič
Modified: 2019-06-08 20:22 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-05-13 07:07:16 UTC


Attachments (Terms of Use)

Description Martin Prpič 2015-01-21 12:44:28 UTC
A divide-by-zero flaw was found in the way the oggenc utility, which is used to encode audio into the Ogg Vorbis format, processed certain WAV files. An attacker could provide a specially crafted WAV file that would crash oggenc when processed.

Upstream report:

https://trac.xiph.org/ticket/2137

Comment 1 Martin Prpič 2015-01-21 12:48:07 UTC
Created vorbis-tools tracking bugs for this issue:

Affects: fedora-all [bug 1184450]

Comment 2 Kamil Dudka 2015-01-21 13:09:14 UTC
Does it mean that any crasher bug is considered a security issue?

Should we also track e.g. bug #1003607 as a security issue then?

Comment 3 Martin Prpič 2015-01-21 13:48:35 UTC
(In reply to Kamil Dudka from comment #2)
> Does it mean that any crasher bug is considered a security issue?
> 
> Should we also track e.g. bug #1003607 as a security issue then?

No, not every bug that causes a crash is a security issue. This is yet to be evaluated; that is why I filed this bug. It is worth testing certain crafted inputs and how they crash the utility to find possible code execution flaws. I also created a tracking bug for Fedora because no matter the security implications, this should still be fixed.

Also, note that this has been rated as Low, indicating the impact is quite minimal. I requested a CVE on oss-sec and we'll treat this as a sec issue if it gets a CVE assigned.

Hope this answers your question!

Comment 4 Vasyl Kaigorodov 2015-01-23 11:24:48 UTC
*** Bug 1185268 has been marked as a duplicate of this bug. ***

Comment 5 Kamil Dudka 2015-01-26 12:32:55 UTC
I am not able to reproduce the crash on x86_64 using vorbis-tools-1.4.0-18.fc21 and attachment #983301 [details].  Valgrind output is sane:

$ rpm -q vorbis-tools
vorbis-tools-1.4.0-18.fc21.x86_64

$ curl -JO 'https://bugzilla.redhat.com/attachment.cgi?id=983301'
curl: Saved to filename 'crash_div_zero.wav'

$ valgrind oggenc -r -o test.ogg /tmp/crash_div_zero.wav
==24179== Memcheck, a memory error detector
==24179== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==24179== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==24179== Command: oggenc -r -o test.ogg /tmp/crash_div_zero.wav
==24179==
Encoding "/tmp/crash_div_zero.wav" to
         "test.ogg"
at quality 3.00


Done encoding file "test.ogg"

        File length:  0m 00.0s
        Elapsed time: 0m 00.7s
        Rate:         0.0430
        Average bitrate: 174.2 kb/s

==24179==
==24179== HEAP SUMMARY:
==24179==     in use at exit: 0 bytes in 0 blocks
==24179==   total heap usage: 1,167 allocs, 1,167 frees, 722,016 bytes allocated
==24179==
==24179== All heap blocks were freed -- no leaks are possible
==24179==
==24179== For counts of detected and suppressed errors, rerun with: -v
==24179== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


Please provide self-contained steps to reproduce the bug.

Comment 6 Siddharth Sharma 2015-02-17 06:22:49 UTC
Analysis
========

1. In the source file audio.c of oggenc in function where it opens the .wav file
 
int wav_open(FILE *in, oe_enc_opt *opt, unsigned char *oldbuf, int buflen)
{

2. here char array for reading buffer is defined

unsigned char buf[16];
...

3. then the buffer is read into format.channels, when reading here from malicious or specially crafted .wav file the value read from the buffer could be feeded as Zero '0' which would result in format.channels = 0
 
format.channels =    READ_U16_LE(buf+2);

4. After that while reading value into opt->total_samples_per_channel, here if format.channels is 0 would lead to division by zero of variable len in the code

        if(len)
        {
            opt->total_samples_per_channel = len/(format.channels*samplesize);
        }

Security impact of this issue is very low as it would require attacker to social engineer / convince the victim to open the malicious file.

Comment 8 Kamil Dudka 2015-02-17 11:17:14 UTC
Siddharth, were you able to trigger the crash or not?

The file in question seems to be processed by raw_open() instead of wav_open().  Therefore the above analysis does not apply I am afraid.

(In reply to Siddharth Sharma from comment #6)
> Security impact of this issue is very low as it would require attacker to
> social engineer / convince the victim to open the malicious file.

Even in that case, there will be just a division by zero.  It will not give you an interactive root shell I guess...

Comment 9 Siddharth Sharma 2015-02-17 11:23:56 UTC
(In reply to Kamil Dudka from comment #8)
> Siddharth, were you able to trigger the crash or not?
> 
> The file in question seems to be processed by raw_open() instead of
> wav_open().  Therefore the above analysis does not apply I am afraid.
> 
> (In reply to Siddharth Sharma from comment #6)
> > Security impact of this issue is very low as it would require attacker to
> > social engineer / convince the victim to open the malicious file.
> 
> Even in that case, there will be just a division by zero.  It will not give
> you an interactive root shell I guess...

Kamil, I was not able to trigger crash, but I checked code for the possibility of having such problem, according to this also https://trac.xiph.org/ticket/2137 which states

Stopped reason: SIGFPE 0x0804d497 in wav_open (in=0x805c368, opt=0xbffff2ec, oldbuf=0x805c4d0 "RIFF\f\002", buflen=0xc) at audio.c:552 552 opt->total_samples_per_channel = len/(format.channels*samplesize);


the only place in the code I found where it would trigger division by zero and yes it wont give a root shell, I would rather consider it as dos.

Comment 10 Kamil Dudka 2015-02-19 15:18:04 UTC
I have proposed a patch upstream:

http://lists.xiph.org/pipermail/vorbis-dev/2015-February/020423.html

Comment 11 Fedora Update System 2015-02-28 10:24:36 UTC
vorbis-tools-1.4.0-19.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 12 Fedora Update System 2015-02-28 10:27:00 UTC
vorbis-tools-1.4.0-14.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.