Fortunately, the attackers didn't, or weren't able to, use their access to slip backdoor code into the OpenSSL software, which websites around the world use to provide HTTPS encryption for the pages they serve. That assurance is possible because the code is maintained and distributed through Git, a source-code management system that allows developers and users to maintain independent copies all over the Internet. Since the cryptographic hashes found on OpenSSL matched those elsewhere, there is a high degree of confidence the code hasn't been altered.
A few days ago I posed the question of whether Git's crypto is an example of dangerous amateur cryptography, since Linus isn't (AFAIK) a crypto expert: https://news.ycombinator.com/item?id=6961683
The general answer I got was that Git isn't really crypto, because it isn't using the hash to guarantee integrity, but simply as a checksum to detect corruption.
I didn't find this argument very convincing at the time, and I would now offer the above quotation as evidence that people do in fact treat Git's hashes as a security mechanism that can withstand an adversarial attack.
You'll see plenty of operations do not check the sha1, and will happily hand you bad data, including checkout and clone, depending on circumstances.
I haven't checked on the latest version, but at least previously, you'd have to run around using git fsck specifically to get it to notice some sha1 mismatches.
So at least trivially, the idea that "it uses sha-1 so it's safe" is silly even without considering the implementation, because it doesn't always check the sha-1 :)
(I'm not even going to argue it should, just pointing out it didn't)
Indeed. Assuming the rest of the code is implemented without any vulnerabilities (and that's one hell of an assumption about any code), SHA1, which Git uses as its hashing algorithm, has been completely broken as early as 2005[1].
That said, I'm not sure how you'd go about crafting source code in such a way as to collide with a known hash without it being amazingly obvious. You could change history to make it appear as if your crocked code was always there or had been for a long time, but then you don't have to figure just one hash, then you have to figure every single hash down to the parent. Depending on the number of commits, that's a hell of a lot of work, even with an algorithm to break SHA1.
And even then if you change the hashes, since Git is distributed, the developers will quickly figure out that what's in one repo doesn't match all the others when patches start breaking..
You're right. Git really isn't crypto, and this news blurb does sound a bit odd. Hopefully this is just a misunderstanding in the reporting. Matching hashes is probably a pretty good sanity check, but it isn't the kind of solid guarantee that a project like OpenSSL needs.
Fortunately, one great thing about decentralized source control systems is that everyone has a copy of everything. Hopefully someone has simply located a repository which hasn't been updated since before the breach, and done some direct comparisons.
detecting corruption is pretty much the same thing as detecting changes though right? Git uses SHA-1 hashes (I think). If someone managed to change the code in a way that still properly compiles AND doesn't change the checksum hash, well... pretty unlikely.
Have there been recent public disclosures of vulnerabilities in hypervisors?
Breaking out of virtual machines is a really interesting process but it's important to remember that a hypervisor can be attacked with pretty much the same techniques you can attack any other program. Virtual machines aren't a magic contain-all-the-hackers solution. There was an interesting talk on DEFCON 19 about breaking out of KVM: http://www.youtube.com/watch?v=tVSVdudfF8Q
Technically that was breaking out of QEMU. It was not KVM specific.
If you break into QEMU, you should be a non-privileged user. If you are using libvirt, you are in a cgroup based jail (basically a container) with SELinux being enforced too. So after breaking into QEMU, you would still need to break out of the container before you could attack anything.
But Nelson's exploit was pretty cool. I initially thought remote code execution wasn't possible and he turned around pretty quickly with the exploit. It's quite impressive.
There may be some alarmism getting started here. "The attack was made via hypervisor through the hosting provider" can be interpreted in several ways and (to me) doesn't necessarily indicate a hypervisor exploit. It sounds like it could be similar to the Linode admin access hack.
That was my impression, too. It sounds more likely a hosting company admin had malware installed or re-used passwords, which naturally would give attackers full access to all VMs hosted by the provider.
Considering the amateurish defacement, I think that's far more likely than some sort of a Xen/KVM breakout exploit. If there was such a zero-day, some group would probably be going after numerous providers in secret, not doing something like this.
i may be misunderstanding (there seem to have been at least two famous hacks on linode), but why would you use the word "hypervisor" to explain that someone had hacked your host's admin account? isn't the presence of that word (the h word) what makes this (potentially) scary?
also, will htp ever come back from exile? (not that it seems too unhappy where it is).
Simple logic: The defacement was amature at best. If the group has a 0-day in a hypervisor they would have gone to multiple hosting companies and multiple attacks would have taken place, there are many more targets that are worth much more than openSSL.
Most likely, the administration panel of the hosting company was comprimised through malware/phishing. Seriously, if a group like this had a 0-day in hypervisor then they would be doing much much more damage.
Defacing OpenSSL's website might be low-value, but backdooring OpenSSL code (trusting-trust style!) would be about as high-value a target as I could imagine.
This doesn't surprise me one bit if its a hypervisor hack. You have to design in this stuff from day one rather than tack it on as an afterthought. To quote Theo de Raadt on virtualization, who I agree with:
"x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit.
You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes."
may as well link directly to OpenSSL's post on it (which says the same thing) [0]. Also, assuming the traceroute on www.openssl.org is correct, this[1] is their webhost.
[+] [-] haberman|12 years ago|reply
A few days ago I posed the question of whether Git's crypto is an example of dangerous amateur cryptography, since Linus isn't (AFAIK) a crypto expert: https://news.ycombinator.com/item?id=6961683
The general answer I got was that Git isn't really crypto, because it isn't using the hash to guarantee integrity, but simply as a checksum to detect corruption.
I didn't find this argument very convincing at the time, and I would now offer the above quotation as evidence that people do in fact treat Git's hashes as a security mechanism that can withstand an adversarial attack.
[+] [-] DannyBee|12 years ago|reply
You'll see plenty of operations do not check the sha1, and will happily hand you bad data, including checkout and clone, depending on circumstances.
I haven't checked on the latest version, but at least previously, you'd have to run around using git fsck specifically to get it to notice some sha1 mismatches.
So at least trivially, the idea that "it uses sha-1 so it's safe" is silly even without considering the implementation, because it doesn't always check the sha-1 :)
(I'm not even going to argue it should, just pointing out it didn't)
You can also GPG sign git commits (see http://mikegerwitz.com/papers/git-horror-story.html for a long explanation of what does and does not get checked)
[+] [-] Karunamon|12 years ago|reply
That said, I'm not sure how you'd go about crafting source code in such a way as to collide with a known hash without it being amazingly obvious. You could change history to make it appear as if your crocked code was always there or had been for a long time, but then you don't have to figure just one hash, then you have to figure every single hash down to the parent. Depending on the number of commits, that's a hell of a lot of work, even with an algorithm to break SHA1.
And even then if you change the hashes, since Git is distributed, the developers will quickly figure out that what's in one repo doesn't match all the others when patches start breaking..
[1] - https://www.schneier.com/blog/archives/2005/02/cryptanalysis...
[+] [-] cliffbean|12 years ago|reply
Fortunately, one great thing about decentralized source control systems is that everyone has a copy of everything. Hopefully someone has simply located a repository which hasn't been updated since before the breach, and done some direct comparisons.
[+] [-] ams6110|12 years ago|reply
[+] [-] throwaway125|12 years ago|reply
Breaking out of virtual machines is a really interesting process but it's important to remember that a hypervisor can be attacked with pretty much the same techniques you can attack any other program. Virtual machines aren't a magic contain-all-the-hackers solution. There was an interesting talk on DEFCON 19 about breaking out of KVM: http://www.youtube.com/watch?v=tVSVdudfF8Q
[+] [-] res0nat0r|12 years ago|reply
[+] [-] aliguori|12 years ago|reply
If you break into QEMU, you should be a non-privileged user. If you are using libvirt, you are in a cgroup based jail (basically a container) with SELinux being enforced too. So after breaking into QEMU, you would still need to break out of the container before you could attack anything.
But Nelson's exploit was pretty cool. I initially thought remote code execution wasn't possible and he turned around pretty quickly with the exploit. It's quite impressive.
[+] [-] wmf|12 years ago|reply
[+] [-] meowface|12 years ago|reply
Considering the amateurish defacement, I think that's far more likely than some sort of a Xen/KVM breakout exploit. If there was such a zero-day, some group would probably be going after numerous providers in secret, not doing something like this.
[+] [-] andrewcooke|12 years ago|reply
also, will htp ever come back from exile? (not that it seems too unhappy where it is).
[+] [-] est|12 years ago|reply
[+] [-] xSwag|12 years ago|reply
Simple logic: The defacement was amature at best. If the group has a 0-day in a hypervisor they would have gone to multiple hosting companies and multiple attacks would have taken place, there are many more targets that are worth much more than openSSL.
Most likely, the administration panel of the hosting company was comprimised through malware/phishing. Seriously, if a group like this had a 0-day in hypervisor then they would be doing much much more damage.
[+] [-] beambot|12 years ago|reply
[+] [-] thirdsight|12 years ago|reply
"x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit.
You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes."
[+] [-] kyrra|12 years ago|reply
[0] http://www.openssl.org/news/secadv_hack.txt
[1] http://www.indithosting.se/
[+] [-] zurn|12 years ago|reply
"Virtually Impossible: The Reality Of Virtualization Security" talk video from 30C3 a few days ago: http://media.ccc.de/browse/congress/2013/30C3_-_5445_-_en_-_...
Slides from apparently same talk from Defcon Russia: http://www.slideshare.net/DefconRussia/gal-diskin-virtually-...
[+] [-] sneak|12 years ago|reply
I've been hearing this usage more often these days.
[+] [-] justincormack|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]