Because an operating system running on Qemu behaves differently, in measurably quirky ways, than one running under (a) VMWare, (b) Virtual PC, (c) Intel VT-X Virtualization and (d) native hardware. Validating that assertion is the point of the challenge.
How I'm sure it's not just something like VMWare is that we wrote a hardware-virtualized rootkit ourselves and saw Joanna's talk last year and have read everything else Joanna has produced and, to the extent that the word of "yet another security researcher" matters to you, Blue Pill is real, Joanna is hard core, and her work is nothing like VMWare (which isn't a trap-and-execute hardware VMM).
If Joanna wants to stipulate that we pick Blue Pill out of a morass of pre-installed kernel and userland rootkits, we would of course agree to that term. Neither Joanna's team nor ours seems to think that's a meaningful addition to the test. Like the Vitriol rootkit Dino Dai Zovi wrote for Matasano last year, Joanna's rootkit lives in a special slice of memory inside of a special execution context carved out by the hardware. It is unlike any other X86 rootkit in how it intercepts control of the platform and how it stays resident.
Installing a bunch of crappy malware alongside something as slick as Blue Pill is very much the same as trying to hide a Ferarri in a junkyard lot filled with rusted out Chevy Novas. But, by all means, if Joanna wants to add meaningless obstacles --- let nobody say we allowed those obstacles to impede science!
If 5 laptops is what it takes to get this challenge off the ground, then we'll do 5 laptops.
However, I don't know what the number of laptops has to do with removing luck from the challenge. If she wants to reduce our likelihood of a lucky guess to below 3%, we can use repeated trials on the same hardware (with Joanna's team stipulating how cleanup after each trial is to occur) to the exact same effect.
Helu. I'm Thomas Ptacek, one of the four challenge team members --- Slashdot left out Dino Dai Zovi, who kicked this off by writing a virtualized rootkit at Matasano last year.
Joanna has responded to our challenge. We invited her to stipulate any terms she deemed reasonable. She proferred:
Five (5) laptops instead of two (2), as a defense against lucky guessing.
We can't crash the machines in the process of testing.
We can't spike the CPU on the machine for more than one (1) second.
We have to open source our detector, and she'll open source her rootkit.
We have to arrange to have her paid between $384,000 and $416,000, and wait six months.
Here's where it stands: all parties agree that by Black Hat '07, Blue Pill will not be in a state where it is hard to detect. Our detection techniques are likely to detect Blue Pill at Black Hat. Blue Pill requires six months of engineering time to get to a state where Joanna is confident that we can't detect it.
Here's why you care: a few weeks ago, Microsoft decided that Vista Home would not allow virtualization, in part because of the threat of virtualized malware. To the best of our knowledge, there have been two (2) real hypervisor rootkits ever produced: Joanna's Blue Pill, and Matasano's Vitriol. Neither has ever been seen in the wild, because neither has been released to the public. Meanwhile, our team is preparing to demonstrate at Black Hat this year that hypervisor malware is actually even easier to detect than the kernel malware operating systems like Vista are already exposed to.
Joanna's Blue Pill work, along with all the rest of her work (check out this project, where she turns AMD security hardware against forensics devices), is top-notch. In a weird, secretive space like security, this is how science gets done. Joanna chooses a side: it's possible to make undetectable malware. We square off on the opposite side. Then we debate it using code, presentations, papers, and I guess Slashdot stories. Hopefully, in the end, we all learn something.
Hope this stays interesting for everyone. Thanks for paying attention!
As Mikko acknowledges, the real purpose of ".bank" is not to make it easier for end-users to recognize fake sites. A new TLD does almost nothing to ameliorate that problem; end-users don't know what TLDs are, or what the slash character in a URL means. And before you yelp that end-users should learn that stuff, ask yourself: do you understand how the NANP phone number scheme works, or what the 3-digit exchange number in the middle of your phone number means? But you can use your phone just fine, can't you?
The purpose of ".bank" is to make it easier for security software to patrol for fake bank sites. A great idea! Why didn't somebody think of it before? Because they did: most of the mainstream AV vendors will also sell you something that will spot fake bank sites. They do it by building and tracking whitelists of valid banking sites. If that sounds like a lot of work, it's because it is.
F-Secure would like the rest of the world to do that work for them. If all the banks lived under ".bank", they could issue a ".bank-detector" plugin that would flag illicit bank sites. This may not be a horrible idea; open-source projects could do the same thing easily too. But, as everyone who tracks this stuff is pointing out, the banks aren't going to comply: they already process transactions using a myriad of random-sounding unidentifiable domain names, which drastically complicates whitelisting.
These are some of the top security researchers in the country. Do you know what security research bills for? Why does he have to work for you (or "the developers" --- those altruists!) for free?
The OpenBSD BCM driver contains GPL'd code. Here are 12 examples of code copied verbatim from our source tree.
Theo (also in public):
Are you saying you want Marcus to quit? Why did you CC so many people?
Stefano:
This is a major GPL violation. We just want it resolved. We'd love to see a clean OpenBSD BCM driver!
Theo:
Why are you trying to drag Marcus through the mud? Do you want him to quit?
Joseph:
Theo, Michael CC'd us because we're part of the BCM reversing team. Can we help you clean the driver up?
Theo:
So you think Marcus should quit?!
Joseph:
No, we just said the opposite.
Theo:
And I ask again, do you see any reason why this whole rant accusing Marcus of copyright violations should have landed in your mailbox?
Michael:
Theo, we don't want you guys to give up! Just work with us to clean up the licensing status of the code!
Theo:
You're too late. Marcus quit. Are you not human? Are you surprised?
Michael:
Little bit, yeah. This was a major GPL violation, and it doesn't seem like an accident. Why are you arguing about it?
Theo:
Why are you still calling Marcus a thief?
Frankly, I have a hard time seeing how Marcus could be so thin-skinned as to be hurt by a GPL challenge, and yet somehow work on the same team as Theo. Presumably, Marcus never actually talked to Theo. It's all for the best, then. Marcus will be happier someplace else.
Anybody --- not just the DHS --- can spoof the DNS today. And yet, by all available evidence, DNS spoofing is vanishingly rare. Mutual authentication over the untrusted Internet is a solved problem: TLS provides an end-to-end guarantee that your connection to your banking web application terminates with someone who can vouch for your bank's crypto keys. And you don't simply trust SSL certificates to the government: you also trust a myriad of commercial entitities as well.
This is a red herring on multiple levels. There are lots of places that intelligence agencies can step in to violate your privacy on the Internet; you "trust" an access-layer providers, a number of backbone providers, the owners of the DNS roots, the certificate authorities, Google, and probably 10 more entities. But more importantly, DNSSEC is irrelevant. Nobody depends on it now (it doesn't "exist"now: tell me how my Mac does a secure lookup for Google.com on Speakeasy). It's likely that nobody ever will depend on it. And that's OK, because we have better mechanisms in place. We should spend more effort on adding negotiated opt-in SSL for things besides web and mail, and less on huge infrastructure projects to "secure" one tiny link in the connectivity chain.
You're right that I'm being unfair and misleading about RFC2535
You're wrong about the service model for DNSSEC being well-understood. Name a problem that is better solved by DNSSEC than by TLS, either in current practice or in theory.
You're wrong about the deployment problems of DNSSEC, but I won't dignify a point you won't even take the time to make fully.
BIND and NSD are the two examples of mainstream nameservers with DNSSEC support. But djbdns, which dwarfs NSD in deployments, does not and likely never will support DNSSEC. Neither does Active Directory, Novell, or Apple. And which operating systems currently ship with DNSSEC-enabled resolvers?
BIND 9 was developed by the same team as BIND 8. The errata lists in each successive release of BIND 9 aren't smaller than those of BIND 8. BIND 9 has had multiple vulnerabilities. The BIND team's time is better spent shoring up their own code than foisting new "standards" on the rest of us.
The current "standard" (RFC2535) remains "dead and buried" according to DNS pater familias Paul Vixie
Nobody even knows what problem DNSSEC is meant to solve, and why it's worth deploying in a world with pervasive TLS
It's a nightmare to deploy, both for administrators and for software developers who have to handle things like precomputing tens of thousands of expensive signatures
The only reference implementation of the protocol is BIND, the second-least-trusted piece of open source code on the Internet.
DNSSEC is a huge waste of time. For a fraction of the effort, we could have pervasive opportunistic VPN-style connections. Or we could clean up the mess of insecure code that currently provides our core infrastructure. Or a unified standard secure email transport based on GPG/PGP. Or a concerted effort to solve the cross-site scripting problem. You could come up with a way to secure and authenticate the AOL OSCAR IM protocol and still do more good than DNSSEC ever will.
Of course, the IETF people will never admit this. The IETF types used to define themselves by making fun of the OSI X-standards people; "rough consensus and working code!". The Internet won, CLNP lost. Where do you think all those standards bureaucrats you made fun of in the OSI groups went? That's right; to IETF working groups.
I would rather all hiring decisions go through the person that actually manages a team and produces a product, not some "HR Technical Specialist", which is really some moron with an HR degree who has worked for a tech company before.
Uh, the way you would "rather" it works is the way it does work at every technical company I've been involved with or known people at. Can you give a specific example of a company where HR interviews and selects the technical candidates?
Without bothering to read the article, I will point out that as far as your bank is concerned, digest algorithms protect SSL negotiation in general and the key exchange in particular. A worst-case break in SHA-1 and MD5 can negate the protections provided by RSA and AES.
Microsoft made $3.5 billion (net) last quarter alone, and has enough cash on hand to buy a company the size of Home Depot outright.
Absurd. Home Depot is the second largest retailer in the world, with top-line revenue exceeding $80bn and quarterly gross profits of over $6bn. Microsoft has net tangible assets of only $35bn. HD is in the top 20 of the Fortune 500, Microsoft is #48.
In the parallel universe of business that ESR inhabits, Microsoft still has more to worry about from HD than the other way around. What other completely obvious things do ESR and his co-author get wrong in this essay?
Network-layer, Deering-model multicast is never going to happen. It has nothing to do with ISP business models and everything to do with simple technical feasibility:
Routing table management is an issue even in unicast (which is why I can't get an ASN and advertise a/27, even though that would be incredibly convenient and useful). But multicast addresses individual pieces of content --- video streams, game rooms, chat channels --- and requires diverse, interdomain routing for each. This is akin to demanding BGP advertisements for every popular page on the web.
The protocols for interdomain routing barely exist and have never been proven; no production network relies on them. Even interior routing for multicast is in flux; just a few years ago, the model changed to single-sender, which simplifies routing but changes the service model so only one source can efficiently send data.
Forward error correction may work for streaming media, but it's a disaster for tiny, discrete updates, and outside of FEC there are no proven ideas in multicast reliability. "Scaleable Reliable Multicast" isn't a protocol, it's a position paper from the early '90s. The well-known current multicast reliability protocols all require infrastructure support: strategically deployed "repair" servers.
There isn't even an agreement among protocol designers about what multicast is supposed to accomplish anymore. BitTorrent is taking a lot of the steam out of it; so are unicast solutions to streaming media that prove that multicast is inessential. Multicast gets used tactically inside of some networks, but if you're on the same LAN as your other players, the network is already plenty fast for gaming even with unicast.
You're thinking too small. The real problem moving forward is virtualization; the industry is converging to a state where hosted servers will transparently share underlying hardware; the new threat model is VM-to-VM, which is why the earlier commenter who dismissed "overly complex local-only problem scenarios" (paraphrase) is off base.
The CPU aggressively caches aspects of what programs do. It doesn't
make an exception for RSA. You obviously can't just read key bits out
of the cache.
But caches are finite, and way, way too small to accomodate everything
every program does. So operations from one program are constantly
evicting cached values from other programs. This makes the other
program imperceptably but measurably slower. By writing a program
that constantly and carefully measures those time differences, you can
watch an RSA operation from another program leave footprints through
the cache.
There are years-old attacks like this against the L1 and L2 caches,
and extensions that use hyperthreading to improve the resolution. Some
variants, which measure timing differences but don't track cache
footprints, are remote attacks. These aren't. You run a "spy" process
on the machine; it repeatedly executes a series of operations
and measures timing differences. Aciicmez found an overlooked cache
which makes Pentium branch prediction work (the BTB). They published
back in August.
From what I can tell, this paper extends the attack; they figured out
that the Pentium 4 architecture has two BTB caches, and their original
attack wasn't hitting both of them. Their new attack does, and that
creates much bigger timing differences, making RSA's footprints much
easier to see.
This is really cool stuff, but from where I stand, they hit game-over
back in August with the original BTB attack. This paper reads like a
refined exploit for the same vulnerability.
Since this is localhost-only, and (unlike Bernstein's and Boneh's
attacks) can't be extended remote, it's not going to impact SSL or
(single-user) SSH. The classic victim of timing attacks is smart
cards. For these attacks, another interesting possibility is DRM;
these attacks say you can't trust crypto running on the same Pentium
4+ as an attacker.
This would be a pendantic comment, except stock values are central to the story:
The closing price of a share of SCOX or IBM does't mean anything unless you also quote the number of outstanding shares. The fact that a share of IBM is worth ~80x a share of SCOX is misleading. In reality, SCOX closed down today ~1% with a market cap (shares x price) of 35MM (a pittance); IBM closed up.5% with a market cap of 125.5Bn, or 4,185 times as much as SCO.
Cite closing market caps, not stock prices. Or just cite the percentage change.
No, the impact of this problem was wider than what the front page suggests; the same bug hit Firefox (which uses its own "NSS" SSL library, not OpenSSL), and several of the root certificates were e=3 (e=3 is a widely-recommended optimization). Long story short, Firefox, Opera, and Konqueror are all spoofable until you download patches.
The simple exploit (generate a new WELLSFARGO.COM cert and "sign" it in a way that will trick a browser into believing a root CA signed it) is literally 3 lines of Python.
You're also wrong about the crypto details: e=3 RSA is not "weaker" than e=65537. The problem is not that people used "weak" RSA parameters; the problem is that they didn't verify all the bits in an RSA-decoded signature, but instead tried to fish something that looked like a valid SHA/MD5 hash out of it. If you screw up any of the details in RSA signature verification, you're screwed, e=3, e=5, or e=65537. Conversely if you get the details right, e=3 is as secure as factoring.
It is funny that this is just hitting Slashdot now; it's weeks old.
Last week we had advisories from the OpenSSL project and the Mozilla team that the two most popular open-source implementations of RSA, probably accounting for the majority of all deployed RSA code, were so badly broken that an arbitrary attacker could generate a valid SSL certificate for Wells Fargo offline and sell it.
This got no coverage on Slashdot. Ok, fine. Maybe it's a bit esoteric.
Today, an amateur wiki site on cryptography, with (apparently) fewer articles than even the Wikipedia crypto collection, does get coverage.
Slashdot Mirror
Because an operating system running on Qemu behaves differently, in measurably quirky ways, than one running under (a) VMWare, (b) Virtual PC, (c) Intel VT-X Virtualization and (d) native hardware. Validating that assertion is the point of the challenge.
How I'm sure it's not just something like VMWare is that we wrote a hardware-virtualized rootkit ourselves and saw Joanna's talk last year and have read everything else Joanna has produced and, to the extent that the word of "yet another security researcher" matters to you, Blue Pill is real, Joanna is hard core, and her work is nothing like VMWare (which isn't a trap-and-execute hardware VMM).
You should become a secure programmer, which is the rate she's working from. There aren't enough secure programmers to go around.
If Joanna wants to stipulate that we pick Blue Pill out of a morass of pre-installed kernel and userland rootkits, we would of course agree to that term. Neither Joanna's team nor ours seems to think that's a meaningful addition to the test. Like the Vitriol rootkit Dino Dai Zovi wrote for Matasano last year, Joanna's rootkit lives in a special slice of memory inside of a special execution context carved out by the hardware. It is unlike any other X86 rootkit in how it intercepts control of the platform and how it stays resident.
Installing a bunch of crappy malware alongside something as slick as Blue Pill is very much the same as trying to hide a Ferarri in a junkyard lot filled with rusted out Chevy Novas. But, by all means, if Joanna wants to add meaningless obstacles --- let nobody say we allowed those obstacles to impede science!
If 5 laptops is what it takes to get this challenge off the ground, then we'll do 5 laptops.
However, I don't know what the number of laptops has to do with removing luck from the challenge. If she wants to reduce our likelihood of a lucky guess to below 3%, we can use repeated trials on the same hardware (with Joanna's team stipulating how cleanup after each trial is to occur) to the exact same effect.
Helu. I'm Thomas Ptacek, one of the four challenge team members --- Slashdot left out Dino Dai Zovi, who kicked this off by writing a virtualized rootkit at Matasano last year.
Joanna has responded to our challenge. We invited her to stipulate any terms she deemed reasonable. She proferred:
You can probably predict our response.
Here's where it stands: all parties agree that by Black Hat '07, Blue Pill will not be in a state where it is hard to detect. Our detection techniques are likely to detect Blue Pill at Black Hat. Blue Pill requires six months of engineering time to get to a state where Joanna is confident that we can't detect it.
Here's why you care: a few weeks ago, Microsoft decided that Vista Home would not allow virtualization, in part because of the threat of virtualized malware. To the best of our knowledge, there have been two (2) real hypervisor rootkits ever produced: Joanna's Blue Pill, and Matasano's Vitriol. Neither has ever been seen in the wild, because neither has been released to the public. Meanwhile, our team is preparing to demonstrate at Black Hat this year that hypervisor malware is actually even easier to detect than the kernel malware operating systems like Vista are already exposed to.
Joanna's Blue Pill work, along with all the rest of her work (check out this project, where she turns AMD security hardware against forensics devices), is top-notch. In a weird, secretive space like security, this is how science gets done. Joanna chooses a side: it's possible to make undetectable malware. We square off on the opposite side. Then we debate it using code, presentations, papers, and I guess Slashdot stories. Hopefully, in the end, we all learn something.
Hope this stays interesting for everyone. Thanks for paying attention!
Dave G. covered this on our blog last month. There's backstory to this.
As Mikko acknowledges, the real purpose of ".bank" is not to make it easier for end-users to recognize fake sites. A new TLD does almost nothing to ameliorate that problem; end-users don't know what TLDs are, or what the slash character in a URL means. And before you yelp that end-users should learn that stuff, ask yourself: do you understand how the NANP phone number scheme works, or what the 3-digit exchange number in the middle of your phone number means? But you can use your phone just fine, can't you?
The purpose of ".bank" is to make it easier for security software to patrol for fake bank sites. A great idea! Why didn't somebody think of it before? Because they did: most of the mainstream AV vendors will also sell you something that will spot fake bank sites. They do it by building and tracking whitelists of valid banking sites. If that sounds like a lot of work, it's because it is.
F-Secure would like the rest of the world to do that work for them. If all the banks lived under ".bank", they could issue a ".bank-detector" plugin that would flag illicit bank sites. This may not be a horrible idea; open-source projects could do the same thing easily too. But, as everyone who tracks this stuff is pointing out, the banks aren't going to comply: they already process transactions using a myriad of random-sounding unidentifiable domain names, which drastically complicates whitelisting.
Uh, gross? Did you mean to write:
int allocstuff(char **a, char **b) {if((*a = malloc(100))) {
*b = malloc(100);
}
if(!*b) free(*a);
return(*b != NULL)
}
And, you do know you can safely call free() on the result of a failed malloc (guaranteed to be NULL), right?
Though, if you don't have an answer to what you planned to do in the rest of your program if malloc fails, you have no business coming up with some complicated error reporting protocol instead of simply hooking malloc and gracefully exiting on any failure.
Glad to help. Please stop using goto now.
What an asinine comment. The people who write viruses create viruses. The people who find vulnerabilities don't create vulnerabilities.
These are some of the top security researchers in the country. Do you know what security research bills for? Why does he have to work for you (or "the developers" --- those altruists!) for free?
Paraphrase (with accurate chronology):
Michael (in public):
The OpenBSD BCM driver contains GPL'd code. Here are 12 examples of code copied verbatim from our source tree.
Theo (also in public):
Are you saying you want Marcus to quit? Why did you CC so many people?
Stefano:
This is a major GPL violation. We just want it resolved. We'd love to see a clean OpenBSD BCM driver!
Theo:
Why are you trying to drag Marcus through the mud? Do you want him to quit?
Joseph:
Theo, Michael CC'd us because we're part of the BCM reversing team. Can we help you clean the driver up?
Theo:
So you think Marcus should quit?!
Joseph:
No, we just said the opposite.
Theo:
And I ask again, do you see any reason why this whole rant accusing Marcus of copyright violations should have landed in your mailbox?
Michael:
Theo, we don't want you guys to give up! Just work with us to clean up the licensing status of the code!
Theo:
You're too late. Marcus quit. Are you not human? Are you surprised?
Michael:
Little bit, yeah. This was a major GPL violation, and it doesn't seem like an accident. Why are you arguing about it?
Theo:
Why are you still calling Marcus a thief?
Frankly, I have a hard time seeing how Marcus could be so thin-skinned as to be hurt by a GPL challenge, and yet somehow work on the same team as Theo. Presumably, Marcus never actually talked to Theo. It's all for the best, then. Marcus will be happier someplace else.
Anybody --- not just the DHS --- can spoof the DNS today. And yet, by all available evidence, DNS spoofing is vanishingly rare. Mutual authentication over the untrusted Internet is a solved problem: TLS provides an end-to-end guarantee that your connection to your banking web application terminates with someone who can vouch for your bank's crypto keys. And you don't simply trust SSL certificates to the government: you also trust a myriad of commercial entitities as well.
This is a red herring on multiple levels. There are lots of places that intelligence agencies can step in to violate your privacy on the Internet; you "trust" an access-layer providers, a number of backbone providers, the owners of the DNS roots, the certificate authorities, Google, and probably 10 more entities. But more importantly, DNSSEC is irrelevant. Nobody depends on it now (it doesn't "exist"now: tell me how my Mac does a secure lookup for Google.com on Speakeasy). It's likely that nobody ever will depend on it. And that's OK, because we have better mechanisms in place. We should spend more effort on adding negotiated opt-in SSL for things besides web and mail, and less on huge infrastructure projects to "secure" one tiny link in the connectivity chain.
Nothing about DNSSEC has improved since wrote about it last year:
DNSSEC is a huge waste of time. For a fraction of the effort, we could have pervasive opportunistic VPN-style connections. Or we could clean up the mess of insecure code that currently provides our core infrastructure. Or a unified standard secure email transport based on GPG/PGP. Or a concerted effort to solve the cross-site scripting problem. You could come up with a way to secure and authenticate the AOL OSCAR IM protocol and still do more good than DNSSEC ever will.
Of course, the IETF people will never admit this. The IETF types used to define themselves by making fun of the OSI X-standards people; "rough consensus and working code!". The Internet won, CLNP lost. Where do you think all those standards bureaucrats you made fun of in the OSI groups went? That's right; to IETF working groups.
I would rather all hiring decisions go through the person that actually manages a team and produces a product, not some "HR Technical Specialist", which is really some moron with an HR degree who has worked for a tech company before.
Uh, the way you would "rather" it works is the way it does work at every technical company I've been involved with or known people at. Can you give a specific example of a company where HR interviews and selects the technical candidates?
Without bothering to read the article, I will point out that as far as your bank is concerned, digest algorithms protect SSL negotiation in general and the key exchange in particular. A worst-case break in SHA-1 and MD5 can negate the protections provided by RSA and AES.
Microsoft has $35bn in net tangible assets. Presumably this is why you got modded down; the rest of this comment read thoughtful.
Microsoft made $3.5 billion (net) last quarter alone, and has enough cash on hand to buy a company the size of Home Depot outright.
Absurd. Home Depot is the second largest retailer in the world, with top-line revenue exceeding $80bn and quarterly gross profits of over $6bn. Microsoft has net tangible assets of only $35bn. HD is in the top 20 of the Fortune 500, Microsoft is #48.
In the parallel universe of business that ESR inhabits, Microsoft still has more to worry about from HD than the other way around. What other completely obvious things do ESR and his co-author get wrong in this essay?
The genius of Google's strategy of keeping applications "in beta" forever is that they get two press events for each product launch.
What I don't get is, why do you people keep falling for it?
Network-layer, Deering-model multicast is never going to happen. It has nothing to do with ISP business models and everything to do with simple technical feasibility:
There isn't even an agreement among protocol designers about what multicast is supposed to accomplish anymore. BitTorrent is taking a lot of the steam out of it; so are unicast solutions to streaming media that prove that multicast is inessential. Multicast gets used tactically inside of some networks, but if you're on the same LAN as your other players, the network is already plenty fast for gaming even with unicast.
Forget about multicast.
You didn't even read the article.
You're thinking too small. The real problem moving forward is virtualization; the industry is converging to a state where hosted servers will transparently share underlying hardware; the new threat model is VM-to-VM, which is why the earlier commenter who dismissed "overly complex local-only problem scenarios" (paraphrase) is off base.
Aciicmez et al are extending an attack they published a few months ago. It's real, but:
It targets RSA implementations, not the algorithm, which is fine
Attackers need to be on the same host as the victim
This specific attack is tuned to the Pentium 4 architecture
This paper doesn't break SSL.
We wrote about the attack two months ago. A quick, dumbed-down recap:
The CPU aggressively caches aspects of what programs do. It doesn't make an exception for RSA. You obviously can't just read key bits out of the cache.
But caches are finite, and way, way too small to accomodate everything every program does. So operations from one program are constantly evicting cached values from other programs. This makes the other program imperceptably but measurably slower. By writing a program that constantly and carefully measures those time differences, you can watch an RSA operation from another program leave footprints through the cache.
There are years-old attacks like this against the L1 and L2 caches, and extensions that use hyperthreading to improve the resolution. Some variants, which measure timing differences but don't track cache footprints, are remote attacks. These aren't. You run a "spy" process on the machine; it repeatedly executes a series of operations and measures timing differences. Aciicmez found an overlooked cache which makes Pentium branch prediction work (the BTB). They published back in August.
From what I can tell, this paper extends the attack; they figured out that the Pentium 4 architecture has two BTB caches, and their original attack wasn't hitting both of them. Their new attack does, and that creates much bigger timing differences, making RSA's footprints much easier to see.
This is really cool stuff, but from where I stand, they hit game-over back in August with the original BTB attack. This paper reads like a refined exploit for the same vulnerability.
Since this is localhost-only, and (unlike Bernstein's and Boneh's attacks) can't be extended remote, it's not going to impact SSL or (single-user) SSH. The classic victim of timing attacks is smart cards. For these attacks, another interesting possibility is DRM; these attacks say you can't trust crypto running on the same Pentium 4+ as an attacker.
This would be a pendantic comment, except stock values are central to the story:
The closing price of a share of SCOX or IBM does't mean anything unless you also quote the number of outstanding shares. The fact that a share of IBM is worth ~80x a share of SCOX is misleading. In reality, SCOX closed down today ~1% with a market cap (shares x price) of 35MM (a pittance); IBM closed up .5% with a market cap of 125.5Bn, or 4,185 times as much as SCO.
Cite closing market caps, not stock prices. Or just cite the percentage change.
No, the impact of this problem was wider than what the front page suggests; the same bug hit Firefox (which uses its own "NSS" SSL library, not OpenSSL), and several of the root certificates were e=3 (e=3 is a widely-recommended optimization). Long story short, Firefox, Opera, and Konqueror are all spoofable until you download patches.
The simple exploit (generate a new WELLSFARGO.COM cert and "sign" it in a way that will trick a browser into believing a root CA signed it) is literally 3 lines of Python.
You're also wrong about the crypto details: e=3 RSA is not "weaker" than e=65537. The problem is not that people used "weak" RSA parameters; the problem is that they didn't verify all the bits in an RSA-decoded signature, but instead tried to fish something that looked like a valid SHA/MD5 hash out of it. If you screw up any of the details in RSA signature verification, you're screwed, e=3, e=5, or e=65537. Conversely if you get the details right, e=3 is as secure as factoring.
It is funny that this is just hitting Slashdot now; it's weeks old.
Last week we had advisories from the OpenSSL project and the Mozilla team that the two most popular open-source implementations of RSA, probably accounting for the majority of all deployed RSA code, were so badly broken that an arbitrary attacker could generate a valid SSL certificate for Wells Fargo offline and sell it.
This got no coverage on Slashdot. Ok, fine. Maybe it's a bit esoteric.
Today, an amateur wiki site on cryptography, with (apparently) fewer articles than even the Wikipedia crypto collection, does get coverage.
What am I missing here?