Pete Finnigan's Oracle Security Weblog

Slavik sent me the code to his PL/SQL fuzzer quite some time ago to have a look and a play and he promised to make it available via his blog. The blog post has arrived finally around 10 days ago with a detailed description of the fuzzer, some example run and also the code for download.

Fuzzer or Fuzzor; Slavik uses both terms, I don't know, generally its called a fuzzer in my experience but the name doesn't really matter, it's what it does that matters. Fuzzing started in 1989 by professor Barton Miller who coined the name when he saw the effects of randon characteres on a modem line caused by storms crashing Unix utilities. He then set the task as a graduate project to create a fuzzer, and he coined the name Fuzz. it has nothing to do with fuzzy logic but to do with sending random input to a program with the intention of crashing that program. The idea is different to static code analysis as it is dynamic testing and is aimed at replicating the idea of someone who doesnt read the manuals for an application but instead just randomly bangs away at the keyboard; in this case looking for something to break - a bug - we are interested from a security perspective as we would like to crash a program dynamically to see if it can be expolited from a security perspective.

This is exactly what Slavik's fuzzer does. Its written in PL/SQL, tests PL/SQL packages, functions and procedures and is driven by a set of database tables to hold the configuration and the results. The idea is that you can target a particular package or a complete schema.

The nature of a fuzzer is that it sends random input to a particular function or procedure so its running that code hoping to crash it. Therefore do not run this tool on a production database or any database that you do not want to damage..

To run the fuzzer you must first create the schema. Another reason to not run the code in production is the need to create an additional schema that has some dangerous privileges such as EXECUTE ANY PROCEDURE. Then create the tables for the schema and you then need to create the fuzzer package called "fuzzer". Finally running the fuzzer is as simple as:

SQL> exec fuzzor.run_package(’Test of encode', 'TEST', 'ENCODE1');

PL/SQL procedure successfully completed.

SQL>

Next run a report from the same package with FUZZER.REPORT. This reports the number of objects fuzzed and the number of executions and of course the results. I would change the report to highlight the issues located better to the beginning of the report or to allow exclusion of the "good" values. Clearer reports can be made with SQL scripts in SQL*Plus of course.

The code is available from Slavik's site under PL/SQL Fuzzer Source Code. Finally again; do not run this in a database you need and certainly not in production databases.