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.
Visually, this nested rectangle concept is used in browsers in the form of Cascading Style Sheets. This picture is a great illustration of what I’m talking about:
_______________________________________ | | | margin (transparent) | | _________________________________ | | | | | | | border | | | | ___________________________ | | | | | | | | | | | padding | | | | | | _____________________ | | | | | | | | | | | | | | | content | | | | | | | |_____________________| | | | | | |___________________________| | | | |_________________________________| | |_______________________________________| | element width | | box width |
Now, the parser for these protocols is supposed to bound the offsets and lengths as it descends down each level of TLV and therein lies the vulnerability pattern. But essentially mutating these lengths (and offsets where possible) you can create out-of-bound reads and integer overflows which of course, result in all kinds of nastiness.
Here are some examples of the Nested TLV Vulnerability Pattern:
- OpenSSL ASN.1 Parsing Vulnerability
- Microsoft Security Bulletin MS04-007
- TCPDump ISAKMP Identification Payload Integer Underflow Vulnerability
Here are a few protocols that have the Nested TLV Vulnerability Pattern: ASN.1 (LDAP, SNMP, X.509 Certificates, DHCP), LLDP, DNS, SCTP and ISAKMP.
End of the day, the Nested TLV pattern has to do with lengths, offsets and containments.