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