Slashdot Mirror
Null Character Hack Allows SSL Spoofing
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.'"
\0\0ps.
Give me Classic Slashdot or give me death!
Would a CA really grant a certificate for paypal\0.badguy.com ?
If not, the CA should not have issued the cert in the first place. Which CA was it?
Go green: turn off your refrigerator.
*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.
TODO: Something witty here...
Go do something else for a while. If it were not for you we all would be safer !!
All we have to do is get the CAs to pay attention to the certs they issue, correct?
Uh-oh. We're screwed.
A thousand pounds of wood moving at 300 feet per minute. Don't get in the way.
It's a shame that the Microsoft BSTR didn't become the dominant form of string, then these problems wouldn't be occurring.
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.
#fuckbeta #iamslashdot #dicemustdie
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?
This guy's the limit!
And a better idea is.... \1? It's called a standard. What about any optimized language, are huge overheads really better? Or am I missing something?
This isn't really a browser issue.
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.
I put on my robe and wizard hat..
Well, if the CA software respected the null as the end of the string, they wouldn't have issues the certificate to badguy.com. They would've just seen badguy.com attempting to get a certificate for PayPal.com.
A debate older than time_t ?
Who's the fscking idiot who thought having \0 indicate end-of-string..
His name should not be that fscking hard to find, if you care about that, the SSL related code is open source.
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?
Nostalgia's not what it used to be.
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.
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).
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 paramount, and not even bother to check for poisoned nulls??!!?"
How can I believe you when you tell me what I don't want to hear?
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.
the alternative is to store (and maintain) the length of the string.
Do you even lift?
These aren't the 'roids you're looking for.
Other languages have different vulnerabilities. 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.
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 dangerous - my hair is gray fixing programs where the null was overwritten for some reason or where the scanning, input, whatever was depend on some such terminator instead of hardware termination based on length, signal, memory boundary, memory protection, etc.
Back to the topic, CAs are in business for money, not to make things more secure or so. That's mostly the problem in computing today, you think that security certificates, PCI, even most of other regulations, etc are there to enhance security and I have a bridge to sell. They are there to make money, sell a product, shift the blame, whatever but definitely not for security which is much, much more than just some technology.
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.
Swedish plasma phys. PhD student; MSc EE; knows maths, programming, electronics; finance interest; seeks opportunities
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 repeated 7Fh times.
Note that this is a C/C++ construct that has been - uh - deprecated by languages like pascal ages ago. Nobody says that a 00h character has to end a string, and you can do much better than that. Truly, I've seen many issues with 0 terminated strings in the last 8 years - many of them in important libraries. 0 terminated strings suck. Control characters without any textual meaning suck. Get rid of them.
That won't be someone in the SSL related code I guess. It's more like a language/library problem.
Perhaps one should use a ';' 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.
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?
Yes; the PASCAL style, which have the added benefit of very efficient length checking. The only downside is that strings longer than 256 chars would have to use more than one byte for storing length; all of the other advantages are maintained.
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 to attack each other, and security systems were in place just to prevent common user errors from destroying others' work. The 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.
Palm trees and 8
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.
And that's a holdover from CP/M days.
I claim first use of "Error No. 0B" - or "No. 0B error." It'll be the new ID 10T!
I don't get it.
Isn't this just the same company?
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
Where is the line or two of code that would check the entire URL for validity, ie no bullsh\1t characters and proper structure? This to me is a nobrainer.
Are programmers today, the ones we trust with our global information infrastructure, this really lazy/stupid/careless?
After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
Who's the fscking idiot who thought having \0 indicate end-of-string was a good idea?
Dennis Ritchie, 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 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 throwing "fscking idiot" around at the way that things are implemented in what's essentially the closest thing a to a lingua franca in programming.
Freedom isn't free; its price is the well-being of others.
#include <stdbool.h>
bool evil_string_p(const char* s, size_t n) { return memchr(s, 0, n); }
This is not language related problem. Having a C string doesn't stop you to proper check it or handle it safely.
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 actually occur in a web of trust, how would we correct it? Manual Override? Do you really trust your users to manually override this web of trust?
So now badguy.com is properly untrusted, but now your user can manually override that trust level. Now what?
Sorry, I don't want a web of trust, because it is too hard to correct a false positive, or false negative. It would need manual override of the trust relationships to fix broken trusts results and other, who knows what, problems.
See my sig, it kind of explains things.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
It doesn't really matter, they'd probably still issue it.
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 domain that uses characters that are supposedly illegal.
In any case, web browsers need to flag these things and make it obvious the address or certificate isn't what it appears to be.
Finally, end-user need to be educated that login.paypal.com is not the same as login.paypal.com\0.badsite.com or !ogin.paypa!.com or 1ogin.paypa1.com.
Somehow I think the latter may be a lost cause with some people.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.)
>>>Who's the fscking idiot who thought having \0 indicate end-of-string was a good idea??!!?
That was an excellent way to save space in an era when computers only had ~0.004 megabytes of RAM, and ~0.07 megabytes of disk storage. Sure today we can afford to waste space on exotic byte-counting routines, but back then such luxuries were not possible. The NULL method to end a string was nice & compact.
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
Actually, Unix was a rewrite from scratch (of Multics but simpler), as was C (of B but more expressive), and Multics did see some use once it was completed, mostly in mainframes and systems that required a high degree of reliability. Hurd did not fail so horribly because it was a rewrite, it failed because something else came along sooner (Linux), which itself had been written from scratch. Plan 9 was intended to be a research system for exploring new concepts.
The point still remains: it was a poorly planned move to take code that was designed for environments where everyone could be trusted, and use it in an environment where that was not the case. Worse still was using a system based on combining various other systems, each of which had different security goals, for things like banking and other security-sensitive applications -- e.g. what we did with the Internet. The move to e-commerce over the Web happened too quickly and with too little planning, and was built on marketing hype from software companies and consultants.
Palm trees and 8
The rendering and networking side of Mozilla browsers are most definitely C++. The JavaScript bit is the user interface side.
I'm l\0\0king forward to using the new slashd\0t \0wnzrd meme. (I've never witnessed the birth of a meme before, wow!).
After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
Do you have a citation for that? As I recall, C copied its string handling (or, rather, lack of string handling) directly from BCPL. Arguments to authority are bad enough, but they're even worse when the authority in question isn't even relevant.
I am TheRaven on Soylent News
Tim Callan, vice president of product marketing at VeriSign, responds (in more detail) to these Black Hat presentations in his new SSL blogpost: https://blogs.verisign.com/ssl-blog/2009/07/busy_day_at_black_hat.php He fills some of the holes that Marlinspike and Kaminsky dug.
Besides, Mozilla-family browsers are mostly written in Javascript, whereas Webkit is a C++ package
Apples to oranges. Compare Safari (mostly Objective-C) to a Mozilla-family browser, or compare WebKit (mostly C++) to Gecko (also mostly C++). There's nothing stopping you from writing a browser in JavaScript on top of WebKit, just as there is nothing stopping you from writing a Gecko browser in C (this has been done).
Yet somehow kids here consider Webkit interesting and cool, and Mozilla obsolete garbage. I happen to disagree
No, most people consider Gecko to be crufty, barely-maintainable, code and WebKit to be much cleaner. The fact that WebKit was created largely because Dave Hyatt, a Gecko developer, felt the same way when he was hired to write a new browser, lends some weight to this belief.
I am TheRaven on Soylent News
Firefox 3.5 is _not_ vulnerable to this attack.
Yes. The browser is a fault for treating an ASN.1 string as a null terminated string.
The CA is at fault for issuing a certificate for a domain that does not exist, and in fact is not even legal under the domain name system.
(Yes the second level domain does exist, but the company would not sell me a cert for some non-existant second level domain merely because the .com TLD exists.)
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
Which brings up a question I've been wondering about for awhile: How much really old crap from the 70s and 80s is till "brewing in the bowels" of modern OSes? I'm mean it wasn't but a few years ago that MSFT was hit with the "wmf flaw" which was going back to Win3.xx, and I'm sure that Linux probably has some seriously old code lying around in there somewhere since it is over a decade and a half old, and shares much in common with ancient Unix.
So how much really old code is brewing in our modern OSes? I remember looking at the Win2K source and being amazed at how they had code with comments like "HACK- not really sure what this does, but when removed causes data corruption in every version of Office from V6 on up. Do NOT touch!" and while I haven't torn into the source code for Linux, it wouldn't surprise me if some of the older libraries had something similar. So how much from our "dinosaur days" of early computing is still floating around the guts of the major three OSes (Linux, OSX, Windows) anyway?
ACs don't waste your time replying, your posts are never seen by me.
Do you have a citation for that? As I recall, C copied its string handling (or, rather, lack of string handling) directly from BCPL.
OP wondered "who thought having \0 indicate end-of-string was a good idea" -- not who did it first. I don't know that Ritchie invented it, but he certainly thought it a good enough idea to use it in the new language he was developing.
Arguments to authority are bad enough...
Okay then, how about "there must be some reason that programmers have kept using it for 40+ years?" Ah, appeal to history, can't have that either... Look, I'm not arguing that null-terminated strings are a brilliant idea that should be preserved in gold as though handed down by the gods themselves. Just that it's entirely possible that there's some reason that the idea wasn't immediately cast on a scrap-heap, and that the OP should consider that prospect before claiming that the very many programmers who have used and endorsed it were a lot of gibbering clowns.
Argument to authority or history don't prove merit, but they are strongly suggestive of the possibility of merit--that the idea deserves well-thought-out criticism rather than outright dismissal.
Freedom isn't free; its price is the well-being of others.
BCPL used counted strings. That's what my memory says, and I can check The Book in a flash.
(flash)
"By convention, byte 0 contains the numbers of characters in the string, which are stored consecutively from byte 1." (p. 50, BCPL - tlaic)
You know, Java has counted strings, and they use 32 whole bits for the length. Not fully general, but large enough for most domain names. In Java proper (not its native libraries, sigh), there's also no issues with buffer overrun.
you can safely operate on a string when you don't have its beginning.
This is a serious benefit for certain applications - a Pascal-style string would require you to copy substrings in order to use them (so it could maintain the length), whereas a C-style string lets you use an arbitrary pointer.
A C program that processes text files (e.g. logfiles) into some other format (e.g. csv files) would probably run much faster in C than in Pascal, if the C program is allowed to take advantage of the aforementioned benefit.
How does nul terminated strings help in case b? You have to allocate memory in both cases anyway and keeping track of a pointer to the length store isn't hard.
nul terminated strings are simple and efficient. They also require more effort on the part of the client code. Which is the C way.
...mostly.
Verisign (& presumably the rest of their group - Thawte, Geotrust) and Comodo didn't issue it - their systems never allowed null characters in subjects.
Some evidence so far (as this isn't the first time it's come up, just the first to be published like this and as with so much at Blackhat, sensationalised) points to Globalsign as the issuing CA, although I'd be surprised if they hadn't fixed it by now.
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.
Because Pascal strings stored the length in a single byte and that single byte could only represent an unsigned integer up to 2^8 - 1 or 255. Hence the comments about pascal strings and 255 character lengths.
Unfortunately, C strings do not support easy, efficient string concatenation.
First of all, if I want to put string Y at the end of string X, I need to figure out where string X ends. Since I don't know the length of X, I have to inspect every single byte of it (possibly waiting for it to be paged in from disk) until I find the end. Of course there's no guarantee that there is a null character within the region allocated for X, so I have to accept the possibility that the pointer will wrap around past the end of my address space or hit an unallocated part of virtual memory (throwing an exception/signal). In fact, a naive strlen implementation could be an infinite loop!
Then I have to make sure that the string Y doesn't overlap X. This means that a naive strcat implementation could also be an infinite loop! After that, I have to copy each byte of Y individually to the end of X. I can't ever operate on more than one byte at a time because I can't expect to read past the first null byte I see (that could cause a page fault).
Another option is to find the length of Y in order to know how many bytes to copy before the null char is wiped out, which means inspecting every byte to find the null.
Once I have the length of X and Y I can perform an easy, efficient memory copy, which presumably copies whole words (4 or 8 bytes) at a time rather than individual bytes. If the lengths were stored with the strings, the memory copy could be done immediately and then the only additional work would be to add the length of Y to the length of X.
of the day I found a similar exploit in IE6. During a pentest I noticed that a company had a password reset site with a url like "passwordedit.info.example.com" so I regestered "passwordedit.info" and sent e-mails to some employees saying "your password will soon expire, please go to passwordedit.info.example.com and change it". However the 'e' in "example" was a Unicode character thet looked/displayed like ASCII 'e' but was not.
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
The problem with that is that you're now limiting the maximum length of your string to whatever the witdth of the number at the beginning is.
Don't be ridiculous. It's trivial to implement Pascal strings that have all but arbitrary length. Just start the string with a length-of-length indicator, followed by a series of bytes which indicate the length in some encoding, followed by the string data itself. Or is 2048 bits of length not enough for you? :)
Of course, there's overhead, and it's complicated. I'm not saying it's a good idea. I'm just saying that an end-of-string marker is *not* required to implement strings.
The solution here isn't to switch all certificate reading code over to Pascal-style strings
But this I violently disagree with. While I don't advocate Pascal-style strings in general, no encoded data structure should use C-style strings. They should either use length indicators (2 or 4 bytes would be more than enough in this case), or fixed width fields. But C-style strings is a stupid *stupid* idea.
That said, I have no idea if that's what the spec *actually* requires. The spec may very well define strings as I've described above, but the implementations are simply b0rked.
Just think about it, knowing the size beforehand is a _huge_ advantage.
Remember people that put strlen() inside a 'for'? Stupid in C, in Pascal it's constant time (and very fast)
how long until
If you're passing substrings around, you most likely know the size anyway, and if you're doing read-only stuff you don't want the overhead of a string copy.
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.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Who's the fscking idiot who thought having \0 indicate end-of-string was a good idea??!!?
My guess would be either Brian Kernighan or Dennis Ritchie.
Neither of which I'd characterise as 'an idiot' though they probably thought of the C programming language as a gigantic practical joke at the time...
http://www.elsop.com/wrc/humor/unixhoax.htm
In the free world the media isn't government run; the government is media run.
* allowed for easy, efficient string concatenation
Well, 3 out of 4 ain't bad, right? Null-terminated strings are absolutely the worst for string concatenation. To concat a bunch of strings C-style requires that you get the total length of the strings. strlen is O(n) where n is the length of the string. Next you have to copy the text. strcpy is O(n) of course but strcat is O(n+m) where n is the string being copied and m is the string appended to. The first thing strcat has to do is walk to the end of the first string to find the end. But we've walked that string how many times before? Totally inefficient using the standard library. If strcat and strcpy had been specified to return the end of the string being written to it wouldn't be so bad. But they weren't.
Note that certs can and are used for things other than SSL on DNS names. In fact, the field used for the domain name is "Common Name". The CN field is used for a dozen things depending on what the cert is used for.
We should probably blame Netscape and everyone else who pushed using X.509 unchanged instead of trivially adding a field that required a valid DNS name.
This is a mismatch between the X.509 standard and how browsers use it. Most interesting is that the browsers have the information to correctly parse it, whereas the CAs don't have the information to do so, unless they are only issuing certs for SSL. As someone who would like to see widely usable PKI outside of the web-browser, I'd really rather fix the browsers than break the certs.
I think Mauve has the most RAM. --PHB (Dilbert Comic)
It is good that Verisign have taken steps in their own baliwick to deal with illegal characters in their certificates, but their practices, including EV Certificates, won't stop other CA's from spoofing anyone's certificate, including Verisign. No holes are filled. This is a system-wide problem that must be fixed at the browser level.
I am not a robot. I am a unicorn.
Yeah, in the same kind of reasoning no cars should ever crash since you should drive safely.
IE6 was fixed and no press release was made (we are discreet) domains and URLs have been changed to protect the guilty
Exactly how does hiding the domains and URLs protect the guilty? We all know who makes IE6. And how can you call yourself discreet while posting the story on Slashdot and naming the guilty party?
Yes, theoretically it is correct as Pascal strings are defined / described. This is an ages old argument but many languages (many "Pascals") have "strings" which have a descriptor or length not limited to 256, the programmer just doesn't have to take care of it. And they have no separate API or whatever for different "strings", mostly they are actually just handled by compiler. The pain of delimiters is bad, have to have another class or whatever to handle strings as continuous memory (the implementation may be whatever as in Haskel, etc.) And especially with Unicode or for example protocol stream it means scanning everything, every time instead of letting hardware to do it's work - great for one (maybe) but when talking thousand and thousands at the same time it eats cpu cycles which, especially in interface controllers, are already used too much.
There are special hardware solutions but they are not very common, computers still (mostly) work on bit level (there are exceptions). The delimiters are bad even other way, what is a delimiter for one class of data is / may not be a delimiter but data in another class of information so transformations can get sometimes tricky if data can not be trusted - most common have been overflows of zero limited strings and/or terminators in protocol strings. Or zero and here and maybe the the non-breaking space in HTML or whatever.
Actually I like C (and assembler) because of the power over code, but it definitely needs more code and more caution to use strings in those languages than in Pascal, PL/I, ADA, and other languages where strings are transparent (not Pascal strings as defined). Many interpreted languages can handle strings without terminator so.. All high level languages should (IMHO) have a class of string which is transparent in compiler, not some ever changing API, proven going from one octet to multiple for Unicode, etc - old (new?) style just doesn't seem to work too well - causes problems as this.
Scan your databases for FQDs for issued certs with the null string. Then revoke them.
Then go after the people who requested them and ask for an explanation.
Wearing pants should always be optional.
The problem with that is that you're now limiting the maximum length of your string to whatever the witdth of the number at the beginning is.
But the length of strings is limited anyway by the hardware; there's always going to be a maximum size to any addressable array. If the width of the number is of type size_t, that is, large enough to store the size of any possible array on the hardware in question, storing the length of a string with the string doesn't introduce any limit on the string's length.
It does make a statement about the validness for using such a language today
The odd thing is that Firefox is written in C++, and C++ strings aren't NULL terminated, they store the string length alongside the string. I wonder why Firefox is using C strings when it doesn't need to.
I haven't gone and looked at the code, but a program like Firefox that's written in C++ shouldn't be vulnerable to this - C++ strings are not NULL terminated, so shouldn't be vulnerable to this exploit. Either the Firefox developers are using C strings, which they shouldn't do, or they're incorrectly constructing their C++ strings.
Would this mean that there's a similar site out there called Slashnaught.org?
Or would that be Slashdot's good twin?
If you can read this, I forgot to post anonymously.
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.
[q]using contact information from Whois records, sends him an email asking to confirm his ownership of the site.[/q]
I've requested several SSL certificates over the years. Never ever have I received such an email to confirm ownership, nor was I pre-confirmed as the domains were registered elsewhere. Okay, so the CA was not netsol or thawte. But it sure was a CA that was acknowledged by both MSIE6/MSIE7/MSIE8/FF2/FF3
I don't see a reason why my CA wouldn't simply hand me a valid cert for paypal.com, no technical stuff, anyone can do this. Okay, my cert would probably be revoked as soon as someone finds out, but by then the damage could be millions...
.sig: No such file or directory
No certificate should have been issued for an invalid domain name (NUL characters are not permitted in DNS identifiers).
Yes they are. Please see my previous comment on this subject.
I'll have to look into the code for that, but having done a bit of C++ work myself, libraries are the main reason why you do this. Current applications are starting to be very large collections of libraries plus some control logic and possibly a GUI. This means that your libraries need to be secure as well and that the interface to those libraries should be consistent. Generally, you can't say that for C++ applications since they tend to use C-libraries. It's very nice to have boost and other "standardized" C++ libraries, but their usefulness is limited by having to use C, MFC libraries and the Windows API. I've had to juggle between char*, wchar*, basic_string templates and - eh - CString (I'm trying to forget) quite often.
Because the base types used in Java are pretty well defined, and since Java byte-code cannot modify things that should not be modified, Java is suffering less from this problem. Then again, Java programmers seem to be less aware of using e.g. byte[] access and the vulnerabilities of the JVM may be hard to deal with. Java also lacks some const constructs - Java 7 might alleviate that a bit. But I still think the situation for managed languages with well defined API's is much better in this respect.
And I presume that there is quite a bit of legacy code in Firefox as well, which may make all the difference.
PS please replace Java by Python or C# at your leisure, I'm drawing from experience here.
"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."
Here's what happened : Moxie Marlinspike found this and sent his boss a message through his website, but the problem was, Mr. Kaminsky had tried his DNS poisoning on that website and all the traffic went through Kaminsky. Kaminsky afterward declared that he had found a way to do it :)
:)
Of-course I'm j/k but Dan is a genius and can do it
Read and Comment at my BLOG
!!!
Agreed, it is a shame, the null terminated came in C very late in game
C doesn't implement strings. All implementations of C that I know of implement libraries that make it possible to use strings in C.
But there's nothing to stop you from linking to your own library.
have fun trying to register a real domain name with a : / or " in it. It simply cannot be done.
there is a protocol layer and there are limitations placed by ICANN on your TLD.
Yes, but you can put whatever you want in your subdomains, which is what this attack was based on, without having to follow ICANN's rules.
I think we have a terminology issue here. NUL characters are indeed permitted in DNS "labels", one element of a DNS identifier, but the CA is issuing certificates for not just DNS labels but actual Internet (ARPANET) hostnames. As described in RFC 1035, Internet hostnames are further constrained to "start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen." No NUL characters are permitted.
I would also like to note that, as the hostname listed in the certificate is invalid, the CA cannot have properly verified, even minimally, that the recipient actually owned the hostname in question.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
The expression "sizeof(string)" will give you either the size of the pointer type on your platform (if string is a char*) or the size of the array allocated to hold the string, regardless of the amount of space actually used. Neither would be very helpful. Also, assert() statements are no-ops outside of development builds and thus not suitable for this sort of runtime test.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat