Null Character Hack Allows SSL Spoofing 280
Posted
by
timothy
from the cannot-anticipate-all-evil dept.
from the cannot-anticipate-all-evil dept.
eldavojohn writes "Two researchers, Dan Kaminsky and Moxie Marlinspike, came up with exact same way to fake being a popular website with authentication from a certificate authority. Wired has the details: 'When an attacker who owns his own domain — badguy.com — requests a certificate from the CA, the CA, using contact information from Whois records, sends him an email asking to confirm his ownership of the site. But an attacker can also request a certificate for a subdomain of his site, such as Paypal.com\0.badguy.com, using the null character \0 in the URL. The CA will issue the certificate for a domain like PayPal.com\0.badguy.com because the hacker legitimately owns the root domain badguy.com. Then, due to a flaw found in the way SSL is implemented in many browsers, Firefox and others theoretically can be fooled into reading his certificate as if it were one that came from the authentic PayPal site. Basically when these vulnerable browsers check the domain name contained in the attacker's certificate, they stop reading any characters that follow the "\0 in the name.'"
Re:Are CA's that stupid? (Score:5, Insightful)
Re:Are CA's that stupid? (Score:5, Insightful)
CAs should be fixed to not allow garbage in the domain. \0 isn't a legal character in DNS protocol, so why should anyone be allowed to register a domain certificate with something that is not allowed.
I miss pascal strings, where the first byte was the length of the string. It had lots of cool advantages in situations like this over C's null terminated strings.
Re:Are CA's that stupid? (Score:5, Insightful)
When C Strings Attack! (Score:4, Insightful)
*sigh* Why is anyone still using null-terminated strings? It's almost a shame that Pascal didn't become dominant...many of these bugs would simply not occur.
Re:Are CA's that stupid? (Score:3, Insightful)
Come over to C++ - we have it all!
Re:So now... (Score:5, Insightful)
No, all we have to do is make CA's liable for the certs the issue.
And we trust CAs *why* again? (Score:5, Insightful)
If you ask me, networks of trust such as PGP are far more difficult to compromise than a central authority. Anything centralized is going to have only a handful of people, who are easy to find, and being private citizens, easily compromised. On the other hand, an integrated cryptographic interface where anyone can vouch for the authenticity of a site, ie; a reputation-based evaluation schema, would be (relatively speaking) more secure.
I have a reputation amongst my friends and family of being "tech savvy". They trust my advice on technology. If that advice could be included in a database an integrated directly into the browser, then others they know that are also "tech savvy" (and trust) could inform their browsing actions much more than a single profit-orientated organization. I could, for example, add "l0pht industries" to my list of trustees, or "Bruce Schneider"... Or even "Rob Malda", and those people would become part of the trust network that my friends would then rely on. This is where the technology should go -- but because it conflicts with monied interests and in a capitalist society it is only the dollar value of a thing that makes our institutions protect it, it probably never will.
Trust is really the central issue, not cryptography. Cryptography enables us to extend our trust relationships into the digital world.
Re:Makes me wonder (Score:5, Insightful)
Idiots? I think not. Put yourself in the shoes of programmers in the 70s. Could you have come up with a better idea that did all these?
Sure, today, C strings might seem like a poor decision today, in this age of virtual memory, C++ classes, and sophisticated optimizing compilers. But at the time, C strings were the least bad of the available alternatives.
If we were using pascal strings... (Score:4, Insightful)
Someone would just get a certificate that managed to put the ".badguy.com" part starting at byte 255 of some string.
Null is not a legal character in a domain name, even if you're using UTF strings. It shouldn't be allowed in a certificate.
Re:Are CA's that stupid? (Score:2, Insightful)
Cheap certificate services are automated, so yes.
The question is... why in hell is firefox treating strings from the net as if they're already escaped?
Great summary (Score:5, Insightful)
The summary really explained what it's all about, rather than sound like a newspaper who want's you to read more. This is great! Too few summaries are like this. Editors, you should make sure every story get such a good presentation on Slashdot.
Re:Are CA's that stupid? (Score:3, Insightful)
Well, it did say "the null character \0". That seems pretty obvious. It's the null character, and we're calling it \0 because it's unprintable.
Re:And we trust CAs *why* again? (Score:3, Insightful)
The modern CA hierarchy IS a web of trust. You have the control over which CAs and even which individual certificates you trust. If you go with the default trust relationships provided by your browser or OS vendor, and you aren't satisfied, you have no one to blame but yourself.
Re:And we trust CAs *why* again? (Score:3, Insightful)
The modern CA hierarchy IS a web of trust.
No, it's properly a forest (i.e., multi-rooted tree). All the trust flows one way, from the CA roots. That works better because smaller numbers of people need to know what they're doing. Normal people, even normal website admins, don't need to know the details. By contrast, a web of trust will only work between people who understand the security implications of getting it wrong and who are therefore appropriately cautious. So small groups of techies are ideal, the general public... less so.
Re:Are CA's that stupid? (Score:3, Insightful)
CAs should be fixed to not allow garbage in the domain. \0 isn't a legal character in DNS protocol, so why should anyone be allowed to register a domain certificate with something that is not allowed.
Exactly. My mind is totally blown by this. They're issuing SECURITY certificates and they don't VALIDATE USER INPUT?!?!? Isn't that the very first thing they cover when talking about how to design apps securely? This is would take, what, a one-line regular expression to catch? God help them if Bobby Tables wants a cert.
Re:Makes me wonder (Score:3, Insightful)
The problem is that the certificate, being written in ASN.1 format, does use a Pascal-style length-delimited string, whereas the browser is using C-style strings. When the ASN.1 string is converted into a C-style string the early NUL terminator is preserved, truncating the domain, and this truncated domain is then used to verify that the certificate matches the URL. This wouldn't be an issue if the same string format was used in both places, whether Pascal-style or C-style.
There are multiple aspects to this vulnerability. No certificate should have been issued for an invalid domain name (NUL characters are not permitted in DNS identifiers). Given the sensitivity of the field, the domain name should not have been converted from ASN.1 format to a C-style string without some runtime verification that the resulting string is equivalent to the original, including the length. Finally, it would have made more sense to store and compare the domain name starting from the TLD; that way, if the name somehow did get truncated, the part which was verified would be the most important part and not some arbitrary subdomain.