Call: +44 (0)7759 277220 Call
Blog

Pete Finnigan's Oracle Security Weblog

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

[Previous entry: "January 2009 CPU is out"] [Next entry: "A paper on how to find Oracle SID's"]

A PL/SQL Fuzzer / Fuzzor



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.

There has been 2 Comments posted on this article


January 16th, 2009 at 04:42 pm

Pete Finnigan says:

Hi Pete,

Thanks for taking the time and for your comments. The name Fuzzor == Fuzz ORacle.
I will definitely improve the reporting...



January 20th, 2009 at 08:25 am

Pete Finnigan says:

Hi Slavik,

Thanks for the name clarification, nice play on the word fuzzer; I should have realised. smile

cheers

Pete