Discussion:
Bug#867579: libopenmpt: Security updates libopenmpt-0.2.7386-beta20.3-p10 available
Add Reply
Jörn Heusipp
2017-07-07 14:41:52 UTC
Reply
Permalink
Raw Message
Source: libopenmpt
Version: 0.2.7386~beta20.3-3
Severity: important
Tags: upstream

Dear Maintainer,


A couple of security-related fixes have been released upstream as
version 0.2.7386-beta20.3-p10. See
https://lib.openmpt.org/libopenmpt/md_announce-2017-07-07.html .

p10 fixes a heap buffer overflow which allows an attacker to write
arbitrary data to an arbitrarily choosen offset. It can be triggered
with a maliciously modified PSM file. This needs to be fixed ASAP via
a security update in Stretch. The bug happens due to 2 samples in a
PSM file using the same sample slot in libopenmpt, whereby the second
sample uses an invalid offset inside the file. That way, the second
sample did not re-allocate (via
sampleHeader.GetSampleFormat().ReadSample(Samples[smp], file); deeper
down the call chain in SampleIO.cpp:73) the sample buffer itself but
only set the sample size metadata
(sampleHeader.ConvertToMPT(Samples[smp]);, ultimately at
Load_psm.cpp:1054). Later, as a loading post-processing step,
Sndfile.cpp:411 calls PrecomputeLoops() which writes a couple of
samples before and after the actual sample data (the amount is
statically known (InterpolationMaxLookahead) and accounted for when
allocating the sample buffer). However, due to the sample buffer and
sample length mismatch caused by the bug, this can write extrapolated
sample data to an arbitary location offset from the first sample's
buffer (PrecomputeLoopsImpl<T>() in modsmp_ctrl.cpp:263).

p8 is an out-of-bounds read directly after a heap-allocated allocated
buffer. It is difficult to trigger in practice because std::vector
does grow its buffer exponentially.

p9 fixes another potential race condition due to the use of non
thread-safe <time.h> functions. As discussed previously in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864195#67 , this
again can at worst cause wrong data to be returned for date metadata
in libopenmpt. However, please note that the same, now rewritten code
path, could also trigger an assertion failure in glibc under memory
pressure (which probably is a glibc bug, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867283 ), thereby
causing the application to crash.


-- System Information:
Debian Release: 9.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Jörn Heusipp
2017-07-07 14:51:35 UTC
Reply
Permalink
Raw Message
tags -1 + security
James Cowgill
2017-07-14 16:16:52 UTC
Reply
Permalink
Raw Message
Control: severity -1 grave
Control: tags -1 fixed-upstream

Hi,
Post by Jörn Heusipp
Source: libopenmpt
Version: 0.2.7386~beta20.3-3
Severity: important
Tags: upstream
Dear Maintainer,
A couple of security-related fixes have been released upstream as
version 0.2.7386-beta20.3-p10. See
https://lib.openmpt.org/libopenmpt/md_announce-2017-07-07.html .
p10 fixes a heap buffer overflow which allows an attacker to write
arbitrary data to an arbitrarily choosen offset. It can be triggered
with a maliciously modified PSM file. This needs to be fixed ASAP via
a security update in Stretch. The bug happens due to 2 samples in a
PSM file using the same sample slot in libopenmpt, whereby the second
sample uses an invalid offset inside the file. That way, the second
sample did not re-allocate (via
sampleHeader.GetSampleFormat().ReadSample(Samples[smp], file); deeper
down the call chain in SampleIO.cpp:73) the sample buffer itself but
only set the sample size metadata
(sampleHeader.ConvertToMPT(Samples[smp]);, ultimately at
Load_psm.cpp:1054). Later, as a loading post-processing step,
Sndfile.cpp:411 calls PrecomputeLoops() which writes a couple of
samples before and after the actual sample data (the amount is
statically known (InterpolationMaxLookahead) and accounted for when
allocating the sample buffer). However, due to the sample buffer and
sample length mismatch caused by the bug, this can write extrapolated
sample data to an arbitary location offset from the first sample's
buffer (PrecomputeLoopsImpl<T>() in modsmp_ctrl.cpp:263).
Firstly, sorry it's taken some time for me to get around to this. Since
this bug had the potential for remote code execution and looked pretty
serious, I requested a CVE number for it and it has been assigned
CVE-2017-11311.
Post by Jörn Heusipp
p8 is an out-of-bounds read directly after a heap-allocated allocated
buffer. It is difficult to trigger in practice because std::vector
does grow its buffer exponentially.
OK this should be fixed as well.
Post by Jörn Heusipp
p9 fixes another potential race condition due to the use of non
thread-safe <time.h> functions. As discussed previously in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864195#67 , this
again can at worst cause wrong data to be returned for date metadata
in libopenmpt. However, please note that the same, now rewritten code
path, could also trigger an assertion failure in glibc under memory
pressure (which probably is a glibc bug, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867283 ), thereby
causing the application to crash.
Again, I'm not sure if it is worth fixing this in stretch - it modifies
quite a bit of code. The glibc bug is important, but I'm not sure it
should be worked around in libopenmpt. It's also mitigated by the fact
that on Linux, if you're suffering from memory pressure, something is
probably about to be killed by the OOM killer anyway.

Thanks,
James
Debian Bug Tracking System
2017-07-14 16:21:04 UTC
Reply
Permalink
Raw Message
Post by James Cowgill
severity -1 grave
Bug #867579 [src:libopenmpt] libopenmpt: CVE-2017-11311
Severity set to 'grave' from 'important'
Post by James Cowgill
tags -1 fixed-upstream
Bug #867579 [src:libopenmpt] libopenmpt: CVE-2017-11311
Added tag(s) fixed-upstream.
--
867579: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867579
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
Debian Bug Tracking System
2017-07-14 16:54:04 UTC
Reply
Permalink
Raw Message
Your message dated Fri, 14 Jul 2017 16:52:14 +0000
with message-id <E1dW3p8-000FR1-***@fasolo.debian.org>
and subject line Bug#867579: fixed in libopenmpt 0.2.8461~beta26-1
has caused the Debian Bug report #867579,
regarding libopenmpt: CVE-2017-11311
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)
--
867579: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867579
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
Debian Bug Tracking System
2017-07-16 12:21:31 UTC
Reply
Permalink
Raw Message
Your message dated Sun, 16 Jul 2017 12:17:08 +0000
with message-id <E1dWiU0-000Gca-***@fasolo.debian.org>
and subject line Bug#867579: fixed in libopenmpt 0.2.7386~beta20.3-3+deb9u2
has caused the Debian Bug report #867579,
regarding libopenmpt: CVE-2017-11311
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)
--
867579: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867579
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
Loading...