It’s cool that Charlie Miller fuzzed the iPhone and broke it, but the catch phrase for me was (paraphrased) “When I start the fuzzer, I want to get some sleep and when I wake up find tons of 0-days“. I remember watching the movie with my kids and it wasn’t that the factory made awesome chocolates, but the whole thing was automated with elves and such.
Archive for Mutations
IPv6 Fuzzing and Testing
At Mu, we take testing IPv6 pretty seriously, especially since the IPv4 address space is vanishing faster than you say all octets of an IPv6 address. We released our first version of IPv6 test suite for fuzzing 3 years ago which includes coverage for fragmentation, various extension headers and and options. Most of the fun in fuzzing IPv6 happens with the extension headers which are much like IPv4 options, except it’s a chained linked-list like IKE payloads. In the one of the IPv6 test suites, we have more than 100,000 test cases that exercise various parts of the IPv6 capabilities!
Fieldomatic Complexity
If you’ve gone through my CanSecWest slides, I talk a lot about Field’s and how they are the fundamental units of protocols (network or file formats). The linkage information between the Field’s and across messages is a pretty powerful way to infer the cyclomatic complexity of the code that parses these messages. When generating test cases (fuzzing being one kind), we can leverage these structural and semantic linkages to generate systematic constraint violations that ultimately exercise the various branches taken in the parser.
Itsy Bitsy Protocol Spider
In the OOMPH blog I talked about specification coverage and how the effectiveness of attacks can be measured. Part of building object oriented mutations that mimic the design and interconnectedness of protocols, is to leverage attacks on referenced structures in related protocols. But how are protocols related?
Vulnerability Patterns – Emptiness
As in Nada, Nothing. When I wrote the title, it sounded silly that something as simple as this would be a pattern, but the number of NULL-pointer DoS’ that this creates is pretty amazing. It’s a very effective pattern that is about removing mandatory elements/fields from a protocol and sending them off to /dev/null.
Vulnerability Patterns – Nested TLV’s
Protocols (in the loose sense of structured exchange of messages) are like russian dolls. Everything at some point is contained within everything else. The Nested TLV vulnerability pattern is probably more to do with binary protocols than ascii ones. You can think of each TLV as a rectangle from a bounds perspective.
Vulnerability Patterns – TLV’s
In the quest to provide complete Attack Surface Coverage, we strive to identify patterns of abuse in protocols that we can replicate across other protocols and applications. We call them Vulnerability Patterns, because it abstracts the problem away from the programming language, the protocol or the one-off vulnerability in a particular version of a given product. It’s a powerful concept, especially if you can capture this pattern and apply it to every single place you see it. It’s no different from Design Patterns used in software engineering.
Attack Surface Coverage
The concept of Attack Surface is a formal way for quantifying the exposure of a connected system. It’s a measure of exposure and not that of vulnerabilties. However, two aspects of Attack Surface, channels and protocols, are key in figuring out how to attack a system and where the failure points are. In the last blog about mutations, I wrote about how we can create reusable mutation objects that can be plugged into arbitrary protocols and how we can use code coverage as one metric for measuring the effectiveness of it. From a system level perspective, I want to introduce this new notion of Attack Surface Coverage.
O.O.M.P.H.
Object Oriented Mutations for Protocol Hardening.
Seriously though, I want to write about the process through which we create mutations and how ultimately it gets linked up in an assorted set of seemingly unrelated protocols. The take aways (for the impatient) are that mutations are really unit-tests, but have their origins in the following:
- Protocol specification
- Code reviews
- Known vulnerabilities that other people have found
- Expertise
- Structure
- Semantics
- State
Categories: Mutations
