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.
Archive for January 2007
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.
ruby, dup2 and rinetd
When you are attacking an xinetd-based process model, there’s no reliable way to know if the child process seg-faulted. The accept’ing socket is always alive and GDB’s follow-fork-mode doesn’t quite help us with this since child processes are being spawned and killed all the time.
Proxies, procs and yield
First the definition: Proxies are objects that masquerade as some other object that’s contained within them, effectively intercepting all messages to the contained object. Proxies are used in multiple places like debugging, tracing, intercepted delegation, benchmarking, etc. But those have already been solved. This post is not about that.
Heuristics for Packet Field Identification
When performing any type of protocol fuzzing, one must obtain three key pieces of information about the target protocol: structure, state and semantics. The structure of a network protocol is the format of the messages, which contains a series of fields which, at the simplest level, are integers and strings. When dealing with any protocol with public specifications, this information is easily obtained. However, what is one to do when the specs are not publicly available, say in the case of a proprietary industrial control and automation protocol?
Categories: Research
Enums, strings and laziness
If you look at the glibc equivalent for converting #defines to strings for purposes of perror, it’s a massive array that, at compile-time, builds all the strings.
The biggest drawback with this approach is that the #define and the corresponding friendly strings are defined and reconciled in two different places. If someone updates the header file to add a new errno, then s/he has to remember to also update this other place so perror works as expected. I’m using errno as an example, but this is a common problem when writing code in C or C++. The problem is exacerbated when certain enums are conditional (based on the operating system, cpu type and so on). Then these checks now need to be in multiple places. Ugliness.
