* Anthony Towns: > On Sat, Nov 26, 2005 at 10:59:57AM +0100, Florian Weimer wrote: >> For the "exploits" we have seen so far to work, the malicious party >> needs upload access to the archive and has to plant a specially >> crafted package there, for which they have created an evil twin >> package. (Same for attacking one of the text files listing hashes.) >> Looks a bit far-fatched to me. > > Not really. Joining Debian isn't particularly difficult, and it might > not even be out of the question to find someone who'll sponsor an upload > without rebuilding the .deb. I think it's safe to imagine that there are > developers right now who've done some shady things in the past; is it > that far fetched to imagine it's worth protecting against developers > who try to abuse their priveleges?
No, but they can directly upload a bad package. No need to create an MD5 collision and sneak the "evil twin" package into some mirror archive. > The way we do that has to be mostly after the fact, of course: someone > uploads a bad package, people find out it's bad, we trace it back to > whoever uploaded it, then we kick them out of the project. Have we already done that? Have we expelled people becaue they put vulnerable code into Debian? > But that only works if the bad package is actually discovered. If the > .deb's distributed across hundreds of mirrors and to thousands of users, > it's reasonably likely that it will be discovered; but if it's possible > to target the attack against an individual user, and leave the rest of > the Debian universe untouched, you've got a much better chance of > not getting caught. Hence: distribute an iced .deb in the archive, that > does no harm ever and thus needn't arouse any suspicion; and sneak a > fire .deb that has the exploit activated onto the mirror of your target. You can embed code that checks for characteristics of the victim system and activate the attack only if there's a match. The advantage is that you need only to compromise a DD account (or become a DD yourself), and not both a DD account and part of the mirror cascade which is used by the victim. > "Looks a bit far-fetched" comes under the "famous last words" heading > for security analysis. One part of security analysis is figuring out which potential attacks are relevant. Keep in mind that most attacks never happen. There's no point in wasting resources on irrelevant attacks. It's embarrassing to be wrong on such matters, in both directions. Money thrown at a problem that turns out to be a non-issue is money lost. But you hardly ever read about those failures. There is one attack on MD5 which is a significant threat to many companies: the PR attack. There are many, many security experts who are all too willing to label your system as broken just because it uses MD5 internally. With the right media spin, such claims of insecurity can become a PR nightmare and very costly. > Worse, the existance of a practical md5(A+B+C)=md5(A+D+C) attack means > that it's not out of the question that there're md5(A+B)=md5(C+D) > attacks in the hands of particularly well resourced groups (which is > worse, since the version uploaded to the archive could then be entirely > innocent looking). Personally, I don't have any interest in making the > NSA's job any easier, or that of other signals intelligence groups. Oh, many Debian packages happily leak so much data over the network that I often wonder if it is feasible to create user profiles using this information. 8-) > SHA256 is better than SHA1 in the same way 2048 bit RSA keys are better > than 512 bit RSA keys. No, the algorithms are somewhat different. It's easy to build a 256 bit hash which is less secure than a 160 bit hash, so it's not really comparable to the RSA situation. > MD5 is broken, and isn't extensible. SHA1 is fragile, but not > broken, and is extensible. What do you mean with "extensible"? Both MD5 and SHA1 are based on MD4, and SHA256 is based on SHA1, but AFAIK, no rationale for the changes from MD4 -> SHA1 and SHA1 -> SHA256 has been published. (Ron Rivest explained his changes from MD4 to MD5.) >> In terms of security, there are some better hash functions. > > My understanding was that there aren't other hash functions that've had > remotely similar levels of cryptographic analysis to md5 and sha. Neither MD5 nor SHA1 have received much public scrutiny. Dobertin's work on MD5 has never been fully published. I've already joked that the difference between Wang et al. and European or U.S. cryptographers is that the Chinese government doesn't tell their researchers not to publish their results. 8-P > IIRC, the elliptic curve cryptography stuff was supposed to be > similarly neat, until people started analysing it seriously, at > which point it broke. The NSA has recently licensed ECC patents from Certicom. There are weak elliptic curves as far as cryptography is concerned, but there are also others: inefficient ones and those which have been patented by Certicom. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
