
Project Triforce: Run AFL on Everything - mytummyhertz
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2016/june/project-triforce-run-afl-on-everything/
======
dantillberg
What's AFL? "american fuzzy lop" /
[http://lcamtuf.coredump.cx/afl/](http://lcamtuf.coredump.cx/afl/)

------
mickgardner
I really wanted this to be about Australian Rules Football...

------
CGamesPlay
I really want AFL to be able to run on arbitrary VMs (specifically, I want to
run AFL on my rails application).

Are there plans to add pluggable tracing modules to AFL?

~~~
mytummyhertz
checkout the details of the project, the idea is that you can run AFL on
arbitrary VMs (like your rails VM)! just need to have your test cases, your
userland harness, and the addresses to monitor for "panics"

~~~
CGamesPlay
AFL can fuzz ruby by running ruby on arbitrary inputs. This tests that paths
through the ruby interpreter are being stressed.

AFL cannot fuzz ruby _code_ using the same mechanism, because it does not have
the right level of insight. AFL can't detect if a branch in my ruby code was
tested, only that the code for `if` in the core ruby interpreter has been
tested both ways. For this reason, in order to properly test interpreted code,
you need to add the AFL instrumentation at the ruby layer, not the native
layer.

I don't think AFL currently supports this, and I don't think this project
actually enables it. But I would be happy to be corrected!

~~~
stevekemp
> AFL can fuzz ruby by running ruby on arbitrary inputs.

If you're brave (consider "system rm -rf /home") this is worth doing. I
recently ran such a fuzzing test against GNU Awk.

Unfortunately the bugs I reported are still unfixed, but it didn't take too
long to find them, and it was a good learning exercise:

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

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

I'm sure passing "random" input to Perl, Python, Ruby, and many other
languages will lead to similar results.

~~~
mytummyhertz
i've actually used AFL to find some input parsing bugs in Perl, Python, and
Ruby.

Perl was the team who fixed them the fastest.

none of the teams (rightly) considered these particularly high impact.

------
softblush
[https://web.archive.org/web/20160627201122/https://www.nccgr...](https://web.archive.org/web/20160627201122/https://www.nccgroup.trust/us/about-
us/newsroom-and-events/blog/2016/june/project-triforce-run-afl-on-everything/)

------
616c
So I am still reading through their Linux container security paper, and I like
their stuff, but who are these NCC people? In the last few months I have seen
multiple postings on their papers and blog posts, seemingly out of nowhere,
never having heard of them pry to the container paper.

~~~
dyn-
Glad to hear it. As mytummyhertz said, NCC Group (where we both work) is made
up in the US from iSEC Partners, Matasano Security and Intrepidus Group
consultancies (who were all purchased by NCC Group in the last few years). In
the UK it's primarily NGS. iSEC Partners/Matasano/Intrepidus Group/NGS have
published research/security presentations/tools (sslyze) etc for years.

~~~
616c
I am kind of new to the infosec scene. I was curious because your stuff seems
thorough, but the new TLD domain made me wonder where you all came from, like
rebranding or something else. Sounds like a little column A, little column B.

My favorite quick security tool on Linux is firejail, which uses seccomp-bpf
under the hood. So I was quite excited to see in your container paper
discussion of that and the interaction of Linux subsystems I do not really
grok.

Keep up the good work. Obviously not all for me, but I benefit. :-)

~~~
dyn-
Thanks, firejail is a nice little tool. Yeah the .trust TLD isn't a rebranding
or anything, just another NCC Group side-project.

