874934 - Heap-buffer-overflow READ in speex_resampler_process_float

Status: RESOLVED DUPLICATE of bug 874915

(Core :: Web Audio, defect)

Description

[Atte Kettunen]

Attachment: Repro-file

Tested on: 

OS: Ubuntu 12.04

Firefox: ASAN opt-build 24.0a1 from 
https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux64-asan/1369217427/ 

Might have something to do with https://bugzilla.mozilla.org/show_bug.cgi?id=874915

ASAN-report:

==30819== ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f3b053c8a68 at pc 0x7f3b27649052 bp 0x7f3afd293cb0 sp 0x7f3afd293ca8
READ of size 4 at 0x7f3b053c8a68 thread T28
    #0 0x7f3b27649051 in speex_resampler_process_float /builds/slave/m-cen-l64-asan-ntly-0000000000/build/media/libspeex_resampler/src/resample.c:867
    #1 0x7f3b245f9786 in mozilla::dom::AudioBufferSourceNodeEngine::CopyFromInputBufferWithResampling(mozilla::AudioChunk*, unsigned int, unsigned long, unsigned long, unsigned int, unsigned int&, unsigned int&) /builds/slave/m-cen-l64-asan-ntly-0000000000/build/content/media/webaudio/AudioBufferSourceNode.cpp:213
    #2 0x7f3b245f7f7e in mozilla::dom::AudioBufferSourceNodeEngine::CopyFromBuffer(mozilla::AudioChunk*, unsigned int, unsigned int*, long*, unsigned int, unsigned int) /builds/slave/m-cen-l64-asan-ntly-0000000000/build/content/media/webaudio/AudioBufferSourceNode.cpp:289
    #3 0x7f3b245f671f in mozilla::dom::AudioBufferSourceNodeEngine::ProduceAudioBlock(mozilla::AudioNodeStream*, mozilla::AudioChunk const&, mozilla::AudioChunk*, bool*) /builds/slave/m-cen-l64-asan-ntly-0000000000/build/content/media/webaudio/AudioBufferSourceNode.cpp:392
    #4 0x7f3b2456617e in mozilla::AudioNodeStream::ProduceOutput(long, long) /builds/slave/m-cen-l64-asan-ntly-0000000000/build/content/media/AudioNodeStream.cpp:411
.
.
.

Comment 1

[Christoph Diehl [:posidron]]

This bug looks very similar to bug 867104 - it is crashing in the same frame / line number, the rest of the stack is also basically the same.

Comment 2

[(no longer active)]

Comment on attachment 752800 [details]
Repro-file

OK, so the test case here is crafted in a way that the first time that we set the buffer, we set the offset and duration, and the second time we fall into this check <http://hg.mozilla.org/mozilla-central/annotate/6066b9d92032/content/media/webaudio/AudioBufferSourceNode.cpp#l544> which means that the offset and duration will not get updated.  Now, note that the second buffer is shorter than the first one.  The length of the second buffer is crafted in a way that falls shorter than the offset argument to start(), which means that we end up updating the buffer, but the engine's mOffset will be past the end of the buffer, so future audio processing will proceed based on memory which doesn't belong to us.

Comment 3

[(no longer active)]

Also, note that those memory accesses are just floating point reads, so things should be ok (safe crash) but with speex involved, I don't know if the incoming data affects the branching decisions or is used as an offset or something like that.  CCing Jean-Marc to see if he knows.

Comment 4

[(no longer active)]

This is indeed a dupe of bug 874915.  The different stacks are caused by the fact that this test case does resampling, and the other one does not.  I'll attach my fix there.

Comment 5

[Jean-Marc Valin]

I don't have access to bug 874915. Do you still need any help from me?

Comment 6

[(no longer active)]

(In reply to Jean-Marc Valin (:jmspeex) from comment #5)
> I don't have access to bug 874915. Do you still need any help from me?

You're CCed there now, but my question is given comment 2 and 3, would you expect speex being involved making this bug exploitable?

Comment 7

[Jean-Marc Valin]

Sorry about the delay. So if I understand correctly, the bug is that the Speex resampler is being called with the wrong input length, which causes it to read floating point data past the end of the actual read buffer. If that's the case, then I don't see a way to exploit this because the resampler only does arithmetic on that data to produce the output samples. The actual values do not affect the control flow in any way (the resampler basically considers any audio as valid anyway).

Comment 8

[(no longer active)]

(In reply to Jean-Marc Valin (:jmspeex) from comment #7)
> Sorry about the delay. So if I understand correctly, the bug is that the
> Speex resampler is being called with the wrong input length, which causes it
> to read floating point data past the end of the actual read buffer. If
> that's the case, then I don't see a way to exploit this because the
> resampler only does arithmetic on that data to produce the output samples.
> The actual values do not affect the control flow in any way (the resampler
> basically considers any audio as valid anyway).

Great, that's exactly what I needed to know.  Thanks!

Comment 9

[(no longer active)]

Mass moving Web Audio bugs to the Web Audio component.  Filter on duckityduck.