Lone Star Ruby Conf Speaker Interview: Nephi Johnson

Okay, time for a second interview with a Lone Star Ruby Conference speaker.  This time, Nephi Johnson (@d0c_s4vage) talks a bit about his presentation — "Less-Dumb Fuzzing and Ruby Metaprogramming".

---

Fuzzing isn't always well understood.  Can you describe fuzzing, and tell us what situations it's a good fit for?

Nephi Fuzzing is a term used to describe the process of feeding an application unexpected inputs in order to find flaws in the code.  During development, it's pretty much impossible to write code that will handle all possible inputs correctly.  Fuzzing helps to uncover some of the more subtle and unforeseeable flaws that haven't been found through code reviews and normal testing.  Fuzzing is typically very automated and usually involves feeding a program thousands or millions of sets of malformed input.  The program being fuzzed is then monitored for crashes, exceptions, and/or performance.

The last person to really talk about fuzzing in the Ruby Space was Zed Shaw.  That's kind of a tough act to follow.  Why is this an important topic for Rubyists, and why are you the right person to talk about it?

Nephi I think fuzzing is an important topic for every developer (or anyone who wants to find bugs in an application).  If you have the time to fuzz a product, you will almost certainly uncover flaws in it.  One bug fixed during development is one less bug that customers have to experience with a release product.  Not finding flaws in the code after extensive fuzzing is also a big confidence booster.  I think this is especially applicable to Rubyists because of the flexibility (and fun) that comes with using Ruby.  I think anyone could make their own fuzzer/data-generator with Ruby in a short amount of time.  Also, if someone wanted to use the library I've written, it just so happens that I've written it in Ruby [*sarcasm*].

Why am I the right person to talk about fuzzing?  Fuzzing is something that I spend most of my free time doing or working on.  I put a lot of thought into coming up with ways to more efficiently fuzz programs.  As a security researcher, I have different goals in fuzzing than developers.  I want to find the really interesting bugs, bugs that might allow one to run their own code or do something entirely unexpected with the program.  I think my perspective on fuzzing might provide different insights for those who use fuzzing outside of the security field.

What prompted you to speak at LSRC this year?

Nephi Someone had mentioned to me that it might be interesting to hear from somebody in the security field and suggested I submit a talk.  I liked the idea, chose to talk about a project I've been working on using Ruby, and here I am.

Other than your own talk, what are you most looking forward to?

Nephi I'm looking most forward to the talks "Vim for the modern Rubyist", "What every Ruby programmer should know about threads", and "Getting Started With C++ Extensions."  Why these talks?  I love using vim - it was the first text editor I used when I started using Linux and now it's all I use, threads give me trouble sometimes (ruby threads, that is), and I've been wanting to write my own ruby extensions for a while now.