Bug#510205: buffer overflow in libaudiofile
The SUSE update simply contains the patch from: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510205#17 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510205: buffer overflow in libaudiofile
hi, any news on this one? since this is being tracked with critical severity, it really should be handled as swiftly as possible (it's been six months now since the original disclosure). suse has issued updates for CVE-2008-5824, perhaps their patches may be helpful [1]. thanks. mike [1] http://lists.opensuse.org/opensuse-security-announce/2009-02/msg0.html -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510205: buffer overflow in libaudiofile
Hi, what is the current status of this bug, anyone still working on this? Cheers Nico -- Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. pgpoDfhsAleKB.pgp Description: PGP signature
Bug#510205: buffer overflow in libaudiofile
It seems the root of the bug is some misunderstanding between the parsing and the decoding code about samples/frames per block. What is parsed as "samplesPerBlock" in the .wav file is a _frame_ count in reality, if we follow what seem to be libaudiofile's conventions. If you just decode less samples as in the proposed patch you'll always skip the second half of each buffer. The appended patch works better for me. It still doesn't protect against buffer overflows. best regards Matthias --- --- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt --- --- $NetBSD$ --- ./libaudiofile/wave.c.orig 2004-03-06 07:39:23.0 +0100 +++ ./libaudiofile/wave.c @@ -220,7 +220,8 @@ static status ParseFormat (AFfilehandle extraByteCount = LENDIAN_TO_HOST_INT16(extraByteCount); af_fread(&samplesPerBlock, 1, 2, fp); - samplesPerBlock = LENDIAN_TO_HOST_INT16(samplesPerBlock); + samplesPerBlock = LENDIAN_TO_HOST_INT16(samplesPerBlock) + * track->f.channelCount; af_fread(&numCoefficients, 1, 2, fp); numCoefficients = LENDIAN_TO_HOST_INT16(numCoefficients);
Bug#510205: buffer overflow in libaudiofile
tags 510205 + patch
thanks
Hi!
On Tue, Dec 30, 2008 at 02:28:58PM +0100, Max Kellermann wrote:
> Today, the Music Player Daemon project received a bug report from
> Anton Khirnov: MPD crashed when attempting to play a WAV file. "file"
> says:
>
> RIFF (little-endian) data, WAVE audio, Microsoft ADPCM, stereo 44100
> Hz
>
> The MPD bug report: http://musicpd.org/mantis/view.php?id=1915
>
> The test file: http://filebin.ca/meqmyu/max_theme.wav
It seems that audiofile's modules/msadpcm.c::ms_adpcm_decode_block()
incorrectly scales the samplesPerBlock value with the number of
channels. All adpcm-coded files with two channels should be affected.
With the attached patch, I can play the "max_theme" test file without
audiofile crashing. However, I think a few additional checks are in
order to make the module more robust against malicious input. I'll try
to check this in the next days.
Regards,
Daniel.
diff -r 247fd11d763d libaudiofile/modules/msadpcm.c
--- a/libaudiofile/modules/msadpcm.cSat Jan 03 20:35:58 2009 +0100
+++ b/libaudiofile/modules/msadpcm.cSun Jan 04 01:43:06 2009 +0100
@@ -129,8 +129,7 @@
ms_adpcm_state *state[2];
/* Calculate the number of bytes needed for decoded data. */
- outputLength = msadpcm->samplesPerBlock * sizeof (int16_t) *
- msadpcm->track->f.channelCount;
+ outputLength = msadpcm->samplesPerBlock * sizeof (int16_t);
channelCount = msadpcm->track->f.channelCount;
@@ -180,8 +179,7 @@
The first two samples have already been 'decoded' in
the block header.
*/
- samplesRemaining = (msadpcm->samplesPerBlock - 2) *
- msadpcm->track->f.channelCount;
+ samplesRemaining = msadpcm->samplesPerBlock - 2;
while (samplesRemaining > 0)
{
Processed: Re: Bug#510205: buffer overflow in libaudiofile
Processing commands for cont...@bugs.debian.org: > tags 510205 + patch Bug#510205: buffer overflow in libaudiofile Tags were: security Tags added: patch > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510205: buffer overflow in libaudiofile
Hi! On Tue, Dec 30, 2008 at 02:28:58PM +0100, Max Kellermann wrote: > Solution: don't use libaudiofile. Change libaudiofile to allocate the > correct buffer size. Add buffer size checks to libaudiofile. Many thanks for investigating and the detailed report. I'll try to get the buffer allocation fixed. Regards, Daniel. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510205: buffer overflow in libaudiofile
Package: libaudiofile0 Version: 0.2.6-6 Severity: critical Today, the Music Player Daemon project received a bug report from Anton Khirnov: MPD crashed when attempting to play a WAV file. "file" says: RIFF (little-endian) data, WAVE audio, Microsoft ADPCM, stereo 44100 Hz The MPD bug report: http://musicpd.org/mantis/view.php?id=1915 The test file: http://filebin.ca/meqmyu/max_theme.wav Turns out that this is a bug in libaudiofile. When attempting to decode the file, libaudiofile writes past the buffer in msadpcm.c:194 code = *encoded >> 4; newSample = ms_adpcm_decode_sample(state[0], code, coefficient[0]); *decoded++ = newSample; Valgrind output: ==4680== Invalid write of size 2 ==4680==at 0x8CF0478: ms_adpcm_run_pull (msadpcm.c:194) ==4680==by 0x8CEAF75: _AFpull (modules.c:111) ==4680==by 0x8CF11A3: int2rebufferf2vrun_pull (rebuffer.template:409) ==4680==by 0x8CDE4ED: afReadFrames (data.c:228) ==4680==by 0x435EBA: audiofile_streamdecode (audiofile_plugin.c:159) ==4680==by 0x4145A2: decoder_stream_decode (decoder_thread.c:49) ==4680==by 0x414A5C: decoder_run (decoder_thread.c:189) ==4680==by 0x414B7B: decoder_task (decoder_thread.c:214) ==4680==by 0x72E0453: g_thread_create_proxy (gthread.c:635) ==4680==by 0x62CBFC6: start_thread (pthread_create.c:297) ==4680==by 0xAA595AC: clone (in /usr/lib/debug/libc-2.7.so) ==4680== Address 0x15a66de8 is 0 bytes after a block of size 4,096 alloc'd ==4680==at 0x4C2260E: malloc (vg_replace_malloc.c:207) ==4680==by 0x8CDF96A: _af_malloc (util.c:122) ==4680==by 0x8CEEEBA: _AFsetupmodules (modules.c:2539) ==4680==by 0x8CDE151: afGetFrameCount (format.c:218) ==4680==by 0x435CDD: audiofile_streamdecode (audiofile_plugin.c:141) ==4680==by 0x4145A2: decoder_stream_decode (decoder_thread.c:49) ==4680==by 0x414A5C: decoder_run (decoder_thread.c:189) ==4680==by 0x414B7B: decoder_task (decoder_thread.c:214) ==4680==by 0x72E0453: g_thread_create_proxy (gthread.c:635) ==4680==by 0x62CBFC6: start_thread (pthread_create.c:297) ==4680==by 0xAA595AC: clone (in /usr/lib/debug/libc-2.7.so) A quick look at the code revealed that the allocated buffer size depended on the following formula: bufsize = outc->nframes * _af_format_frame_size(&outc->f, AF_TRUE); outc->nframes basically comes from _AF_ATOMIC_NVFRAMES (1024), because the msadpcm module does not implement the max_pull callback. This results in a 4096 byte allocation in modules.c:2539 (frame size is 4). In ms_adpcm_decode_block(), msadpcm->samplesPerBlock is set to 2036 (unverified value from the input file header). outputLength is 8144, which obviously does not fit into the allocated 4096 byte buffer. I could reproduce the same crash with "normalize-audio max_theme.wav". The real crash happens after closing the file, probably due to heap corruption. valgrind notices the problem before the crash actually occurs. Severity "critical" because this is may be used for a remote DoS attack on software like MPD. I did not investigate whether it is possible to inject code this way. Chances are good, since arbitrary amounts of heap can be overwritten. Both Debian Etch and Lenny are affected. Solution: don't use libaudiofile. Change libaudiofile to allocate the correct buffer size. Add buffer size checks to libaudiofile. Regards, Max Kellermann -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
