8 ms·

These books are probably great but if you look at some of the best/worst bugs found in the past few years, there's one tool that seems to come up over and over

by exDM69 12y ago

These books are probably great but if you look at some of the best/worst bugs found in the past few years, there's one tool that seems to come up over and over again: afl-fuzz. I recon that the easiest way to get started with bug hunting might be to just set up afl-fuzzing on some trivial code that has lots of potential for going wrong. Stuff like JSON/HTML/HTTP parsing in C is a great candidate to find integer overflow or buffer overrun bugs in (some of the bugs in this list are exactly that). Throw some CPU time for the fuzzing, and pretty soon you should have a handful of repro cases. The nice thing about these is that the bugs could be very trivial to fix but have enormous security consequences. If someone wants a suggestion for a project to try some fuzzing against, the new h2o/libh2o web server and its HTTP parser component (picohttpparser) look very well written but not very well tested (only a handful of hand written, hard coded test cases). I'm pretty sure there's one or more potentially disastrous bugs in it. edit: almost all bugs in this list seem to be integer overflow bugs. That hints that these issues were found using a static analysis tool like ClangAnalyzer or Coverity.

tptacek 12y ago
Reading some of the actual reports, these look like straight code findings (see for instance the numbered step-by-step explanations). They also aren't particularly complicated bugs.
dsacco 12y ago
Please don't start this way. Michal Zalewski didn't write afl fuzzer so it would be used without deep technical knowledge. It's actually not for beginners at all despite how powerful it is. As a general rule to start in security work, you will want to know how to program in at least one language competently, then move on to theoretical understanding of vulnerabilities, then finding them painstakingly by hand, and finally by automation. It's perfectly fine to use afl (or other similar tools), but understand that using an automated tool without first knowing how to do things by hand and groking the theory will stunt your growth and make it hard to progress very far. Pop open a weakened VM and exploit a few buffer overflow bugs the old fashioned way before you use a fuzzer. With code review, learn the nuances of each language before you automate your audit. You shouldn't have to rely on an automated tool to find out register globals is on in PHP (as one example).
- exDM69 12y ago
  I agree with you if we're talking about someone who is just getting started in programming and debugging. It's not a good starting point if you want to understand why these bugs exist or how to exploit them. But if we're talking about someone who is already a competent programmer, perhaps looking to learn a new tool, there's just no point (except perhaps learning) in trying to find bugs manually in production software by reading code or by trying to write test inputs that invoke unwanted behavior. After all, most code works fine at least 99% of the time, finding the 1% manually is a lot of effort. Tools like afl-fuzz or static analysis tools are so much faster (when you throw enough CPU time at them) in finding unwanted behavior that there aren't many reasons not to use them. For learning and getting started with exploits, I like your idea of using some kind of "weakened" VM, but that's a whole different deal than finding and fixing bugs (not even talking about exploiting) in production code (which is where the bounties are).
- dalke 12y ago
  I realize there's a philosophy that it's best to start from the lowest levels and work one's way up. It's one I can empathize with, in spirit, though I disagree. The same logic means that people shouldn't use static code analysis tools, or valgrind, or even debuggers, until they acquire deep technical knowledge. While I think all of these tools help reinforce the principles. If someone starts with the fixed and unwavering goal of security analysis in mind, then perhaps I can agree with you. If however someone is only curious about security analysis, and finds that spending a year to "grok the theory" is a high barrier, then even clumsy use of semi-automated tools may provide more concrete incentive to learn the underlying skills. While I don't believe you are correct, another question is, how many white hats do we end up with? Even if it takes 2 years to learn security skills by using automation, and only 1 year without automation, if after 10 years there are 500 following your path, while 10,000 following my path, then that's a net gain for the good side, yes? (I assume that there is such a thing as "good enough", and that it's relatively stable. Obviously if there is only a market for 500, and your 500 are always better than my 10,000 then that changes the dynamics.) Finally, it's also good to have even the script kiddies on the side of good than the side of lolz.
  - 12y ago
sprkyco 12y ago
Python flavored afl-fuzz for reference: https://bitbucket.org/jwilk/python-afl https://bitbucket.org/jwilk/python-afl
tptacek 12y ago
afl-fuzz gets a lot of press because it's neat, because like Peach it's a well-packaged version of a tool every tester has their own half-assed version of, and because lcamtuf wrote it and everyone likes lcamtuf. It is not, however, responsible for most security bugs. Most testers don't use afl-fuzz.

by exDM69 12y ago

tptacek 12y ago

Reading some of the actual reports, these look like straight code findings (see for instance the numbered step-by-step explanations). They also aren't particularly complicated bugs.

dsacco 12y ago

Please don't start this way. Michal Zalewski didn't write afl fuzzer so it would be used without deep technical knowledge. It's actually not for beginners at all despite how powerful it is. As a general rule to start in security work, you will want to know how to program in at least one language competently, then move on to theoretical understanding of vulnerabilities, then finding them painstakingly by hand, and finally by automation. It's perfectly fine to use afl (or other similar tools), but understand that using an automated tool without first knowing how to do things by hand and groking the theory will stunt your growth and make it hard to progress very far. Pop open a weakened VM and exploit a few buffer overflow bugs the old fashioned way before you use a fuzzer. With code review, learn the nuances of each language before you automate your audit. You shouldn't have to rely on an automated tool to find out register globals is on in PHP (as one example).

exDM69 12y ago
I agree with you if we're talking about someone who is just getting started in programming and debugging. It's not a good starting point if you want to understand why these bugs exist or how to exploit them. But if we're talking about someone who is already a competent programmer, perhaps looking to learn a new tool, there's just no point (except perhaps learning) in trying to find bugs manually in production software by reading code or by trying to write test inputs that invoke unwanted behavior. After all, most code works fine at least 99% of the time, finding the 1% manually is a lot of effort. Tools like afl-fuzz or static analysis tools are so much faster (when you throw enough CPU time at them) in finding unwanted behavior that there aren't many reasons not to use them. For learning and getting started with exploits, I like your idea of using some kind of "weakened" VM, but that's a whole different deal than finding and fixing bugs (not even talking about exploiting) in production code (which is where the bounties are).
dalke 12y ago
I realize there's a philosophy that it's best to start from the lowest levels and work one's way up. It's one I can empathize with, in spirit, though I disagree. The same logic means that people shouldn't use static code analysis tools, or valgrind, or even debuggers, until they acquire deep technical knowledge. While I think all of these tools help reinforce the principles. If someone starts with the fixed and unwavering goal of security analysis in mind, then perhaps I can agree with you. If however someone is only curious about security analysis, and finds that spending a year to "grok the theory" is a high barrier, then even clumsy use of semi-automated tools may provide more concrete incentive to learn the underlying skills. While I don't believe you are correct, another question is, how many white hats do we end up with? Even if it takes 2 years to learn security skills by using automation, and only 1 year without automation, if after 10 years there are 500 following your path, while 10,000 following my path, then that's a net gain for the good side, yes? (I assume that there is such a thing as "good enough", and that it's relatively stable. Obviously if there is only a market for 500, and your 500 are always better than my 10,000 then that changes the dynamics.) Finally, it's also good to have even the script kiddies on the side of good than the side of lolz.
- 12y ago

sprkyco 12y ago

Python flavored afl-fuzz for reference: https://bitbucket.org/jwilk/python-afl https://bitbucket.org/jwilk/python-afl

tptacek 12y ago

afl-fuzz gets a lot of press because it's neat, because like Peach it's a well-packaged version of a tool every tester has their own half-assed version of, and because lcamtuf wrote it and everyone likes lcamtuf. It is not, however, responsible for most security bugs. Most testers don't use afl-fuzz.