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): 0x0000000000623370 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7ffff681abcb] /lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7ffff6820f96] /lib/x86_64-linux-gnu/libc.so.6(+0x777de)[0x7ffff68217de] /usr/lib/x86_64-linux-gnu/libmad.so.0(mad_decoder_run+0x3b)[0x7ffff725ff2b] /usr/bin/mpg321[0x403f61] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7ffff67ca2b1] /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 0x00007ffff67de3fa in __GI_abort () at abort.c:89 #2 0x00007ffff681abd0 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7ffff690fdd0 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x00007ffff6820f96 in malloc_printerr (action=3, str=0x7ffff690fe98 "double free or corruption (out)", ptr=<optimized out>, ar_ptr=<optimized out>) at malloc.c:5049 #4 0x00007ffff68217de in _int_free (av=0x7ffff6b43b00 <main_arena>, p=0x623360, have_lock=0) at malloc.c:3905 #5 0x00007ffff725ff2b in mad_decoder_run () from /usr/lib/x86_64-linux-gnu/libmad.so.0 #6 0x0000000000403f61 in ?? () #7 0x00007ffff67ca2b1 in __libc_start_main (main=0x4037f0, argc=2, argv=0x7fffffffe648, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe638) at ../csu/libc-start.c:291 #8 0x0000000000404e21 in ?? () #9 0x00007fffffffe638 in ?? () #10 0x000000000000001c in ?? () #11 0x0000000000000002 in ?? () #12 0x00007fffffffe863 in ?? () #13 0x00007fffffffe873 in ?? () #14 0x0000000000000000 in ?? ()