Wireshark, dissectors and fuzzers

September 27, 2009 by kowsik

Just saw someone tweet about Python dissectors in Wireshark. Personally, I would’ve preferred a Ruby DSL that maps back to the internal libwireshark API in a way that makes writing dissectors incredibly easy. A couple of years ago, I presented “I see dead protocols” at CanSecWest and talked quite a bit about laziness, impatience and virtue. In the context of dissectors, I dug out some code that I wrote a while back that essentially converts a parser into a fuzzer. Let me explain.

Fuzzing is purely an exercise in semantic data structure manipulation, nothing more. To be more specific, we think that fuzzing is alternate serialization of perfectly valid data structure (message, protocol, file format, ioctl, etc). Being very reductionistic and unzen-like, people tend to think about fuzzing as generational (something that requires fundamental protocol knowledge) and mutational (something that takes a valid data structure and introduces anomalies). But if you look deep enough, you will realize that they are one and the same – as long the end result is the same semantic data structure.

What’s the deal with semantics? Unlike say, XML, most protocols have relationships between fields: checksums, lengths, offsets, etc. In other words it’s more than just a parent-child relationship in a tree data structure. Pictures speak better:


This is a semantic data structure of a PNG file format. The red arrows indicate the semantic relationships (crc’s, length’s).

The semantic structure of Quicktime file format is another interesting one. Here the size relationship includes the size of size itself, a commonly recurring theme in a lot of protocols:

Okay, so these are all file formats, but network protocols are no different. The one new addition is relationship across messages: like XID’s in NFS, DHCP, Cookies in HTTP, Challenge/Response in various Authentication protocols.

Which brings me to dissectors. The ideal dissector won’t just tell you a uint-here, a checksum-there. It should preserve the relationships such that you can take the data structure and use it to generate the very data it parsed in the first place. If you can do this, fuzzing the data structure is easy, since you already have all the semantic information. Not to mention that generating a valid format (for files) or transaction (for network protocols) is simply a matter of serializing the data structure.

Here’s (snippet of) the dissector I wrote for Quicktime which broke Safari during fuzzing and was also used to generate the GraphViz images above.

def parse_atom_elst
    type.uint8 'version'
    type.flags24 'flags'
    nentries = type.count32('num-entries')
    struct('entries') { |g|
        nentries.of = g
        nentries.value.times do |i|
            struct("entry-#{i}") {
                type.uint32 'track-duration'
                type.time32 'media-time'
                type.uint32 'media-rate'
            }
        end
    }
 end

 def parse_atom_hdlr
    type.uint8 'version'
    type.flags24 'flags'
    struct('component') {
        type.uint32 'version'
        type.uint32 'subtype'
        type.uint32 'manufacturer'
        type.flags32 'flags'
        type.flags32 'flags-mask'
        struct('name') {
            len = type.length8('length')
            val = with(len.value) { string.basic('value') }
            len.of = val
        }
    }
 end

 def parse_atom_dref
    type.uint8 'version'
    type.flags24 'flags'
    nentries = type.count32('num-entries')
    struct('entries') { |g|
        nentries.of = g
        nentries.value.times do |i|
            struct("entry-#{i}") {
                parse
            }
        end
    }
end

This DSL walks the various Atom’s in the Quicktime file format and parses them. But each line of the DSL (type.uint8, type.count32, etc) are all building the semantic data structure while at the same time advancing the stream pointer to consume the appropriate number of bytes. The net result is you can output the equivalent of PDML in addition to generating the images above and enabling a whole range of other applications.

Now, if you can turn the output of Wireshark dissectors into active transaction generators, don’t you think that would be cool? Check out Mu Studio! Mu Studio turns any one of the 1600+ pcaps on pcapr into active test cases and that’s not just for fuzzing!



Categories: Fuzzing, Ruby, Tools, Wireshark
775 Comments
Bookmark and Share