Re: mpg123 buffer overflow in versions before 1.32.8 (Frankenstein's Monster)

[Marco Benatto <mbenatto () redhat com>]

Hello,

I just filed the details for the CVE above.

Description:
There's a out-of-bounds write issue in mpg123, the vulnerability is
located when handling crafted streams. During the decoding of PCM the
libmpg123 may write past the end of a heap located buffer, as
consequence heap corruption may happen and arbitrary code execution is
not discarded. The complexity required to exploit this flaw is
considered high as the payload needs to be validated by the MPEG
decoder and by the PCM synth before being executed. Additionally to
successfully execute the attack,the user needs to scan through the
stream making web live stream content (such as web radios) a very
unlikely attack vector.

CVSS: 6.7 CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H

Severity (according to the Red Hat severity policy): Moderate

Please let me know if there's any concern or different opinion
regarding the scoring or description of this issue.

Thanks,

Marco Benatto
Red Hat Product Security
secalert () redhat com for urgent response

On Wed, Oct 30, 2024 at 8:00 PM Marco Benatto <mbenatto () redhat com> wrote:
> Hello,
>
> I went ahead and assigned CVE-2024-10573 for this issue.
> I'll try to come up with the cvss and severity analysis by tomorrow.
>
> Please let me know if there's anything else I could help with.
>
> Thanks,
>
> Marco Benatto
> Red Hat Product Security
> secalert () redhat com for urgent response
>
> On Wed, Oct 30, 2024 at 2:42 PM Dr. Thomas Orgis
> <thomas.orgis () uni-hamburg de> wrote:
> > Dear list,
> >
> > as upstream of mpg123, I recently fixed a possibly serious issue that
> > resulted in writing past a buffer on the heap under certain use cases.
> > The fixed release is 1.32.8.
> >
> > There is no CVE for this (that I know of). If someone allocates one,
> > I'd be fine with that, but I am prioritizing my time in coordination
> > with demanding RL and focussed on getting the fix prepared. The bug
> > report
> >
> >         https://mpg123.org/bugs/322
> >
> > has always been public, so I got the fix out and decided that I do
> > spend a moment on this note here, seeing that distros still ship
> > vulnerable versions, notably Debian stable / oldstable ­— despite
> > the unstable repo duly having picked up my new release. I guess if
> > there is no CVE to grep in announcements people don't notice that it's
> > an important security fix? My bad, then …
> >
> > Observing that versions 1.26.x and 1.31.x are still in the wild, I
> > ported the recent security fix to those release series. Please see
> > recent commits to
> >
> >         svn://scm.orgis.org/mpg123/branches/1.26-fixes and
> >         svn://scm.orgis.org/mpg123/branches/1.31-fixes
> >
> > Current code is also visible under
> >
> >         https://scm.orgis.org/mpg123/branches/1.26-fixes/ and
> >         https://scm.orgis.org/mpg123/branches/1.31-fixes/
> >
> > I am quoting the initial release announcement, also avaiable under
> >
> >         https://mpg123.org/cgi-bin/news.cgi#2024-10-26
> >
> > Releasing mpg123 version 1.32.8: Frankenstein's Monster
> >
> > This is an important security update! There is possible buffer overflow
> > (writing of decoded PCM samples beyond allocated output buffer) for
> > streams that change output properties together with certain usage of
> > libmpg123. This needed seeking around in the stream (including scanning
> > it before actual decoding) to trigger. So, your usual web radio stream
> > as obvious attack vector is unlikely, as you won't seek around in it.
> > If you do work with stream dumps, usage of MPG123_NO_FRANKENSTEIN or
> > the --no-frankenstein option to the mpg123 application is a workaround
> > to avoid the formerly dangerous situation in earlier mpg123 releases.
> > This also means that mpg123 will not decode streams of concatenated
> > files with either varying format or leading Info frames past the first
> > track anymore.
> >
> > With this release, the parser has been improved not to store certain
> > stream properties before actual MPEG frame data matching that property
> > has been stored. This avoids the inconsistency that triggered the
> > overflow. Also note that if you always use a fixed decoding buffer for
> > full stereo of the maximum of 1152 samples per frame, times two and
> > your choice of encoding, your application is also not susceptible.
> >
> > Exploitation of this is not trivial, but I cannot rule out the
> > possibility of gaining code execution. Your exploit payload needs to
> > pass through an MPEG decoder and PCM synth before possibly reaching the
> > CPU. Some heap corruption can follow at the least. So update or
> > mitigate. If you run 1.32.x, there is no excuse not to get the the
> > latest bugfix release now.
> >
> > Basically any version of mpg123 is affected by this, at least those
> > that explicitly support so-called Frankenstein streams.
> >
> > Thanks to kkkkk123 for bringing this heir to the initial bug 322 to my
> > attention.
> >
> >
> > Alrighty then,
> >
> > Thomas
> >
> > --
> > Dr. Thomas Orgis
> > HPC @ Universität Hamburg