The SHA-1 collision attack unveiled on Thursday has claimed its first victim, with the version control system used by the WebKit browser engine becoming corrupted after the two proof-of-concept PDF files that were released by the researchers were uploaded to the repository.
A Dutch team from the Centrum Wiskunde and Informatica research centre in Amsterdam and Google announced on Thursday that they developed a method to crack the SHA-1 algorithm that has been used for a long time to verify the authenticity of digital documents.
As part of the detailed write-up about their achievement, the researchers also released two PDFs as proof, with both having identical SHA-1 hashes but different content.
These were uploaded to the WebKit repository by an unknown individual.
{loadposition sam08}The corruption at the WebKit repository was due to a bug in Apache SVN and occurred on Thursday night, Ars Technica reported. Apache SVN is used by many projects to keep track of code submissions and uses SHA-1 to track files and avoid duplication.
The researchers behind the SHA-1 collision added some words of caution about SVN to their FAQ after the WebKit incident.
Graphic: courtesy Google.
They posed the query "Is SVN affected?" and said, "Yes – please exercise care, as SHA-1 colliding files are currently breaking SVN repositories. Subversion servers use SHA-1 for deduplication and repositories become corrupted when two colliding files are committed to the repository.
"This has been discovered in WebKit's Subversion repository and independently confirmed by us. Due to the corruption the Subversion server will not accept further commits."
The issue was spotted by developer Antti Koivisto who wrote: "Looks like https://bugs.webkit.org/show_bug.cgi?id=168774 caused some sort of SVN problem. Please hold commits until this is resolved."
He was referring to a bug report about the corruption.
Another developer, Alexey Proskuryakov, wrote that the repository needed to be cleaned up and that parts of it were still broken despite his removing one of the PDF files.
"I deleted the remaining PDF file from resources, so svn checkout now works. There is almost certainly more cleanup that needs to be done – I can see that trac.webkit.org <http://trac.webkit.org> is broken. Please reply to the thread about what else you see not working," he urged.
The issue does not appear to be fixed yet.
The Dutch and Google researchers had earlier posted a query about git, the version control system used by the Linux kernel and numerous other projects.
"git strongly relies on SHA-1 for the identification and integrity checking of all file objects and commits. It is essentially possible to create two GIT repositories with the same head commit hash and different contents, say a benign source code and a backdoored one," they wrote.
"An attacker could potentially selectively serve either repository to targeted users. This will require attackers to compute their own collision."
But the author of git, Linux creator Linus Torvalds, gave a different opinion when he was asked on the git mailing list for git whether it would move to a more secure hashing system.
Torvalds replied: "I don't think you'd necessarily want to change the size of the hash. You can use a different hash and just use the same 160 bits from it."
When it was pointed out to him that since there were collisions in valid PDF files, collisions in valid git commit and tree objects could probably be constructed, Torvalds said git did not actually just hash the data, it prepended a type/length field to it.
"That usually tends to make collision attacks much harder, because you either have to make the resulting size the same too, or you have to be able to also edit the size field in the header," he said.
"PDFs don't have that issue, they have a fixed header and you can fairly arbitrarily add silent data to the middle that just doesn't get shown. So PDFs make for a much better attack vector, exactly because they are a fairly opaque data format. Git has opaque data in some places (we hide things in commit objects intentionally, for example, but by definition that opaque data is fairly secondary.
"Put another way: I doubt the sky is falling for git as a source control management tool. Do we want to migrate to another hash? Yes. Is it 'game over' for SHA-1 like people want to say? Probably not.
"I haven't seen the attack details, but I bet:
"(a) the fact that we have a separate size encoding makes it much harder to do on git objects in the first place; and
"(b) we can probably easily add some extra sanity checks to the opaque data we do have, to make it much harder to do the hiding of random data that these attacks pretty much always depend on."
The researchers also said that from version 56 onwards, the Chrome browser, which is owned by Google, would start considering any website protected by SHA-1 to be insecure. Version 56 was released in January. Firefox has deprecated SHA-1 as of 24 February.