Null terminate with extreme prejudice

I've been asked several times about Dan Kaminski's recent hack against X.509 certificates, so here's my explanation of it. I'd say it's not really an attack against X.509 certificates, but an attack that takes advantage of how some web browsers work. It all has to do with null-terminated strings.

A string is a sequence of characters. The string "hello," for example, is the sequence of characters 'h,' 'e,' 'l,' 'l,' and 'o,' which would be encoded as the sequence 104, 101, 108, 108, 111 if we're using the ASCII encoding rules. One way to indicate the end of a string is to add a special character to the end of a string that marks its end, and a common way to do this is with the null character, the character that encodes the value 0. To tell where the end of the string "hello" is, for example, we would add an additional null character to it so that it's represented as the sequence 104, 101, 108, 108, 111, 0, so that the five-character string "hello" is stored as a six-character null-terminated string. Programs that handle null-terminated strings would recognize the 0 as marking the end of the string, and ignore anything after that, and Dan Kaminski found a clever way to take advantage of that fact.

Suppose that you're a hacker who owns the domain yourehacked.com. Because you're the legitimate owner of this domain, you can get SSL certificates that identify your servers. You might want to get a certificate that can be used to authenticate www.yourehacked.com, for example, so that your hacker friends can tell that they're really on your web site and not on a web site run by law enforcement or some other part of the government. If you've set up subdomains to help you manage your web site, you might want to get an SSL certificate for something like www.hacks.yourehacked.com. If you're really creative, you might even request an SSL certificate for www.somebank.com%00.yourehacked.com, where I've indicated the null character by "%00," and Kaminski's hack takes advantage of how some browsers will display a URL like this one.

If a web browser assumes that a URL is a null-terminated string, when it looks at this URL, it's going to stop at www.somebank.com and ignore the rest of it. The part of the browser that handles certificates, however, handles more general strings, and it uses a tag-length-value (TLV) format to do this. In a TLV format, there's a tag that tells you that the following bytes are a string, then there's a length value that tells you how long the string is and then there's the value of the string itself.

This takes a bit more overhead than just handling null-terminated strings does, but it also lets you handle more general values. It also happens to be the way that information in a digital certificate is encoded. Because it's designed to handle more general strings, the part of the browser that handles certificates won't have any problem handling the URL www.somebank.com%00.yourehacked.com, but the parts of the browser that expect null-terminated strings will. In particular, a browser might display this URL as "www.somebank.com" in the its address bar even though it's really connected to part of the yourehacked.com site. So if a hacker can get people to go to this URL, they may think that they're really on the somebank.com web site even though they're really on the yourehacked.com web site. After all, there's a valid SSL connection, and the URL www.somebank.com appears in the address bar of their browser.

Apparently right after Kaminski gave his talk that described this hack, there was a flood of requests at public CAs for new certificates that contained null characters, but I haven't heard that any of these certificates were actually issued. We'll probably hear more about that in the next few weeks.