Date: Wed, 26 Oct 2016 10:46:40 +0100 From: Simon McVittie <smcv@...ian.org> To: oss-security@...ts.openwall.com Subject: Re: Re: jasper: memory allocation failure in jas_malloc (jas_malloc.c) On Wed, 26 Oct 2016 at 10:08:56 +0200, Agostino Sarubbo wrote: > more or less I agree with you, but since time ago I saw that similar bugs > reveiced a CVE, I thought that these type of bugs could interest the community > and them I'm sharing them. > If I'm not mistaken, CWE-789 covers these type of bugs. It depends on the purpose of your software, and how it runs (for example a one-shot command-line tool vs. a long-running daemon). If a command-line tool for converting JPEG2000 to JPEG (or whatever) exits unexpectedly due to a failed attempt to allocate multiple gigabytes of memory, that isn't really any worse than exiting unsuccessfully because an arbitrary limit on image size was exceeded: the user isn't getting their desired JPEG either way. Conversely, if a daemon that accepts uploaded JPEG2000 images and converts them to JPEG exits unexpectedly due to a failed attempt to allocate multiple gigabytes of memory, then that's denying service to the service's other users as well, which is an instance CWE-789. For a general-purpose library like jasper, which could be used in either of those contexts, I suspect the best you can do is to make sure conversion gracefully fails with an appropriate error report (error code or exception or whatever you use) if memory can't be allocated or if a library-user-specified limit is exceeded - then the library user can handle that however they want to, for example by exiting (appropriate for a command-line tool) or by reporting an error but continuing to accept new requests (appropriate for a daemon). Denial-of-service is basically a failure of the "availability" security property: the actions of a malicious user make the service unavailable to its non-malicious users. However, imposing arbitrary limits can also be argued to be a failure of availability: if you put a limit of, say, 100M on the uncompressed size of images you are willing to work with, then that's denying service to non-malicious users whose images happen to need 102M. Choosing where to draw the line is a trade-off rather than an absolute, and library code rarely has enough information or configurability to make an informed decision about the right place for that trade-off. (I recognise the hypocrisy in saying this as a maintainer of D-Bus, whose messages have a completely arbitrary size limit chosen to make it obvious that 32-bit arithmetic on message sizes never overflows :-) S
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ