Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Mon, 2012-10-15 at 13:46 -0400, Michael Gilbert wrote: Are there bug reports with a clear description of the problem, preferably with a proposed fix? Discussion doesn't really get us anywhere. Useful info and actual efforts at fixing problems do. Well it's not that easy in that areas to write simple small issues, when you look back at the discussions from then you probably see why. In small excerpts and short: The most simple form of attacking someone is by using security issues that are know (e.g. because they were fixed in recent versions). So one attack vector would be to prevent that your target doesn't get these updates (which is why they're called blocking). That may e.g. be done by people being in the middle of your line, or having control over your mirror. What do users typically do to stay current? Either they manually update, or they have an auto-update program, or e.g. a Nagios/Icinga check like check_apt. All of this critically depends on the most recent repository data being available. Few isolated issues I found that could now lead to security issues: 1) Programs (I usually mean apt or aptitude here don't give exit statuses != 0 in all cases when something critical has happened. e.g. apt-get update returns 0 even if the update failed. E.g. a cluster operator may have done the following: Added a cron job that calls apt-get update daily and reports an error if $? != 0. Run check_apt via Nagios/Icinga to be notified on updates. An attacker simply blocking the update as described above may now easily prevent updates from being installed. 2) downgrade attacks These have the same idea as blocking attacks (prevent the user to get updates) but are a bit smarter. You don't simply block any update requests, but rather you sent the user old repository data. These are correctly signed by Debian... just... they are old and do not yet know about the updates. The only way of preventing this was, if apt/aptitude would utterly bail out/print error messages/give non-zero exit statuses if the repo-data they are working on are older than some well thought time interval (typically that would be something around the mirror update interval). Of course the time of a Release file would have to be signed ;) And of course it would be the duty of a user to make sure he has a correct time source. But at least now he'd have a chance to have a fully secured chain. 3) There were some other potential issues... where I just suspected that things could be problematic... but where I didn't know how to exactly check this. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On 19 October 2012 09:19, Christoph Anton Mitterer cales...@scientia.net wrote: 1) Programs (I usually mean apt or aptitude here don't give exit statuses != 0 in all cases when something critical has happened. The apt-utils are mostly ok at aborting with non-zero for critical errors. Aptitude is not. e.g. apt-get update returns 0 even if the update failed. This is only for transient errors (such as connection problems) printed with a “W:” label. If a Release file is expired or otherwise invalid the exit status is reliably non-zero. After Wheezy it may be useful to look at using $? = 1 (or 2) to indicate these transient errors (or just consider them the same as the other errors). Calling programs could then retry the update, or switch to a different mirror, which may resolve the issue. If the calling program doesn't care it can test for $? != 0 to catch *all* errors, or $? = 100 for only serious errors. E.g. a cluster operator may have done the following: Added a cron job that calls apt-get update daily and reports an error if $? != 0. Run check_apt via Nagios/Icinga to be notified on updates. An attacker simply blocking the update as described above may now easily prevent updates from being installed. For a short time. Eventually “update” will (or should!) complain about the expired Release files, $? != 0. 2) downgrade attacks These have the same idea as blocking attacks (prevent the user to get updates) but are a bit smarter. You don't simply block any update requests, but rather you sent the user old repository data. These are correctly signed by Debian... just... they are old and do not yet know about the updates. The only way of preventing this was, if apt/aptitude would utterly bail out/print error messages/give non-zero exit statuses if the repo-data they are working on are older than some well thought time interval (typically that would be something around the mirror update interval). Of course the time of a Release file would have to be signed ;) And of course it would be the duty of a user to make sure he has a correct time source. But at least now he'd have a chance to have a fully secured chain. Security and -updates Release files use Valid-Until which partially addresses this. I think this will only trigger an error on “apt-get update”, not “install” or “upgrade”. Presumably update scripts use “update” before “upgrade” and check the status of the former. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/can3verfa9tewymwfmsztpz8hf6inwfk3rxnfrgstnxbzz8m...@mail.gmail.com
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Thu, Oct 18, 2012 at 9:19 PM, Christoph Anton Mitterer wrote: 2) downgrade attacks These have the same idea as blocking attacks (prevent the user to get updates) but are a bit smarter. You don't simply block any update requests, but rather you sent the user old repository data. These are correctly signed by Debian... just... they are old and do not yet know about the updates. The only way of preventing this was, if apt/aptitude would utterly bail out/print error messages/give non-zero exit statuses if the repo-data they are working on are older than some well thought time interval (typically that would be something around the mirror update interval). Of course the time of a Release file would have to be signed ;) The release files *are* signed. Try using snapshot.debian.org (older than 2 weeks I think) as an apt source. It will fail loudly that the release file is expired. This is a whole lot of speculation about things that are already handled. Please think about how you could demonstrate to yourself before pressing it on the rest of the world. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mnhk-q0uwpnki75ryan2s5b-nmo3oecrfwstwxg7ej...@mail.gmail.com
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Mon, Oct 15, 2012 at 02:58:15AM +0200, Christoph Anton Mitterer wrote: debsums is intended primarily as a way of determining what installed files have been locally modified by the administrator or damaged by media errors and is of limited use as a security tool. If you are looking for an integrity checker that can run from safe media, do integrity checks on checksum databases and can be easily configured to run periodically to warn the admin of changes see other tools such as: aide, integrit, samhain, or tripwire. I never claimed (and already explicitly said that before) that it was intended to be used for that,... or that I would do or recommend so... I never said you did. -- WBR, wRAR signature.asc Description: Digital signature
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Sun, Oct 14, 2012 at 9:08 PM, Christoph Anton Mitterer wrote: If so, please submit bugs, and we will look at fixing them. Otherwise, speculation gets us nowhere and actually wastes time. Well I had once a discussion (around March this year) here about blockin/downgrade attacks... which, AFAICS, both are possible in secure APT right now but there was no real outcome. Unforunately it seems that people do not take these higher-level attacks really serious even though the danger they impose is quite high. Are there bug reports with a clear description of the problem, preferably with a proposed fix? Discussion doesn't really get us anywhere. Useful info and actual efforts at fixing problems do. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MOLY-7t_=-zboabthnmqg7j9h7wxbqs_k+2up6v84+...@mail.gmail.com
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On 15 October 2012 18:46, Michael Gilbert mgilb...@debian.org wrote: On Sun, Oct 14, 2012 at 9:08 PM, Christoph Anton Mitterer wrote: If so, please submit bugs, and we will look at fixing them. Otherwise, speculation gets us nowhere and actually wastes time. Well I had once a discussion (around March this year) here about blockin/downgrade attacks... which, AFAICS, both are possible in secure APT right now but there was no real outcome. Unforunately it seems that people do not take these higher-level attacks really serious even though the danger they impose is quite high. Are there bug reports with a clear description of the problem, preferably with a proposed fix? Discussion doesn't really get us anywhere. Useful info and actual efforts at fixing problems do. So far no bugs or problems were uncovered. So nothing to file or fix ;-) I can think of adding SHA-3 hashes... but none of the tools support it yet, so it's future wishlist bug, which I am sure will be acted upon at an appropriate time and doesn't need a bug filed at present time. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlugzqkk5li8k4xr67g25dlntedivrxlwxatguzosfap...@mail.gmail.com
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
* Wouter Verhelst wou...@debian.org [121013 10:56]: On Fri, Oct 12, 2012 at 09:17:32AM +0200, Bernhard R. Link wrote: part at all) will only weaken security. So I think what you say is an argument for keeping md5sum, so that noone think they can use that information for security. This argument is based on the incorrect assumption that everyone in the world knows md5 is broken. No it is based on the assumption that in that set of people that care about security at all but have little enough knowledge of security to mix up protection against faulty hardware with protection against attackers there is at least one user having heared the meme md5 considered broken and might combine those half-knowledges to the correct result that debsums is not about security against attackers. Causing at least one user to not think they could use debsums as protection against wilfull file modification by sticking with md5 is (given there are no benefits from switching hashes at all) a very strong argument that switching hashes for debsums to stick to the hashes it uses. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121014111405.ga15...@client.brlink.eu
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Sun, Oct 14, 2012 at 01:14:19PM +0200, Bernhard R. Link wrote: part at all) will only weaken security. So I think what you say is an argument for keeping md5sum, so that noone think they can use that information for security. This argument is based on the incorrect assumption that everyone in the world knows md5 is broken. No it is based on the assumption that in that set of people that care about security at all but have little enough knowledge of security to mix up protection against faulty hardware with protection against attackers there is at least one user having heared the meme md5 considered broken and might combine those half-knowledges to the correct result that debsums is not about security against attackers. Causing at least one user to not think they could use debsums as protection against wilfull file modification by sticking with md5 is (given there are no benefits from switching hashes at all) a very strong argument that switching hashes for debsums to stick to the hashes it uses. For the reference: the manpage says: debsums is intended primarily as a way of determining what installed files have been locally modified by the administrator or damaged by media errors and is of limited use as a security tool. If you are looking for an integrity checker that can run from safe media, do integrity checks on checksum databases and can be easily configured to run periodically to warn the admin of changes see other tools such as: aide, integrit, samhain, or tripwire. -- WBR, wRAR signature.asc Description: Digital signature
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Sun, 2012-10-14 at 17:25 +0600, Andrey Rahmatullin wrote: debsums is intended primarily as a way of determining what installed files have been locally modified by the administrator or damaged by media errors and is of limited use as a security tool. If you are looking for an integrity checker that can run from safe media, do integrity checks on checksum databases and can be easily configured to run periodically to warn the admin of changes see other tools such as: aide, integrit, samhain, or tripwire. I never claimed (and already explicitly said that before) that it was intended to be used for that,... or that I would do or recommend so... just that people might and that it already happens more or less (rkhunter has a mode of doing so, IIRC). Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Fri, 2012-10-12 at 16:52 -0400, Michael Gilbert wrote: On Fri, Oct 12, 2012 at 4:45 PM, Christoph Anton Mitterer wrote: I wasn't talking about such an impossible task,... but there speaks nothing against relatively easy things,... like securing all of our package repository infrastructure by strong algos (as we already did)... and trying to prevent higher level attacks, like downgrade attacks. Do you have evidence of any of those things? Well as I said previously, in security one should usually not try to only take measures against things one can identify as a problem right now. Especially if there's no considerable disadvantage, then I see no good reason for not using the strongest (in this specific example) hash algorithms available. Now the argument some people threw in, that debsums should stay at MD5 to already hint that it shouldn't be used for intrusion detection: - It's much better than to clearly document that this shouldn't be used in that way (which is already done)... and then use a algo that provides a good trade off between speed and hash quality (MD5 might be just that...). - I still think that one may build up a system using debsums that is equally secure than what AIDE and friends do. At least I see no reason speaking against. If so, please submit bugs, and we will look at fixing them. Otherwise, speculation gets us nowhere and actually wastes time. Well I had once a discussion (around March this year) here about blockin/downgrade attacks... which, AFAICS, both are possible in secure APT right now but there was no real outcome. Unforunately it seems that people do not take these higher-level attacks really serious even though the danger they impose is quite high. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Fri, Oct 12, 2012 at 09:17:32AM +0200, Bernhard R. Link wrote: part at all) will only weaken security. So I think what you say is an argument for keeping md5sum, so that noone think they can use that information for security. This argument is based on the incorrect assumption that everyone in the world knows md5 is broken. (Heck, I'm sure I can find people who don't know that parity checks are not a security measure, yet who think they know about security, if I search good enough) -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121013085625.gf4...@grep.be
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
* Christoph Anton Mitterer cales...@scientia.net [121011 19:39]: On Thu, 2012-10-11 at 11:35 -0500, Peter Samuelson wrote: What makes sense is to use a hash that has the properties that are needed for a particular application. Well... I think that's only really required if performance is very critical, e.g. when you're on embedded devices or so,... but the places I've mentioned should have probably no disadvantages by using a strong algo,... not to mention that newer algos like Keccack are quite fast. There is a disadvantage of having longer hashsums, thus making it harder for people to compare. The only reason that for those md5 is optimal and not crc32 is that there is only one md5 and there is a nice always available tool to compute it, so people can compare it more easy. To use your example of dpkg file checksums, their purpose has _nothing_ to do with security. Well their _intended_ purpose,.. that's right. But nothing keeps people from using it a security manner (e.g. by replication it to a secure remote node or so) and in fact... e.g. rkhunter already has a mode where it uses DPKG directly. Everything doing something like that can also create those sha2 sums on their own and use them. Using the debsums system (which has no security part at all) will only weaken security. So I think what you say is an argument for keeping md5sum, so that noone think they can use that information for security. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121012071732.ga4...@client.brlink.eu
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On 12.10.2012 01:30, Christoph Anton Mitterer wrote: I further looked around: e.g. the Release file seems to only use MD5 not so good :( You didn't look very far / well. $ wget -O- -q http://ftp.debian.org/debian/dists/squeeze/Release | grep -v ^ Origin: Debian Label: Debian Suite: stable Version: 6.0.6 Codename: squeeze Date: Sat, 29 Sep 2012 11:31:27 UTC Architectures: amd64 armel i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sparc Components: main contrib non-free Description: Debian 6.0.6 Released 29 September 2012 MD5Sum: SHA1: SHA256: Please check more carefully before making such assertions. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8de9b71d74d88d059285a00be8b52...@mail.adsl.funky-badger.org
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Thu, Oct 11, 2012 at 7:38 PM, Christoph Anton Mitterer cales...@scientia.net wrote: algo,... not to mention that newer algos like Keccack are quite fast. I wonder if it is really a good idea to search for a security checksum based on the metric that it can be quickly calculated … but off-topic. To use your example of dpkg file checksums, their purpose has _nothing_ to do with security. Well their _intended_ purpose,.. that's right. But nothing keeps people from using it a security manner (e.g. by replication it to a secure remote node or so) and in fact... e.g. rkhunter already has a mode where it uses DPKG directly. I think adding better checksums here would just encourage people to think that they could be used in a security relevant way. And carrying bigger/more checksums around just means that we waste everyones diskspace to keep up the illusion of security for some people. Anyway... I guess it was clear, that I rather meant secure APT... dsc files, Release.gpg, etc. pp. APT will usually negotiate the checksum to use based on what it supports and what is included in the Release file. Supported is currently in squeeze (in wheezy): MD5, SHA1, SHA256(, SHA512) Usually found in a Release file is currently: MD5, SHA1, SHA256 so it will take SHA256 and be done with it. apt-ftparchive/wheezy will generate SHA512 by default as well, I am not sure about dak or others, but that isn't really a problem just yet. This falls apart of course as soon as RSA (or whatever ftpmasters will use in this dystopia) is broken, but I guess we have a problem then anyway. So dropping MD5 and/or SHA1 would be okay I guess, note through that apt-get --print-uris outputs md5sum by default as some scripts can't cope with other checksums. See #576420 as an example why, so you would need to find and fix these scripts first I guess (or just break them of course). There is one exception: pdiffs work entirely with SHA1, were is some work pending on the dak side, I guess while incorporating them into APT we could work on that. In case of an emergency you could just disable that optional feature of course (user as well as server side). And in the end of all days, really interesting is only a pre-image attack, collision is kinda boring … Oh, and there is Description-md5. I can't imagine a scenario in which it would be useful to change the English description of a package for an attack (which you want to hide by displaying the translations of the not modified version), but feel free to be the first to launch a successful pre-image attack on long descriptions (with the side problem of not changing size and checksum of the [compressed] Packages file including the description). Beside, for Debian this attack becomes easier now as the translation is split out and the md5sum therefore pre-calculated, so you can write whatever you want in the Translation-* files as a description without caring for Description-md5 (side problem still applies though). Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAZ6_fAgOpwsdmmjZXm5P_UocZ0CjEsx=ohoe2gg_rybwnc...@mail.gmail.com
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On 12/10/12 12:10, David Kalnischkies wrote: I wonder if it is really a good idea to search for a security checksum based on the metric that it can be quickly calculated … but off-topic. It depends what you're using it for: security is not magic pixie dust. A hashing algorithm that is faster and equally collision-resistant is better for integrity-checking (faster and no less secure), but worse for password hashing (an attacker can try potential passwords faster). Anyway... I guess it was clear, that I rather meant secure APT... dsc files, Release.gpg, etc. pp. APT will usually negotiate the checksum to use based on what it supports and what is included in the Release file. Another relevant hashing algorithm is the one that GnuPG (as used by the ftpmasters) uses to generate the signature for InRelease and Release.gpg. For wheezy-as-testing, InRelease appears to be signed with (RSA +) SHA1, which is the GnuPG default. In principle the ftpmasters could configure gpg to sign with SHA256 (or even SHA512) in future, assuming stable's gnupg (and preferably also oldstable's gnupg) can verify such signatures. squeeze's gnupg does seem to support the SHA-2 set of hashes (SHA224 up to SHA512). Oh, and there is Description-md5. I can't imagine a scenario in which it would be useful to change the English description of a package for an attack This doesn't seem to matter, even if the descriptions were security-sensitive. The signed file (In)Release(.gpg) contains MD5, SHA1, SHA256 hashes of both Packages and Translation-*, so you can be sure that nobody has modified Packages or Translation-* since they left dak; and anyone who could cause dak to incorporate maliciously-colliding descriptions (a DD or DM with upload privileges) could do more damage by uploading a malicious .deb instead. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50780315.3010...@debian.org
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
Hi Paul. On Fri, 2012-10-12 at 10:09 +0800, Paul Wise wrote: I further looked around: e.g. the Release file seems to only use MD5 not so good :( Wrong, the Release file has had all 3 since sarge. woody had MD5 SHA-1. Then what's this: ftp://ftp.de.debian.org/debian/dists/sid/Release Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Fri, 2012-10-12 at 09:17 +0200, Bernhard R. Link wrote: There is a disadvantage of having longer hashsums, thus making it harder for people to compare. The only reason that for those md5 is optimal and not crc32 is that there is only one md5 and there is a nice always available tool to compute it, so people can compare it more easy. Do you think it often happens that people compare this manually? I doubt... even for MD5,... cause whenever it goes above a few files, it gets a pain with MD5, too. And the tools for the newer alogs (well at least SHA2) are also quite widespread now. Everything doing something like that can also create those sha2 sums on their own and use them. Using the debsums system (which has no security part at all) will only weaken security. Well one argument would be, that these hashes are already created and automatically maintained... So I think what you say is an argument for keeping md5sum, so that noone think they can use that information for security. Wheter that works?! ;-) smime.p7s Description: S/MIME cryptographic signature
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Fri, 2012-10-12 at 13:49 +0200, Christoph Anton Mitterer wrote: Then what's this: ftp://ftp.de.debian.org/debian/dists/sid/Release Ah... my bad... the file is simply truncated at some point... but I guess this most be a local error. On Fri, 2012-10-12 at 08:26 +0100, Adam D. Barratt wrote: You didn't look very far / well. Please check more carefully before making such assertions. Yep... sorry for making stupid noise... should have noticed it already, when the file was only the first 30 lines or so (as it appears here). Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On 12.10.2012 12:49, Christoph Anton Mitterer wrote: On Fri, 2012-10-12 at 10:09 +0800, Paul Wise wrote: I further looked around: e.g. the Release file seems to only use MD5 not so good :( Wrong, the Release file has had all 3 since sarge. woody had MD5 SHA-1. Then what's this: ftp://ftp.de.debian.org/debian/dists/sid/Release It's a file containing MD5, SHA1 and SHA256 sums, as has already been explained to you. /=== | $ wget -q ftp://ftp.de.debian.org/debian/dists/sid/Release | | $ sha256sum Release | ca8a6b8809246a885e74600d2a61a0b73ead28dd0f324a682d8d3d359d82aa35 Release | | $ grep -v ^ Release | Origin: Debian | Label: Debian | Suite: unstable | Codename: sid | Date: Fri, 12 Oct 2012 08:17:30 UTC | Valid-Until: Fri, 19 Oct 2012 08:17:30 UTC | Architectures: amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 s390x sparc | Components: main contrib non-free | Description: Debian x.y Unstable - Not Released | MD5Sum: | SHA1: | SHA256: \=== I'm struggling to see what point you believe you're making here. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/c881b1115792d5f04cc31b53c1bef...@mail.adsl.funky-badger.org
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On 12 October 2012 13:03, Adam D. Barratt a...@adam-barratt.org.uk wrote: I'm struggling to see what point you believe you're making here. The point he was trying to make that he either caught a mirror during update, or his connection was flaky, as he didn't fetch the complete file, nor verify it's gpg signature. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlugp6ep6e+d0obqfdx0n8h8oezopbjr05jnpm07jqbr...@mail.gmail.com
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Fri, Oct 12, 2012 at 7:49 PM, Christoph Anton Mitterer cales...@scientia.net wrote: Then what's this: ftp://ftp.de.debian.org/debian/dists/sid/Release Sounds like you have a person in the middle hacking your network (or a browser bug), it works for me: pabs@chianamo ~ $ GET ftp://ftp.de.debian.org/debian/dists/sid/Release | grep ^SHA SHA1: SHA256: -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6evoavm7yarnovztopg5ussf2bnwdjnoazoj8rdd+a...@mail.gmail.com
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Friday, October 12, 2012 05:10:12 David Kalnischkies wrote: On Thu, Oct 11, 2012 at 7:38 PM, Christoph Anton Mitterer cales...@scientia.net wrote: algo,... not to mention that newer algos like Keccack are quite fast. I wonder if it is really a good idea to search for a security checksum based on the metric that it can be quickly calculated … but off-topic. FWIW, NIST disagrees. Keccack is SHA-3: http://csrc.nist.gov/groups/ST/hash/sha-3/winner_sha-3.html signature.asc Description: This is a digitally signed message part.
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Fri, Oct 12, 2012 at 09:05:01AM -0600, Wesley J. Landaker wrote: On Friday, October 12, 2012 05:10:12 David Kalnischkies wrote: On Thu, Oct 11, 2012 at 7:38 PM, Christoph Anton Mitterer cales...@scientia.net wrote: algo,... not to mention that newer algos like Keccack are quite fast. I wonder if it is really a good idea to search for a security checksum based on the metric that it can be quickly calculated … but off-topic. FWIW, NIST disagrees. Keccack is SHA-3: http://csrc.nist.gov/groups/ST/hash/sha-3/winner_sha-3.html And conspiracy theories are lingering why that is… :) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
Hey Paul. On Fri, 2012-10-12 at 20:48 +0800, Paul Wise wrote: Sounds like you have a person in the middle hacking your network (or a browser bug), it works for me: *g* guess I somehow deserved that ;) ... and not even SHA-3 would have protected me from not verifying against Release.asc ^^ Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Fri, 2012-10-12 at 13:10 +0200, David Kalnischkies wrote: Oh, and there is Description-md5. I can't imagine a scenario in which it would be useful to change the English description of a package for an attack (which you want to hide by displaying the translations of the not modified version) I cannot think of any either, well at lest not of anything, for which a plain collision would be enough,... But it's a general security paradigm, that one shouldn't just focus on the attack vectors one can think of... but rather trying to secure everything ;) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Fri, Oct 12, 2012 at 4:31 PM, Christoph Anton Mitterer wrote: But it's a general security paradigm, that one shouldn't just focus on the attack vectors one can think of... but rather trying to secure everything ;) Which is impossible, or at least man-powerwise insurmountable. There are something like 500 million lines of code in a Debian release. Obviously not all code bits have security implications, but the right flaw in any one link in that chain could lead to security problems. If we were rigorous, that would 500,000 lines of code to review per DD. An impossible and error-prone task. It's more about identifying mistakes, learning from them, attempting to track *everything*, and correcting known problems quickly. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mp9wqmuuey4-err4jnnrzn1nnpkpscbz5nt1ca4dru...@mail.gmail.com
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Fri, 2012-10-12 at 16:37 -0400, Michael Gilbert wrote: Which is impossible, or at least man-powerwise insurmountable. There are something like 500 million lines of code in a Debian release. I wasn't talking about such an impossible task,... but there speaks nothing against relatively easy things,... like securing all of our package repository infrastructure by strong algos (as we already did)... and trying to prevent higher level attacks, like downgrade attacks. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Fri, Oct 12, 2012 at 4:45 PM, Christoph Anton Mitterer wrote: On Fri, 2012-10-12 at 16:37 -0400, Michael Gilbert wrote: Which is impossible, or at least man-powerwise insurmountable. There are something like 500 million lines of code in a Debian release. I wasn't talking about such an impossible task,... but there speaks nothing against relatively easy things,... like securing all of our package repository infrastructure by strong algos (as we already did)... and trying to prevent higher level attacks, like downgrade attacks. Do you have evidence of any of those things? If so, please submit bugs, and we will look at fixing them. Otherwise, speculation gets us nowhere and actually wastes time. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MNPfrP=n+92thmy7tsqp8wqrkpexynghif0nhs0zpm...@mail.gmail.com
Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
Hi folks. AFAICS, secure APT and similar things (e.g. dpkg's file hash sums) still use even MD5. Wouldn't it make sense to start discussions about moving to the strongest possible? Or, like in the case of package files (dsc and friends) make a policy of verifying all hashes, and fail if any single doesn't match? I mean SHA-1 is far from being broken, but recently there was an estimation on when one will see first collisions (the archive on the NIST list requires registration, but Schneier has re-posted it on his blog[0]). So I guess one shouldn't delay that forever... Cheers, Chris. [0] http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html smime.p7s Description: S/MIME cryptographic signature
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
[Christoph Anton Mitterer] Wouldn't it make sense to start discussions about moving to the strongest possible? No. What makes sense is to use a hash that has the properties that are needed for a particular application. To use your example of dpkg file checksums, their purpose has _nothing_ to do with security. They cannot protect against a malicious attacker, because an attacker who can corrupt /usr/bin/lsof can also corrupt /var/lib/dpkg/info/lsof.md5sums. (And /var cannot be read-only as /usr sometimes is.) If you need protection against a malicious attacker, you need to generate and store your checksums in some other way.[1] [1] Check out 'apt-cache search tripwire' for various ways to reinvent that wheel. tripwire was an early implementation of this idea, so it is mentioned in other package descriptions. Rather, the checksums are for integrity checking in the face of disk corruption or administrative snafu. Basically to answer the question Would it help to reinstall this package? MD5 is perfectly well suited for that. The presence of the md5sums file in control.tar.gz is just a convenience so that end systems don't have to calculate it at install time, much like providing .pyc or .elc files in a .deb (which we don't do, but we could). My point is not to pick on your specific example, but to suggest actually _thinking_ about what a hash is used for, as opposed to the common knee-jerk reaction oooh, MD5 is weak, it must be replaced! every time someone sees MD5. (Or SHA-1.) Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121011163521.gc4...@p12n.org
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Thu, 2012-10-11 at 11:35 -0500, Peter Samuelson wrote: What makes sense is to use a hash that has the properties that are needed for a particular application. Well... I think that's only really required if performance is very critical, e.g. when you're on embedded devices or so,... but the places I've mentioned should have probably no disadvantages by using a strong algo,... not to mention that newer algos like Keccack are quite fast. To use your example of dpkg file checksums, their purpose has _nothing_ to do with security. Well their _intended_ purpose,.. that's right. But nothing keeps people from using it a security manner (e.g. by replication it to a secure remote node or so) and in fact... e.g. rkhunter already has a mode where it uses DPKG directly. They cannot protect against a malicious attacker, because an attacker who can corrupt /usr/bin/lsof can also corrupt /var/lib/dpkg/info/lsof.md5sums. Yeah see above... if you have plain dpkg,... then yes... but people may impose further measure to secure these sums (replicating them to other nodes or attaching MACs to these files as XATTRs, etc. pp..)... this does not necessarily mean that I'd suggest such things (cause people should rather use AIDE or friends then). Rather, the checksums are for integrity checking in the face of disk corruption or administrative snafu. Basically to answer the question Would it help to reinstall this package? MD5 is perfectly well suited for that. In principle you're right here,... and I also use it just for that purpose... but as said above,... we cannot know what people do... and if dpkg would have generic mechanisms for storing the sums (e.g. all in /var/lib/dpkg/info/lsof.sums)... nothing would IMHO speak against using a stronger algo per default. Anyway... I guess it was clear, that I rather meant secure APT... dsc files, Release.gpg, etc. pp. the common knee-jerk reaction oooh, MD5 is weak, it must be replaced! every time someone sees MD5. (Or SHA-1.) Well I quite clearly said, that I wouldn't consider especially the later as broken but experience has shown that such migrations can take quite some time... and these estimations showed that collisions for even SHA-1 are not out of the world... Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On 2012-10-11 19:38, Christoph Anton Mitterer wrote: On Thu, 2012-10-11 at 11:35 -0500, Peter Samuelson wrote: What makes sense is to use a hash that has the properties that are needed for a particular application. Well... I think that's only really required if performance is very critical, e.g. when you're on embedded devices or so,... but the places I've mentioned should have probably no disadvantages by using a strong algo,... not to mention that newer algos like Keccack are quite fast. Debian on a low power embedded system fits in the normal category I assume? What is embedded device then? -- brother http://sis.bthstudent.se -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50770c0e.3010...@bsnet.se
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Thu, Oct 11, 2012 at 01:19:58AM +0200, Christoph Anton Mitterer wrote: Hi folks. AFAICS, secure APT and similar things (e.g. dpkg's file hash sums) still use even MD5. dpkg-genchanges and dak both generate md5, sha1 and sha256. So .deb files themself are hashed by all 3 of them. A as far as I know all tools that verify those files also check all 3 of those hashes. As far as I understand, there is no need to move away from sha256 to SHA-3 when it becomes available at this time. So basicly the question is if we want to keep the md5 and sha1 in those files or not. MD5 is covered by policy, and it's the only mentioned in policy, maybe that should change. There are also the md5sums files that are stored in the .deb file. I'm not really sure what the real use case for them is and wouldn't have a problem with them going away. Then there dpkg status file keeps track of config files with md5 to see if they changed on upgrade. I can see no good reason to change this. Wouldn't it make sense to start discussions about moving to the strongest possible? I see no reason why we can't also add SHA-3 to the files when the tools become available. Or, like in the case of package files (dsc and friends) make a policy of verifying all hashes, and fail if any single doesn't match? As far that's already the case? Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121011181855.ga8...@roeckx.be
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Thu, Oct 11, 2012 at 08:18:55PM +0200, Kurt Roeckx wrote: There are also the md5sums files that are stored in the .deb file. I'm not really sure what the real use case for them is and wouldn't have a problem with them going away. debsums(1) aka what packages on my system are corrupt by a recent FS failure -- WBR, wRAR signature.asc Description: Digital signature
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Fri, Oct 12, 2012 at 12:42:57AM +0600, Andrey Rahmatullin wrote: On Thu, Oct 11, 2012 at 08:18:55PM +0200, Kurt Roeckx wrote: There are also the md5sums files that are stored in the .deb file. I'm not really sure what the real use case for them is and wouldn't have a problem with them going away. debsums(1) aka what packages on my system are corrupt by a recent FS failure I know about debsums, I just don't find it useful. For the case of corruption I would either use backups or reinstall the whole thing. If there is corruption it ussually screws up more than the files covered by the md5sums. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121011223542.ga20...@roeckx.be
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
Le Thu, Oct 11, 2012 at 08:18:55PM +0200, Kurt Roeckx a écrit : MD5 is covered by policy, and it's the only mentioned in policy, maybe that should change. Hi Kurt and everybody, For control files, Checksums-Sha1 and Checksums-Sha256 are covered in chapter 5, where they are marked as recommended. - http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Checksums These multiline fields contain a list of files with a checksum and size for each one. Both Checksums-Sha1 and Checksums-Sha256 have the same syntax and differ only in the checksum algorithm used: SHA-1 for Checksums-Sha1 and SHA-256 for Checksums-Sha256. Checksums-Sha1 and Checksums-Sha256 are multiline fields. The first line of the field value (the part on the same line as Checksums-Sha1: or Checksums-Sha256:) is always empty. The content of the field is expressed as continuation lines, one line per file. Each line consists of the checksum, a space, the file size, a space, and the file name. For example (from a .changes file): Checksums-Sha1: 1f418afaa01464e63cc1ee8a66a05f0848bd155c 1276 example_1.0-1.dsc a0ed1456fad61116f868b1855530dbe948e20f06 171602 example_1.0.orig.tar.gz 5e86ecf0671e113b63388dac81dd8d00e00ef298 6137 example_1.0-1.debian.tar.gz 71a0ff7da0faaf608481195f9cf30974b142c183 548402 example_1.0-1_i386.deb Checksums-Sha256: ac9d57254f7e835bed299926fd51bf6f534597cc3fcc52db01c4bffedae81272 1276 example_1.0-1.dsc 0d123be7f51e61c4bf15e5c492b484054be7e90f3081608a5517007bfb1fd128 171602 example_1.0.orig.tar.gz f54ae966a5f580571ae7d9ef5e1df0bd42d63e27cb505b27957351a495bc6288 6137 example_1.0-1.debian.tar.gz 3bec05c03974fdecd11d020fc2e8250de8404867a8a2ce865160c250eb723664 548402 example_1.0-1_i386.deb In the .dsc file, these fields should list all files that make up the source package. In the .changes file, these fields should list all files being uploaded. The list of files in these fields must match the list of files in the Files field. - For MD5, it is only mentionned in the description of the Files field (same chapter), in appendix D about other control fields (MD5sum), and in appendix E about configuration file handling. Please let us know if there is something else missing about SHA-1 or SHA-256 checksums. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121011224310.ga12...@falafel.plessy.net
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Thu, 2012-10-11 at 20:18 +0200, Kurt Roeckx wrote: dpkg-genchanges and dak both generate md5, sha1 and sha256. So .deb files themself are hashed by all 3 of them. A as far as I know all tools that verify those files also check all 3 of those hashes. Ah? Ok... I somehow had in mind that a) generating the stronger ones was just optional,... and that they were not yet everywhere verified. So basicly the question is if we want to keep the md5 and sha1 in those files or not. Probably... and nothing speaks against adding sha512... or (once it has been well introduced) Keccack. MD5 is covered by policy :-/ , and it's the only mentioned in policy, maybe that should change. Guess so. There are also the md5sums files that are stored in the .deb file. I'm not really sure what the real use case for them is and wouldn't have a problem with them going away. Well these are the ones for dpkg, aren't they? Where it was mentioned before, that they are not primarily intended for security (but where I replied, nothing keeps users from using them for this purpose). I see no reason why we can't also add SHA-3 to the files when the tools become available. :) I further looked around: e.g. the Release file seems to only use MD5 not so good :( Sources files seems to use MD5, SHA1 and SHA256... though MD5 seems to have a special status (Files vs. Checksums-algo). That might be just historic, though. Similarly the Packages files... MD5/SHA1/SHA256... If they are all checked (and verification is considered to be failed if a single one doesn't match)... then I guess I'm quite happy. Though I would still think, that on a mid-/long-term-range it doesn't harm to drop MD5/SHA1 e.g. in favour of SHA512/Keccack. Or, like in the case of package files (dsc and friends) make a policy of verifying all hashes, and fail if any single doesn't match? As far that's already the case? That would be good :) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
Kurt Roeckx wrote: Andrey Rahmatullin wrote: Kurt Roeckx wrote: There are also the md5sums files that are stored in the .deb file. I'm not really sure what the real use case for them is and wouldn't have a problem with them going away. debsums(1) aka what packages on my system are corrupt by a recent FS failure I know about debsums, I just don't find it useful. For the case of corruption I would either use backups or reinstall the whole thing. If there is corruption it ussually screws up more than the files covered by the md5sums. The use case for debsums is for *detection* of corruption. And neither is it a security mechanism. But it is a useful integrity check mechanism. Bob signature.asc Description: Digital signature
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Fri, Oct 12, 2012 at 8:30 AM, Christoph Anton Mitterer wrote: I further looked around: e.g. the Release file seems to only use MD5 not so good :( Wrong, the Release file has had all 3 since sarge. woody had MD5 SHA-1. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6f-37fuhwcgfnxmu-md-qutora6mwjewxhrzfuehg7...@mail.gmail.com
Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)
On Fri, Oct 12, 2012 at 8:30 AM, Christoph Anton Mitterer wrote: Sources files seems to use MD5, SHA1 and SHA256... though MD5 seems to have a special status (Files vs. Checksums-algo). That might be just historic, though. Similarly the Packages files... MD5/SHA1/SHA256... Only since wheezy has that been true for all files listed in Packages/Sources though. squeeze Packages is missing SHA-1 and SHA-256 for 1905 binary packages. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6EHRFK2Qj7H7A4=UF3SqnroEMeAd4xA=Pfzum8=a7s...@mail.gmail.com
