Control: clone -1 -2
Control: reassign -2 libmad 0.15.1b-8
Control: block -1 by -2
On Thu, Aug 03, 2017 at 01:11:07PM +0200, Moritz Muehlenhoff wrote:
> Source: libao
> Severity: important
> Tags: security
>
> This was assigned CVE-2017-11548:
> http://seclists.org/fulldisclosure/2017/Jul/84
FWIW wrt libao, I can't reproduce what was reported there on Stretch.
The 'crasher' example does still crash, but it blows up in libmad,
not in libao ...
I don't see any commit in the upstream libao repo which would have
addressed this, so I thought I'd take a quick look myself while I'm
prepping a new upload.
If I believe the backtrace from the original report - then at first
blush by eye, the worst I can see this doing in libao is getting it
to pass calloc some crazy large request to allocate - and then calloc
faulting instead of just failing ... which seems like a rather suspect
outcome to see in its own right. But there's not enough detail in that
backtrace to see what was really passed where.
In theory libao might be able to do some stronger/safer checking there,
but in that report we still have:
caller passes it junk -> large calloc -> libc segfaults
And since that code is managing allocations for channel mapping, and
with things like ambisonics there could be an arbitrarily large number
of channels to map ... putting some arbitrary limit on the size
passed to calloc in libao doesn't quite seem like a "solution" either.
So while libao might be able to do something more to muffle this (and
there is room for improvement in that code - it's not actually checking
to see if calloc failed everywhere that it probably should in a maximum
paranoia world, but that's not the bug which this example file appears
to have hit), I'm not really seeing a "bug" in libao which this example
demonstrates, let alone a real security issue resulting from it.
Which means I'm cloning it to libmad, since the next step here seems
to fairly clearly be fixing whatever currently explodes in it with
this example file - and when that is done, we can have another look
in that light as to whether libao ought to be doing something more to
protect its callers from themselves too ...
I won't close this copy for now, since I haven't fully analysed this
all the way down (and libmad doesn't have -dbg{,syms} available, so I
am going to stop here today). Below is what I'm currently seeing on
Stretch when running the example given.
Cheers,
Ron
$ gdb mpg321
(gdb) r libao_1.2.0_memory_corruption.mp3
Starting program: /usr/bin/mpg321 libao_1.2.0_memory_corruption.mp3
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2, and 3.
Version 0.3.2-1 (2012/03/25). Written and copyrights by Joe Drew,
now maintained by Nanakos Chrysostomos and others.
Uses code from various people. See 'README' for more!
THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK!
Playing MPEG stream from libao_1.2.0_memory_corruption.mp3 ...
MPEG 1.0 layer III, 192 kbit/s, 44100 Hz mono
*** Error in `/usr/bin/mpg321': double free or corruption (out):
0x00623370 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7681abcb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x76820f96]
/lib/x86_64-linux-gnu/libc.so.6(+0x777de)[0x768217de]
/usr/lib/x86_64-linux-gnu/libmad.so.0(mad_decoder_run+0x3b)[0x7725ff2b]
/usr/bin/mpg321[0x403f61]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x767ca2b1]
/usr/bin/mpg321[0x404e21]
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x767de3fa in __GI_abort () at abort.c:89
#2 0x7681abd0 in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x7690fdd0 "*** Error in `%s': %s: 0x%s ***\n")
at ../sysdeps/posix/libc_fatal.c:175
#3 0x76820f96 in malloc_printerr (action=3, str=0x7690fe98 "double
free or corruption (out)", ptr=, ar_ptr=)
at malloc.c:5049
#4 0x768217de in _int_free (av=0x76b43b00 ,
p=0x623360, have_lock=0) at malloc.c:3905
#5 0x7725ff2b in mad_decoder_run () from
/usr/lib/x86_64-linux-gnu/libmad.so.0
#6 0x00403f61 in ?? ()
#7 0x767ca2b1 in __libc_start_main (main=0x4037f0, argc=2,
argv=0x7fffe648, init=, fini=,
rtld_fini=,
stack_end=0x7fffe638) at ../csu/libc-start.c:291
#8 0x00404e21 in ?? ()
#9 0x7fffe638 in ?? ()
#10 0x001c in ?? ()
#11 0x0002 in ?? ()
#12 0x7fffe863 in ?? ()
#13 0x7fffe873 in ?? ()
#14 0x in ?? ()
