Vulnerability Complexities

Dave Goldsmith had a great post earlier today which I would like to point out to anyone who hasn’t read it yet. With comments like, “I’m quite positive that when this vulnerability reached Sun Microsystems, someone’s head exploded”, I found his commentary very amusing. Even though this vulnerability is now eight years old, it’s a perfect example of design flaws and complicated programming problems capable of creating very interesting results. I don’t want to get too far off topic, but personally, I find classic stack and heap buffer overflows to be very boring. While these kinds of vulnerabilities may have been interesting a few years ago, there really isn’t anything exciting about seeing the same vulnerability repeatedly, unless of course there’s some element of surprise or distinctiveness about it. These days, what I find to be exciting are vulnerabilities that often occur because of poor software design. Like this vulnerability, usually this results in applications exhibiting many complicated behaviors, which can often be influenced and combined to create positive situations for an attacker that wouldn’t have otherwise been possible. Now that’s interesting.

Here’s a little bit of history on this vulnerability: Secure Networks originally developed a module for their vulnerability scanner, Ballista, which could detect the “RPC packet bounce” vulnerability on Solaris operating systems. Oddly enough, even though Secure Networks released a vulnerability module to detect this particular vulnerability, I don’t recall them having releasing a security advisory. Around this same time, I had read the release notes to the latest Ballista release and developed a proof-of-concept exploit based on this information. The same year, Sun Microsystems released a patch that addressed a separate Solaris vulnerability, which could have been used to locally compromise a server. I researched the patch and concluded that it didn’t properly address the vulnerability, and in fact, it was still vulnerable. After modifying my exploit to utilize both of these vulnerabilities, the once “patched” local vulnerability became a new, remote zero-day vulnerability. When Sun Microsystems released the next version of Solaris, they included additional functionality, thereby adding further complexity to the situation. As the exploit utilized one vulnerability to attack another, the second vulnerability was receiving data in such a way that made it think it received an address it needed to look up. What’s interesting about this is that by utilizing any sort of DNS spoofing techniques, any attacker could still reliably exploit this problem by first “spoofing” the arbitrary commands they intended to execute.

How’s that for complicated?

2 Responses to “Vulnerability Complexities”

April 14, 2006 at 11:14 pm, tqbf said:

IIRC, the bounce attack belonged to CORE SDI S.A., which had an interesting (read: I don’t understand it) relationship to Secure Networks and to Network Associates, who owned us when this bug was current.

My guess is, between that and the fact that the statd bounce isn’t so much an “exploitable hole in someone’s software” as a “crippling design defect in a protocol”, we never really had the impetus to drive to a vendor patch, and thus to an advisory.

By way of example, we didn’t release ToolTalk until after the “in-the-wild” exposure got completely ridiculous; without the exploit sightings, vendor patch reluctance probably would have kept that advisory hidden.

August 16, 2006 at 11:37 am, ivan said:

The relationship between CORE and SNI was quite simple: CORE did software development for SNI under contract. Basically we developed a bunch of vulnerability checks for Ballista. In the process we uncovered some bugs and developed some interesting things. The statd bounce was one of them, another one is the first (as far as I know) return-into-libc exploit that gera wrote for some old sendmail bug, a first attempt at a more rigorous verification of randomness for TCP ISNs, DNS attacks with predictable query IDs, NIS+ bugs, FTPD bouncing, other Sun RPC tricks using the portmapper and a few other things that I surely forgot about already. There was no official advisory from Core or SNI about statd bouncing but a public discussion about it appeared on bugtraq in 98-99. We did not deem the finding “groundbreaking” and worthy of an advisory, it just proved that local RPC services could be reached remotely. Later in 1999 CERT did release an advisory about it but back then they did not have the habit of crediting the security researchers that found bugs.
http://www.landfield.com/isn/mail-archive/1998/Apr/0109.html

Comments are closed.