Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security Google Apache

Apache Subversion Fails SHA-1 Collision Test, Exploit Moves Into The Wild (arstechnica.com) 167

Posted by EditorDavid from the making-a-hash-of-it dept.
WebKit's bug-tracker now includes a comment from Friday noting "the bots all are red" on their git-svn mirror site, reporting an error message about a checksum mismatch for shattered-2.pdf. "In some cases, due to the corruption, further commits are blocked," reports the official "Shattered" web site. Slashdot reader Artem Tashkinov explains its significance: A WebKit developer who tried to upload "bad" PDF files generated from the first successful SHA-1 attack broke WebKit's SVN repository because Subversion uses SHA-1 hash to differentiate commits. The reason to upload the files was to create a test for checking cache poisoning in WebKit.

Another news story is that based on the theoretical incomplete description of the SHA-1 collision attack published by Google just two days ago, people have managed to recreate the attack in practice and now you can download a Python script which can create a new PDF file with the same SHA-1 hashsum using your input PDF. The attack is also implemented as a website which can prepare two PDF files with different JPEG images which will result in the same hash sum.
This discussion has been archived. No new comments can be posted.

Apache Subversion Fails SHA-1 Collision Test, Exploit Moves Into The Wild More

Apache Subversion Fails SHA-1 Collision Test, Exploit Moves Into The Wild

Comments Filter:

  • In other news (Score:1)

    by Anonymous Coward

    Webkit is apparently on SVN repository.

    • And that's the problem, that SVN has crap handling of colliding values. They use their own homebrew NoSQL store, FSFS, which doesn't handle things like duplicates in any way because it's NoSQL and web scale and stuff, like MongoDB [youtube.com]. So the message here is "don't build your app around a crap NoSQL database store", not "SHA-1 will kill you".

      Anyway, I've gotta get back to my job shovelling pig shit, and administering anal suppositories to sick horses.

  • It's now time to retire SVN... everywhere... permanently.

    • Re: (Score:1)

      by Anonymous Coward

      If you don't like it, don't use it. Personally, I love it.

    • Re: (Score:3, Funny)

      by espenskaufel ( 4657525 )
      I do not understand why many developers feel so strongly about versions control systems. I wonder if carpenters feel the same way about hammers or if developers are just way to opinionated...

      • Pretty sure they do.

      • I wonder if carpenters feel the same way about hammers

        Hahahah tip of the iceberg. I saw two carpenters on my house arguing about who had better screwdrivers. Yes people most definitely do.

      • I wonder if carpenters feel the same way about hammers or if developers are just way to opinionated...

        Yeah, typical carpenter hammer arguments:

        *) Hammer weight (usually 16-24oz for house framing)
        *) Handle type (wood? Fiberglass? (fiberglass hammers suck tbh))
        *) Is the face of the hammer smooth or textured?

  • "In the wild" - slight exaggeration (Score:3)

    by geekpowa ( 916089 ) on Sunday February 26, 2017 @04:49PM (#53935071)

    Someone checked in PDFs that demonstrate the first engineered SHA-1 collision and this broke SVN. PDFs in question took 6500+ cpu years + 110 GPU years to generate. "In the wild" is a bit panicky & excessive.

    What does this actually means in terms of integrity of repos and other things that rely on SHA-1? Does it merely break repos or does it facilitate injection attack vectors - how important is secure hashing in the guts of repos? What precisely is being secured? SHA-1 has been deprecated for SSL certs already so you shouldn't be using certs with SHA1 sigs anymore. Myself, keep an eye on how this develops and start thinking about using SHA-2 but won't be replaing git or existing usage of SHA1 for password hashing anytime soon.

    • In today's world of large botnets and distributed computing 6500+ cpu years + 110 GPU years is not a particularly daunting number.

    • "In the wild" is a bit panicky & excessive.

      No, it's really not. This demonstrates that SHA-1 is not only weak, but broken. One golden rule about security is that it never improves over time. It means that collisions are now possible, and are within reach of moderate sized organisations. Google can clearly manage, governments certainly can and any criminal organisation with a large enough botnet can manage too. This isn't just finding random data either: it's a practical attack whereby two valid PDFs bot

      • This. It is safe to say SHA-1 is effectively broken at this point and existing users should start migrating to better alternatives.

        But let's not panic either. The world is not crumbling down to pieces anytime soon.

      • "not only weak, but broken" seems premature. The attack here involves manipulating two obtuse file formats to yield altered files with a shared hash, different to original unaltered hashes. Definitely weakened and yeah you are probably right this is the final toll for SHA-1 and from here things are likely to get worse quickly. I'll be mindful of this when I think about the various places where I use SHA-1 and start thinking about switching in other things. But I am failing to see how this right now transl

        • "not only weak, but broken" seems premature. The attack here involves manipulating two obtuse file formats to yield altered files with a shared hash, different to original unaltered hashes.

          It took less than 3 years for MD5 to go from "first collisison" to "can fake certificate trust chains".

          . But I am failing to see how this right now translates into a practical vector for the various places where I encounter SHA-1.

          But don't forget that the open literature discovered an as-yet-unknown attack against MD5 in

      • Re: (Score:3)

        by guruevi ( 827432 )

        Say it with me: Hashing is not Encryption. Hashing is not Encryption. Hashing is not Encryption.

        Very high level:
        Hashing is the irreversible mapping of a set of bits onto a (usually smaller) set of bits in order to obfuscate the original set of bits (one-way)
        Encryption is the mapping of a set of bits onto another equally sized set of bits where the mapping is reversible through some process (two-way)

        Hashing can be done with salts so that using rainbow tables is harder or impossible, but there will always be

      • It means that collisions are now possible, and are within reach of moderate sized organizations.

        This is the key. 6500 CPU years or 110 GPU years of computational power is not that difficult to achieve. When this news broke last week a few of us at my work had a discussion about it and while those number sound impressive we then realized that at work we have access to probably 2x that processing power in our building.

    • Right, it is still just like Linus said about the git sha-1, not really a big deal because it isn't even the security layer.

      If developers with write access to your repo are malicious, you have much worse problems. This is not a serious threat, it is just an edge case that the future will prevent.

      The real lesson IMO is, if you do roll your own security, use a library for the password hashing. And if the algorithm ends up having been the wrong one, you'll just update the library. If it is on the network, use

      • Re: (Score:2)

        by tlhIngan ( 30335 )

        If developers with write access to your repo are malicious, you have much worse problems. This is not a serious threat, it is just an edge case that the future will prevent.

        What if they aren't malicious? I mean, WebKit SVN is down not because a developer wanted to try it, but because they were submitting a test case. A test case meant to verify that WebKit's caching algorithms aren't vulnerable to a SHA-1 collision.

        And in checking in this test case, he inadvertently broke the entire repository. It's complet

        • None of that has meaning or value.

          This doesn't crash anything, and a test case meant to do some shit that it doesn't do well doesn't cause a problem other than for that test case. There is no bad thing happening in your story, just somebody has some shitty code.

          Then you wave your hands and say, "he inadvertently broke the entire repository."

          There is no worry that repositories would, or even might, or even could, because irreparable. That's just making shit up wildly. The speculation in the stories were goin

    • Re: (Score:3)

      by guruevi ( 827432 )

      If someone checked in, that means they have permissions to do so. It's not like Git just blindly accepts commits with the same hash but different contents. We know it's possible, it's even possible with SHA256 to create a collision, as long as you're making a hash, you can create a collision as you're mapping an infinite set of bits onto a finite set of bits, there will always be a second set of bits that creates a collision as the number of sets approaches infinity regardless of the hash function you use.

      T

  • I am trying to read their paper on the sha1 collisions over here: https://shattered.io/static/sh... [shattered.io] and there's some unusual equation stuff.

    mi = (mi3 mi8 mi14 mi16)1

    Can anyone explain that to me in english?

  • Hash Functions 101 (Score:5, Informative)

    by FeelGood314 ( 2516288 ) on Sunday February 26, 2017 @07:45PM (#53935723)
    A hash function takes an arbitrary string of bits and outputs a string of bits of a fixed length.
    A CRC is an example of a hash function and a long CRC would probably be good enough for GIT or most repositories.
    First Pre-image resistance - this is a test of the one wayness of the function. Given a hash value it is difficult to find a pre-image that hashes to that value. Given y a string of bits of length hash output length finding X such that h(X) = y is hard.MD-5 and SHA-1 are still resilient against first pre-image attacks
    Second Pre-image resistance - given a message X finding a Y such that h(X)=h(Y) is difficult. MD-5 and SHA-1 are still resilient against second pre-image attacks
    Collision resistant - It is hard to find two messages X and Y such that h(X) = h(Y). Note the attacker here is free to choose both X and Y. Both MD-5 and SHA-1 are no-longer collision resistant.

    So far however the two messages X and Y have to be nearly identical. They have to start and end the same way and the blocks that are changed actually have to be changed and tested together to make sure the hash function internal state changes only in a specific way. I can't create a document that says the rent will be $3000 per month and another that says it will be $30000. (I might create one that says it is $3149.21 and the other $53210.63 per month, like in the PDF example they played with a colour field). Also because of the way the internal state of the hash function changes we now have a way of detecting if someone is feeding a "funny" stream of bits into our hash function and detect this attack with a very low probability of a false positive.
    • This still can be weaponized. Even if I only have two bit streams that start the same and then only differ in a block that I couldn't control I can still create malicious executables. Once I have the two streams that collide as long as the bits I add to both streams are identical the hashes will remain identical. I then have code after the differing block(s) that checks a value of a field in the differing blocks and behaves differently based on this value. I now have a good executable that is well behav

Slashdot Top Deals

"Mach was the greatest intellectual fraud in the last ten years." "What about X?" "I said `intellectual'." ;login, 9/1990

Close