Date: Sun, 16 Nov 2014 18:15:57 +0100 From: Robert Święcki <robert@...ecki.net> To: oss-security@...ts.openwall.com Subject: Re: Fuzzing findings (and maybe CVE requests) - Image/GraphicsMagick, elfutils, GIMP, gdk-pixbuf, file, ndisasm, less 2014-11-16 15:10 GMT+01:00 Hanno Böck <hanno@...eck.de>: > Hi, > > I wanted to share a couple of issues I recently found via zzuf and afl > fuzzing. It's a telling story about the state of some of the free > software projects involved and I can only encourage others to join the > effort to find bugs via fuzzing. Some of them are really low hanging > fruit. > I'm cc-ing cve-assigners, I leave it up to you to decide which you > assign CVEs. If you want / need more info on details please ask. > > > Imagemagick: > Multiple issues in PCX, DCM parser and generic issue in resize code > http://www.imagemagick.org/script/changelog.php > These already got CVEs: > http://int21.de/cve/CVE-2014-8354-ImageMagick-oob-heap-overflow.html > http://int21.de/cve/CVE-2014-8355-ImageMagick-pcx-oob-heap-overflow.html > http://int21.de/cve/CVE-2014-8562-ImageMagick-dcm-oob-heap-overflow.html > > GraphicsMagick: > Fork of Imagemagick, so some of the above also affect it, tests with > the same fuzzed sample set turned out one independent other issue: > http://sourceforge.net/p/graphicsmagick/code/ci/37ab9576dbdfeecd8bbc0a312a49b362846016c1/ > Heap Overflow / oob read > One more issue with PNGs that turned out to be weird, it caused an > error message to overflow: > http://sourceforge.net/p/graphicsmagick/code/ci/0dc6e1d3119f1dda668b0f2d1464459a06767879/ > > elfutils: > Checks done with the set of files that crashed binutils turned out one > issue: > https://lists.fedorahosted.org/pipermail/elfutils-devel/2014-October/004215.html > Invalid read > american fuzzy lop found a couple more: > https://lists.fedorahosted.org/pipermail/elfutils-devel/2014-November/004230.html > and more: > https://lists.fedorahosted.org/pipermail/elfutils-devel/2014-November/004249.html > > GIMP: > Invalid reads in import plugins for fli and tga. > https://bugzilla.gnome.org/show_bug.cgi?id=739133 > https://bugzilla.gnome.org/show_bug.cgi?id=739134 > > claws-mail / gdk-pixbuf > Assert in gdk-pixbuf when trying to load a malformed file as an > animation. This was an accidental discovery when I clicked on a > malformed PNG I send while reporting another issue (in graphicsmagick) > in my mail client (and it crashed with an assert). > https://bugzilla.gnome.org/show_bug.cgi?id=739785 > http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3322 > > file/libmagic: > out of bounds read when parsing JPG header > http://bugs.gw.com/view.php?id=398 > https://github.com/file/file/commit/59e63838913eee47f5c120a6c53d4565af638158 > > ndisasm: > Actually I found this by running ndisasm on /dev/urandom - no joke! > Crash / oob read: > http://bugzilla.nasm.us/show_bug.cgi?id=3392289 > > less: > Out of bounds read, upstream doesn't answer and doesn't have a public > bug tracker. This wasn't really found by fuzzing but by running less on > a likely malwared gif, I reduced it to a smaller testcase: > http://int21.de/cve/less-oob Really nice job! Just to reiterate what others in previous "fuzzing" threads had already said. A given bugs is a security where given set of code is by design (and after a solid security review process) supposed to be exposed to untrusted inputs. I can easily see that certain libs you're fuzzing (imagemagick et al) are widely used to parse untrusted inputs (image conversion pipelines and such esp. in the web software) and by discovering bugs in them you're doing a great job preventing some web servers and a couple of users from being pwnd. However, even if tools like file/ndisasm/gimp/readelf can be used by many (w/o strong system isolation boundaries) to analyze untrusted inputs (for reverse engineering, malware analysis and similar purposes) - I'd simply put a blame on those users when if they get pwnd - as they're depending on tools, which hadn't been properly evaluated for the purpose (by efforts of those users, or by their contractors or by the community at large) and the likelihood that we'll start accepting those tools as good enough for said purposes in the coming years is seriously low. There are thousands of software packages available under a typical Linux distro. And a serious share of it will fail when dealing with untrusted inputs. So, maybe instead of fuzzing everything what is available from the command-line - we should rather draw a line between software which is designed and tested for the said purpose (web browsers, kernel networking stacks, network services) and software which is not. The alternative is that we'll spend a lot of time in the next year(s) discussing seemingly non-security bugs on security lists. To sum up: If somebody uses 'file' in an unconstrained OS environment on untrusted inputs, and he gets pwnd in the result, then it's not a security problem, it's an incompetence problem - and IMO it should be discussed elsewhere. I appreciate your enthusiasm to fuzz every OSS project out there - I just wanted to ask you (and others who might join this effort) to apply a well-thought-out set of criteria when categorizing your findings (security bug, usability bugs). And good luck with your fuzzing! -- Robert Święcki
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.