4 ms·

American fuzzy lop

92 points by jcr 12y ago

vishaldpatel 12y ago
So, what's a "fuzzer"? =/
- jcr 12y ago
  https://en.wikipedia.org/wiki/Fuzz_testing https://en.wikipedia.org/wiki/Fuzz_testing
- charleslmunger 12y ago
  A fuzzer is a tool that generates malformed input to try and trigger crashes in parsers, usually with the hope of finding a bug that can be turned into a security exploit.
  - zurn 12y ago
    Parsing bugs is one category of tickled bugs, another is correctly encoded values that confuse the deeper logic layers. Eg heartbleed was the latter.
yzzxy 12y ago
Enjoying the recent spatter of articles on fuzzing, it's an interesting topic to read about and file for future use. This page brings me back to a question that I've been having a lot recently: how does one get really good at *nix in this day and age? It seems like the era of learning on a college mainframe computer is over, and "sysadmining" for hobby and SaaS nowadays projects often totally abstracts the nitty-gritty bits of the OS. Yet these systems still power our computers and servers, and there appears to be a real utility in understanding them well. I run Debian as my daily driver, with a fairly "hardcore" setup without a fancy GUI, but I still feel like I haven't even scratched the surface of my OS. I don't really understand how library linking or process messaging or anything like that works, and I'm not sure how to start learning.
- 13 12y ago
  I picked up a random piece of hardware I knew probably ran linux under the hood, and found that hacking it really threw me in the deep end. Working with stuff that's not documented, has probably never been tried and looks utterly impossible is a heap of fun and for me at least a good teaching tool. Pick an arbitrary goal and learn how to get there.
- emilburzo 12y ago
  The best way, for me, was fixing something that didn't work. The "problem" now is, *nix has gotten pretty good/stable/justworks(tm). So the other, more time consuming way, is probably contributing to different areas. That should force you understand all the different systems better.
- f- 12y ago
  Honestly, I don't think it's been easier in the days of university mainframes. Today, it takes minutes to download, run, and brick new OSes in a VM; you have terabytes of free and easily searchable documentation and code samples at your fingertips; hardware is cheaper than ever; etc. It's pretty great. My best advice would be, don't overthink it. Take one random thing apart, see how it works, and see if you can break it. Try digging into the inner workings of memory virtualization, or write a "hello world" bootsector in assembly, or figure out how syscalls happen and write your own that does something silly, or design a simple program that injects something into an ELF binary without using any higher-level tools. Or, perhaps, just browse random 2- an 3-section manpages and experiment with what you find.
  - xorcist 12y ago
    Couldn't agree more. Take one random thing apart. It won't feel like learning, but that's what it's like. You will not wake one morning and be done, because there's always one more thing to learn.. and that's good!
- rtpg 12y ago
  An OS + Compiler course can go a long way to understanding the grand strokes on those. When it actually starts mattering, it's so dependent on what system you're working with that it's hard to provide an "abstract" understanding that will cover everything. I, for one, am glad that I don't really _have_ to know all of this. If it does become critical to a component I'm writing, I'm glad to know this stuff, but like a sibling comment said, everything just works. Shoulders of giants and all that, but at the end of the day, what's important is being able to build functional systems, and that's gotten easier.
petercooper 12y ago
ICYMI, there was an article that was popular on here a week or two ago about using afl to 'generate' JPEGs out of thin air: http://lcamtuf.blogspot.co.uk/2014/11/pulling-jpegs-out-of-thin-air.html http://lcamtuf.blogspot.co.uk/2014/11/pulling-jpegs-out-of-t...
- Luc 12y ago
  ICYMI: In Case You Missed It.
chris_wot 12y ago
Awesome! However... could you change the instruction to "login as root" to also suggest: echo core | sudo tee /proc/sys/kernel/core_pattern
anon4 12y ago
A word of warning: the links on the demo page http://lcamtuf.coredump.cx/afl/demo/ http://lcamtuf.coredump.cx/afl/demo/ lead to pages with images that can make your browser use up all your memory and your system will be unresponsive until the OOM killer kicks in. I admit that it's my fault for not reading the warning on the very page I'm linking, but I imagine there are others like me, so here. WARNING: some of the demo pages will crash your browser.
unsigner 12y ago
Is there a good fuzzer for Windows command-line executables? I looked around a day or two ago and everything "advanced" was Linux-only.
unbelievr 12y ago
I have wanted to apply some amount of fuzzing for embedded development, but have not yet stumbled over any tools or strategies for this. Is there anyone who have some experience with this? More specifically, I want to test against a stack with an API written in C, but the problem is that it is only accessible through code. Code that needs to be flashed to physical hardware before running. A crash in the stack leads to some trigger that can give output, so it's easy to identify a crash. For now, I have made a serialization layer for the API functions, but feel like any fuzzing methodologies would mainly test the serialization instead of the underlying stack. Is there any tools out there that can do this, or what AFL-fuzz does but on ARM Cortex M running with a debugger?
jcr 12y ago
I probably shouldn't ruin the fun, but for those that missed the joke, the name "American Fuzzy Lop" is actually a breed of extremely fuzzy rabbits. http://en.wikipedia.org/wiki/American_Fuzzy_Lop http://en.wikipedia.org/wiki/American_Fuzzy_Lop
krakensden 12y ago
From the Makefile: ifneq "$(shell echo $$HOSTNAME)" "raccoon" CFLAGS += -Wno-format endif
com2kid 12y ago
I'd kill for good fuzzing tools that ran on embedded systems that lack a real OS. The embedded world really needs some better tooling.

American fuzzy lop

92 points by jcr 12y ago

vishaldpatel 12y ago

So, what's a "fuzzer"? =/

jcr 12y ago
https://en.wikipedia.org/wiki/Fuzz_testing https://en.wikipedia.org/wiki/Fuzz_testing
charleslmunger 12y ago
A fuzzer is a tool that generates malformed input to try and trigger crashes in parsers, usually with the hope of finding a bug that can be turned into a security exploit.
- zurn 12y ago
  Parsing bugs is one category of tickled bugs, another is correctly encoded values that confuse the deeper logic layers. Eg heartbleed was the latter.

yzzxy 12y ago

Enjoying the recent spatter of articles on fuzzing, it's an interesting topic to read about and file for future use. This page brings me back to a question that I've been having a lot recently: how does one get really good at *nix in this day and age? It seems like the era of learning on a college mainframe computer is over, and "sysadmining" for hobby and SaaS nowadays projects often totally abstracts the nitty-gritty bits of the OS. Yet these systems still power our computers and servers, and there appears to be a real utility in understanding them well. I run Debian as my daily driver, with a fairly "hardcore" setup without a fancy GUI, but I still feel like I haven't even scratched the surface of my OS. I don't really understand how library linking or process messaging or anything like that works, and I'm not sure how to start learning.

13 12y ago
I picked up a random piece of hardware I knew probably ran linux under the hood, and found that hacking it really threw me in the deep end. Working with stuff that's not documented, has probably never been tried and looks utterly impossible is a heap of fun and for me at least a good teaching tool. Pick an arbitrary goal and learn how to get there.
emilburzo 12y ago
The best way, for me, was fixing something that didn't work. The "problem" now is, *nix has gotten pretty good/stable/justworks(tm). So the other, more time consuming way, is probably contributing to different areas. That should force you understand all the different systems better.
f- 12y ago
Honestly, I don't think it's been easier in the days of university mainframes. Today, it takes minutes to download, run, and brick new OSes in a VM; you have terabytes of free and easily searchable documentation and code samples at your fingertips; hardware is cheaper than ever; etc. It's pretty great. My best advice would be, don't overthink it. Take one random thing apart, see how it works, and see if you can break it. Try digging into the inner workings of memory virtualization, or write a "hello world" bootsector in assembly, or figure out how syscalls happen and write your own that does something silly, or design a simple program that injects something into an ELF binary without using any higher-level tools. Or, perhaps, just browse random 2- an 3-section manpages and experiment with what you find.
- xorcist 12y ago
  Couldn't agree more. Take one random thing apart. It won't feel like learning, but that's what it's like. You will not wake one morning and be done, because there's always one more thing to learn.. and that's good!
rtpg 12y ago
An OS + Compiler course can go a long way to understanding the grand strokes on those. When it actually starts mattering, it's so dependent on what system you're working with that it's hard to provide an "abstract" understanding that will cover everything. I, for one, am glad that I don't really _have_ to know all of this. If it does become critical to a component I'm writing, I'm glad to know this stuff, but like a sibling comment said, everything just works. Shoulders of giants and all that, but at the end of the day, what's important is being able to build functional systems, and that's gotten easier.

petercooper 12y ago

ICYMI, there was an article that was popular on here a week or two ago about using afl to 'generate' JPEGs out of thin air: http://lcamtuf.blogspot.co.uk/2014/11/pulling-jpegs-out-of-thin-air.html http://lcamtuf.blogspot.co.uk/2014/11/pulling-jpegs-out-of-t...

Luc 12y ago
ICYMI: In Case You Missed It.

chris_wot 12y ago

Awesome! However... could you change the instruction to "login as root" to also suggest: echo core | sudo tee /proc/sys/kernel/core_pattern

anon4 12y ago

A word of warning: the links on the demo page http://lcamtuf.coredump.cx/afl/demo/ http://lcamtuf.coredump.cx/afl/demo/ lead to pages with images that can make your browser use up all your memory and your system will be unresponsive until the OOM killer kicks in. I admit that it's my fault for not reading the warning on the very page I'm linking, but I imagine there are others like me, so here. WARNING: some of the demo pages will crash your browser.

unsigner 12y ago

Is there a good fuzzer for Windows command-line executables? I looked around a day or two ago and everything "advanced" was Linux-only.

unbelievr 12y ago

I have wanted to apply some amount of fuzzing for embedded development, but have not yet stumbled over any tools or strategies for this. Is there anyone who have some experience with this? More specifically, I want to test against a stack with an API written in C, but the problem is that it is only accessible through code. Code that needs to be flashed to physical hardware before running. A crash in the stack leads to some trigger that can give output, so it's easy to identify a crash. For now, I have made a serialization layer for the API functions, but feel like any fuzzing methodologies would mainly test the serialization instead of the underlying stack. Is there any tools out there that can do this, or what AFL-fuzz does but on ARM Cortex M running with a debugger?

jcr 12y ago

I probably shouldn't ruin the fun, but for those that missed the joke, the name "American Fuzzy Lop" is actually a breed of extremely fuzzy rabbits. http://en.wikipedia.org/wiki/American_Fuzzy_Lop http://en.wikipedia.org/wiki/American_Fuzzy_Lop

krakensden 12y ago

From the Makefile: ifneq "$(shell echo $$HOSTNAME)" "raccoon" CFLAGS += -Wno-format endif

com2kid 12y ago

I'd kill for good fuzzing tools that ran on embedded systems that lack a real OS. The embedded world really needs some better tooling.