Can we get the same without the "agenda-pushing attentionwhore" part, please?
OK, so what we have is a clever exploit taking advantage of the (flawed) way some apps (but not all, and notably not Firefox) handles certificates. What the fracking frack does DNNSEC have to fracking do with that? That's ridiculous agenda-pushing, from someone unable to secure his own domain, after having predicted the end of the world (repeteadly, on such ridiculously evident non-issues as the conficker update) to no avail. I believe the word is "attentionwhore".
Hey, some apps are unable to handle certs correctly, we should overhaul the current system and roll it into some measures which would prevent dark-skinned people from flying with more than 100 mL of fluid? That ought to solve it. Shirley. I mean, fixing the apps so that they correctly handle the certificates doesn't make sense. Or does it?
Sortcuts removed etc...
Once again, Firefox's complete superiority is affirmed.
>> What the fracking frack does DNNSEC have to fracking do with that?
DNSSEC has a lot to do with this, if DNS addresses are authenticated (well signed) it means some of these silly man-in-the-middle attacks would be harder to pull off. Well, at least until someone works out how to spoof that too!
I like C, but sometimes I think there might be a way of terminating a string that is less liable to cause errors...
and stop calling me Shirley!
@Allan George Dyer,
The problem is not C, and has little to do with string terminators. It has everything to do with an application not validating its inputs properly. It seems to me that the reason he added the null terminator after the asterisk is probably because the input validator would not accept a single asterisk as input (good), but would happily hand off a truncated string that "seems" to be the correct length (bad).
The root cause here is a discrepancy between how the end application interprets valid input, and how the validator accepts it. This is called "command injection", and it's easy to avoid by, hum, validating input properly.
Of course, the browser expects that certificates from an issuing authority are already valid, such is the nature of the system (being an "authority" and all). Therefore, putting the browsers at fault is also disingenious. Sure, clients can double-check just in case (as apparently Firefox does), and so they should; but at the end of the day, if you can't trust a Certificate Authority, how much of an "authority" is it?
Nice bug, but not a long term problem
Congrats to the researchers. It's a wonderful bug -- the sort of thing that will appear in text books for years to come -- and if you are running any of the afflicted SSL clients then I dare say it is *really* bad. But in a month or two it will be history. (These are counted strings, so replace strcmp with memcmp, recompile and redistribute.)
Can't these hacker tossers inform the relevant people of these security vulnerabilities without all this attention-whoring, dick-waving, 733t haxxor "hacker conference" bullsh!t? He's just explained to half the world how to break the internet's most widely-used security protocol, and one that lets me by DVDs from Play.com safely and securely.
I can't believe...
that no-one's commented on the bloke's name yet. Moxie Marlinspike? Jeez.
Gotta wonder if the rest of the family are named after Swiss Army Knife accessories too. Carl Corkscrew? Terence Tinopener? Fred Frigginguselesslittleblade? Timmy Toolforgettingstonesoutofhorseshooves? (Or, of course, Philip Screwdriver.)
OK, sure, maybe it's an assumed name for the purposes of his research, so that the black hats don't come and get him in the night. But if you're choosing an alias, wouldn't you go for something good? I mean, Moxie Marlinspike? Jeez.
An adventurer is not you.
> he listed the site as *\0.thoughtcrime.org
An exploit worthy of Bobby Drop Table's mother.
RE: How bad is this?
The real danger is that someone can perform a man-in-the-middle attack and see all the information being transferred on a connection that for all purposes looks correct and secure.
This will be a relatively short term issue as all the major CAs will now go through their registrations and revoke all the certificates that exploit this. Although a few years down the road someone will be able to pull this off on a CA that isn't paying attention.
Re: Nice bug, but not a long term problem
“… (These are counted strings, so replace strcmp with memcmp, recompile and redistribute.)”
Actually, no, you wouldn't be using strcmp at all when comparing against a wildcarded string. You would, however, check that the actual length is correct (strlen(domain) == domain_length or memchr(domain, 0, domain_length) == NULL) and that the last two or three components (as appropriate) are not wildcarded.
¨DNSSEC has a lot to do with this, if DNS addresses are authenticated (well signed) it means some of these silly man-in-the-middle attacks would be harder to pull off. Well, at least until someone works out how to spoof that too!¨
So you´ve got apps that don´t handle certificates correctly, creating a security hole... that you intend to plug by implementing a whole new layer which sole result will be to throw more certificates at the same, flawed apps? How does that work, exactly? Surely that´s the most bothersome, inefficient and guaranteed-to-fail approach ever. Unless I´m missing something obvious, it sounds like ¨hey, there´s smoke coming from my car, I´ll fix the fire risk by dousing it in petrol! And if it doesn´t work, I´ll use more petrol!¨