SSL Hack Exposes An Interesting Coding Error
Dan Kaminsky was back at BlackHat this year talking about an SSL hack that would allow a web site to spoof other sites. He shared the glory for this with Moxie Marlinspike, who also identified the same vulnerability. The hack was an interesting attack, not against the design of SSL, but against the coding of certain SSL implementations.
The vulnerability is demonstrated by placing “\0” into a URL used to identify a subdomain. Since some browsers translated “\0” into a single character (ASCII zero), some browsers failed to fully qualify the domain name of the site. While looking into the problem, I originally wondered why any system would let you insert null characters into the name. RFC 3986 says the following:
As a result, a common security concern for server implementations that handle a URI, either as a whole or split into separate components, is proper interpretation of the octet data represented by the characters and percent-encodings within that URI.
It went on to say that the ‘\’ character should be handled with care, along with things like: ‘/’, ‘.’, ‘..’, and others. That made sense. The fact that someone strung together the characters ‘\’ and ‘0’ should not have made any difference when the URL was processed by the browser. Although nothing should have happened, it apparently did in certain browsers. It could have happened when the parsing algorithm passed the byte sequence off to a routine that reprocessed the characters according to standard C/C++ tokenizing rules. This is a classic coding error that exposes an underlying vulnerability. Your attempt to correctly implement a standard syntax is obstructed by the tools you use. It’s also notoriously difficult to spot in any type of code review.
Now, you may ask, did this really represent a coding error or should they have specified the syntax of URLs to exclude ambiguous interpretations. We see many crypto standards specifying rules to prevent ambiguity, should it have happened here? Before you answer, remember that these standards must be interpreted for both English language sites and those that use alternate character sets. I’m interested in hearing what you think.
Jim Molini, CISSP, CSSLP
