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?