Lucian Constantin
CSO Senior Writer

SHA-1 collision can break SVN code repositories

News
Feb 27, 20174 mins

The WebKit repository was corrupted after someone committed two colliding PDF files to it

A recently announced SHA-1 collision attack has the potential to break code repositories that use the Subversion (SVN) revision control system. The first victim was the repository for the WebKit browser engine that was corrupted after someone committed two different PDF files with the same SHA-1 hash to it.

The incident happened hours after researchers from Google and Centrum Wiskunde & Informatica (CWI) in the Netherlands announced the first practical collision attack against the SHA-1 hash function on Thursday. Their demonstration consisted of creating two PDF files with different contents that had the same SHA-1 digest.

This proved without a doubt that SHA-1 is cryptographically broken because a hash function should always produce different digests (hashes) for different pieces of data or files. SHA-1 is a hash function used to calculate an alphanumeric string that serves as the cryptographic representation of a file or a piece of data. 

A WebKit developer wanted to build a test to prove that the demonstrated collision can’t be used for cache poisoning in the context of WebKit’s disk cache deduplication feature that relies on SHA-1. In order to do this, he uploaded the two PDF files generated by CWI and Google to the WebKit SVN which then started giving out errors.

It seems that even after removing the files, some problems remained and further manual intervention was required to fix them.

The issue is not specific to WebKit’s repository, but to all SVN-based repositories. The Subversion developers have released a script that SVN administrators can use to prevent SHA-1 colliding files from being committed to their repositories. Meanwhile, work for a more permanent fix is in progress.

Git, a competing and more popular version control system, also uses SHA-1 internally, and according to the CWI and Google researchers, is theoretically vulnerable.

“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,” the researchers said on their shattered.io website. “An attacker could potentially selectively serve either repository to targeted users.”

This kind of attack would require attackers to compute their own collision, which at this time requires significant resources. It took Google over nine quintillion SHA-1 computations, the equivalent of a year of continuous computations on 110 GPUs or 6,500 CPUs.

Linus Torvalds, the founder of both Linux and git, doesn’t seem too concerned about the attack’s implications, partly because it can be easily deterred by adding some simple checks that would make an attack not worth it.

“Unlike some ‘signing a pdf’ attack, git doesn’t fundamentally depend on the SHA1 as some kind of absolute security,” Torvalds said in a discussion on the git mailing list. “If we have the minimal machinery in git to just notice the attack, the attack essentially goes away. Attackers can waste infinite amounts of CPU time, and if it’s cheap for us to notice, it completely disarms all that attack work.”

Later in that same discussion, the git developers decided to use the collision detection code provided by the CWI researchers to build some protection. Meanwhile moving git to another hash function is being discussed as a goal and SHA3 seems to be the chosen candidate because it has better performance than SHA2.

“I doubt the sky is falling for git as a source control management tool,” Torvalds concluded in one of his emails. “Do we want to migrate to another hash? Yes. Is it ‘game over’ for SHA1 like people want to say? Probably not.”

Even though it’s been known for a long time that SHA-1 is theoretically vulnerable to collision attacks, the real-world implications of a practical attack for file synchronization, deduplication and backup systems, in particular, are yet to be seen. In 90 days, the Google and CWI researchers plan to disclose the code they used to generate the colliding PDF files, which will allow others to create similar collisions, if they have the necessary computing resources.

Lucian Constantin

Lucian Constantin writes about information security, privacy, and data protection for CSO. Before joining CSO in 2019, Lucian was a freelance writer for VICE Motherboard, Security Boulevard, Forbes, and The New Stack. Earlier in his career, he was an information security correspondent for the IDG News Service and Information security news editor for Softpedia.

Before he became a journalist, Lucian worked as a system and network administrator. He enjoys attending security conferences and delving into interesting research papers. He lives and works in Romania.

You can reach him at lucian_constantin@foundryco.com or @lconstantin on X. For encrypted email, his PGP key's fingerprint is: 7A66 4901 5CDA 844E 8C6D 04D5 2BB4 6332 FC52 6D42

More from this author