SoylentNews is people
SoylentNews
from the more-collisions-than-a-NASCAR-race dept.
PGP keys, software security, and much more threatened by new SHA1 exploit:
Three years ago, Ars declared the SHA1 cryptographic hash algorithm officially dead after researchers performed the world's first known instance of a fatal exploit known as a "collision" on it. On Tuesday, the dead SHA1 horse got clobbered again as a different team of researchers unveiled a new attack that's significantly more powerful.
The new collision gives attackers more options and flexibility than were available with the previous technique. It makes it practical to create PGP encryption keys that, when digitally signed using SHA1 algorithm, impersonate a chosen target. More generally, it produces the same hash for two or more attacker-chosen inputs by appending data to each of them. The attack unveiled on Tuesday also costs as little as $45,000 to carry out. The attack disclosed in 2017, by contrast, didn't allow forgeries on specific predetermined document prefixes and was evaluated to cost from $110,000 to $560,000 on Amazon's Web Services platform, depending on how quickly adversaries wanted to carry it out.
The new attack is significant. While SHA1 has been slowly phased out over the past five years, it remains far from being fully deprecated. It's still the default hash function for certifying PGP keys in the legacy 1.4 version branch of GnuPG, the open-source successor to PGP application for encrypting email and files. Those SHA1-generated signatures were accepted by the modern GnuPG branch until recently, and were only rejected after the researchers behind the new collision privately reported their results.
Git, the world's most widely used system for managing software development among multiple people, still relies on SHA1 to ensure data integrity. And many non-Web applications that rely on HTTPS encryption still accept SHA1 certificates. SHA1 is also still allowed for in-protocol signatures in the Transport Layer Security and Secure Shell protocols.
In a paper presented at this week's Real World Crypto Symposium in New York City, the researchers warned that even if SHA1 usage is low or used only for backward compatibility, it will leave users open to the threat of attacks that downgrade encrypted connections to the broken hash function. The researchers said their results underscore the importance of fully phasing out SHA1 across the board as soon as possible.
"This work shows once and for all that SHA1 should not be used in any security protocol where some kind of collision resistance is to be expected from the hash function," the researchers wrote. "Continued usage of SHA1 for certificates or for authentication of handshake messages in TLS or SSH is dangerous, and there is a concrete risk of abuse by a well-motivated adversary. SHA1 has been broken since 2004, but it is still used in many security systems; we strongly advise users to remove SHA1 support to avoid downgrade attacks."
(Score: 3, Informative) by Mojibake Tengu on Thursday January 09 2020, @10:29AM (8 children)
Not just git, but also mercurial, subversion, ...
Technically, we have no safe version control today.
Ignorance is a bliss.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 0) by Anonymous Coward on Thursday January 09 2020, @10:48AM (1 child)
What odds would you expect on being able to backdoor a commit in a way that results in a hash collision?
(Score: 5, Informative) by Lester on Thursday January 09 2020, @11:55AM
I think it is not easy.
Getting collisions usually implies creating a very different message with a lot padding data. That works well for formats where the visible part is small and there is a lot of unused bytes to get the right hash. i.e. a PDF, may have a lot of data that it is not shown anywhere with a reader.
In the case of software sources if not easy to hide. You need change a few sentences of code to make the backdoor, and then add a lot padding data to get the same hash, the padding data should be in a comment i..e. /* data....*/ to prevent compiler complains. nevertheless, the diff would be very evident, i.e. In the log you would see "changes from version X to X+1: 200 lines of code changed", you would say "what did they change?" and you would see 200 lines of gibberish commented in addition to the hack. That would trigger all alarms.
Nevertheless, It is dangerous, I am sure that there are a lot of bad guys smarter than me that will find a more subtle way.
(Score: 2) by PiMuNu on Thursday January 09 2020, @12:05PM (4 children)
> Technically, we have no safe version control today.
For clarity - is sha1 the algorithm used to compare two commits and determine if they are the same? Or is it the algorithm to prevent unauthorised access to e.g. github/gitlab repository (when I do git+ssh or git+https, github/gitlab checks that I am authorised to write to the repo).
Presumably the security threshold for the former is lower than for the latter.
(Score: 2) by Mojibake Tengu on Thursday January 09 2020, @12:25PM
With loss of object identity guarantee, expect fake history in breached repositories or mitm trojanized cloning.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 1, Informative) by Anonymous Coward on Thursday January 09 2020, @12:43PM
The attack is something like:
I make a pull request containing a useful change.
The pull request contains the signature of my change.
The innocuous code is reviewed and approved.
But when the pull is actually executed, I send a different change, with the same signature, that contains some sort of malware.
It would be possible for this to go unnoticed, as the modification would occur after code review and only looking at the actual diff after the fact would reveal it.
(Score: 0) by Anonymous Coward on Thursday January 09 2020, @10:06PM (1 child)
In a commit, the SHA-1 hash is of the text "commit $metadata_site_in_base_10" + null terminator + all the following data concatenated together: commit message, committer, commit date, author, author date, tree object hash, and a list of parent hashes. It is possible to substitute in a collision like that by changing information, but even with a chosen prefix attack, you still have to somehow get your data to line up correctly to be a valid commit. You could also change an object, but a chosen prefix attack doesn't really help you there either, as you'd still have to have two valid objects when finished with the process, which is only really an issue with file formats that let you add arbitrary garbage at the end.
(Score: 2) by driverless on Friday January 10 2020, @12:06PM
You would also need to do all that in close to real time, which can't happen for any of the attacks on SHA-1 or even the older, even more broken MD5.
(Score: 2) by maxwell demon on Thursday January 09 2020, @02:42PM
No, to my knowledge only git made the SHA1 key double as the revision number.
The Tao of math: The numbers you can count are not the real numbers.