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

[James Cowgill]

Hi,

On 08/06/17 13:23, Johannes Schultz wrote:
>>> I don't understand patch p6 well enough to say how
>>> serious it is (depends on where the invalid pointer being dereferenced
>>> comes from).
>>
>> As far as I know, it is just a NULL pointer. Johannes did the analysis
>> and might be able to elaborate (CCed).
> 
> Correct. I am not sure if it is possible at all to trigger that field to
> be NULL in libopenmpt but it is possible in OpenMPT in some live editing
> situations. I cannot be 100% sure if libopenmpt would ever be able to
> trigger this crash but it should be obvious that adding a null-pointer
> check should do no harm to the library.

OK. In that case all these fixes will almost certainly be deferred until
the first point release of stretch. The release team only wants
emergency fixes in the last week up to the release.

>>> 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.
>>
>> Again, Johannes knows more about these.
> 
> I guess it depends on what you define as "reasonable". Depending on the
> malformed file and setup, they may take minutes to load (given that
> enough (virtual) memory is available to load all the truncated samples).
> The test cases that were generated by American Fuzzy Lop were about 5KB
> in size and took about 10 seconds to load on my machine, which I would
> say is quite excessive for such a tiny file, but those examples can be
> modified (by adding more malformed sample slots) to extend the loading
> time from seconds to minutes while still being about 5KB.
> 
> To give some perspective, I don't just use libopenmpt on Desktop systems
> but also to scan module data in a server application where users can
> upload their own modules, and if a user could keep a server request busy
> for a minute (while also wasting tons of memory and CPU time), that
> server could be DOSed very easily. Thus I'd strongly suggest to include
> those two patches.

I see, that is quite a long time to wait! Do you have these testcases so
I can try them? My only concern is that p3 is pretty big so it has the
potential of causing a regression. p5 looks fine.

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/20170608/f634bbe0/attachment.sig>