LWN: Comments on "EU to fund Free Software code review (FSFE)"

EU to fund Free Software code review (FSFE)

mathstuf — Thu, 25 Dec 2014 07:18:45 +0000

Well, the problem with the text formats I'm working with are that they have a count of fields followed by that many fields. It has found crashes, but most are just variations on a theme (not validating that a line-based format actually reads all of a line, typical iostream parsing issues, a bunch of 'fin >> stdstr; strncmp(stdstr.c_str(), "foo", strlen("foo"));' patterns causing havoc when a space is changed, etc.). I think something which knew that field A is a count of the number of field B's would get much more interesting results quicker by exploiting off-by-one errors, switching newline formats, and other assumptions parsers likely make (and our parsers are very trusting :/ ). Not that the found issues are worthless, but the blind changes aren't all that effective with such structured files.

EU to fund Free Software code review (FSFE)

pabs — Thu, 25 Dec 2014 02:06:19 +0000

I don't have any experience with afl and text formats but it seems to be able to handle them fine according to the author's blog:

http://lcamtuf.blogspot.com/2014/11/afl-fuzz-nobody-expec...
http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-final...

EU to fund Free Software code review (FSFE)

mathstuf — Mon, 22 Dec 2014 16:13:32 +0000

The problem with afl is that it doesn't support multifile inputs at all and sucks (compared to its binary format efficacy) with text formats. For smaller, binary formats, sure.

EU to fund Free Software code review (FSFE)

pabs — Sun, 21 Dec 2014 01:40:24 +0000

That sounds like an interesting approach but ultimately I think that American fuzzy lop (afl) is a better approach for a fuzzer as it directly manipulates code paths based on code instrumentation. Sulley might be a good tool for proprietary code though.

FYI, this appears to be the canonical sulley repo:

https://github.com/OpenRCE/sulley

EU to fund Free Software code review (FSFE)

mathstuf — Sat, 20 Dec 2014 05:48:33 +0000

Another fuzzer is sully[1] where you can describe your data format and it will intelligently manipulate the data accordingly (or at least that is the idea; haven't used it myself yet).

[1]https://github.com/levigross/Sully

EU to fund Free Software code review (FSFE)

pabs — Sat, 20 Dec 2014 00:44:23 +0000

As a formal group, the Debian code audit project is no longer operating. Individual Debian members who are interested in security (including the main person from the code audit project, Steve Kemp) often do security auditing and find issues, for example:

http://blog.steve.org.uk/tags/security/
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=afl&...

If you want to help improve Debian's security the biggest thing you could do is convince LF/RH/etc to fund work on the inclusion of grsec/PaX into Linux mainline.

Aside from that there are a lot of different things that you can do to help improve Debian's security:

https://wiki.debian.org/Hardening/Goals

Personally I'm working on check-all-the-things, a tool that makes it easy to find out about all the various static analysis tools (and other checkers) and run them automatically on an unpacked source tree or a post-build tree. My objective here is to change the culture of Debian so that all new packagers at minimum do shallow audits based on greps for problematic language/toolkit/library constructs, run some static analysis tools and are aware of fuzzers like afl and zzuf. A related tool for focusing audits is ubuntu-security-tools.

https://anonscm.debian.org/cgit/collab-maint/check-all-th...
https://code.launchpad.net/~ubuntu-security/ubuntu-securi...

EU to fund Free Software code review (FSFE)

justcs — Fri, 19 Dec 2014 23:35:45 +0000

Does anyone know the status of the Debian code audit? Is it still active?