
Fuzzing with american fuzzy lop - bootload
http://lwn.net/Articles/657959/
======
stevekemp
Using the writeup I managed to find a crashing SSH-key which would give `ssh-
keygen -l -f $file` a segfault.

Great writeup, and a great tool.

Bug reported to Debian, where it languishes:

[https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=801530](https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=801530)

Reported upstream, and seem to be fixed somewhere between OpenSSH 6.6 and 6.8:

[http://lists.mindrot.org/pipermail/openssh-unix-
dev/2015-Oct...](http://lists.mindrot.org/pipermail/openssh-unix-
dev/2015-October/034455.html)

Brief background on the reason for searching:

[http://blog.steve.org.uk/so_about_that_idea_of_using_ssh_key...](http://blog.steve.org.uk/so_about_that_idea_of_using_ssh_keygen_on_untrusted_input_.html)

------
bhaak
I found this ctype function bug^Wundefined behavior for glibc with afl-buzz:

[https://sourceware.org/bugzilla/show_bug.cgi?id=17674](https://sourceware.org/bugzilla/show_bug.cgi?id=17674)

I was expecting that it would get closed as "undefined behavior" although the
"This is perfectly valid undefined behaviour" line made my day.

I just wanted to have this bug documented for other people or in case this
behavior would ever be part of a security related issue.

~~~
to3m
Bogus results is one thing; segmentation faults are another matter entirely!
This is especially true for a ctype-type function. "isblank"? I can't even
imagine what it would be doing internally for it to be possible to make it
crash.

[this post was previously just as above, but in a more allusive form, so
apologies if you saw that instead]

~~~
to3m
The comment here suggests why:
[http://osxr.org/glibc/source/ctype/ctype.h](http://osxr.org/glibc/source/ctype/ctype.h)

I'd considered a table-driven approach - I mean, perhaps it's a bit daft for
isblank, but OK for some of the more random categories - but assumed they'd
index on c&0xFF or something, rather than just using the int input verbatim!

It's not immediately obvious to me why that wasn't done (maybe glibc has to
support one's complement?), since none of the high-bit ASCII chars appear to
have a defined value. Then you can decide EOF is -1 - no reason not to - and
it would capture that as well. (The functions don't appear to have a defined
output for EOF, even though it's a defined input, so it could just shared the
same output as (signed char)-1, and that would be OK. At least it's not a
crash.)

------
to3m
Here's a CppCon 2015 presentation that I enjoyed, for whatever that's worth,
giving an introductory overview of this sort of technology, with some
examples. AFL is mentioned: Kostya Serebryany - Beyond Sanitizers -
[https://www.youtube.com/watch?v=qTkYDA0En6U](https://www.youtube.com/watch?v=qTkYDA0En6U)

------
Robadob
List of bugs identified using AFL is available on their webpage[1], seem to
have it bookmarked from the last time AFL would have been mentioned here.
Always find fuzzing to be a pretty interesting (and impressive) technique.

[1]
[http://lcamtuf.coredump.cx/afl/#bugs](http://lcamtuf.coredump.cx/afl/#bugs)

------
pnathan
I always think of this when I see that name: [http://rabbitbreeders.us/wp-
content/uploads/american-fuzzy-l...](http://rabbitbreeders.us/wp-
content/uploads/american-fuzzy-lop-rabbit-breed.jpg)

------
loginusername
Has anyone ever fuzzed fuzzy lop itself using fuzzy lop?

~~~
hannob
Yes. Didn't find anything.

(Strictly speaking you can't fuzz it itself, because you need something that
takes a file input as an input. But there are tools sipped with it, e.g. one
that parses the fuzzer's output stats, that you can fuzz.)

~~~
loginusername
If I could, I would upvote this.

