Stories
Slash Boxes
Comments

SoylentNews is people

posted by cmn32480 on Sunday February 26 2017, @09:42PM   Printer-friendly
from the just-take-it-out-back-and-shoot-it-already dept.

Thursday's watershed attack on the widely used SHA1 hashing function has claimed its first casualty: the version control system used by the WebKit browser engine, which became completely corrupted after someone uploaded two proof-of-concept PDF files that have identical message digests.

The bug resides in Apache SVN, an open source version control system that WebKit and other large software development organizations use to keep track of code submitted by individual members. Often abbreviated as SVN, Subversion uses SHA1 to track and merge duplicate files. Somehow, SVN systems can experience a severe glitch when they encounter the two PDF files published Thursday, proving that real-world collisions on SHA1 are now practical.

On Friday morning, the researchers updated their informational website to add the frequently asked question "Is SVN affected?" The answer:

"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."

Source: ArsTechnica


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Monday February 27 2017, @04:04PM

    by Anonymous Coward on Monday February 27 2017, @04:04PM (#472321)

    From the second cited source: "GIT strongly relies on SHA-1 for the identification and integrity checking of all file objects and commits."

    When I read the first time that git relies on the hash to identify versions (and that was even marketed as advantage), my very first thought was: Damn bad idea. Well, now I'm proven right. Well, it turns out that it's an even worse idea than I thought back then: I wasn't aware that you could actually break the complete repository with a hash collision.

    Lesson: Always keep your security measures independent from the actual function.

    Lesson 2: Hashes have collisions, period. If your system fails as soon as a collision occurs, it is broken. Yes, the collision may be unlikely, but never assume it is impossible. Especially if you are processing user-generated data, as users can be actively malicious.