Your message dated Sun, 17 Dec 2017 09:38:23 +0000 with message-id <[email protected]> and subject line Bug#884581: Removed package(s) from unstable has caused the Debian Bug report #741707, regarding md5 is insecure, even for obnam to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 741707: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741707 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: obnam Version: 1.6.1-1 Severity: important Tags: security Here's a feasible attack on obnam due to its use of md5. 1. Generate a a binary that is modified to contain a md5 colliding section. (Trivial.) 2. Find ways to upload files to lots of Debian systems that I want to attack later. This can be as simple as sending an email to a mailing list[1]. Or could as tricky as posting a comment to a blog that's full of binary spam. Use these methods to get the evil version of my binary onto the system's disk, it doesn't matter where on disk it's put. (Trivial.) 3. Some of those systems will be backed up with obnam. If the alignment gods are smiling (or if obnam uses rolling checksums?), the data I sent will start at the start of a block, so the colliding md5 will be used by obnam. (Requires luck, but it's easy to cast a wide net in step 2.) 4. Become Debian maintainer, ideally using a throwaway account or the old transnational republic ID card. Upload a Debian package containing the good version of my binary. (Trivial.) 6. Systems will back that up with obnam. Except, it has the same md5, so they'll reuse the data from the evil version that was previously backed up in step 3. 7. Wait for the backups to be restored, and game over. Due to this attack, I would much, much prefer obnam to use a hash that has good collision resistence. I suggest SHA-2 (possibly the 512 version as that's supposed to be faster on 64 bit), or possibly Skein. MD5 is the worst possible choice, and SHA-1 is not a wise choice. I would also recommend parametizing the hash used by obnam, so that if whatever hash you choose gets broken later, it can easily switch to its replacement. Workarounds: use --deduplicate=never (wastes disk space) or --deduplicate=verify (expensive over a network) or avoid restoring (at least) distribution provided files from obnam backups or use something like tripwire to layer better checksums on top, and verify that a restore restored the right versions of files before using it or separate different file sources (system, web, email etc) into separate obnam repositories -- see shy jo [1] Such as this one?! Eeek. Better check the headers for anything suspicious..
signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---Version: 1.22-1+rm Dear submitter, as the package obnam has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see https://bugs.debian.org/884581 The version of this package that was in Debian prior to this removal can still be found using http://snapshot.debian.org/. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing [email protected]. Debian distribution maintenance software pp. Chris Lamb (the ftpmaster behind the curtain)
--- End Message ---
