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.
Over the next few blogs I’ll try and relate vulnerabilities on seemingly disparate protocols and see how there’s something fundamental about them. For each pattern, we’ll examine a set of published vulnerabilities and then talk about which other protocols have this pattern.
The two common patterns that people immediately identify with are buffer overflow and format-string. Obviously, when we are writing mutations, we want to overflow every part of the protocol and insert format strings in all the places that are likely to be written to a log file, etc. Are there others? Let’s start with TLV’s (Type/Length/Values).
This is a classic. Supposedly a protocol contains a list of TLV fields for [ahem] extensibility. The theory is that the parser for this protocol can skip over types that it doesn’t understand since there’s a length associated with it. Well, reality works differently. If the length field includes the length of the type field, then a length of zero will typically cause infinite loops. Long time ago, in the early part of my previous life building IDP’s, we had a bug in the IP-options parsing code where the pointer increment in the while loop wasn’t checking for zero-lengths. The result? Infinite loops followed by a kernel panic when the watch-dog kicked in. Turns out we were not the only ones:
This pattern exists in protocols like DHCP, ISAKMP, IPv6, LLDP, SCTP, PPPoE, etc.
For the next Vulnerability Pattern, we’ll go through Nested TLV’s. Stay tuned.