Torvalds Downplays SHA-1 Threat to Git

Torvalds Downplays SHA-1 Threat to Git

When researchers demonstrated the first practical collision attack for the cryptographic hash function SHA-1 last week, they also identified related v

Paper Spells Out Tech, Legal Options for Encryption Workarounds
Google details how it will overturn encryption signals in Chrome
Look before you leap: 4 hard truths about IoT

When researchers demonstrated the first practical collision attack for the cryptographic hash function SHA-1 last week, they also identified related vulnerabilities impacted by the now-compromised algorithm.

According to the SHAttered research post, co-authored by Google and a host of cryptography experts, the popular Apache Subversion repository is vulnerable to corruption via SHA-1 collided files. Researchers also warned that git, a version control system for software used by developers, is also vulnerable to SHA-1 related attacks.

According to researchers, in the case of git, because it strongly relies on SHA-1 for the identification and integrity checking of all file objects and commits, there is a window of opportunity for an attack.

“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 back-doored one. An attacker could potentially selectively serve either repository to targeted users. This will require attackers to compute their own collision,” according to the SHAttered report.

“The sky isn’t falling,” said Linux kernel creator Linus Torvalds in a blog post over the weekend.

“There’s a big difference between using a cryptographic hash for things like security signing, and using one for generating a ‘content identifier’ for a content-addressable system like git,” he wrote.

Torvalds noted that the nature of the SHA-1 git attack would be easy to mitigate against as well. “If you host your project on something like http://github.com or kernel[.]org, it’s already sufficient if the hosting place runs the checks every once in a while–you’ll get notified if somebody poisoned your well,” Torvalds wrote.

According to Kevin Bocek, chief security strategist for Venafi, running checks might not be sufficient enough, however. “While Torvalds argues that the necessary hacks for this would be obvious since they’d introduce changes to code, flaws in open source code can go unnoticed for years. Several recent high-profile vulnerabilities, such as Heartbleed, did just that,” Bocek said.

Torvalds touches on this concern in his post. “The git internal data structures are actually very transparent too, even if most users might not consider them so. There are places you could try to hide things in (in particular, things like commits that have a NUL character that ends printout in ‘git log’), but ‘git fsck’ already warns about those kinds of shenanigans,” he wrote.

Even if flaws went unnoticed, Torvalds said, “Git will eventually transition away from SHA-1″. There’s a plan, it doesn’t look all that nasty, and you don’t even have to convert your repository.” He didn’t mention a timeline in his post only noting, “it’s not like this is a critical ‘it has to happen now thing’.”

Apache Subversion Vulnerable Too

As part of its SHAttered report, researchers are also warning the popular Apache Subversion (SVN) repository, used by software developers of FreeBSD, SourceForge and CodePlex, is vulnerable to corruption if SHA-1 collided files are added to the repository.

“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,” the SHAttered report warned.

Nick Sullivan, cryptography expert at Cloudflare, points out the Apache Subversion flaw only becomes a vulnerability when the rep-sharing feature that deletes duplicate files is turned on. If two different files are placed into the same repository that have the same hash the rep-sharing feature will be corrupted and not work, he said.

“The worst you could do as an attacker would be to cause people interacting with a repository to not be able to use certain third-party tools or any tool that uses the rep-share tool,” Sullivan said.

It’s important not to conflate the issues of the onerous task of finding a new SHA-1 collision and how SHA-1 collided files can be used in SVN repositories to corrupt them, he said.

“This is a story about SHA-1 being used as an identifier in SVN. How expensive it is to find a new (SHA-1) collision is irrelevant to this bug because all you need to do is use the collision that already exists,” he said.

Go to Source

COMMENTS