3

I'm doing a research on fuzzing and I would like to know the answer to the question in the title. The cvedetails uses the following categories for vulnerabilities:

 Bypass a restriction or similar 
 Cross Site Scripting 
 Denial of service 
 Directory Traversal 
 Execute arbitrary code on vulnerable system 
 Gain Privileges
 Http Response Splitting 
 Memory Corruption 
 Obtain information 
 Overflow vulnerability (includes stack and heap based overflows and other overflows) 
 Cross site request forgery(CSRF) 
 File Inclusion 
 Sql Injection

What I would like to know is the following: can any software testing be considered fuzzing. So for example if I'm looking for SQL injections in some web application (like some CMS system) with sqlmap, havij, sqlninja, can that be categorized as fuzzing? Because on the other side, in all papers fuzzing is only references when looking for buffer overflows - stack overflows, heap overflows, integer over/underflows, format string bugs.

So I guess I'm asking is the following: can discovering any vulnerability with any automated tool be categorized as fuzzing?

Thank you in advance

eleanor
  • 528
  • 2
  • 5
  • 11

1 Answers1

5

The short answer is: no.

Here the long answer: The origin of fuzzing (or fuzz testing) is sending random data or slightly random data (i.e. sticking to a certain format or mutating something valid).

The goal of fuzzing is usually to provoke an application crash. This crash can then be analyzed with debuggers or memory monitoring tools (i.e. Valgrind) to see if a memory corruption vulnerability was triggered and fix (or exploit) it.

Fuzzing allows you to start the application with lots of invalid inputs and defer deep analysis of the application to when a known crash has occured.

Both fuzz testing and using a web vulnerability scanner have in common that they are techniques in the field automated vulnerability testing. Web scanners, however, finds specific vulnerabilities using quite strategic, sophisticated attacks. Varying assumptions, playing with input/output handling of web apps. Fuzzers don't need to be that smart (although they may be, of course).

Oh, this might be less relevant but sqlmap, for example, does not only scan for SQL injection flaws but does a very smart job in exploiting them.

freddyb
  • 521
  • 3
  • 9
  • So what you're saying is that fuzzing can only detect buffer overflows - conditions when the malicious input was sent to the program, which caused it to crash? So any other types of vulnerabilities are discovered by vulnerability scanners. This site http://gpo.zugaina.org/dev-db/sqlmap/euscan says that the sqlmap is a python based fuzzer. Can you provide me with more details what vulnerability types a fuzzer can detect? Thank you – eleanor Feb 19 '12 at 00:23
  • My main point was, that sqlmap does something sophisticated. Using SQL Syntax and checking the output variation. But there are fuzzers which stick to specific languages (i.e. JavaScript) as well. My reasoning is slightly flawed, I'm afraid ;) -- But! Sqlmap is doing black-box analysis and not hoping for application crashes. That's imho a notable criterion to distinguish vulnerability scanners from fuzzers. – freddyb Mar 13 '12 at 10:31
  • I have one more question then. If fuzzing is expected to detect application crashes, then it can only detect buffer overflow vulnerabilities. Why are so many sources saying that it can also detect other types of vulnerabilities like sql, xss, command execution, etc, if they don't provoke application to crash, but just display additional entries from the database, etc. – eleanor Mar 20 '12 at 09:14
  • 1
    The term fuzzing is not precisely defined. Considering that you're doing this for a some kind of research I would suggest that you find a good computer security book and quote the author's definition of fuzzing :) In *my* opinion fuzzing is less sophisticated than vulnerability scanning. Fuzzing especially requires you to run the application on your own, whereas vulnerability scanning may happen with remote machines. – freddyb Mar 20 '12 at 12:51