Fuzzing is not just buffer overflows

We recently introduced a few improvements to our beSTORM fuzzing framework to make it test for things other than the common buffer overflow, format strings, integer overflow, off-by-one, etc. These includes less common vulnerabilities like command execution and code injection. These type of vulnerabilities are more complicated to test as they require close integration with the product being tested – namely monitor what it tries to open (similar to what filemon does) and what it tries to execute (in the case of Perl, PHP, etc).

Armed with these new tests we took one of the candidate we knew had no vulnerabilities of “common” ones as it is written in Perl, as such it was never audited for vulnerabilities, launched our fuzzing module for HL7 (Health Level 7) and awaited for the results, after several hundred of tests it detected something very particular:


\x0bMSH|^~\\&|||||20071203173658|||20071203173658.98 \x0d`/usr/bin/whoami`|||XXX|\x0d\x1c\x0d

Instead of the “normal” – non fuzzed traffic:

\x0bMSH|^~\\&|||||20071203173658|||20071203173658.98 \x0dMSH|||XXX|\x0d\x1c\x0d

Caused the program located under /usr/bin/whoami to get launched, of course this isn’t a ready made exploit or it is a vulnerability none the less, you can probably guess what the next step is :)

Update: The author of the program has promptly fixed the vulnerability and has released a new version, accessible by using the toolkit’s CVS version.
P.S: even though the software hasn’t been updated since March 2005, several vendors provide it as part of their HL7 implementations.

A CVE has been given to this vulnerability: CVE-2007-6264