Bug 1184448 (CVE-2014-9638)

Created vorbis-tools tracking bugs for this issue:

Affects: fedora-all [bug 1184450]

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?

(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!

*** Bug 1185268 has been marked as a duplicate of this bug. ***

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.

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.

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...

(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.

I have proposed a patch upstream:

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

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.

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.