CVE-2017-11548

Debian Bug report logs - #870608
CVE-2017-11548

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: CVE-2017-11548

Date: Thu, 03 Aug 2017 13:11:07 +0200

Source: libao
Severity: important
Tags: security

This was assigned CVE-2017-11548:
http://seclists.org/fulldisclosure/2017/Jul/84

Cheers,
        Moritz

Message #14 received at 870608@bugs.debian.org (full text, mbox, reply):

From: Ron <ron@debian.org>

To: Moritz Muehlenhoff <jmm@debian.org>, 870608@bugs.debian.org

Subject: Re: Bug#870608: CVE-2017-11548

Date: Sat, 13 Jan 2018 18:20:39 +1030

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 ?? ()

Message #33 received at 870608@bugs.debian.org (full text, mbox, reply):

From: Elimar Riesebieter <riesebie@lxtec.de>

To: 870608@bugs.debian.org

Cc: 870406@bugs.debian.org

Subject: There is a possible patch available

Date: Wed, 6 Mar 2019 03:15:40 +0100

[Message part 1 (text/plain, inline)]

Hi all,

did someone checked

https://git.xiph.org/?p=libao.git;a=commit;h=d5221655dfd1a2156aa6be83b5aadea7c1e0f5bd 

?

Elimar
-- 
  We all know Linux is great... it does infinite loops in 5 seconds.
        -Linus Torvalds

[signature.asc (application/pgp-signature, inline)]

Message #38 received at 870608@bugs.debian.org (full text, mbox, reply):

From: Ron <ron@debian.org>

To: Elimar Riesebieter <riesebie@lxtec.de>, 870608@bugs.debian.org

Cc: 870406@bugs.debian.org

Subject: Re: Bug#870608: There is a possible patch available

Date: Thu, 7 Mar 2019 15:49:40 +1030

On Wed, Mar 06, 2019 at 03:15:40AM +0100, Elimar Riesebieter wrote:
> Hi all,
> 
> did someone checked
> 
> https://git.xiph.org/?p=libao.git;a=commit;h=d5221655dfd1a2156aa6be83b5aadea7c1e0f5bd 

You mean the commit which has :?

 author    Ron <ron@debian.org>  Sat, 13 Jan 2018 09:49:20 +0000 (20:19 +1030)
 committer Ron <ron@debian.org>  Sat, 13 Jan 2018 15:19:59 +0000 (01:49 +1030)

It was a while ago now, but yeah, I *probably* looked at that one ...


For the people on the other bug(s), the analysis behind that is here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870608#14

And the tldr version is, you can't punt this back to libao, and that
patch doesn't fix your bug.  AFAICS there is no bug in libao detected
by this "CVE", its test case explodes in libmad, not libao - and the
patch above just fixes some other potential issues I saw by eye while
auditing libao enough to give the analysis above.


And since Kurt seems to have done the same for libmad in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870406#25

It looks like the ball is squarely in the court of whoever cares about
mpg321 to do some debugging next and find what it's doing wrong.  And
then _possibly_ push back if some flaw in a support library really is
exacerbating the mistake it makes.

  Cheers,
  Ron

Send a report that this bug log contains spam.