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

[Johannes Schultz]

Am 12.06.2017 um 18:17 schrieb James Cowgill:
> On 08/06/17 23:10, Johannes Schultz wrote:
>> Hi,
>>
>>>> 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.
>>
>> I have attached some manually-crafted worst-case files to demonstrate
>> the issue. For maximum effect, a 64-bit build has to be used, because
>> otherwise memory allocation will fail fairly quickly and the malformed
>> sample data won't even be attempted to be decoded.
>>
>> p3 is smaller than it looks since some of it is just moving around
>> things and as a consequence re-indenting them. The actual decoding logic
>> is not modified. A diff without whitespaces should show this.
> 
> Thanks.
> 
> Do any of these issues have CVE numbers?

Not that I'm aware of. We didn't request any.

Cheers,
Johannes