Computer scientists say they’ve discovered a “severe vulnerability” in the world’s most widely used software encryption package that allows them to retrieve a machine’s secret cryptographic key. The bug in the OpenSSL cryptographic library is significant because the open-source package is used to protect sensitive data in countless applications and operating systems throughout the world. Although the attack technique is difficult to carry out, it could eventually be applied to a wide variety of devices, particularly media players and smartphones with anti-copying mechanisms.
most of these kind of attacks are possible but require all sorts of things to work out perfectly for the attacker. Such as ones where the user has to download the file, give it admin rights, and then execute it. At that point, while technically there is a problem with the software, the real problem is the user.
The attacker might as well call the person they are trying to hack and kindly ask them to install LogMeIn or TeamViewer, because some of these require that kind of user assitance to pull off…
Thise one is a bit different with the fluctualting power levels being the key player here, but still.
“Servers, by contrast, would be much harder to attack because they are generally located in places that prevent people from manipulating their power supply”
ok, as an IT Admin (among other things), if i saw one of my users wander into the server room and start messing with cords and power cables (or the fuse box for the building), I would just shoot them and save myself the trouble. explaining to the police why the murder was just would take less time and rebuilding my RAID arrays and re imaging my server environment (and bla bla bla).
alternatively hackers can just wait for really hot days when everyone is using their AC unit in their homes and pray that a rolling brownout will let them decode a fraction of the public key (it took the scientists 100 hours or so to get a whole public key under a highly controlled area).
“The scientists are also experimenting with the possibility of exploiting the bug using lasers or natural radiation sources, they said.”
…if you have to go so far as to use “lasers” or “radiation” to exploit a “bug” then your putting more more effort into trying to create variables in which 0.000001% of devices actually function in. “Awesome! it only took us 8 years and 700 cans of Redbull and Hot pockets but we did it! We cracked into a terminal at the ‘institute of lasers and radiation’, our hard work will not go unnoticed!” …see what I mean? Statistically speaking it would be more likely to actually acquire a device storing the public key by mugging random people within a 5 mile radius of the office building whose data you want to get into. At that point why not just go in and steal the server? If you want the data bad enough to try and bend the fabric of space and time to get it then your likely desperate enough to risk armed robbery.
I am going to end this rant here because if i don’t it will go on for many many pages… Glad this flaw was exposed because ultimately it will lead to an even more bullet proof OpenSSL, and that benefits everyone… (except the people trying to hack into the “institute of lasers and radiation”)
Agreed – I think it’s going *way* overboard, describing this as a “severe” vulnerability. I mean, really – reading the machine state by monitoring fluctuations in the power supply? Maybe possible in lab conditions, but what about in reality? Wouldn’t it be defeated by something as simple as having the machine multitasking?
holly hell!!!1 The institute for lasers and radiation actually exists! http://www.inflpr.ro/
I am sending them an email right now about this exploit as this might be the only institute (aside from MIT) that could run into this problem in a real world scenario… I will post what i head back from them…
Heh, yeah. If users have free access to the datacenter or electrical room at all you have bigger and more serious problems than this bug in OpenSSL.
http://xkcd.com/705/
We all like xkcd, but I don’t get the connection to the story here.
I think he is comparing me to the sysadmin in the comic. To be honest its about a perfect comparison.
“particularly media players and smartphones with anti-copying mechanisms.”
please, let’s not fix it!
and a smart attacker would know to use this chart to see what phones they can hijack using this method: http://www.engadget.com/2009/09/27/website-rates-best-and-worst-cel…
Now, if they use the column on the right, all they need to do is make sure the user walks into a Rave (ideally combining the phones radioactive properties with the lasers at the party). it’s a perfect plan
…this is something you would see in a cartoon in which all the boxes have ACME on the side.
More like practically unfeasible.
Fully agree. For this to work,
1) The device has to use an unbuffered power supply (e.g., embedded devices like smart cards), and
2) the attacker has to have full physical access to the device containing the private key.
They mention these restrictions somewhere in their article, but I wish they would have said this more prominently and not stated that it’s just “more difficult” with servers.
When you have full physical access to a device containing the private key (as you do with copy protected bluray players etc.), it’s not surprising that sooner or later someone will get access to that key one way or another. Nothing can prevent that.
Still, it’s nice that somebody found this vulnerability so that it can be fixed, but it sure as hell isn’t “severe”.
If somebody outside of academia found this bug, they would have posted it to full-disclosure or openssl-dev and then thats it. But as most other parts of society, universities are highly compromised by capitalism today and have to squeeze out all the juice they can out of everything they get. Thats why you get this paper. And don’t underestimate the time they invested here, it takes several weeks just to polish such papers(same way you are careful with your wording in mailing lists or usenet).
While the practical impact is limited, those cryptographic game rules typically have a reason. People use and misuse crypto for all kinds of things. Experience tells that they is most certainly a work flow or product out there that is directly affected by this.
In the crypto world the breach is still “severe”, because they can get the key using little data, effort and computing time compared to an exhaustive key search. That’s what severe means, it has little to do with how feasible is the attack in the real world.
Most crypto attacks are infeasible nowadays anyway, that’s the point of having 100 years of security research now isn’t it?
And then again, this vulnerability isn’t in the algorithm itself, it’s the hardware and implementation.
I wouldn’t say that this is a severe bug in OpenSSL as such – it’s difficult to exploit in real-life, especially for the uses where it’s in our interest that it’s not broken.
However, I wouldn’t say it’s a useless or irrelevant attack, as some of the other comments here seem to imply. Getting a 1024-bit RSA key factored in 104 hours is impressive – and it could be very useful for breaking proprietary devices. And not just quick little hacks, but actually being able to “legitimately” sign firmware or the likes.
Btw, I assume the 104 hours is just the factorization time – would be interesting knowing how long it took to collect the used flawed samples. If we’re talking a 10-minute “harvesting” process, it might even be real-world feasible for stuff other than attacking devices you own..
…then again, it’s about harvesting bits from the private key – devices doing auth only need the public key. Probably less interesting than I initially thought
Harvesting bits from the public key would not make much sense now, would it? After all, it’s public.
Exactly, which is why I said “probably less than I initially thought”.
Well, the way firmware signing usually works isn’t compromised by this. Usually, the private key needed to sign the firmware is stored somewhere safe at the manufacturer of the device, so you would have to have physical access to the manufacturer’s systems to retrieve the private key.
Aside from talking whether this is real-world feasible or not, people should start thinking of securing their systems / devices should a break occurs, in terms of limiting the damage after the intrusion, in conjunction with investing money/time in IPS, etc.
Has the OpenBSD team’s “patched” version 0.9x of OpenSSL fixed this vulnerability?