Null Character Hack Allows SSL Spoofing 280
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.'"
\0wned (Score:5, Funny)
\0\0ps.
Re:\0wned (Score:5, Funny)
I don't get it, you didn't post anything.
Re:\0wned (Score:5, Funny)
Re: (Score:2)
Paypal.com versus Badguy.com (Score:5, Funny)
I don't get it.
Isn't this just the same company?
Re:Paypal.com versus Badguy.com (Score:5, Informative)
P.S.
Obligatory explanation: In the early 2000s, paypal.com was arbitrarily closing customers' account and keeping the money for themselves. (You can read more detail at paypalsucks.com) After a couple of years of this, the Bush adminstration's FTC investigated, found paypal guilty, and required paypal.com to refund all the money they had taken. Some people received full refunds while others received flat payouts. I was one of those who received a $50 check.
So long story short - Paypal.com and Badguy.com are synonymous for many people.
Another action Bush's FTC took was against record companies. They found the companies had created an illegal cartel to pricefix retail sales of CDs (gee what a surprise), and the companies agreed to settle the case by issuing refunds. I received an $18 check, ditto my brother, ditto my mom, and ditto my two nieces. It might take-awhile but eventually the law catches-up to illegal corporate activities.
Re: (Score:2)
In the early 2000s!? This happened to our organization last week! If you can, avoid Paypal like the plague.
Re: (Score:2)
Is the null character valid in a domain name? (Score:5, Interesting)
If not, the CA should not have issued the cert in the first place. Which CA was it?
Re: (Score:3, Funny)
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: (Score:2)
Re: (Score:2)
If Pascal strings had become standard, we'd be dealing with 256-bytes length limits all over the place as Pascal only use eight bits to store the string length. I imagine there'd be attacks that involved making the length counter overflow. We'd still have bugs, but different bugs.
Re: (Score:2)
Or they would have done what Delphi (Pascal-based) did, in fact, do: strings are reference-counted and copy-on-write and can contain any characters. They can also be treated as c-type strings when necessary (called a PChar, meaning a Pointer to an array of char), because assigning to a string automatically adds in a null byte at the end. But you can still get around the string handling and screw things up if you try hard enough.
Re: (Score:2)
Actually, the limit for standard pascal strings is 255 characters. Byte 0 of the string is the length of the string and 1 to ??? is the actual string. The limit could be overcome by storing the length separately from the data. However, pascal style strings are not inherently more secure than C style strings. You could invent a hack that plays around with length bit ( or field ).
Re: (Score:3, Funny)
Re:When C Strings Attack! (Score:4, Funny)
The first string says to the bartender, "Give me a beer." The bartender turns to the second string and says, "and what about for you?" To which the second string replies, "I would also like a beer#@a9101gb230b81;kajf3#$B89*#()*13!$%#@$"" and goes on and on spewing gibberish.
The bartender, shocked, asks the first string, "What is your buddy's problem?"
The first string answers, "Oh, you'll have to excuse him, he isn't null terminated."
Re:When C Strings Attack! (Score:4, Interesting)
>>>"I would also like a beer#@a9101gb230b81;kajf3#$B89*#()*13!$%#@$""
When I first read this I thought something was wrong with my modem. This is how online surfing used to appear prior to the advent of error-correction. Random noise could suddenly appear in the middle of your test. ..... Well I think I'm done for the day. Goodbye all!
+++
ATH
bio#OP*qe! B89*#()*13!B89*#()*13!B89*#()*13! (click)
CARRIER LOST
Re:When C Strings Attack! Strange replies? (Score:2)
Agreed, it is a shame, the null terminated came in C very late in game when byte counting wasn't too expensive any more. I really don't get the replies of only 256 byte (octet?) max length? Pascal (PL/I, Algol, etc) strings can have up to unlimited length depending on language, computer, etc implementation. Any modern(?), intelligent language should be able to handle a continuous string of bytes (mostly octets but even NLS and other "strings") without any terminator or special API, it's so lame! And it is d
What if they could be sued? (Score:2)
Yes, they are in it to make money, but would they be as careless if they could be sued for any losses due to their negligence? (I am also including MS for all its security flaws.)
What's the alternative? (Score:2)
Perhaps one should use a ';' [xkcd.com] to end strings instead.
Seriously, I would say the problem is not C strings, but the CA *not* using C strings instead. If they properly recognized the null character as a string terminator, they wouldn't issue a certificate for paypal.com to badguy.com.
Re:When C Strings Attack! (Score:5, Interesting)
Java strings!
32bit signed int, max length 2GB.
That ought to be enough for anybody. ;) If you need longer, there's special buffer classes that can go longer.
The string also chooses between ASCII and Unicode when initialized, (you can manually set char encoding, as well) so properly cleaned/trimmed ASCII strings don't waste any memory. (Except for the 3 bytes extra that go into a length int, instead of a null char - but those 3 bytes also give you an amazing speedup when you need to know the length of the string.)
I believe C# implements Strings in a similar way.
Re: (Score:2)
Never mind, the write-up mislead me a bit.
Re: (Score:3)
Um, that's the actual null character, not the backslash character followed by the numeral zero. Your brain was supposed to unescape it. The string contains the actual null character; it was simply escaped for display purposes.
Dan Kaminski, would you STOP ALREADY !! (Score:5, Funny)
Go do something else for a while. If it were not for you we all would be safer !!
Re: (Score:2)
You can read the hacklog here [antilimit.net] along with the one for Kevin Mitnick's hack.
Re: (Score:2)
His computer just got hacked too.
It was their websites that got hacked (first). Not suprising using an external blog/site hosting provider.
So now... (Score:5, Funny)
All we have to do is get the CAs to pay attention to the certs they issue, correct?
Uh-oh. We're screwed.
Re:So now... (Score:5, Insightful)
No, all we have to do is make CA's liable for the certs the issue.
Re: (Score:2)
Re: (Score:3, Interesting)
Isn't that why they charge huge amounts for the certs?
No, I think that's called rampant profiteering. And because competition has driven the price down too low for them (oh no, they can only get away with charging ~50 euros for an automatically-generated chunk of data) they've introduced extended validation certs, where they actually do what they were supposed to be doing in the first place and charge yet more money for it...
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: (Score:3, Informative)
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.
Really? It seems to me that with a centralized system, you have one enti
Re: (Score:3, Informative)
The problem is the same with Moody's, actually: the central issue is that the people doing the auditing are being paid by the people they're auditing. Simply having browser users pay CAs (or investors pay rating agencies) would put the economic incentives in the right place, but that idea doesn't sit well with a lot of people.
So instead, we're left with imperfect and leaky regulation. CAs really
Re: (Score:2)
If you want to subvert that, you have to convince that entity that you are trust worthy. If you have a decentralized system, you could have 1000 entities controlling trust. That's 9999 more chances you have to trick someone.
Yes, and compromising any one entity results in a 1/m damage, where m is the member count. The benefit here is that the number of compromises a person can make in a trust network before discovery (the risk) is exponential, not linear -- that is to say, two people are more than twice as likely to discover the subversion from a single source.
Re: (Score:3, Funny)
Really? It seems to me that with a centralized system, you have one entity controlling trust. If you want to subvert that, you have to convince that entity that you are trust worthy. If you have a decentralized system, you could have 1000 entities controlling trust. That's 9999 more chances you have to trick someone.
Well, one thing I certainly can't trust is Slashdot users' ability to do arithmetic.
Re:And we trust CAs *why* again? (Score:4, Informative)
I'd rather add "Bruce Schneier" to my list of trustees, but your friend "Bruce Schneider" may be okay too.
I'm really not trying to be a smartass. I just want people to get his name right; he deserves it.
Re: (Score:2)
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.
Bruce Schneider, Chiropractor and Cranio-Sacral therapist [drbruceschneider.com]? He does seem pretty trustworthy, I guess.
Re: (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: (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.
Hardly (Score:2)
Web of trust is easy to spoof, provided a certain level of autonomy in the system. All a hacker would have to do is spoof Millions (billions, trillions) of trust relationships making it look like something is highly trusted by lots of people. Suddenly that badbuy.com website looks highly trusted to someone who has never seen it before.
And what happens when geeks gets a hold of the technology and slashdots the web of trust for Microsoft.com as -1 EvilCorp?
Let us assume for a second that both the cases above
it's not all bad (Score:2)
More significantly, an attacker can also register a wildcard domain, such as *\0.badguy.com, which would then give him a certificate that would allow him to masquerade as any site on the internet and intercept communication.
That doesn't sound that bad, does it?
Only as secure as the gate-keeper. (Score:2, Interesting)
The browser is going "Show me that this cert is valid for paypal.com" and the CA is going "Here it is, for paypay.com" , at least as far as the browser is concerned.
This is no more a flaw then if the CA just started letting anyone buy certs for paypal.com.
Having multiple CAs (and cheap CAs) is a good thing, but we're only ever secure with ssl as the least secure CA.
Re: (Score:2)
Having multiple CAs (and cheap CAs) is a good thing, but we're only ever secure with ssl as the least secure CA.
Sort of, but with regards to your personal security it's really just as secure as the least secure CA that is in the trusted list of the browser of your choice. Not that it makes this any better.
I think browsers should start removing CAs who aren't doing human verification..
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
You could argue that but I might argue that NULL in not a valid character in an FQDN. It is by extension not a valid character in the CN attribute of a certificate issued for an FQDN. I have not looked at the code but the cert parser probably decrypts the certificate looks at the length of the string copies that many bytes into some other data structure null character inclusive, as well as everything beyond it just like it should.
Then some other code looks at the data obtained from the SSL cert now stored
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:If we were using pascal strings... (Score:5, Informative)
It's actually rather amusing that people here proclaim Pascal-style strings as the solution to all our woes.
It's because certificates use ASN.1 [wikipedia.org], essentially a modern-day Pascal string, that these vulnerabilities are possible. If certificates instead were encoded using C-style strings, NULLs wouldn't be an issue.
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: (Score:2)
Yeah, I didn't even have to RTFM!
Re: (Score:2)
And by that I meant RTFA. I can't even type a one-liner properly for f\0
Re: (Score:2)
Defense-in-depth (Score:2, Informative)
Yes, the CAs should have clear standards on what they can and cannot issue a certificate for.
However, browser makers need to assume some CAs will issue non-compliant certificates.
They should also assume some compliant certificates will be confusing to end users, whether it is because of a look-alike character, such as 1/l/!, 0/O, or many such UNICODE pairings. This applies not just to certificates but also second-level domains where an authoritative server run by badguy.com might return an address for a do
VeriSign Responds to Black Hat (Score:4, Informative)
gentlemen that reminds me... (Score:4, Interesting)
The trick was that IE stopped parsing the url at the bogus 'e' and went to "passwordedit.info" (my site) while displaying "passwordedit.info.example.com" in the url bar.
My site recorded the new passwords while forwarding the change request to the real site
IE6 was fixed and no press release was made (we are discreet)
domains and URLs have been changed to protect the guilty
Hmmm... (Score:3, Funny)
Or would that be Slashdot's good twin?
Moxie at Black Hat (Score:4, Informative)
Moxie's presentation was very enlightening. Out of all the presentations I saw over the last two days, his was easily the most interesting.
First, he went over his last presentation- that due to CA sloppiness, it is possible for an attacker to issue valid SSL certificates as an intermediary CA. No hack involved.
Second, the null character exploit. This was the bulk of his presentation, and he went into detail why this works, and why Firefox pre-3.5 plus a bunch of other SSL stacks are vulnerable. Dont want to get a cert for every site you want to spoof? Get a wildcard \0 cert.
Third, it is possible to defeat OCSP with the number 3.
Fourth, he demonstrated how, due to these bugs in SSL and OCSP, it is possible to deploy your own "software updates" whenever Firefox or other program attempts to auto-update.
I hope he puts his presentation up sometime soon.
Re:Are CA's that stupid? (Score:5, Insightful)
Re:Are CA's that stupid? (Score:4, Informative)
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: (Score:3, Insightful)
Come over to C++ - we have it all!
Re: (Score:2)
Re: (Score:2)
Re:Are CA's that stupid? (Score:4, Informative)
\0 isn't a legal character in DNS protocol
Say, that's a pretty good idea. Start by limiting the input to DNS-valid characters.
Geez.
For anyone who thinks "Well, I guess there might be some bad CAs out there," please keep in mind that it only requires one of the CAs (or their delegates) that your browser recognizes to make a mistake and you're hosed. Now go look at how many CAs are listed in your browser.
Damnit, it's time to flog this again:
Every time this topic comes around I feel like I should share this thing I've run across:
Perspectives. [cmu.edu]
Basically, "network notaries". Decentralization of (a kind of) authentication.
This is one thing that makes self-signed certs viable for a popular audience.
Re: (Score:2)
Whoa buddy, keep your supersized text on the DL man...
Psst, Editors... someone should fix that code/ability before we have huge
Goatse [shit.everywhere]
Re: (Score:2)
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.
It's called an asciiz string and the CPU has instructions to handle them specifically in many cases. It's a very primitive data structure.
Re: (Score:2)
If it's not allowed in DNS protocol (which wouldn't surprise me, unless punicode-escaped), then primarily, it is the client's job to defend against it. Even if all legitimate DNS information sources are checked, the client shouldn't assume that the next DNS request will go to or be replied to from a real server.
Re: (Score:2)
Re: (Score:2)
If it's not allowed in DNS protocol (which wouldn't surprise me, unless punicode-escaped), then primarily, it is the client's job to defend against it. Even if all legitimate DNS information sources are checked, the client shouldn't assume that the next DNS request will go to or be replied to from a real server.
The problem is - how would Firefox or someone other client-side check that the cert is invalid in that sense since you check then length and will get the length reported based on the null terminator. Now if the cert had something in it to tell you, then that could provide a method of checking, but I doubt it has something of that nature in there; and this would not be a simple thing to do on the client side (e.g. Firefox, IE, Opera, etc.)
Honest, this goes to show the CA's software is broken - it should
Re: (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 want
Re:Are CA's that stupid? (Score:5, Insightful)
Re: (Score:2)
Re: (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?
Re: (Score:2)
Re: (Score:2)
Ah, yeah, I guess you're right. Misleading article :/
Re: (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: (Score:2)
Re: (Score:2)
Pascal vs. C: Round 2 (Score:2)
A debate older than time_t ?
Re: (Score:2)
His name should not be that fscking hard to find, if you care about that, the SSL related code is open source.
Re: (Score:2)
That won't be someone in the SSL related code I guess. It's more like a language/library problem.
Re: (Score:2)
Re: (Score:2)
Who's the fscking idiot who thought having \0 indicate end-of-string was a good idea??!!?
I'm honestly curious, since I don't know enough about the problem to do more than ask questions: don't you need an end-of-string indicator of some type? Wouldn't any other end-of-string indicator do exactly the same thing? In other words, isn't this about the (bad) assumptions being made by the browser's URL parser, rather than about the inherent evil of a specific end-of-string delimiter?
Re: (Score:2)
don't you need an end-of-string indicator of some type?
Nope. The alternative would be to carry around the length at the start of the string. This would be known as a Pascal-style string (in contrast to what we're discussing here, which is a C-style string).
Re: (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
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.
Re: (Score:2)
Absolutely true. However, it does make a statement about the validness for using such a language today, especially for security related applications. How long should we keep such languages and libraries around?
Re: (Score:2)
More likely, it was chosen because of the storage saving, and because there was not a risk of hackers trying to cause strings to misbehave by passing null characters in the wrong places. C and Unix were originally used in environments where people were not trying
Re: (Score:2)
Also, with C strings, you don't need to worry about counter overflows, and you can safely operate on a string when you don't have its beginning. (Consider strtokThe real "idiot" move was taking the same hunks of code from the age where everyone could trust each other, and trying to use it in an age where some people cannot be trusted.
Rewriting everything from scratch didn't seem to work too well for MULTICS people, the Hurd people, the Plan 9 people, and so on.
Re: (Score:2)
Somebody, a long time ago, (in a galaxy very, very close) realized that (a) you could have longer strings with less overhead and (b) sometimes you're reading streaming input and don't know ahead of time where the data will end. Having null-terminated strings was very useful when CPU cycles were expensive, registers were expensive, and buffered data was expensive.
The better question is "Who's the fscking idiot who would use a null-terminator, (on a short string, no less,) in a situation where security is pa
Re: (Score:2)
Are programmers today, the ones we trust with our global information infrastructure, this really lazy/stupid/careless?
Re: (Score:2)
bool evil_string_p(const char* s, size_t n) { return memchr(s, 0, n); }
Re: (Score:2)
Who's the fscking idiot who thought having \0 indicate end-of-string was a good idea?
Dennis Ritchie [wikipedia.org], actually. Have you won a Turing award lately?
Anyway, as to the substance, you'd prefer maybe we keep the length of a string in a byte character unsigned integer... (wait, is that big enough?) instead, then update it every time we change the length of the string at all? There's trade-offs [joelonsoftware.com] for every design decision. This wasn't a stellar one, and brilliant people make mistakes, and fail to accurately predict the future. But really, I am highly skeptical that you have the standing to go th
Re: (Score:2)
Meh, with the number of bytes we have lying around on the computer: just make it 64 bits. If anybody ever creates a string of 18446744073709551616 characters or higher, we'll give him a cookie. You could also use variable length encoding such as DER. In that case you can go up to a number that is much higher than 2^128 you run out of particles in the universe pretty quickly. DER uses one byte encoding up to 7Fh. After that you get 8180h, up to 81FFh, then you get 820100h up to 82FFFF up to FExx where xx is
Re: (Score:2)
And that's a holdover from CP/M days.
Re: (Score:2)
It's a shame that the Microsoft BSTR didn't become the dominant form of string, then these problems wouldn't be occurring.
Is the Microsoft BSTR anything like the Microsoft BSOD?
Re: (Score:2)
I thought BSTR was short for "bastard"
Re: (Score:2)
It's a shame that pearl necklaces didn't become the dominant form of string... oh, never mind.
Re: (Score:3, Informative)
It's a shame that the Microsoft BSTR didn't become the dominant form of string, then these problems wouldn't be occurring.
A Microsoft BSTR is simply a length-prefixed string, which are themselves older than Microsoft.
Re: (Score:2)
Other languages have different vulnerabilities [slashdot.org]. There's no substitute for a brain behind the keyboard when writing software that's supposed to be secure.
Besides, Mozilla-family browsers are mostly written in Javascript, whereas Webkit is a C++ package. Yet somehow kids here consider Webkit interesting and cool, and Mozilla obsolete garbage. I happen to disagree.