Bug#864195: libopenmpt: Security updates libopenmpt-0.2.7386-beta20.3-p7 available

James Cowgill jcowgill at debian.org
Wed Jun 7 09:45:50 UTC 2017


Control: tags -1 security

Hi,

On 05/06/17 07:03, Jörn Heusipp wrote:
> 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-p7. See 
> https://lib.openmpt.org/libopenmpt/md_announce-2017-06-02.html
>
> These most importantly fix a couple of possible crashes which can be 
> triggered by maliciously modified or malformed or truncated module 
> files as well as denial-of-service through hangs or excessive CPU 
> consumption which can also be triggered maliciously modfied or 
> malformed or truncated module files.

I've had a look at the patches now and this is what I think:

p1-division-by-zero-in-tempo-calculation.patch
p2-infinite-loop-in-plugin-routing.patch
p6-invalid-memory-read-when-applying-nnas-to-effect-plugins.patch

These three are clearly denial-of-service by malicious module file and
should be fixed in stretch. However, I don't think the first two are
"serious" because they're just denial-of-service bugs in a library
almost exclusively used on end user machines (as opposed to eg remote
code execution). I don't understand patch p6 well enough to say how
serious it is (depends on where the invalid pointer being dereferenced
comes from).

p3-excessive-cpu-consumption-on-malformed-files-dmf-mdl.patch
p5-excessive-cpu-consumption-on-malformed-files-ams.patch

Are these actually security bugs? As long as the code finishes in a
reasonable amount of time and produces the right results, then there's
not much harm in leaving the code as it is.

p4-theoretical-null-pointer-dereference-during-out-of-memory-while-error-handling.patch

I don't think this is a security bug. It requires malloc to fail, and
the chances of that happening on Linux are very small. If that does
occur, you're likely to be killed by the OOM killer anyway.

I also note that the C++ standard _requires_ std::exception::what to
return a non-null value so a very intelligent compiler could
legitimately remove the null check (I doubt GCC does this though).

p7-race-condition-in-multi-threaded-use-it.patch

I also don't think this is a security bug (at least on Linux). Looking
at the glibc sources, the internal tzdata state is protected by a mutex
so the only risk here is that localtime will return some garbage time
values. Since the string generated by this function is only going to be
shown to the user, nothing that bad will happen in this case. Finally,
it relies on a multithreaded client application loading 2 modules at the
same time which seems unlikely to me.

Thanks,
James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20170607/be7c0fdf/attachment.sig>


More information about the pkg-multimedia-maintainers mailing list