See how mpg123 compares to other vendors in security performance
Am Thu, 31 Oct 2024 14:38:00 -0300 schrieb Marco Benatto <mbenatto () redhat com>: I just filed the details for the CVE above. Thanks a lot! The description sounds about right.
-- Dr. Thomas Orgis HPC @ Universität Hamburg
Am Fri, 1 Nov 2024 08:52:28 +0800 schrieb Alexander Patrakov <patrakov () gmail com>: Is there any way to check if any of my MP3 files contain the stuff that triggers the bug? Would, for example, Checkmate (https://github.com/Sjord/checkmate) flag them without also being exposed to security risks? It's tricky to detect the exact situation(s) that would lead to the decoder buffer overflow. The mpg123 parser is very persistent in making various damaged or ill-prepared MPEG streams work. MPEG streams (files) have a history of lots of stuff being tagged on or even just being actually damaged during transfer/storage. This makes it kind of a worst case from the security POV and my main defense for still maintaining this is that the codebase has been tested for bugs over a long period now and things like that are rather rare to be still found. This particular issue is embarrassing, though. In retrospect I should have not supported Frankenstein streams at all, I guess (I think I added that … been a long time). But I do have hope that the extensive testing the code gets on various fronts results in minimal chance of such glaring flaw surfacing again.
What a scanner like checkmate can do is to tell you if the file matches an ideal simple structure and will definitely not trigger the issue. It will be overly cautionous. Mpg123 will properly decode a lot more files, including the case of
cat .mp3 | mpg123 -
where the individual files may wary in lots of properties. The triggering of the bug needs two conditions:
1. MPEG headers vary in format (stereo or mono, for example). 2. There are incomplete frames that trigger the situation where the header got parsed, but no matching frame body was read.
Even this is not enough to really say if this is a stream that would trigger, as you need a certain combination of libmpg123 usage and stream.
If you know you deal with clean individual files and no streamdumps with random junk inserted, your referred scanner could do the trick and be a safe option. If you want to be a bit less extreme and more correct in terms of how mpg123 would parse the stream, with more error resilience, you can check for Frankenstein streams as mpg123 itself detects them:
mpg123 --index -n 0 file.mp3
will just run the parser over the file for indexing frame offsets, but not run the decoder on any of them (-n 0).
$ mpg123 --index -n 0 ~/Downloads/mpg123heapoverflowwrite High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3 version 1.32.8; written and copyright by Michael Hipp and others free software (LGPL) without any warranty but with best wishes
Warning: Xing stream size off by more than 1%, fuzzy seeking may be even more fuzzy than by design! Note: Illegal Audio-MPEG-Header 0x00000000 at offset 609. Note: Trying to resync... Note: Skipped 92 bytes in input.
Warning: Encountered more data after announced end of track (frame 1/1). Frankenstein! Note: Illegal Audio-MPEG-Header 0x6f9d179f at offset 910. Note: Trying to resync... Note: Skipped 17 bytes in input.
Warning: Real sample count 3456 differs from given gapless sample count 1152. Frankenstein stream? Directory: /home/user/Downloads/
Terminal control enabled, press 'h' for listing of keys and functions.
Playing MPEG stream 1 of 1: mpg123heapoverflowwrite ...
This was a Frankenstein track. [0:00] Decoding of mpg123heapoverflowwrite finished.
You could check for the message like this:
$ test "This was a Frankenstein track." = "$(mpg123 --index -n 0 ~bernd/Downloads/mpg123heapoverflowwrite 2>&1 | tail -n 2 | head -n 1)" && echo yes yes
You could be more cautionous by looking for 'Frankenstein' anywhere in the output, but that would catch files with that in the Path.
Also, you can add --no-infoframe to still let concatenated files that match in decoder properties pass through:
$ cat /some/album/.mp3 > /dev/shm/test.mp3 $ mpg123 --no-infoframe --index -n 0 /dev/shm/test.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3 version 1.32.8; written and copyright by Michael Hipp and others free software (LGPL) without any warranty but with best wishes
Directory: /dev/shm/
Terminal control enabled, press 'h' for listing of keys and functions.
Playing MPEG stream 1 of 1: test.mp3 ...
[0:00] Decoding of test.mp3 finished.
(no Frankenstein complaint)
$ mpg123 --index -n 0 /dev/shm/test.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3 version 1.32.8; written and copyright by Michael Hipp and others free software (LGPL) without any warranty but with best wishes
Warning: Xing stream size off by more than 1%, fuzzy seeking may be even more fuzzy than by design!
Warning: Encountered more data after announced end of track (frame 204/204). Frankenstein!
Warning: Real sample count 185602176 differs from given gapless sample count 235008. Frankenstein stream? Directory: /dev/shm/
Terminal control enabled, press 'h' for listing of keys and functions.
Playing MPEG stream 1 of 1: test.mp3 ...
This was a Frankenstein track. [0:00] Decoding of test.mp3 finished.
Thinking about this, I just realize that -n 0 also neatly avoids noise through metadata display, as that is only triggered by mpg123 when actually decoding.
So in short:
mpg123 --no-infoframe --index -n 0 testfile.mp3 \ | grep '^This was a Frankenstein track\.'
would be an adequate test.
Alrighty then,
Thomas
-- Dr. Thomas Orgis HPC @ Universität Hamburg
Hello,
Is there any way to check if any of my MP3 files contain the stuff that triggers the bug? Would, for example, Checkmate (https://github.com/Sjord/checkmate) flag them without also being exposed to security risks?
On Fri, Nov 1, 2024 at 1:42 AM Marco Benatto <mbenatto () redhat com> wrote: 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 MPG123NOFRANKENSTEIN 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
-- Alexander Patrakov
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 MPG123NOFRANKENSTEIN 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
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.
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 MPG123NOFRANKENSTEIN 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
A heap-based buffer over-read in the getbits function in src/libmpg123/getbits.h in mpg123 through 1.25.5 allows remote attackers to cause a possible denial-of-service (out-of-bounds read) or possibly have unspecified other impact via a crafted mp3 file.
Buffer overflow in mpg123 before 1.18.0.
Integer overflow in the INT123parsenewid3 function in the ID3 parser in mpg123 before 1.25.5 on 32-bit platforms allows remote attackers to cause a denial of service via a crafted file, which triggers a heap-based buffer overflow.
The nexttext function in src/libmpg123/id3.c in mpg123 1.24.0 allows remote attackers to cause a denial of service (buffer over-read) via a crafted mp3 file.
The IIIistereo function in libmpg123/layer3.c in mpg123 through 1.25.1 allows remote attackers to cause a denial of service (buffer over-read and application crash) via a crafted audio file that is mishandled in the code for the "blocktype != 2" case, a similar issue to CVE-2017-9870.
In mpg123 1.25.0, there is a heap-based buffer over-read in the convertlatin1 function in libmpg123/id3.c. A crafted input will lead to a remote denial of service attack.
Integer signedness error in the storeid3text function in the ID3v2 code in mpg123 before 1.7.2 allows remote attackers to cause a denial of service (out-of-bounds memory access) and possibly execute arbitrary code via an ID3 tag with a negative encoding value. NOTE: some of these details are obtained from third party information.
The httpopen function in httpget.c in mpg123 before 0.64 allows remote attackers to cause a denial of service (infinite loop) by closing the HTTP connection early.
Heap-based buffer overflow in httpdget.c in mpg123 before 0.59s-rll allows remote attackers to execute arbitrary code via a long URL, which is not properly terminated before being used with the strncpy function. NOTE: This appears to be the result of an incomplete patch for CVE-2004-0982.
Multiple buffer overflows in mpg123 0.59r allow user-assisted attackers to trigger a segmentation fault and possibly have other impacts via a certain MP3 file, as demonstrated by mpg1DoS3. NOTE: this issue might be related to CVE-2004-0991, but it is not clear.
Buffer overflow in mpg123 before 0.59s-r9 allows remote attackers to execute arbitrary code via frame headers in MP2 or MP3 files.
Buffer overflow in the findnextfile function in playlist.c for mpg123 0.59r allows remote attackers to execute arbitrary code via a crafted MP3 playlist.
Buffer overflow in the getauthfromURL function in httpget.c in mpg123 pre0.59s and mpg123 0.59r could allow remote attackers or local users to execute arbitrary code via an mp3 file that contains a long string before the @ (at sign) in a URL.
Buffer overflow in layer2.c in mpg123 0.59r and possibly mpg123 0.59s allows remote attackers to execute arbitrary code via a certain (1) mp3 or (2) mp2 file.
Heap-based buffer overflow in readstring of httpget.c for mpg123 0.59r and 0.59s allows remote attackers to execute arbitrary code via a long request.
mpg123 0.59r allows remote attackers to cause a denial of service and possibly execute arbitrary code via an MP3 file with a zero bitrate, which creates a negative frame size.