Downnload

Features

Works by using Reflection to create 'live instances' of classes and then fuzzing each of the exposed methods

there are currently 16 different payloads for basic types (int, unint, char) and strings

Fully automated use of cdb to find issues (i.e. you can start the fuzzer and go for lunch)

use of an 'FuzzedMethods' list for each fuzzed dll to avoid re-fuzzing the same methods

stored of exception information in an 'ExceptionData' file (per dll)

use of an 'ExcludeList'to list the classes/methods that should be further analyzed

auto detection of methods that consume large amounts of memory (currently set to 20M) and auto-detection of methods that 'hang' (some callbacks or windows pop-ups have this behaviour).The methods identified are automatically added to the 'ExcludeList'

The results are current quite conservative (i.e. only the realy bad exeptions are shown). this means that there might be several exploitable vulnerabilies that are currenly reported as 'Normal CLR exception'

A big blind spot at the moment is that the current version does not fuzz certain static methods (which can be invoked without need of a constructor (i.e. a live instance))

When it finds an interface it tries to find who implements that interface and tries to create an instance of them (supports caching of objects for performance reasons). The problem here is that the class created is not documented, and ideally we should be fuzzing each of those implementations (especially in the cases where that Interface is used as a parameter)

When in auto mode, it auto-restarts fuzzing session after a predefined number of seconds (this also helps in long fuzzing sessions since the process is refreshed regularly, which of course might also introduce some blind spots)

Files:

The binary (DN_BOFinder.exe) can be found on the DN_BOFinder_V0.2\binary folder

The results will inside the DN_BOFinder_V0.2\binary\_fuzz_results folder (created on first run)

The source code is in DN_BOFinder_V0.2\Source Code

fuzzing modes

There are 5 operational fuzzing modes:

File ::: to Fuzz a file (in this mode a CLR crash will also crash the fuzzer)

File Auto ::: to Fuzz a file automatically (in this mode new processes of DN_BOFinder are started in the 'File' Mode under cdb (Microsoft's Command Line Debugger). The cdb output is analyzed for unhandled exception data which when discovered is appended to the 'ExepctionData'

Dir ::: to fuzz directories (basically invoking 'File Auto' for each *.dll in the target directory

Method ::: to fuzz a method directly

Method Auto ::: to fuzz a method automatically (this will invoke the method using the number of payloads specified)

Current limitations

when one of the create parameters value is null, the method is not invoked (since it was throwing a lot of errors). This is a legacy from the first version of this fuzzer (before cdb automation) so it should be possible to remove this now

Need to add support for call stack information (and sequence of methods invoked) since sometimes the exception is not thrown by the method we fuzzed (and we need those details to replicate the state of that issue)

the fact that we don't fuzz the same method twice creates some blind spots (since some errors occur by state changes in previous methods)

the payloads are still quite basic, in a future version the fuzzing of live objects (i.e. variation of it) will be implemented

the creation of live instances is still not very cleaver and has problem with more complex types (like the ones that require a file to be loaded before some of its methods make sense). The plan is to implement a new fuzzing mode where we are able to use real objects created during an execution of an real application (for exemple an win32 gui app or an ASP.NET website) and fuzz them.

Bugs and to-do-list

we should delete the 'ExcludeList'and 'ExceptionData' when nothing is found

list the methods/classes that we couldn't fuzz

Add a Gui

Add code coverage

export results in XML format

add directory recursive capabilities to the 'Dir' fuzzing mode

HOW-TO use instructions

'Fuzzing MsCorLib'

> binary\DN_BOFinder.exe file mscorlib.dll

by default if no path is included, DN_BOFinder will try to find the file in the current directory or in the main .Net 2.0 directory

If all goes well you will see a large number of entries that look like these:

while this is running, open the \DN_BOFinder_V0.2\binary\_fuzz_results folder and you will see three files in there:

* mscorlib.dll_ExceptionData.txt - Will contain details about exeptions discovered (only in auto or dir modes)
* mscorlib.dll_ExcludeList.txt - Will contain a list of methods to exclude (only in auto or dir modes)
* mscorlib.dll_FuzzedMethods.txt - will contain a list of methods and classes that have been fuzzed

Which is an error that occured inside the mscorwks.dll and was the reason the .NET assembly crashed.
The exeption mscorwks!IEE+0x13277 is actually quite common, and I think it is a false positive since it looks like part of a method that checks for bad points (which is weird method to check it, but it seems to be quite common on the CLR). I need to load the symbols in my dev laptop (which is always offline btw :) ) to see where mscorwks!IEE+0x13277 resolves to.

Now that we have an issue you have two choices:

1) add manually the signature of the offending class System.Text.RegularExpressions.MatchEvaluator to the _fuzz_results\system.dll_ExcludeList.txt file or

2) run

> DN_BOFinder file auto system.dll

which will do that for you :)

the output of "DN_BOFinder file auto system.dll" should be something like:

so what is happening here is, you get an [INFO] everytime a fuzzing session starts (i.e. new process) and we have a bunch of 'Normal CLR Exception' entries (which crash the CLR but I think are false positives (I would actually put money that some of these might be exploitable (most are null pointers)). Note for example that the case I shown above (System.Text.RegularExpressions.MatchEvaluator) is here shown as a 'Normal CLR Exception'

Every time a 'CLR Exception' occurs, its signature is added to the MethodsFuzzed list and the process restarts (only in the cases where the error doesn't match one of my hard-coded signatures the methods are added to the ExcludeList and its data added to the ExceptionData.

...

Eventually you start to get some more interresting issues like for example:

(these type of cmp are another type of exceptions that I think are false positives)

fuzzing methods

lets go back to the system.dll System.ComponentModel.ComponentResourceManager.ApplyResources(System.Object,System.String) discovered before

the final piece of the puzzle is to see if this method is exploitable (i.e. can we contol the CPU Registers from a variable that we control). So to do that, the easier way is to run just that method with all fuzzed combinations.

And that is what we can do with the method option. (you can also write a simple c# code to do that)

the first one, MediaPlayer.RadioPlayerClass.BindRadioMemory(), seems to be one that is caused by some change of state on a previous fuzzed method, but the 2nd one looks much more interresting: MediaPlayer.RadioServerClass.Unregister(Int32)