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
_______________________________________________
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
