No, this attack is much worse than my home router exploits (which, admittedly, aren't getting fixed anytime soon). While it is indeed nice to have compromised firmware living somewhere on your LAN, being able to generically attack everyone using a given ISP is a much more valuable proposition -- especially when I don't need to worry about the pesky paranoid people changing their router passwords, or even using a router I haven't built a script to attack.
I'm being very circumspect about implications. August 6th will be an interesting day.
It's funny you mention the iptables auto-block. There's been a known attack here for years -- spoof the root servers attacking you, and...yeah.
That being said, we agree on the ultimate fix...run yum update, and be done.
I'm serious. They really, truly, have no idea. They pay a bunch of people to do various things, and at various levels of influence correct errors, but that is not the same as knowing why they work.
Think of rogue employees damaging everything on their way out as shark attacks: There are people who are truly terrified of sharks, and indeed, it does suck to get bitten by them. It's not exactly common, however. But think of loss of institutional knowledge and goodwill as a car accident: Huge loss of time, potentially enough damage that experts (mechanics / consultants) need to be brought in, but common, manageable, and often someone else's problem.
It doesn't really work that way, but by then it's too late.
find -- you're sweeping the file system and comparing against rules. Maybe IO-driven CPU, at best. tar -- You're appending a couple headers. No work. compress -- OK, here there's a CPU bound. remote-execute remote-copy -- Throwing stuff onto the network and pulling it off. uncompress -- OK, more CPU bound. untar -- Now you're adding files to the file system, but only as fast as the network can give them to you. No work here either, really.
So, in your example, you have two CPU bound processes. Interestingly, the problem itself is a network copy, which conveniently always has two processes. About the only improvement an extra core would add, then, is maybe find going a little faster.
Parallelize the compressors and decompressors, now, and you're onto something.
If the attacker (the ISP!) is willing to replace NXDOMAIN, why not replace any name that isn't www? Or any name that returns a fixed 302? The precedent must be set.
I think it's an accident. It's actually tricky to differentiate nonexistent subdomains vs. unregistered domains; what's on the wire is the same, it's just which name server tells you something. See www.publicsuffix.org to see how hard this problem is.
I'm pretty optimistic that, now that the issue's been identified, everyone will stop violating trademarks.
And this is what I sent (many, many) affected sites:
IOActive Security Pre-advisory: Non-Neutral Major ISP Behavior Injecting Security Vulnerabilities Into Entire Web Dan Kaminsky, Director of Penetration Testing, IOActive Inc. Jason Larsen, Senior Security Researcher, IOActive Inc.
Executive Summary: A number of major broadband ISP's have deployed advertising servers that impersonate, via DNS, hostnames within your trademarked domain. We have determined that these injected servers are, in fact, vulnerable to Cross-Site Scripting attacks. Since these servers are being injected into your trademarked domains, their vulnerability can be used to attack your users and your sites. Due to recent activity by Network Solutions, we believe this vulnerability will be discovered shortly, and we will thus be unveiling this matter on Saturday, April 19th, at the Seattle Toorcon security conference. We believe that the security hole is reasonably straightforward to fix, either by temporarily disabling the advertising server, or by resolving the error condition that allows Cross-Site Scripting. We are contacting the affected ISP's to address at least the security issue in play. The fundamental trademark violation issue is outside our scope, however, we encourage you to pay close attention to this case, as the fundamental design of these advertising systems requires direct impersonation of your protected marks.
Details: We would prefer to keep the names and mechanisms required for this vulnerability under wraps, at least for the next few days, while the ISP's in question manage and mitigate the security implications of this behavior. We can confirm the following attacks have been verified to work against your site, via this XSS vulnerability:
A) Arbitrary cookie retrieval. Any web page on the Internet can retrieve all non-HTTP-only cookies from your domains. B) Fake site injection. A victim can be directed to "server2.www.realsite.com" or "server3.www.realsite.com", which will appear to be a host in your domain. We believe any phishing attempts from this perfect-address spoofed subdomain are more likely to be successful. C) Full page compromise. A victim can be directed to your actual HTTP site, with all logged in credentials, and our attack page will still be able to fully manipulate the target site as if we ourselves were the victim. Note, while we cannot attack HTTPS resources, we can prevent upgrade from HTTP to HTTPS. This may affect any shopping carts within your sites.
We believe this behavior is illustrative of the risks of violating Network Neutrality. Indeed, it is our sense that the HTTP web becomes insecurable if man-in-the-middle attacks are monetized by providers -- if we don't know what bits are going to reach the client, how can we control for flaws in those bits?
We do not believe the vulnerability is intentional, only the injection. We were partially involved in the discovery of the Sony Rootkit some time ago; we recognize this pattern. That case resolved itself reasonably, and we are hopeful this one can be managed well as well. If your technical, press, or legal staff has any comments on this matter, please feel free to contact us at dan.kaminsky@ioactive.com. This is a matter that strikes at the core of the viability of HTTP as a medium for business, and we are committed to defending this medium for your operations. Thank you!
OK, so, since DiMaggio had his 56 game streak 60 years ago, what are the odds (by their measurement) of a 55 game streak occuring some time between now and then?
Almost guaranteed, by their method.
What is the likelihood that we'd see no such streaks?
Almost none by their method.
Did we see any such streaks? No, no we didn't.
Pretty fatal flaw.
Something says their probability calculations were probably a bit off. There are two things they're not taking into account: First, as has been mentioned elsewhere, baseball is not a one-shot game. Things happen as a streak picks up, and you necessarily end up with less and less data about what those things are as a streak progresses (since you have fewer and fewer samples of behavior on a 20-game streak, a 30 game streak, and so on). The game changes, the players change, the pitches change.
Second, players, pitchers, and the game itself have changed over the last 60 years. One reason we may not be seeing DiMaggio's records hit again, is that the skill levels are just so rarified.
Took a look at some servers I monitor. Indeed, 25% IE6, 40% IE7, 35% Gecko. Interesting -- I'd not realized the IE7 push had gone so well, or that Firefox's penetration was so high.
You prove his point quite beautifully, retrieving non-DRM'd HTML from www.pcmag.com that suspiciously looks exactly like non-photocopy-protected text from a paper magazine.
People code their web pages to IE6, because that's what the vast majority of the userbase has. Now, enough of the userbase uses Firefox, such that it's worth testing and making sure rendering is reasonable enough there. But, seriously. People build to IE.
Now, this is not great. We should have consistent behavior, and follow superior engineering guidelines as realized through the standards process. People should be building not just to the De Facto standard of IE6, people should instead be building to the specifications made after the fact.
Note, by the way, the entire web is back-standardized, like (as far as I can tell) all good standards. First, build something that works, then remark on what makes things work. This is as opposed to the other way, which is to make a standard and hope it's useful.
So, here's the problem: You've got millions of pages built one way (to the browser), but this is a total pain for devs, who'd very much rather build them the other way (to the refined specification). What to do?
One model is to have the devs identify themselves. That's the tag that's been brought up.
The other model is to bring pain to all the devs who know nothing about the formal specifications, to silently but noticably break their sites. This seems very nice to those who are pissed at those devs for writing non-standards compliant code. It increases the cost in the future of such behavior occurring. Seems like a great idea, right?
In the real world, you don't really get to do that to your customers. Say what you will about Adobe, a Flash file will render the same no matter what, on all Flash players, ever. If the effect of the standardization process is that your code may silently explode in 18 months, forget standards, go for something that would never threaten you with that.
Is that what you want? No? Then relax, and realize that destructive migration paths do more damage to standards than anything else could.
Encryption is hard, because key management is hard. Instead of sending one file, you have to send two, through totally different channels.
Well, "have to" is relative. A huge amount of the time you see "encryption", the decryption key is right there next to it. But, you see, the data is encrypted. So it's safe.
"All it requires is a screwdriver"...which you're not allowed to take on planes. Also, what's the warranty implications of popping the box?
If you'll all forgive the snark, here's my impression of a Mac user trying to present at a conference:
"Does anyone have a DVI to VGA adapter? Anyone? Anyone?...please?"
Whatever should have happened (projectors w/ DVI ports, Mac users who don't forget their dongles), what does happen is pretty damning. It's pretty damaging to the brand, from a business side.
I'd agree, except it's much easier to find CD's than it is to find Vinyl. There's a selection effect on the publisher, because it's so much more expensive to print vinyl and because they may have to expect DJ's to want to spin it live. There's also a selection effect on the consumer, who has to find the records.
Look, the kid's trying to differentiate himself, by his astonishing music collection. Good or bad, people are genuinely astonished that some 15 year old has a thousand records. Mission accomplished.
Not all bits are created equal. I can sit here with a random number generator for a thousand years, and never get anything that even approaches an MP3, let alone music. Bits are easy to acquire, selected bits get harder. "Vinyl" is seen as having more selection invested into it, because you have to actually spend the time to pick which bits you're going to acquire, and can't just get them all overnight.
There are totally people who have huge MP3 collections where every single one is hand-chosen. There are also people who just grab absolutely everything they can and throw it into the pile. The deal with Vinyl is that the latter is pricey, and thus rare.
I don't think geeks get to tell anyone why they are or aren't cool. We've got some pretty weird things to be excited about (*ahem* whether whitespace should delimit code blocks *ahem*).
If someone has a thousand albums on MP3, whatever. It doesn't say anything about them. They spent a night raiding P2P. Big deal.
If someone has a thousand albums on Vinyl, it's a different story. You think something of him. Maybe good, maybe bad, but you can expect him to rather deeply identify himself by his music. Each record was individually chosen, to the exclusion of others. Time was invested, thought was expressed, identity is reflected.
And that, of course, is what not just Vinyl, but the entire shared music experience is really about. Music is more than bits. Music is more than waves of air lapping or pounding at one's eardrums. Music is, or at least can be, about identity. That a fifteen year old kid is desperately trying to assert his should surprise absolutely nobody here.
'compilation CDs that could only exist in the dreams of a music fan'
Now That's What I Call Music! 26 (U.S. series) is a compilation album released November 13, 2007. It also has 4 #1 Hot 100 U.S. Billboard hits. This is also the third NOW! album not to feature a country song. It should also be noted that Nickelback's "Rockstar" is left completely unedited. It sold 208,000 copies in its first week, making it one of the lowest-selling debut weeks of a U.S. Now! CD. However, in the second week the album went up to #3 with 234,000 copies. So far it has sold 442,000 copies in two weeks.
First, we only needed 48 to 64 bit addresses. 128 bits are actually unmanageable. I'm not going to argue it out, as it's an old and painful discussion. Suffice it to say, the real world has shown that raw IP's are used a lot more than people thought.
Second, autoconfiguration has been a nightmare. Addressing depended on DNS, and then DNS was bolted on, poorly. *sighs*
Third, it really should have been partially backwards compatible with IPv4. I know they wanted to build new toys and all that, but the correct approach would have been a standard V4 header, with a V6 extension that added between 16 and 32 bits of endpoints. Core IPv4 routers would have been limited to routing based on only the first four bytes of the IP at best, but that's better than the present 0.
There's more, of course. Too many spherical holy cows involved, and we've suffered for it.
No, I'll stand by my original point. Predicting the behavior of a turing-complete environment is quite literally the halting problem. People keep trying to "prove" software, and let me tell you first hand, it keeps failing miserably. I think you're ignoring the reality that most software transforms external data, meaning unpredictable environmental inputs (even mouse clicks!) are first class citizens.
The problem is that MD5 can only hash the bag of bits available at compile time. It misses the accumulated bits at runtime. This isn't an MD5 bug, it's a bug in the concept that you can sign behavior or predict what software will do.
Signing can only establish behavior. I didn't used to believe that -- I was wrong.
...is that people stop installing the patches at all.
You really only get to screw up a few times, before the risk of broken patches exceeds the risk of getting hit by a non-public vulnerability. Then, people won't install patches, even when the exploit is public!
One real problem is that this entire engineering model is very, very new. The rules of physics do not change, day to day, but what's happening on the Internet transforms remarkably, moment to moment. It really is a war out there, and the bad guys learn quick.
It is important to realize that the web, for all its warts (and I've been findin' em) is a remarkably secure place, given what it really is. It's our first actual success at mobile code. Wrap your mind around that -- it's really terrifying, and yet, we use it every day. Cool!
Still, everyone's got a lot of work to do, and it is indeed unfair to judge Firefox v. IE based on publicly known vulnerabilities alone. The metrics are guaranteed to be skewed -- Mozilla just doesn't have the freedom to test (due to their NDA-less development model) like Microsoft does.
(Disclosure: I've known Window for years, and I consult at Microsoft on security matters.)
I'm pretty sure I talked about third party attestation in that paper.
A more interesting point was made to me just the other day, which is that there's always enough ambient entropy in any real world system to deviate between trusted and untrusted behavior. In other words, for a turing complete app, you *can't* create a meaningful hash, because you aren't capturing all bits that will drive the execution flow. So, getting code signed really doesn't assert anything other than a business relationship. App signatures don't actually work, for any arbitrarily good hash.
"I think it's safe! I think it's safe! I think it's safe!":)
Look. Virtualization is not a security technology. I've gotten a VMWare engineer to admit this publicly, on stage, with only mild needling. Virtualization reduces hardware to a protocol that must be parsed, or (as is increasingly common) it allows direct passthrough to devices on buses that have no conception of host vs. guest (see: USB).
There was actually some really cool work recently done by Jeff Forristal, who pointed out that since all VM's are on the same LAN, all the old LAN-based attacks work really well cross-VM. Oops.
Now, regarding Joanna's attack, she's completely right that everyone's going to virtualization -- it's just so much more manageable. The consumer market will eventually embrace this.
Slashdot Mirror
[This is Dan Kaminsky]
No, this attack is much worse than my home router exploits (which, admittedly, aren't getting fixed anytime soon). While it is indeed nice to have compromised firmware living somewhere on your LAN, being able to generically attack everyone using a given ISP is a much more valuable proposition -- especially when I don't need to worry about the pesky paranoid people changing their router passwords, or even using a router I haven't built a script to attack.
I'm being very circumspect about implications. August 6th will be an interesting day.
It's funny you mention the iptables auto-block. There's been a known attack here for years -- spoof the root servers attacking you, and...yeah.
That being said, we agree on the ultimate fix...run yum update, and be done.
Companies don't know why they work.
I'm serious. They really, truly, have no idea. They pay a bunch of people to do various things, and at various levels of influence correct errors, but that is not the same as knowing why they work.
Think of rogue employees damaging everything on their way out as shark attacks: There are people who are truly terrified of sharks, and indeed, it does suck to get bitten by them. It's not exactly common, however. But think of loss of institutional knowledge and goodwill as a car accident: Huge loss of time, potentially enough damage that experts (mechanics / consultants) need to be brought in, but common, manageable, and often someone else's problem.
It doesn't really work that way, but by then it's too late.
It's an interesting example you raise. Lets take a look at your example:
find | tar | compress | remote-execute 'remote-copy | uncompress | untar'
find -- you're sweeping the file system and comparing against rules. Maybe IO-driven CPU, at best.
tar -- You're appending a couple headers. No work.
compress -- OK, here there's a CPU bound.
remote-execute remote-copy -- Throwing stuff onto the network and pulling it off.
uncompress -- OK, more CPU bound.
untar -- Now you're adding files to the file system, but only as fast as the network can give them to you. No work here either, really.
So, in your example, you have two CPU bound processes. Interestingly, the problem itself is a network copy, which conveniently always has two processes. About the only improvement an extra core would add, then, is maybe find going a little faster.
Parallelize the compressors and decompressors, now, and you're onto something.
If the attacker (the ISP!) is willing to replace NXDOMAIN, why not replace any name that isn't www? Or any name that returns a fixed 302? The precedent must be set.
I think it's an accident. It's actually tricky to differentiate nonexistent subdomains vs. unregistered domains; what's on the wire is the same, it's just which name server tells you something. See www.publicsuffix.org to see how hard this problem is.
I'm pretty optimistic that, now that the issue's been identified, everyone will stop violating trademarks.
--Dan
This is Dan -- glad you're all enjoying!
There's more data here:
http://www.doxpara.com/DMK_Neut_toor.ppt
And this is what I sent (many, many) affected sites:
IOActive Security Pre-advisory: Non-Neutral Major ISP Behavior Injecting Security Vulnerabilities Into Entire Web
Dan Kaminsky, Director of Penetration Testing, IOActive Inc.
Jason Larsen, Senior Security Researcher, IOActive Inc.
Executive Summary: A number of major broadband ISP's have deployed advertising servers that impersonate, via DNS, hostnames within your trademarked domain. We have determined that these injected servers are, in fact, vulnerable to Cross-Site Scripting attacks. Since these servers are being injected into your trademarked domains, their vulnerability can be used to attack your users and your sites. Due to recent activity by Network Solutions, we believe this vulnerability will be discovered shortly, and we will thus be unveiling this matter on Saturday, April 19th, at the Seattle Toorcon security conference. We believe that the security hole is reasonably straightforward to fix, either by temporarily disabling the advertising server, or by resolving the error condition that allows Cross-Site Scripting. We are contacting the affected ISP's to address at least the security issue in play. The fundamental trademark violation issue is outside our scope, however, we encourage you to pay close attention to this case, as the fundamental design of these advertising systems requires direct impersonation of your protected marks.
Details: We would prefer to keep the names and mechanisms required for this vulnerability under wraps, at least for the next few days, while the ISP's in question manage and mitigate the security implications of this behavior. We can confirm the following attacks have been verified to work against your site, via this XSS vulnerability:
A) Arbitrary cookie retrieval. Any web page on the Internet can retrieve all non-HTTP-only cookies from your domains.
B) Fake site injection. A victim can be directed to "server2.www.realsite.com" or "server3.www.realsite.com", which will appear to be a host in your domain. We believe any phishing attempts from this perfect-address spoofed subdomain are more likely to be successful.
C) Full page compromise. A victim can be directed to your actual HTTP site, with all logged in credentials, and our attack page will still be able to fully manipulate the target site as if we ourselves were the victim. Note, while we cannot attack HTTPS resources, we can prevent upgrade from HTTP to HTTPS. This may affect any shopping carts within your sites.
We believe this behavior is illustrative of the risks of violating Network Neutrality. Indeed, it is our sense that the HTTP web becomes insecurable if man-in-the-middle attacks are monetized by providers -- if we don't know what bits are going to reach the client, how can we control for flaws in those bits?
We do not believe the vulnerability is intentional, only the injection. We were partially involved in the discovery of the Sony Rootkit some time ago; we recognize this pattern. That case resolved itself reasonably, and we are hopeful this one can be managed well as well. If your technical, press, or legal staff has any comments on this matter, please feel free to contact us at dan.kaminsky@ioactive.com. This is a matter that strikes at the core of the viability of HTTP as a medium for business, and we are committed to defending this medium for your operations. Thank you!
Yours Truly,
Dan Kaminsky
Jason Larsen
OK, so, since DiMaggio had his 56 game streak 60 years ago, what are the odds (by their measurement) of a 55 game streak occuring some time between now and then?
Almost guaranteed, by their method.
What is the likelihood that we'd see no such streaks?
Almost none by their method.
Did we see any such streaks? No, no we didn't.
Pretty fatal flaw.
Something says their probability calculations were probably a bit off. There are two things they're not taking into account: First, as has been mentioned elsewhere, baseball is not a one-shot game. Things happen as a streak picks up, and you necessarily end up with less and less data about what those things are as a streak progresses (since you have fewer and fewer samples of behavior on a 20-game streak, a 30 game streak, and so on). The game changes, the players change, the pitches change.
Second, players, pitchers, and the game itself have changed over the last 60 years. One reason we may not be seeing DiMaggio's records hit again, is that the skill levels are just so rarified.
Took a look at some servers I monitor. Indeed, 25% IE6, 40% IE7, 35% Gecko. Interesting -- I'd not realized the IE7 push had gone so well, or that Firefox's penetration was so high.
You prove his point quite beautifully, retrieving non-DRM'd HTML from www.pcmag.com that suspiciously looks exactly like non-photocopy-protected text from a paper magazine.
Actually, wait.
Alright, here's the reality of things:
People code their web pages to IE6, because that's what the vast majority of the userbase has. Now, enough of the userbase uses Firefox, such that it's worth testing and making sure rendering is reasonable enough there. But, seriously. People build to IE.
Now, this is not great. We should have consistent behavior, and follow superior engineering guidelines as realized through the standards process. People should be building not just to the De Facto standard of IE6, people should instead be building to the specifications made after the fact.
Note, by the way, the entire web is back-standardized, like (as far as I can tell) all good standards. First, build something that works, then remark on what makes things work. This is as opposed to the other way, which is to make a standard and hope it's useful.
So, here's the problem: You've got millions of pages built one way (to the browser), but this is a total pain for devs, who'd very much rather build them the other way (to the refined specification). What to do?
One model is to have the devs identify themselves. That's the tag that's been brought up.
The other model is to bring pain to all the devs who know nothing about the formal specifications, to silently but noticably break their sites. This seems very nice to those who are pissed at those devs for writing non-standards compliant code. It increases the cost in the future of such behavior occurring. Seems like a great idea, right?
In the real world, you don't really get to do that to your customers. Say what you will about Adobe, a Flash file will render the same no matter what, on all Flash players, ever. If the effect of the standardization process is that your code may silently explode in 18 months, forget standards, go for something that would never threaten you with that.
Is that what you want? No? Then relax, and realize that destructive migration paths do more damage to standards than anything else could.
Dude.
People keep losing the damn thing, leaving it on the ends of VGA cables or whatever. Go to a few conferences. It's...embarassing.
Encryption is hard, because key management is hard. Instead of sending one file, you have to send two, through totally different channels.
Well, "have to" is relative. A huge amount of the time you see "encryption", the decryption key is right there next to it. But, you see, the data is encrypted. So it's safe.
*sighs*
"All it requires is a screwdriver"...which you're not allowed to take on planes. Also, what's the warranty implications of popping the box?
...please?"
If you'll all forgive the snark, here's my impression of a Mac user trying to present at a conference:
"Does anyone have a DVI to VGA adapter? Anyone? Anyone?
Whatever should have happened (projectors w/ DVI ports, Mac users who don't forget their dongles), what does happen is pretty damning. It's pretty damaging to the brand, from a business side.
It's inexpensive, and scales astonishingly. I've spent the last two years in it, and it's just how I audit code nowadays.
I'd agree, except it's much easier to find CD's than it is to find Vinyl. There's a selection effect on the publisher, because it's so much more expensive to print vinyl and because they may have to expect DJ's to want to spin it live. There's also a selection effect on the consumer, who has to find the records.
Look, the kid's trying to differentiate himself, by his astonishing music collection. Good or bad, people are genuinely astonished that some 15 year old has a thousand records. Mission accomplished.
Not all bits are created equal. I can sit here with a random number generator for a thousand years, and never get anything that even approaches an MP3, let alone music. Bits are easy to acquire, selected bits get harder. "Vinyl" is seen as having more selection invested into it, because you have to actually spend the time to pick which bits you're going to acquire, and can't just get them all overnight.
There are totally people who have huge MP3 collections where every single one is hand-chosen. There are also people who just grab absolutely everything they can and throw it into the pile. The deal with Vinyl is that the latter is pricey, and thus rare.
I don't think geeks get to tell anyone why they are or aren't cool. We've got some pretty weird things to be excited about (*ahem* whether whitespace should delimit code blocks *ahem*).
If someone has a thousand albums on MP3, whatever. It doesn't say anything about them. They spent a night raiding P2P. Big deal.
If someone has a thousand albums on Vinyl, it's a different story. You think something of him. Maybe good, maybe bad, but you can expect him to rather deeply identify himself by his music. Each record was individually chosen, to the exclusion of others. Time was invested, thought was expressed, identity is reflected.
And that, of course, is what not just Vinyl, but the entire shared music experience is really about. Music is more than bits. Music is more than waves of air lapping or pounding at one's eardrums. Music is, or at least can be, about identity. That a fifteen year old kid is desperately trying to assert his should surprise absolutely nobody here.
Now That's What I Call A Shitcanning.
Couple major things went wrong:
First, we only needed 48 to 64 bit addresses. 128 bits are actually unmanageable. I'm not going to argue it out, as it's an old and painful discussion. Suffice it to say, the real world has shown that raw IP's are used a lot more than people thought.
Second, autoconfiguration has been a nightmare. Addressing depended on DNS, and then DNS was bolted on, poorly. *sighs*
Third, it really should have been partially backwards compatible with IPv4. I know they wanted to build new toys and all that, but the correct approach would have been a standard V4 header, with a V6 extension that added between 16 and 32 bits of endpoints. Core IPv4 routers would have been limited to routing based on only the first four bytes of the IP at best, but that's better than the present 0.
There's more, of course. Too many spherical holy cows involved, and we've suffered for it.
No, I'll stand by my original point. Predicting the behavior of a turing-complete environment is quite literally the halting problem. People keep trying to "prove" software, and let me tell you first hand, it keeps failing miserably. I think you're ignoring the reality that most software transforms external data, meaning unpredictable environmental inputs (even mouse clicks!) are first class citizens.
The problem is that MD5 can only hash the bag of bits available at compile time. It misses the accumulated bits at runtime. This isn't an MD5 bug, it's a bug in the concept that you can sign behavior or predict what software will do.
Signing can only establish behavior. I didn't used to believe that -- I was wrong.
...is that people stop installing the patches at all.
You really only get to screw up a few times, before the risk of broken patches exceeds the risk of getting hit by a non-public vulnerability. Then, people won't install patches, even when the exploit is public!
One real problem is that this entire engineering model is very, very new. The rules of physics do not change, day to day, but what's happening on the Internet transforms remarkably, moment to moment. It really is a war out there, and the bad guys learn quick.
It is important to realize that the web, for all its warts (and I've been findin' em) is a remarkably secure place, given what it really is. It's our first actual success at mobile code. Wrap your mind around that -- it's really terrifying, and yet, we use it every day. Cool!
Still, everyone's got a lot of work to do, and it is indeed unfair to judge Firefox v. IE based on publicly known vulnerabilities alone. The metrics are guaranteed to be skewed -- Mozilla just doesn't have the freedom to test (due to their NDA-less development model) like Microsoft does.
(Disclosure: I've known Window for years, and I consult at Microsoft on security matters.)
OK, it's pretty damn cool to see people 'round here referencing my work on Javascript MD5 collisions :)
...and the original paper:
The relevant links are:
http://www.doxpara.com/research/md5/t1.html
http://www.doxpara.com/research/md5/t2.html
http://www.doxpara.com/research/md5/md5_someday.pdf
I'm pretty sure I talked about third party attestation in that paper.
A more interesting point was made to me just the other day, which is that there's always enough ambient entropy in any real world system to deviate between trusted and untrusted behavior. In other words, for a turing complete app, you *can't* create a meaningful hash, because you aren't capturing all bits that will drive the execution flow. So, getting code signed really doesn't assert anything other than a business relationship. App signatures don't actually work, for any arbitrarily good hash.
Someone mentioned that it takes an extraordinarily small amount of energy (1 pJ) to flip bits.
Will this be stable in the field? I mean, EMF should be able to elicit those kinds of potentials fairly easily.
This is why it only costs $100 to buy your telephone records.
McNealy's law, people. You have no privacy, get over it.
--Dan
And what's Tommy the Tank Engine security?
:)
"I think it's safe! I think it's safe! I think it's safe!"
Look. Virtualization is not a security technology. I've gotten a VMWare engineer to admit this publicly, on stage, with only mild needling. Virtualization reduces hardware to a protocol that must be parsed, or (as is increasingly common) it allows direct passthrough to devices on buses that have no conception of host vs. guest (see: USB).
There was actually some really cool work recently done by Jeff Forristal, who pointed out that since all VM's are on the same LAN, all the old LAN-based attacks work really well cross-VM. Oops.
Now, regarding Joanna's attack, she's completely right that everyone's going to virtualization -- it's just so much more manageable. The consumer market will eventually embrace this.