WebApp Sec mailing list archives
Taxonomies and multi-factor vulnerabilities
From: "Steven M. Christey" <coley () mitre org>
Date: Thu, 14 Jul 2005 00:52:20 -0400 (EDT)
Frank O'Dwyer asked:
Also what makes you think these things fit into a hierarchy at all, never mind an objective one? There are any number of ways to categorise these things. They have a habit of belonging in more than one category, too.
One of the main problems is that many vulnerabilities are combinations or compositions of multiple factors, each of which can be a security-relevant problem on its own, and a hierarchy can't capture that. These Multi-Factor Vulnerabiities (MFVs) are difficult to classify effectively, since currently available schemes treat vulnerabilities as if they are atomic, and any MFV could occupy multiple places in a hierarchy. Consider the classic MFV, which is exploited by symlink following. OK, so it's not the most common issue in web application security, but it still serves as a demonstration. Factors include: - permissions (attacker has access to a directory the victim operates in) - filename predictability (attacker knows, or can predict, what filename will be written to) - race condition - design factor: lack of standard, widespread, and/or portable support for safe temporary file creation in most programming languages, lack of atomic operations for effectively creating symlinks This issue occupies several places in most classification schemes. Remove any one of these factors and you've either eliminated the vulnerability entirely, or you've reduced the attack surface. Another multi-factor vulnerability occurs in directory traversal problems. Suppose you have a web application that runs on Windows that tries to filter out bad "../" requests (yes there are much better ways to protect against this issue, but let's face it, that's what a lot of programmers with an ounce of clue do). Now suppose an attacker uses "hex-encoded backslashed directory traversal" sequences to break into the app using a sequence like ".%2e\.%2e\FILE.dat" and succeeds. There are multiple factors involved: - programmer checked for ".." before canonicalization - OK so it's a canonicalization error - programmer didn't account for "\" being the underlying directory separator character in Windows - no wait, it's an incomplete blacklist - programmer generated a filename outside the web root - so the result is "directory traversal" - the design didn't do whitelisting - the design (or the implementation?) didn't use OS API routines to obtain the real full pathname I haven't tried to determine how many publicly reported vulnerabilities are multi-factor, but it wouldn't surprise me if it's in the 10-20% range these days. If you include design flaws as factors, that number is probably a lot higher. A lot of "buffer overflows" these days are multi-factor. I know that a lot of people on this list understand this, but this is one of the major challenges for building the "right" scheme to effectively capture these kinds of problems. I wish I knew the answer but I'm only just starting to ask better questions. - Steve
Current thread:
- Taxonomies and multi-factor vulnerabilities Steven M. Christey (Jul 13)
- <Possible follow-ups>
- RE: Taxonomies and multi-factor vulnerabilities Evans, Arian (Jul 14)