Glenn Brunette's Security Weblog

UPDATED: Solaris - Now With More Fuzz

Friday Jan 04, 2008

Every six months or so, I try to do a run of my fuzz tests against the Solaris OS. The first test was conducted a year ago with build 42 followed by a test during our summer break on build 68 of Nevada. It should come as no shock then that I conducted another test during the winter break on build 80.

The tools and methodology are the same (although there are still some kinks to be worked out to make it fully automated), but for those who have not read my earlier post, I will summarize. The tests were conducted on a fresh installation of Nevada build 80 built with the SUNWXCall (Entire + OEM) installation cluster. A sparse-root, non-global zone (called "fuzz") was created for the tests and the software was loaded into the zone. Next, the names of all of the ELF binaries were collected, using the make-exec-list script run from within in the non-global zone. Next, the make-fuzz-tests script was run to generate the 36 different fuzz files to be used as input for each binary tested. Lastly, the test was kicked off using the exec-fuzz-tests script. The script pretty much runs unattended except when I need to kill off runaway processes. I still need to add some code to kill off anything started at the end of each test so you do not end up with tons of extra processes running and consuming memory.

At any rate, the test run completed and I have posted my results in Bugster and the bugs are also available in the OpenSolaris Bug Database Search using the keyword fuzz. The programs impacted can be viewed using this query.

While I tend to do this kind of work for fun as a holiday distraction, it does have real benefit. Programs that fail during a fuzz test (usually core dumping although a runaway or two have also been found) fail due to unvalidated input that leads to a buffer overflow or arithmetic exception of some kind. Input validation is not to be taken lightly and should be performed by every program and service. In fact, on the CERT Top 10 Secure Coding Practices list, validate input is item #1 and with good reason.

Take care,

Glenn

Technorati Tag:

[5] Comments
Like this post? del.icio.us | furl | slashdot | technorati | digg
Posted at 01:43PM Jan 04, 2008 by gbrunett in Solaris 10 Security
Tags:
Comments:

Some number of the bugs reflected in your query have been dealt with
or are not reproducible. The query should be modified to reflect only
those bugs that are still open.

Posted by jl7459 on January 05, 2008 at 09:47 AM EST #

jl7459, you are absolutely correct - as it was my intent to show all of the issues that have been uncovered by this grass-roots project. That said, I do not know of a way to only query those not already fixed or closed (using the OpenSolaris interface). You may have to search using each state value which is certainly sub-optimal, but I do not know a better way. It would be a good RFE for the bugs.opensolaris.org interface however and I will file one.

Posted by Glenn Brunette on January 05, 2008 at 10:16 PM EST #

Are your test scripts available at all?

Posted by Ceri Davies on January 06, 2008 at 05:40 AM EST #

Right now, no. The code that I am using is based on software developed by the University of Wisconsin and their license indicates that it is not redistributable unfortunately. Most of my tweaks are just to make things a bit more automated for me as I need to find all of the Solaris ELF binaries and also bundle up the test cases with the core files for the bug reports that I file. You can find their original software at: ftp://ftp.cs.wisc.edu/paradyn/fuzz/.

Posted by Glenn Brunette on January 06, 2008 at 01:32 PM EST #

Thanks for the pointer!

Posted by Ceri Davies on January 08, 2008 at 04:14 AM EST #

Post a Comment:
Comments are closed for this entry.