Re: improving downloader packages (was: Re: holes in secure apt)
* David Kalnischkies da...@kalnischkies.de, 2014-06-18, 14:11: [0] And his skepticism was reinforced by (independent) discovery of this bug: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1098738 *sigh* and this is still open? 8-O Before someone is rushing to work on that (sorry, I was dreaming)… we actually have a rework for hashsum handling in libapt in our debian/experimental branch which as a minor sideeffect also solves this one. Required quiet some amount of work, multiple api breaks still and uhm… testing… but that is overrated. Someone checking this out would still be welcomed… I've been using 1.1 for a while, and I'm happy to confirm that I can no longer reproduce LP#1098738. I mean MD5 is _really_ broken now... actually I think any secure APT If you happen to have a same-size preimage attack on MD5 I would be interested to hear about it. Preimage attack would be the only one to worry about if we were regenerating all the tarballs ourselves. But this is not the case. My upstream[0] has just released a new version of his software. I compared contents of the new tarball with with old one. The diff looked reasonable (modulo a new tiny security hole: #760455), and I found nothing suspicious inside. So I'm going to upload this package to Debian soon. But maybe this .orig.tar.gz wasn't crafted so that it has an evil twin, with the same MD5 sum, but with completely different contents when unpacked. How could I know? [0] Well, it was either him, or whoever hacked into the FTP server, or the man in the middle between me and the server. The tarball wasn't signed, and it was downloaded over HTTP, so you may never know. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140913162408.ga6...@jwilk.net
Re: improving downloader packages (was: Re: holes in secure apt)
Christoph Anton Mitterer dijo [Fri, Jun 20, 2014 at 10:24:07PM +0200]: I do feel the keyring-maint package is a leftover from days long gone. Nowadays the keyring is kept at a DVCS tree, and regularly exported to a publicly accessible instance. Any reason for that internal repo? I mean what speaks against the idea of expressing everything via signatures by some special keys (which was probably the core idea of my proposal) We want the repo to show what is truth at a given point in time. If we shared our working tree, there'd be space for confusion on keys we have already changed but not yet pushed (we do so on a ~monthly basis). Also, every now and then we handle requests that need not to be made public until they have been implemented. Of course, we try to implement/push them as soon as possible, but it's better to keep them separate in a not yet live place. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140625133327.ga64...@gwolf.org
Re: improving downloader packages (was: Re: holes in secure apt)
Raphael Hertzog dijo [Fri, Jun 20, 2014 at 09:17:25AM +0200]: FWIW, I was thinking about including the possible disappearance as one of the points to talk about in the DebConf BoF we proposed regarding keyring-maint. Why not switch it to something more dynamic ? Make the package an empty shell with symlinks pointing to /var/lib/debian-keyring/, add a cron job that rsyncs the keyring to that directory. Why not prompt users to clone the public git tree instead? :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140625133402.gb64...@gwolf.org
Re: software outside Debian (Re: holes in secure apt)
On 2014-06-23 17:33, Christoph Anton Mitterer wrote: Well I just think that most of the time, our Security Team does some very great job (if not hiding away issues o.O) and fixes are available in Debian very shortly after a fix is available. These guys put a lot effort into that, but their quick response is useless if those periods are so long. It gives an attacker that can MitM (and we must expect that not only the NSA can do this) 7-10 days (!!!) to conceal updates from a system and exploit the security holes they fix. Especially since many server systems update automatically, this is quite problematic IMHO. And how many of these automatic updates require a followup on critical issues? Sure, the library on disk is updated, but are the servers restarted[1]? Are the servers rebooted for that root exploit fixed by an update to the kernel package[2]? Just as I assume that a competent admin will figure out these problems for her services, I assume them to read advisories. And if you read a critical one and you can't find it on the mirrors upon apt-get upgrade something is fishy and someone will be bound to investigate. Kind regards Philipp Kern [1] I'm aware that certain libraries do restart services affected by the upgrade, but there's no generic framework for this. [2] I'm aware that some people like DSA use Nagios checks or cron jobs to ensure that the running kernel image matches the on-disk image or alert otherwise. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/bbf5105a59eed196079d49c1b8625...@hub.kern.lc
Re: software outside Debian (Re: holes in secure apt)
On Tue, Jun 24, 2014 at 11:26:43AM +0200, Philipp Kern wrote: [..snip..] [1] I'm aware that certain libraries do restart services affected by the upgrade, but there's no generic framework for this. whatmaps[A] hooks into the apt pipeline for that and looks for shared objects coming in via security updates. It's far from perfect though since it only handles sysvinit and the mappings of processes to services are currently hard coded. -- Guido [A] https://packages.debian.org/whatmaps -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140624201307.ga8...@bogon.m.sigxcpu.org
Re: software outside Debian (Re: holes in secure apt)
* Christoph Anton Mitterer cales...@scientia.net, 2014-06-22, 04:34: There are a few mechanisms to mitigate downgrade attacks within the archive: * Valid-Until fields in the Release files; I still think the time spans are far too long here... For the record, the validity periods currently are: unstable, experimental: 7 days testing: 7 days wheezy: no limit wheezy(-proposed)-updates: 7 days wheezy/updates at security.d.o: 10 days wheezy-backports: 7 days squeeze: no limit squeeze(-proposed)-updates: 7 days squeeze/updates at security.d.o: 10 days squeeze-lts: 7 days I agree than they could be shorter (particularly the security.d.o ones raised my eyebrows), but I'm not going to lose sleep over it. can someone please tell me against what I could report a bug (i.e. politely ask for enhancement by making the time span much smaller)? My guesses would be: reportbug ftp.debian.org for unstable and experimental; reportbug release.debian.org for testing, (old)stable and their (proposed-)updates; team@security.d.o for the security.d.o archive; debian-lts@lists.d.o for squeeze-lts. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140623124258.ga7...@jwilk.net
Re: software outside Debian (Re: holes in secure apt)
On 2014-06-23 13:42, Jakub Wilk wrote: * Christoph Anton Mitterer cales...@scientia.net, 2014-06-22, 04:34: There are a few mechanisms to mitigate downgrade attacks within the archive: * Valid-Until fields in the Release files; I still think the time spans are far too long here... For the record, the validity periods currently are: [...] can someone please tell me against what I could report a bug (i.e. politely ask for enhancement by making the time span much smaller)? My guesses would be: reportbug ftp.debian.org for unstable and experimental; reportbug release.debian.org for testing, (old)stable and their (proposed-)updates; team@security.d.o for the security.d.o archive; debian-lts@lists.d.o for squeeze-lts. Those are all dak configuration, so controlled by ftpmaster. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/b0ed4a308fd8c8f47cb23708bf94e...@mail.adsl.funky-badger.org
Re: software outside Debian (Re: holes in secure apt)
On Mon, 2014-06-23 at 14:42 +0200, Jakub Wilk wrote: For the record, the validity periods currently are: unstable, experimental: 7 days testing: 7 days wheezy: no limit wheezy(-proposed)-updates: 7 days wheezy/updates at security.d.o: 10 days wheezy-backports: 7 days squeeze: no limit squeeze(-proposed)-updates: 7 days squeeze/updates at security.d.o: 10 days squeeze-lts: 7 days I agree than they could be shorter (particularly the security.d.o ones raised my eyebrows), but I'm not going to lose sleep over it. Well I just think that most of the time, our Security Team does some very great job (if not hiding away issues o.O) and fixes are available in Debian very shortly after a fix is available. These guys put a lot effort into that, but their quick response is useless if those periods are so long. It gives an attacker that can MitM (and we must expect that not only the NSA can do this) 7-10 days (!!!) to conceal updates from a system and exploit the security holes they fix. Especially since many server systems update automatically, this is quite problematic IMHO. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: software outside Debian (Re: holes in secure apt)
For the interested: On Mon, 2014-06-23 at 14:42 +0200, Jakub Wilk wrote: reportbug ftp.debian.org for unstable and experimental; #752450 smime.p7s Description: S/MIME cryptographic signature
Re: software outside Debian (Re: holes in secure apt)
* Adam D. Barratt a...@adam-barratt.org.uk, 2014-06-23, 14:24: * Christoph Anton Mitterer cales...@scientia.net, 2014-06-22, 04:34: There are a few mechanisms to mitigate downgrade attacks within the archive: * Valid-Until fields in the Release files; I still think the time spans are far too long here... For the record, the validity periods currently are: [...] can someone please tell me against what I could report a bug (i.e. politely ask for enhancement by making the time span much smaller)? My guesses would be: reportbug ftp.debian.org for unstable and experimental; reportbug release.debian.org for testing, (old)stable and their (proposed-)updates; team@security.d.o for the security.d.o archive; debian-lts@lists.d.o for squeeze-lts. Those are all dak configuration, so controlled by ftpmaster. I don't doubt it. :-) What I doubt is that ftp-masters would be willing to alter the configuration without blessing of the respective teams. But I could be wrong, of course. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140623170043.gb6...@jwilk.net
Re: sofftware outside Debian (Re: holes in secure apt)
Hi Christoph, On Sonntag, 22. Juni 2014, Christoph Anton Mitterer wrote: one or two bug reports might be oh so more useful than posting on -devel. #752275 and #752277 thanks for these! cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: sofftware outside Debian (Re: holes in secure apt)
On Sun, 2014-06-22 at 12:27 +0200, Holger Levsen wrote: On Sonntag, 22. Juni 2014, Christoph Anton Mitterer wrote: one or two bug reports might be oh so more useful than posting on -devel. #752275 and #752277 thanks for these! To be honest, Holger, I don't know why you've asked me to report these issues at all, if you have nothing better to do, than downgrading their severity with your first post not even half a day after I've reported it. I mean I'd understand such behaviour if these bugs would be open for weeks while I'd haven't replied and they are generally considered to be non-issues. But now I just wonder... what advantages to people have from this mentality of always re-setting the severity when it's not yet fully clear and agreed upon whether there is an issue or not? I mean are DDs somehow punished for having important bugs open? Even if my bug report was wrong, and the issue wouldn't apply... it feels like rather simply hiding away such bugs. The same happened on #752277, even by Michael Gilbert, member of the security team. I mean even if contrib/non-free don't get official security support - what's the problem with best-effort? While I could agree on removing the security tag (even though this is AFAIK not documented to be a tag specifically for the security-team)... I can absolutely not agree on lowering the severity... and yet even more: changing the title from something that clearly shows users there's some security issues to a harmless suggestions for flashplugin fetching improvements I mean this is actively hiding severe security issues... In all doing respect, I really wonder why someone with a view on security like that can be member of the security team. Outrageous. Disturbing. And coming back to you, Holger, and some others who complained why I brought that up on d-d and not in small little bug reports: It's just that... you always have to fight windmills, maintainers and other involved people who have no sense of security, simply don't care or even actively hide these things under the carpet. Apart from that: My reports there weren't obvious spam or completely bogus... so it means I probably had at least something in my mind when I reported them. Given that I don't believe any DDs or the security team is publicly whipped on a daily basis for echo +security or important bugs that are open... I think it's rather impolite if not rude behaviour to more or less blindly change severity/tags or titles without any chat with the reporter. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: sofftware outside Debian (Re: holes in secure apt)
Hi Christoph, On Sonntag, 22. Juni 2014, Christoph Anton Mitterer wrote: To be honest, Holger, I don't know why you've asked me to report these issues at all, [...] so they are tracked and easy to be referenced - #752275 is way better than several message-ids on lists.d.o. But now I just wonder... what advantages to people have from this mentality of always re-setting the severity when it's not yet fully clear and agreed upon whether there is an issue or not? I mean are DDs somehow punished for having important bugs open? why do you think bugs of severity lower than serious are punishment? Even if my bug report was wrong, and the issue wouldn't apply... it feels like rather simply hiding away such bugs. Setting an appropriate severity is not hiding a problem. Also, so far you havent replied to whether you agree that all your three concerns are addressed? And coming back to you, Holger, and some others who complained why I brought that up on d-d and not in small little bug reports: It's just that... you always have to fight windmills, maintainers and other involved people who have no sense of security, simply don't care or even actively hide these things under the carpet. Again: having a proper severity is useful, not hiding. Apart from that: My reports there weren't obvious spam or completely bogus... so it means I probably had at least something in my mind when I reported them. Given that I don't believe any DDs or the security team is publicly whipped on a daily basis for echo +security or important bugs that are open... I think it's rather impolite if not rude behaviour to more or less blindly change severity/tags or titles without any chat with the reporter. True, thats why I tagged 752275 moreinfo and asked some specific questions. Maybe this bug is important indeed, but atm I cannot see why it would be. If 752275 would still be of RC severity it would prevent the package to enter jessie and prevent us from providing wheezy-backports too. *That* to be considered punishment of our users I would agree. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: sofftware outside Debian (Re: holes in secure apt)
Hey Holger, On Wed, 2014-06-18 at 12:46 +0200, Holger Levsen wrote: It also doesn't seem to protect against downgrading attacks... (see my previous post about that). one or two bug reports might be oh so more useful than posting on -devel. I will submit tickets for the ones I know (as soon as I find some time)... but that's just the reason why we have such security issues as I was talking about: There is no concentrated approach to fix these things. You say... if you find such an issue,... report a bug ... at best this means something between the maintainer agrees and just fixes it and a lengthy discussion where the maintainer say oh not this is absolutely security overkill why should I do it And even if it's fixed in the end, it's only fixed for that package, and I don't know all 40k packages of Debian by hard and cannot report a ticket for all packages where it could be an issue. And even if, two weeks later we'll have another package which does the same. That's why I've said already before, that it's more or less useless if we approach one or all of the issues that were now mentioned in this thread by just some concrete coding work and then for each update you need to update the launcher package - thats an aweful lot of work for little / no gain You have a disturbing view on security apparently... o.O If it's little /no gain, that an attacker e.g. in your university network or WiFi can't fool you into installing old e.g. flash-plugin, which can be easily used for at least a normal user exploit (which then usually means root exploit as well) then I don't know... (and how do you handle downgrade attacks here?) As mentioned previously: When the maintainer of such packages keeps his head up and looks for new versions/updates, he'll make a new package with the new hardcoded hash... this prevents a downgrade attack, since an attacker cannot present you anymore an old version which would still verify. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: sofftware outside Debian (Re: holes in secure apt)
FYI: On Wed, 2014-06-18 at 12:46 +0200, Holger Levsen wrote: one or two bug reports might be oh so more useful than posting on -devel. #752275 and #752277 Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: sofftware outside Debian (Re: holes in secure apt)
On Wed, 2014-06-18 at 13:55 +0200, Jakub Wilk wrote: Yes, maintaining packages properly takes time. If packaging new upstream releases is too much effort, why bother uploading it to Debian in the first place? Actually, I think everything that tries to circumvent the package management system should be considered harmful in the first place... on should probably not allow it in main at all... and all downloader packages should have to go to contrib or non-free. Question however is,... what about packages like Mozilla-stuff or gnome-shell which more or less actively do just that via their plugin mechanisms... Personally I'd like to see them deactivated by default... and plugins being packaged (as many are). There are a few mechanisms to mitigate downgrade attacks within the archive: * Valid-Until fields in the Release files; I still think the time spans are far too long here... can someone please tell me against what I could report a bug (i.e. politely ask for enhancement by making the time span much smaller)? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: improving downloader packages (was: Re: holes in secure apt)
Hi, On Thu, 19 Jun 2014, Gunnar Wolf wrote: FWIW, I was thinking about including the possible disappearance as one of the points to talk about in the DebConf BoF we proposed regarding keyring-maint. Why not switch it to something more dynamic ? Make the package an empty shell with symlinks pointing to /var/lib/debian-keyring/, add a cron job that rsyncs the keyring to that directory. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140620071725.gd28...@x230-buxy.home.ouaza.com
Re: holes in secure apt
On Tue, 2014-06-17 at 10:48 +0200, David Kalnischkies wrote: On Mon, Jun 16, 2014 at 12:04:51PM +0200, Thorsten Glaser wrote: Erm, no? You can just cache a working Sources file and exchange the paragraph you are interested in. That’s something that would be easy in a CGI written in shell, *and* perform well. Trivial. The always refers to the small problem that a MITM isn't in control of what source package is acquired by the user later on. Modifying the Source file is of course trivial, the hard part is making the modification count given that at the time the request for the Sources file is made you have no idea what (if any) source package the user will request in 10 seconds/days following this 'apt-get update' (or equivalent) – if the user isn't on to you given that you have thrown away the signatures for binary packages, too, so that he can't even get his build-dependencies without saying yes to a (default: no) warning. I don't quite understand why you think it's so difficult for an attacker to provide a complete archive, where he has added some trojan or whatever to more or less any source package? And if he just looks for main() in any source package an hooks in a little backdoor... or even if he just focuses on the most popular source packages...? From a theoretical standpoint, this is of course all negligible, but in practice it's so annoying/fragile that way better alternatives exist. (Me messing up InRelease parsing [twice] for example with ironically far less coverage - its all about catchy titles I guess) Well I've noticed that but was to depressed to make noise ;-) Anyway... the main question is from my side (at least regarding this sub-thread): Was there any... do we need any... how could we do any assessment about the integrity of the Debian archive and build infrastructure... (i.e. whether this or previous holes was actually used by someone)? I mean all the NSAfriends scandal has clearly shown one thing: There are many people/groups out there which really do want to break into every system and which even go the most annoying ways to reach their goal... being paranoid was actually always justified. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: improving downloader packages (was: Re: holes in secure apt)
On Thu, 2014-06-19 at 21:25 -0500, Gunnar Wolf wrote: Thanks for bringing this topic up. I'm snipping your very detailed implementation proposal, which does not sound like it was written at 4AM at all ;-) ;-) I do feel the keyring-maint package is a leftover from days long gone. Nowadays the keyring is kept at a DVCS tree, and regularly exported to a publicly accessible instance. Any reason for that internal repo? I mean what speaks against the idea of expressing everything via signatures by some special keys (which was probably the core idea of my proposal) Furthermore, it stores its full history, so you can even check if $foo was a valid key at some point in the past. This you can to with my proposal as well... whether the Authority key will sign other keys always just for a time span (+ continuously resigns them) or whether the signatures are not expiring and manually revoked... In both cases you could easily find out and time spans when a key had the state Debian developer, based on the dates of the signatures and revocations. I was thinking about including the possible disappearance Well when I wrote last time, I thought keeping the package might make sense to give offline systems at least a source for a more or less current state of the keyring... but OTOH,... why should offline only systems need this... they can't do any communication with the DDs or verify new packages. But of course... if there the Authority key should then move to some package, e.g. debian-archive-keyring... or perhaps all special keys should move to that package and this should then become the debian-keyring (since it's no longer just the archive keys). Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: improving downloader packages (was: Re: holes in secure apt)
On Fri, 2014-06-20 at 09:17 +0200, Raphael Hertzog wrote: Why not switch it to something more dynamic ? Sounds good... Make the package an empty shell with symlinks pointing to /var/lib/debian-keyring/, add a cron job that rsyncs the keyring to that directory. I've just thought about that... and my initial thought was... use they global keyserver network for this. But my second thought reminded me of what I often brought up here before and what I've now forgot myself: If you use the keyserver network, a solution like rsync or anything similar... then you may easily become vulnerable to blocking/downgrade attacks. Examples: - I pull in new keys/signatures either via SKS keyservers, rsync or some other dynamic method. - Attacker gives me however an old state of the keys/signatures, where e.g. a compromised key is not yet revoked, or he simply drops the revocation signature.. - I won't notice this, any happily verify and packages/etc. since I think the signature is still valid. Thus, if any dynamic key retrival would be implemented, the following would have to be done: - secured connection to some fully trusted server (i.e. not one that uses hkps with GANDI certs :P) in order to prevent any blocking attacks. - some valid from/through information would need to be verified in order to prevent any downgrade/replay attacks. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: improving downloader packages (was: Re: holes in secure apt)
Christoph Anton Mitterer dijo [Wed, Jun 18, 2014 at 04:21:36AM +0200]: On Mon, 2014-06-16 at 20:14 +0200, Jakub Wilk wrote: debian-keyring is not useful for automatic authentication of source packages. Well to be honest I never fully understood the idea behind debian-keyring... IMHO this should be actually debian-developers-keyring and it should be intended just for offline systems (and thus have only little use in the real world). (...) Thanks for bringing this topic up. I'm snipping your very detailed implementation proposal, which does not sound like it was written at 4AM at all ;-) I do feel the keyring-maint package is a leftover from days long gone. Nowadays the keyring is kept at a DVCS tree, and regularly exported to a publicly accessible instance. Furthermore, it stores its full history, so you can even check if $foo was a valid key at some point in the past. FWIW, I was thinking about including the possible disappearance as one of the points to talk about in the DebConf BoF we proposed regarding keyring-maint. signature.asc Description: Digital signature
Re: sofftware outside Debian (Re: holes in secure apt)
Hi, On Mittwoch, 18. Juni 2014, Christoph Anton Mitterer wrote: torbrowser-launcher seems to use the keys from the upstream developers... basically giving them (who are not DDs) the potential power to install _any_ code in the system of Debian users. fun fact: there's at least one DD among them. It also doesn't seem to protect against downgrading attacks... (see my previous post about that). one or two bug reports might be oh so more useful than posting on -devel. That's why I wrote in my previous mail, that usually one should depend on a fixed hash in such downloader packages... doing it with gpg is securely possible, but much more complicated. and then for each update you need to update the launcher package - thats an aweful lot of work for little / no gain (and how do you handle downgrade attacks here?). and,, ISTR flashplugin-nonfree did that years ago. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: sofftware outside Debian (Re: holes in secure apt)
* Holger Levsen hol...@layer-acht.org, 2014-06-18, 12:46: usually one should depend on a fixed hash in such downloader packages... doing it with gpg is securely possible, but much more complicated. and then for each update you need to update the launcher package - thats an aweful lot of work for little / no gain Yes, maintaining packages properly takes time. If packaging new upstream releases is too much effort, why bother uploading it to Debian in the first place? It find the way flashplugin-nonfree currently works absolutely scandalous. It's non-NMU-able, and non-auditable. (and how do you handle downgrade attacks here?). There are a few mechanisms to mitigate downgrade attacks within the archive: * Valid-Until fields in the Release files; * apt refusing to install an older version of a package, unless specifically asked to do so; * security advisories and stable release announcements. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140618115532.ga5...@jwilk.net
Re: improving downloader packages (was: Re: holes in secure apt)
(so not going to comment on the first part of the thread, beside maybe: Its really sad that it is even suggested that DDs would need a technical solution for the inherently social problem of a co-worker dying…) On Wed, Jun 18, 2014 at 04:21:36AM +0200, Christoph Anton Mitterer wrote: On Mon, 2014-06-16 at 20:14 +0200, Jakub Wilk wrote: [0] And his skepticism was reinforced by (independent) discovery of this bug: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1098738 *sigh* and this is still open? 8-O Before someone is rushing to work on that (sorry, I was dreaming)… we actually have a rework for hashsum handling in libapt in our debian/experimental branch which as a minor sideeffect also solves this one. Required quiet some amount of work, multiple api breaks still and uhm… testing… but that is overrated. Someone checking this out would still be welcomed… I mean MD5 is _really_ broken now... actually I think any secure APT If you happen to have a same-size preimage attack on MD5 I would be interested to hear about it. (Its an interesting lesson in api design though. Having MD5 hardcoded in the Files: field was a bad idea in hindsight. Makes you wonder what horrible situation we were in before a time traveler made it less bad with this design…) hash some type to be present (i.e. a secure one like SHA3, or SHA512) One of the advantages of the previously mentioned rework is that it would be quiet easy to add new hash implementations - provided we would have an implementation available of course. Best regards David Kalnischkies signature.asc Description: Digital signature
Re: holes in secure apt
On Mon, Jun 16, 2014 at 12:04:51PM +0200, Thorsten Glaser wrote: On Thu, 12 Jun 2014, David Kalnischkies wrote: For your attack to be (always) successful, you need a full-sources mirror on which you modify all tarballs, so that you can build a valid Sources file. You can't just build your attack tarball on demand as the Erm, no? You can just cache a working Sources file and exchange the paragraph you are interested in. That’s something that would be easy in a CGI written in shell, *and* perform well. Trivial. The always refers to the small problem that a MITM isn't in control of what source package is acquired by the user later on. Modifying the Source file is of course trivial, the hard part is making the modification count given that at the time the request for the Sources file is made you have no idea what (if any) source package the user will request in 10 seconds/days following this 'apt-get update' (or equivalent) – if the user isn't on to you given that you have thrown away the signatures for binary packages, too, so that he can't even get his build-dependencies without saying yes to a (default: no) warning. From a theoretical standpoint, this is of course all negligible, but in practice it's so annoying/fragile that way better alternatives exist. (Me messing up InRelease parsing [twice] for example with ironically far less coverage - its all about catchy titles I guess) Best regards David Kalnischkies signature.asc Description: Digital signature
Re: sofftware outside Debian (Re: holes in secure apt)
Hi Christoph, On Montag, 16. Juni 2014, Christoph Anton Mitterer wrote: Well I guess the reason for flash is rather the license, isn't it? no, it's in contrib, because it's a downloader package. Anyway... just because something it in contrib/non-free for legal reasons... I see no necessity to handle such packages less secure. both torbrowser-launcher as well as flashplugin-nonfree use gpg to verify securely what they've downloaded. so I guess you will need to pick on other examples ;-) And just file bugs when you find these. And probably suggest a patch to Debian policy :-) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: improving downloader packages (was: Re: holes in secure apt)
On Mon, 2014-06-16 at 20:14 +0200, Jakub Wilk wrote: debian-keyring is not useful for automatic authentication of source packages. Well to be honest I never fully understood the idea behind debian-keyring... IMHO this should be actually debian-developers-keyring and it should be intended just for offline systems (and thus have only little use in the real world). The actual system of telling whether someone is a Debian Developer should be via signatures from a special key on the respective Debian Developer's public key. That special key lets call it Debian Developers Authority is controlled by the people who give DD status to others and who (right now) add their keys to debian-keyring. Signatures on DD keys could be either generally expiring after one year... on could make a simple process that automatically signs the key for another year if the respective DD requests for renewal. If not,... you easily sort out MIA people,... such people could in the worst case have died and their private key might now be in the possession of some other guys... or just laying around on some harddisk thrown away... So such a process of automatically sorting out DDs if they don't renew could have some benefits from a security POV... if a DD forgets to renew in due time... one could think about a easy (but more verifying) process to give him back his new signature. And even if one doesn't like that process of always expiring signatures, one could simply give non-expiring signatures... and the people who now remove keys from debian-keyring and mark DDs as being retired or emeritus... could revoke the signature made with the Debian Developers Authority key. For any relevant system (e.g. of the build system or whatever else) a signature would be trusted, if it was signed by a key which in turn was signed by that Debian Developers Authority key. One could even extend this, to denote special rights of some people by other such keys,... e.g. Debian Security Team Authority or Debian Project Leader Authority, etc.. The existing debian-keyring package could be retained for offline systems and simply be regularly filled/updated with keys that are signed by the authority. As a nice side effect one could use the existing keyserver network just as it is... no need for a special key database like debian-keyring. I mean most services like the build services probably never see _all_ of the different DDs regularly, right? So if an upload was made with some key ID 12345678, that key could be fetched on-demand, and one would simply set up gnupg to only trust such keys, that are signed by one of the authority keys. Well perhaps I oversee some problems (this is just a short sketch of how things could be done... completely ignoring advanced features like trust signatures, that may be very fancy in such a trust hierarchy)... but I don't know all the details and it's already past 04:00 am ;) The source package could have been signed years ago by a person who is no longer a DD. Or signed with a key that has been just replaced with another one. Or signed with a key that's not yet shipped in the package. Well I think most of the timing problems could be solved with a system as proposed above... And somehow it must already now be assured that a key is marked as this is a DD... so you don't win/loose anything here, when such a system as described above would be used. With respect to the source package could have been signed years ago... well sure... the whole idea of DD signatures on packages doesn't take away the need for signed repo files, which contain valid from/through dates and the list of currently valid packages. The idea is just, that having both, might help in case one fails (e.g. due to some bug as we've had now). [0] And his skepticism was reinforced by (independent) discovery of this bug: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1098738 *sigh* and this is still open? 8-O I mean MD5 is _really_ broken now... actually I think any secure APT system should always verify _all_ of the present sums and fail if _any_ of them doesn't match and it should _always_ expect at least one hash some type to be present (i.e. a secure one like SHA3, or SHA512) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: sofftware outside Debian (Re: holes in secure apt)
On Tue, 2014-06-17 at 13:39 +0200, Holger Levsen wrote: Well I guess the reason for flash is rather the license, isn't it? no, it's in contrib, because it's a downloader package. Well sure... but flash itself is not in main for it's license... both torbrowser-launcher as well as flashplugin-nonfree use gpg to verify securely what they've downloaded. so I guess you will need to pick on other examples ;-) And just file bugs when you find these. torbrowser-launcher seems to use the keys from the upstream developers... basically giving them (who are not DDs) the potential power to install _any_ code in the system of Debian users. It also doesn't seem to protect against downgrading attacks... (see my previous post about that). flashplugin-nonfree seems to use the key of a DD, which is much better, and I guess Bart Mertens regularly uploads new flash players and signs them himself... but still I see now protection against downgrading attacks. And attacker could easily MitM a user with an older (but vulnerable version) which is however correctly signed. Even if the signatures would expire (and Bart Mertens would resign them every few days)... you'd still have a rather large attack window. Not to talk about the practical problem, that users aren't informed any longer about new version (and security updates). That's why I wrote in my previous mail, that usually one should depend on a fixed hash in such downloader packages... doing it with gpg is securely possible, but much more complicated. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: holes in secure apt
On Thu, 12 Jun 2014, David Kalnischkies wrote: For your attack to be (always) successful, you need a full-sources mirror on which you modify all tarballs, so that you can build a valid Sources file. You can't just build your attack tarball on demand as the Erm, no? You can just cache a working Sources file and exchange the paragraph you are interested in. That’s something that would be easy in a CGI written in shell, *and* perform well. Trivial. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.10.1406161203450.26...@tglase.lan.tarent.de
Re: improving downloader packages (was: Re: holes in secure apt)
On Thu, Jun 12, 2014 at 07:31:14PM +0200, Thijs Kinkhorst wrote: I think a better way than to create such a policy would be to create a simple framework that does in-package downloading right and that downloader packages can depend on and call from their scripts (a bit like dbconfig- common). An existing technical solution will probably be more quickly adopted by the various packages than a set of requirements, and improvements need to be made in only one place. This kind-of exists in game-data-packager: except it isn't structured so that you call it from another package. Instead, the 3rd party stuff to be packaged are handled within gdp itself. I wonder whether it would be possible to extend gdp to provide such a framework, however I have a lot of reservations about the notion of running download code in postinst stages etc. at all. I once planned to rename gdp to just data-packager, coinciding with the first non-game thing to be supported. I idly considered the flash plugin or Oracle's Java as such targets. But I never did it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140616123322.ga12...@bryant.redmars.org
Re: improving downloader packages (was: Re: holes in secure apt)
Hey Thijs.
On Thu, 2014-06-12 at 19:31 +0200, Thijs Kinkhorst wrote:
You raise a lot of broad concerns under the header holes in secure apt
which
I'm afraid does not much to get us closer to a more secure Debian.
Well I admit, that first this is just a lot of words... but I think
that's the first what would need to be done - i.e. agreeing on what we
actually want... and decisions here are probably more upon core Debian
developers (I mean those which are maintaining/developing) the affected
systems and have the necessary insight.
Secondly, given the nature of these issues - they are rather deeply in
the Debian core packages and core (i.e. the build system) - it's
probably not that easy for people other than those
maintainers/developers to really move something.
For example, Thomas mentioned that things would have been more secure if
the buildds and e.g. pbuilder pulls in debian-keyring automatically and
verify maintainer signatures.
So on suggestion of mine would have been: generally do that and only
allow tools like pbuilder not do to so, when some special flag is given.
But I'm far too less into the whole infrastructure so that I could now
whether it works out in practise.
Not many
people will object that making Debian even more secure is a bad idea; it just
needs concrete action, not a large list of potential areas to work on.
Well I'd guess the later is the first step, isn't it?
Taking inventory:
- which tools do we have that obviously directly need secure APT to be
used
- APT, aptitute, etc.
- pbuilder, qemubuilder, piuparts, etc.
- [c]debootstrap
- git-buildpackage
- libraries? python-debian and friends? (especially some
perl/python/php libaries seemed to never really verified any
certificates with SSL per default, until recently)
- which things can be used for high level attacks (downgrading, blocking
attacks), like apt-listbugs, apt-listchanges, debsecan,
debian-security-support, etc. (e.g. attacking a user by not showing him
that a critical bug has been found or fixed which the user must react
on)
- which tools that are probably not directly security critical use
APT/repo-related data in an unverified way
e.g. apt-file
- at which higher levels can we tighten security even more
E.g. currently Release files seem to have a rather large validity, for
example my current one:
Date: Mon, 16 Jun 2014 09:03:47 UTC
Valid-Until: Mon, 23 Jun 2014 09:03:47 UTC
Given that we often have very nasty zero-days,... these 7 days seem
pretty long to me.
Our security team is usually very fast and we have fixes often hours
after they're released... so these long validity times give an attacker
too many additional days.
- how may people use our tools in invalid ways
- do all tools like apt give non-zero exit codes as soon as the
slightest hint for anything security problematic was found?
- may people e.g. use the contents from /var/{lib|cache}/apt/ ,...
trusting that these are always valid, but they might not (possible
races?)
- which tools do we have that circumvent the package management system
(and/or the security team) altogether
(those downloader packages, Mozilla-stuff and other things that install
plugins from the web, tools like clamav, or rkhunter, that may download
stuff from the web)
- which services do we offer (alioth, or things like paste.debian.net)
that could may be used in a way relevant for security,... which are not
tightened up enough.
If e.g. the security team would share important fixes with the
maintainers via paste.d.n... but code could be forged during that steps
(and no, I don't trust any GANDI certs,... than it may be a simple but
effective attack.
I suggest that you focus on one of those aspects of your email and take some
concrete action to get it addressed. For example this part:
Well the problem is,.. if we pick out one,... all other get forgotten...
And as you can imagine it's not up to me to decide any of these ideas...
and at best difficult to implement them alone.
Just take the IMHO too long expiry dates mentioned above... I can't just
decide this (it's probably the ftp masters who do that?)
I think a better way than to create such a policy would be to create a simple
framework that does in-package downloading right and that downloader
packages can depend on and call from their scripts (a bit like dbconfig-
common). An existing technical solution will probably be more quickly adopted
by the various packages than a set of requirements, and improvements need to
be made in only one place.
Well I think both would be needed...
a) clear policy which tells what are packages allowed to do and what not
For a package like torbrowser-launcher, verifying code just via the
upstream GPG keys is of course cheap (however, having the security
issues I've mentioned before), since if it would be done via hard coded
hashes, the debian package needs to update everytime a new upstream
version comes out.
Before it makes sense to write any framework
Re: holes in secure apt
On Thu, 2014-06-12 at 19:43 +0100, Wookey wrote: So it does default to signed downloads and SFAIK will always do this wether or not any keys are installed/available, unless explicitly disabled. What I meant was the discussion here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432309 i.e. different behaviour depending on whether debian-archive-keyring is installed or not. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: sofftware outside Debian (Re: holes in secure apt)
On Thu, 2014-06-12 at 23:06 +0200, Holger Levsen wrote: both flashplugin-nonfree and torbrowser-launcher are (or will be) in contrib (and thus not be part of Debian) for exactly those reasons you described. Well I guess the reason for flash is rather the license, isn't it? Anyway... just because something it in contrib/non-free for legal reasons... I see no necessity to handle such packages less secure. When we have things like susv[2,3,4]... we may not put them into main normally packaged, but - being honest - many users won't simply care for such license details... but what they want is, that they don't donwload HTML documentation that contains javascript which sends all their data to some attacker. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: improving downloader packages (was: Re: holes in secure apt)
* Christoph Anton Mitterer cales...@scientia.net, 2014-06-16, 19:50: Thomas mentioned that things would have been more secure if the buildds and e.g. pbuilder pulls in debian-keyring automatically and verify maintainer signatures. debian-keyring is not useful for automatic authentication of source packages. The source package could have been signed years ago by a person who is no longer a DD. Or signed with a key that has been just replaced with another one. Or signed with a key that's not yet shipped in the package. Incidentally, this is how I discovered this bug. A friend of mine (hi, Marcin!) wondered how he can authenticate a source package that was signed by a key that is not included in debian-keyring. I ensured him that there's nothing to worry about, as apt takes care of this, but he remained skeptical[0]. So I started playing with mitmproxy... [0] And his skepticism was reinforced by (independent) discovery of this bug: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1098738 -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140616181439.ga...@jwilk.net
Re: holes in secure apt
At Thu, 12 Jun 2014 18:35:39 +0200, Christoph Anton Mitterer wrote: On Thu, 2014-06-12 at 10:30 +0200, Thorsten Glaser wrote: The buildd-related software (and most people when doing manual builds with cowbuilder) uses “apt-get source foo” to download the file, fully assuming that apt-get ensures validation, so no “dscverify” is run on the sources downloaded by apt. (If someone uses dget, either dget is new enough to call dscverify, or they had better be doing that by hand.) Which is why we're possibly screwed already... even if the builds don't run as root... it seems like a rather easy way to get into the build hosts... and/or have forged source packages build and distributed. Just that NSA hasn't twittered yet that they didn't doesn't mean this is the case... So... @security-team: is there anything that is going to be done with respect to Debian's infrastructure? Or do we simply assume that noone tried that attack vector before? The security team is responsible for releasing security updates, not for securing Debian's infrastructure. See https://wiki.debian.org/Teams/Security for more information. And if you're really concerned with state actors backdooring Debian packages, then please take a look at reproducible builds: https://wiki.debian.org/ReproducibleBuilds. Securing all buildds and the personal machines of all developers against such sophisticated attackers is very difficult. Although we should of course do our best to keep everything secure, I think the best way to make sure there are no backdoors inserted when binary packages are built is to make it easy to verify they are built from the correct source package. The wiki page also has a nice Useful things you (yes, you!) can do list. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87d2ed6ro9.wl%jer...@dekkers.ch
Re: holes in secure apt
Hi Chris, On Thu, June 12, 2014 01:06, Christoph Anton Mitterer wrote: reopen 749795 stop A better way would be to add more 'found' versions so the BTS version tracking shows this bug as affecting stable. Anyone who believed in getting trusted sources might have been attacked with forged packages, and even the plain build of such package might have undermined users' security integrity. The same is the case with all debian build systems which probably rely on secure APT. It's possible, yes, but you could have noted in that exploitation would still require someone to be able to successfully position themselves to perform mitm operations between different Debian machines, which is far from trivial to say the least. It's really saddening to see that such an issue could slip through, especially when I've personally started already a few threads on debian-devel about the security of secure APT. We (the security team) will contact the maintainer about a fix for stable. In the future, I suggest you familiarize yourself with the proper contact points when you want to raise an issue. The address for security issues is t...@security.debian.org, not debian-devel. You're always welcome on #debian-security if you're unsure about how to handle an issue or where it's best reported. From the APT perspective: If you want to discuss your plans to work on improving APT, you're more on-topic at de...@lists.debian.org. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/833fcaae9c89ef2eca118dab202772f5.squir...@aphrodite.kinkhorst.nl
Re: holes in secure apt
* Thijs Kinkhorst th...@debian.org, 2014-06-12, 08:58: On Thu, June 12, 2014 01:06, Christoph Anton Mitterer wrote: reopen 749795 stop A better way would be to add more 'found' versions so the BTS version tracking shows this bug as affecting stable. Indeed. reopen throws away information about fixed versions, which is not helpful here. :\ -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140612082614.ga2...@jwilk.net
Re: holes in secure apt
On Thu, 12 Jun 2014, Christoph Anton Mitterer wrote:
Anyone who believed in getting trusted sources might have been attacked
with forged packages, and even the plain build of such package might
have undermined users' security integrity.
Then I believe Debian itself may be undermined.
The same is the case with all debian build systems which probably rely
on secure APT.
A buildd (sbuild) or cowbuilder is set up using the normal debootstrap
process with --variant=buildd using the Debian archive keyring of the
host system to validate. (This works.) Then, /etc/apt/sources.list is
written, and APT defaults to secure. The debian-archive-keyring package
is Essential, so this is always installed during the bootstrap. Porters
add debian-ports-archive-keyring (debootstrap can do that).
The buildd-related software (and most people when doing manual builds
with cowbuilder) uses “apt-get source foo” to download the file, fully
assuming that apt-get ensures validation, so no “dscverify” is run on
the sources downloaded by apt. (If someone uses dget, either dget is
new enough to call dscverify, or they had better be doing that by hand.)
The build process inside the chroot of cowbuilder also calls dscverify,
but as debian-keyring (distinct from debian-archive-keyring) is never
installed, it errors out always, which is just ignored. (That being
said, when I was doing porter builds/uploads with cowbuilder and used
dget+dscverify to retrieve the source, even the debian-keyring package
in sid was sometimes not up-to-date enough to have the new keys the
maintainers used to sign their packages in it. Since the proper buildd
infrastructure does not use this but relies on SecureAPT to validate
the files it downloads, this is understandable.)
This means that, if there was ever a chance that 'apt-get source foo'
would not check the integrity of the files it downloaded against
Sources.gz + Release{,.gpg} we’re in pretty deep shit. (Well, there
was, before SecureAPT was enacted, but that’s outside of the scope
of this.)
bye,
//mirabilos
--
“ah that reminds me, thanks for the stellar entertainment that you and certain
other people provide on the Debian mailing lists │ sole reason I subscribed to
them (I'm not using Debian anywhere) is the entertainment factor │ Debian does
not strike me as a place for good humour, much less German admin-style humour”
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/alpine.deb.2.10.1406121024050.17...@tglase.lan.tarent.de
HTTPS everywhere! (was: holes in secure apt)
* Christoph Anton Mitterer cales...@scientia.net, 2014-06-12, 01:06:
- not really secure APT related: apt-listbugs
Not sure whether it uses https for getting bug infos...
$ grep -r /soap.cgi lib/
lib/debian/btssoap.rb:@server=http://#{host}:#{port}/cgi-bin/soap.cgi;
bts(1) and reportbug(1) don't use HTTPS either, AFAICS.
I noticed that http://bugs.debian.org/ started redirecting to the HTTPS
variant recently. But it's only a temporary redirect. Does it mean we
can't rely that HTTPS for bugs.d.o will continue to exist in the future?
In general, I'd love to see all the d.o services that are currently
available over HTTP to move to HTTPS, with permanent redirects and
STS enabled.
but since Debian nowadays uses certs from GANDI,
I'm not quite happy about this either. I suppose it's a tradeoff between
security and usability...
which we generally cannot trust,... this is probably moot anyway.
Last time I checked trust and security were not binary. :
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140612085609.ga3...@jwilk.net
Re: holes in secure apt
On Thu, 2014-06-12 at 00:07 -0400, Joey Hess wrote: AAICS, #749795 talked about bringing this to the security team's attention, but they never seem to have been CCed. Thanks for doing that now... So the security team may not be aware that a security hole in apt was recently fixed, that caused apt-get source to not give any indication when the Release file was lacking a signature. Whether it's closed in unstable or not, this bug is open still in stable, and needs to get a CVE assigned, and a DSA issued. Absolutely But I somehow feel a more concentrated approach is needed... Secure APT seems to be one of the core elements of Debians overall security and integrity... and as I've mentioned in my previous post,... in many places it seems unclear how far stuff is really verified or not. That goes from end-user/admin tools over the whole upload/build/distribution infrastructure to maintenance platforms (alioth) and the hosting of the repos of packages (questions like are all things secured/verified when things like git-buildpackage is used to maintain packages?). Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: holes in secure apt
On Thu, 2014-06-12 at 08:58 +0200, Thijs Kinkhorst wrote: Anyone who believed in getting trusted sources might have been attacked with forged packages, and even the plain build of such package might have undermined users' security integrity. The same is the case with all debian build systems which probably rely on secure APT. It's possible, yes, but you could have noted in that exploitation would still require someone to be able to successfully position themselves to perform mitm operations between different Debian machines, which is far from trivial to say the least. Well I don't think it's that difficult either, is it? It could be my local sysadmin here at the institute (not that he'd do such things)... it could be any network provider,... and of course any of NSA and their friends. Of course if the later guys really want to break in they'll probably find some way ... but we don't have to open the gates and make it trivial for them. We (the security team) will contact the maintainer about a fix for stable. In the future, I suggest you familiarize yourself with the proper contact points when you want to raise an issue. The address for security issues is t...@security.debian.org, not debian-devel. You're always welcome on #debian-security if you're unsure about how to handle an issue or where it's best reported. Well this wasn't about the report that it's still open in stable (actually I only noticed that when Joey mentioned it)... even the requests for some proper communication to the users (via CVE and DSA) are just a side point... My main concern is how we can tighten security here and I think that discussion belongs to debian-devel. It's not that one person alone could go through all the relevant packages and fix them... I think before anything like that makes sense, some sane policy would be needed first, on how packages must behave, like: - are tools allowed to do things unsecured unless the user explicitly gives some very special flag (think of the example that (IIRC) debootstrap doesn't do any verifications, when debian-archive-keyring is not installed - IMHO behaviour like that should be banned) - exit status behaviour (like tools giving 0, although some files like Release* were ignored) - etc. pp. (basically the things I've mentioned before) If you want to discuss your plans to work on improving APT, you're more on-topic at de...@lists.debian.org. Well I knew of the APT list,... but as said... I think this goes beyond just APT (even though APT is probably at the core)... or at least I wouldn't consider things like [c]debootstrap, apt-list*, pbuilder, etc. to be APT. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: holes in secure apt
On Thu, Jun 12, 2014 at 01:06:28AM +0200, Christoph Anton Mitterer wrote: In my opinion this is really some horrible bug... probably it could have been very easily found by others, and we have no idea whether it was exploited already or not. Probably yes. Someone in the last ~11 years could have, but that nobody did tells you a lot about how many people actively work on what so many people seem to assume just has to work and complain loudly if it doesn't in the way it always was (assumed to be)… so, to get anything useful out of this: Should we do a kickstarter now or wait for a libreapt fork? Anyone who believed in getting trusted sources might have been attacked with forged packages, and even the plain build of such package might have undermined users' security integrity. Worst case. In practice you will have installed build-dependencies before which has resulted in a error for those, which should have been enough for you to recognise that something fishy goes on. It is at least what all automatic builders will run into. Assuming of course you don't ignore such errors which many users/scripts happily do… Also, keep in mind that the chain is broken at the Release - Sources level, not at the Sources - tarball level, so if you ship modified tarballs to your target you have to also ship a modified Sources file. For your attack to be (always) successful, you need a full-sources mirror on which you modify all tarballs, so that you can build a valid Sources file. You can't just build your attack tarball on demand as the hash (and filesize) isn't going to match with what Sources declares. (assuming you aren't good at pre-imaging, but then, why do you bother with this one here?) Combine that with the problems of being a good MITM in general and you might understand why my heart isn't bleeding that much about this particular bug. We had worse and nobody really cared… It's really saddening to see that such an issue could slip through, especially when I've personally started already a few threads on debian-devel about the security of secure APT. The most recent one was IIRC: https://lists.debian.org/debian-devel/2012/03/msg00549.html but I've had one before, I think. What is really sad is that many people keep talking about how much more secure everything should be but don't do the smallest bit of work to make it happen or even do a basic level of research themselves. So instead of answering all your questions, I will instead leave them unanswered and say: Go on and check for yourself! You shouldn't trust a random guy like me anyway and if that leads to even one person contributing to apt (or the security team or anything else really) in this area, we have a phenomenal massive increase in manpower … (for apt in the 50% ballpark!) - I think per default APT should refuse to work with unsigned repos/packages. One should really need some configuration switch or option that allows this. I will comment this one though: Michael wanted to look into this for a while now. The plan I was suggesting was something like jessie: support-unauth=true by default, jessie+1: support-unauth=false by default, jessie+2: gone. We will see if this can be implemented at all. Contributions welcome as always. I don't think it's a big issue, since all the major repos are signed and even the end-user tools to make own repos (like debarchiver) support signing. Think again. People do it all the time. It is the default mode of operation for plugging in repos into builders for example. If you are bored, just search for the usage of --allow-unauthenticated. I half-jokingly mentioned with the plan last time that a bunker is nearby, so I would be safe; half-jokingly as at least I got murder threats for far less. I doubt it will be any different with this not big issue. So be careful with what you assume to be simple and uncontroversial. See also xkcd#1172. Some usecases can be transitioned to [trusted=yes] probably, but I am not sure we really gain that much this way (as it makes things actually worse from a security standpoint) so we really shouldn't press the security: don't care crowd in this direction. Hence the slow ride-plan. People should simply be taught to not use unsigned repos... Yeah. I will try my luck with world peace first though. Might be easier… But I am a naive kid. 5 years ago I wondered why a small bug – which even I could provide a patch for – wasn't fixed. Now I wonder how the team manages to keep up with reading bugs at all; but its the same for many other Debian: native packages. aka: It took me a while to understand what no upstream really means … Best regards David Kalnischkies P.S.: Dropping security@, bug@ and everyone else in Reply-To as this chit-chat thread is just noise for them. Please don't pick up cc's at random … If you want to /work/ on anything you could move to deity@ as already suggested. Otherwise lets just talk here… (and no, you don't have to cc me either)
Bug#749795: Info received (holes in secure apt)
Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): APT Development Team de...@lists.debian.org If you wish to submit further information on this problem, please send it to 749...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 749795: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749795 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.749795.b749795.140258676429035.acki...@bugs.debian.org
Re: holes in secure apt
On Thu, 2014-06-12 at 16:54 +0200, Christoph Anton Mitterer wrote: On Thu, 2014-06-12 at 08:58 +0200, Thijs Kinkhorst wrote: If you want to discuss your plans to work on improving APT, you're more on-topic at de...@lists.debian.org. I think this goes beyond just APT (even though APT is probably at the core)... One further thing I've forgot (I've had brought this up here before, but I think the situation is still not satisfying - so sorry for repeating myself): We have a number of packages which circumvent the package management system by downloading normal files (think of HTML files as downloaded by the susv[2,3,4] packages) or even code (like torbrowser-launcher). 1) Some used to do these downloads completely unverified and installed such files Situation has improved here now,... but the problem is that we might have missed packages which do such things. - I'm not sure whether there actually are or not, but there should be clear policies which regulate such behaviour, mandating that verifications must be done... - it should be somehow unified how those verifications are done... I mean it can't be that some packages use MD5 for that job... it's broken, there's no reason to use it. Full stop. 2) Then we have packages like torbrowser-launcher, which, AFAICS, uses the gpg keys of the upstream authors for verifying anthing that was downloaded. I haven't checked the code in detail, whether this is done correctly,.. but I'd after a first glance I'd see already two problems: - downgrading attacks: upstream doesn't use expiring signatures on their files... so an attacker might MitM, with an old copy of some vulnerable torbrowser +sigs... torbrowser-launcher probably happily accepts this, since there is a valid signature signed by one of the keys. - the owners of those GPG keys are more or less empowered to circumvent the FTP masters and the security team... anything they sign, and place on there servers, would be accepted by such package... if they were the attackers, they could even do this on a per user basis, so you have basically no chance of ever noting it. I guess the same issues apply e.g. to flashplugin-nonfree. 3) For packages like torbrowser-launcher or flashplugin-nonfree it's more or less clear that some downloaded (at least when you read the package description)... there are other packages where similar things may happen and this is not directly visible... like gnome-shell which gives the gnome-shell-browser-plugin (which is automatically enabled),... which I think is very unfortunate. With all that we must remember that Debian promises security to its users,... but as you can see, there are ways to easily attack that security or at least to circumvent the security team and security updates infrastructure of the package management system (i.e. aptitude/apt won't ever notice you, when a new flash player came out) I think there should be some clear policy on how packages are allowed to pull in external code/files and install them to the system: - How packages are technically allowed to pull in external code, I think verifications should be mandatory and IMHO that verification should be via hardcoded hash sum (i.e. NOT via some gpg key from upstream),... if a new upstream version comes out, a new package should be released with new hash sums and new download path. That way we protect against downgrading attacks, don't give control to non-debian developers and make sure that all people get the same code (which will make it much easier to find about intentional attacks in that code). After all, software should come in via the package management system and task shouldn't be delegated to downloader-packages or plugin-systems like from Mozilla or GNOME. - There could be standardised package header flags like,... - installs-external-code: having that info just perhaps in the description is IMHO not enough - not-security-supported: debian-security-support is nice,... but it's rather just description,... and not a easy way to find e.g. all packages on some system which are not security-supported. Ideally, package management systems should allow people to allow/disallow with such flags. - one should generally not allow to trust on https/x509 for downloading external code/files, since - like with OpenPGP - too much power is given to people not from Debian (actually much more than with OpenPGP, since anyone in the certificate chain will have full power)... - If verification via OpenPGP/X509 would stay (and as said, security wise this would be a bad idea)... then there should be some documents explaining how maintainers should do the download... i.e. it's stupid to just wget https://bar or to gpg --verify foo ... since the default locations for certs and keys may very well contain CAs/keys you don't wanna trust for software. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: holes in secure apt
On Thu, 2014-06-12 at 10:30 +0200, Thorsten Glaser wrote:
On Thu, 12 Jun 2014, Christoph Anton Mitterer wrote:
Anyone who believed in getting trusted sources might have been attacked
with forged packages, and even the plain build of such package might
have undermined users' security integrity.
Then I believe Debian itself may be undermined.
Well I've expressed that concern before ;-)
A buildd (sbuild) or cowbuilder is set up using the normal debootstrap
process with --variant=buildd using the Debian archive keyring of the
host system to validate. (This works.) Then, /etc/apt/sources.list is
written, and APT defaults to secure. The debian-archive-keyring package
is Essential
I don't think that debian-archive-keyring is Essential... at least not
here ;-) but apt depends on it... so usually it should be in place...
The buildd-related software (and most people when doing manual builds
with cowbuilder) uses “apt-get source foo” to download the file, fully
assuming that apt-get ensures validation, so no “dscverify” is run on
the sources downloaded by apt. (If someone uses dget, either dget is
new enough to call dscverify, or they had better be doing that by hand.)
Which is why we're possibly screwed already... even if the builds don't
run as root... it seems like a rather easy way to get into the build
hosts... and/or have forged source packages build and distributed.
Just that NSA hasn't twittered yet that they didn't doesn't mean this is
the case...
So... @security-team: is there anything that is going to be done with
respect to Debian's infrastructure? Or do we simply assume that noone
tried that attack vector before?
This means that, if there was ever a chance that 'apt-get source foo'
would not check the integrity of the files it downloaded against
Sources.gz + Release{,.gpg} we’re in pretty deep shit. (Well, there
was, before SecureAPT was enacted, but that’s outside of the scope
of this.)
sure...
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Re: HTTPS everywhere! (was: holes in secure apt)
On Thu, 2014-06-12 at 10:56 +0200, Jakub Wilk wrote:
$ grep -r /soap.cgi lib/
lib/debian/btssoap.rb:
@server=http://#{host}:#{port}/cgi-bin/soap.cgi;
:-(
bts(1) and reportbug(1) don't use HTTPS either, AFAICS.
:-(
I noticed that http://bugs.debian.org/ started redirecting to the HTTPS
variant recently. But it's only a temporary redirect.
Redirects generally don't protect you...
In general, I'd love to see all the d.o services that are currently
available over HTTP to move to HTTPS, with permanent redirects and
STS enabled.
Yep :)
but since Debian nowadays uses certs from GANDI,
I'm not quite happy about this either. I suppose it's a tradeoff between
security and usability...
Well... IMHO it's a bad trade of... Debian has had it's own CA... and
all users that got their Debian via some trusted path could have really
secure SSL/TLS with Debian...
Now we have GANDI, which makes Debian's certs 4th level certs... anyone
in the hierarchy above can forge any Debian certs... (not to talk about
the problem, that all clients usually trust gazillions of CAs and not
just the one we need)...
Debian should rather have continued with their own CA and place that
even in some country which doesn't have something like national security
letters and gag orders.
Supplying the Debian Root CA to people not using Debian could have been
easily done by a *single* site that uses a cert available in all
browsers... which offers the Debian Root CA for secure and trusted
download.
Last time I checked trust and security were not binary. :
Well actually security *is* black and white... an attacker won't just
attack you a little bit if he sees a security hole...
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
improving downloader packages (was: Re: holes in secure apt)
Hi Chris, You raise a lot of broad concerns under the header holes in secure apt which I'm afraid does not much to get us closer to a more secure Debian. Not many people will object that making Debian even more secure is a bad idea; it just needs concrete action, not a large list of potential areas to work on. I suggest that you focus on one of those aspects of your email and take some concrete action to get it addressed. For example this part: Op donderdag 12 juni 2014 17:36:23 schreef Christoph Anton Mitterer: We have a number of packages which circumvent the package management system by downloading normal files (think of HTML files as downloaded by the susv[2,3,4] packages) or even code (like torbrowser-launcher). I think there should be some clear policy on how packages are allowed to pull in external code/files and install them to the system: - How packages are technically allowed to pull in external code, I think verifications should be mandatory and IMHO that verification should be I think a better way than to create such a policy would be to create a simple framework that does in-package downloading right and that downloader packages can depend on and call from their scripts (a bit like dbconfig- common). An existing technical solution will probably be more quickly adopted by the various packages than a set of requirements, and improvements need to be made in only one place. If you create something like that I'd gladly use it in the downloader package I maintain (msttcorefonts - which does check hashes of downloaded stuff, btw) and I'm willing to spend time with you on the integration and to see what may be required or missing for my package to use it. If we show that it works for this package, others will surely follow. You just need to take the first step. Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Re: holes in secure apt
+++ Christoph Anton Mitterer [2014-06-12 01:06 +0200]: - [c]debootstrap I think they both default now to verify signatures (which is a good thing)... but IIRC, debootstrap also defaults to not verify anything... if the keyrings aren't installed - admittedly this is unlikely... but possible... I found that I could not get debootstrap to do verified downloads from debian-ports with a debian-ports key. Whatever I did with apt-key, keys and --keyring options, it just said that the key was unavailable and stopped. Nice and secure, but useless, so I've had to use sudo debootstrap --no-check-gpg unstable debian-arm64 http://ftp.debian-ports.org/debian in the meantime. So it does default to signed downloads and SFAIK will always do this wether or not any keys are installed/available, unless explicitly disabled. And yes I should report a bug but have failed to do so thus far. If someone can tell me what I'm doing wrong that would improve the security of this particular usage :-) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140612184356.gn10...@stoneboat.aleph1.co.uk
Re: holes in secure apt
Hi! On Thu, 2014-06-12 at 19:43:56 +0100, Wookey wrote: +++ Christoph Anton Mitterer [2014-06-12 01:06 +0200]: - [c]debootstrap I think they both default now to verify signatures (which is a good thing)... but IIRC, debootstrap also defaults to not verify anything... if the keyrings aren't installed - admittedly this is unlikely... but possible... I found that I could not get debootstrap to do verified downloads from debian-ports with a debian-ports key. Whatever I did with apt-key, keys and --keyring options, it just said that the key was unavailable and stopped. Nice and secure, but useless, so I've had to use sudo debootstrap --no-check-gpg unstable debian-arm64 http://ftp.debian-ports.org/debian in the meantime. So it does default to signed downloads and SFAIK will always do this wether or not any keys are installed/available, unless explicitly disabled. And yes I should report a bug but have failed to do so thus far. If someone can tell me what I'm doing wrong that would improve the security of this particular usage :-) That might actually be a bug/deficiency of mini-dak, but I've not looked into it for a very long time so I could not say for sure off the top of my head. Regards, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140612200634.gb7...@pulsar.hadrons.org
Re: holes in secure apt
On Thu, 12 Jun 2014 19:43:56 +0100 Wookey woo...@wookware.org wrote: +++ Christoph Anton Mitterer [2014-06-12 01:06 +0200]: - [c]debootstrap I think they both default now to verify signatures (which is a good thing)... but IIRC, debootstrap also defaults to not verify anything... if the keyrings aren't installed - admittedly this is unlikely... but possible... I found that I could not get debootstrap to do verified downloads from debian-ports with a debian-ports key. Whatever I did with apt-key, keys and --keyring options, it just said that the key was unavailable and stopped. Nice and secure, but useless, so I've had to use sudo debootstrap --no-check-gpg unstable debian-arm64 http://ftp.debian-ports.org/debian in the meantime. So it does default to signed downloads and SFAIK will always do this wether or not any keys are installed/available, unless explicitly disabled. And yes I should report a bug but have failed to do so thus far. If someone can tell me what I'm doing wrong that would improve the security of this particular usage :-) This works for me: sudo apt install debian-ports-archive-keyring sudo apt-key add /usr/share/keyrings/debian-ports-archive-keyring.gpg sudo debootstrap --variant=buildd --foreign --arch=arm64 --keyring /usr/share/keyrings/ debian-ports-archive-keyring.gpg sid arm64-sid http://ftp.de.debian.org/debian-ports Make sure apt-key list shows something including: /etc/apt/trusted.gpg.d/debian-ports-archive-2014.gpg pub 4096R/623DB0B8 2014-01-16 [expires: 2015-01-31] uid Debian Ports Archive Automatic Signing Key (2014) ftpmas...@debian-ports.org -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
sofftware outside Debian (Re: holes in secure apt)
Hi Christoph, On Donnerstag, 12. Juni 2014, Christoph Anton Mitterer wrote: [many things] both flashplugin-nonfree and torbrowser-launcher are (or will be) in contrib (and thus not be part of Debian) for exactly those reasons you described. And both rightfully belong to contrib, even though torbrowser is free software. And while I applaud the iceweasel project for its commitment to free software, I would also applaud a firefox-launcher or -installer package in contrib - not everything is for everybody :) cheers, Holger signature.asc Description: This is a digitally signed message part.
holes in secure apt
reopen 749795 stop Hi. I'm reopening this for now, even if the issue is solved from a technical point of view (see below why). In my opinion this is really some horrible bug... probably it could have been very easily found by others, and we have no idea whether it was exploited already or not. Anyone who believed in getting trusted sources might have been attacked with forged packages, and even the plain build of such package might have undermined users' security integrity. The same is the case with all debian build systems which probably rely on secure APT. So IMHO this bug definitely deserves a CVE and a DSA,... so that people are informed that there systems might have been compromised (i.e. if an attacker tricked them into using forged sources)... which is also why I reopen it. And do we need an investigation whether Debian an the Debian archives themselves might have been intruded that way? It's really saddening to see that such an issue could slip through, especially when I've personally started already a few threads on debian-devel about the security of secure APT. The most recent one was IIRC: https://lists.debian.org/debian-devel/2012/03/msg00549.html but I've had one before, I think. I think such bug shows that we can't just move on as we did till now... From the APT perspective: - Do we have unit checks now in APT, which basically test all commands with unsigned repos, repos with invalid signature, packages where the sums don't match the valid repo signatures, etc.? We really should have this,.. and also check for things like expiry dates. - I also think that there should be one place of code that handles all downloads of packages, so that we have some rock solid functions, which do all the checks and verifications. - I think per default APT should refuse to work with unsigned repos/packages. One should really need some configuration switch or option that allows this. I don't think it's a big issue, since all the major repos are signed and even the end-user tools to make own repos (like debarchiver) support signing. People should simply be taught to not use unsigned repos... - That being said,... APT should always delete all cached files (repo lists, signature files, Package and Source lists as well as downloaded packages) as soon as a single verification error occurred at some place. And since 3rd party programs or users may manually take stuff from places like /var/lib/apt/lists or /var/cache/apt/archives... these directories should contain a subdir like unsecured/ where APT downloads stuff to and only moves it out from there once all checks have been passed. - In case any even just remotely possible security issue occurs... apt should exit with a non-zero status and not just a warning wich shell scripts from users usually won't check for. What about 3rd party programs and Debian in general: There are still probably many programs which download stuff without any verification,... or just warn which may be easily overseen: - [c]debootstrap I think they both default now to verify signatures (which is a good thing)... but IIRC, debootstrap also defaults to not verify anything... if the keyrings aren't installed - admittedly this is unlikely... but possible... I've already had a discussion at the respective bug with upstream, but nothing happened... I think such choices make it easily happen for security critical situations to occur... completely unnecessary. - not really secure APT related: apt-listbugs Not sure whether it uses https for getting bug infos... but since Debian nowadays uses certs from GANDI, which we generally cannot trust,... this is probably moot anyway. Securely showing bugs, may be important for users, since they want to now about bugs like big security hole in package XYZ - don't install - apt-listchanges Guess that uses local files an is therefore secure. - apt-file Last time I checked, the bug about not verifying the sums of the Contents-* files was still open - what about our build daemons and building tools like piuparts, pbuilder, pbuilder-uml, debian-builder or qemubuilder Do they use secure APT in ALL places? Is this constantly checked by some unit tests? Or are they easily tricked into using possibly insecure files, by depending on exit statuses which are perhaps not != 0 in case of security problems ... or by using files which were downloaded but not removed when it was found out that they're insecure. I think a package like e.g. pbuilder might easily operate insecurely... it depends on [c]debootstrap for building... if debootstrap is used, but debian-archive-keyring is not installed, then (IIRC) no signature checking is done... in that case forged stuff may be downloaded, chrooted into... and *bam* - already lost the game... and you don't even need a hole like APT not checking files it gets with apt-get source. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: holes in secure apt
Christoph Anton Mitterer wrote: reopen 749795 I'm reopening this for now, even if the issue is solved from a technical point of view (see below why). AAICS, #749795 talked about bringing this to the security team's attention, but they never seem to have been CCed. So the security team may not be aware that a security hole in apt was recently fixed, that caused apt-get source to not give any indication when the Release file was lacking a signature. Whether it's closed in unstable or not, this bug is open still in stable, and needs to get a CVE assigned, and a DSA issued. -- see shy jo -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140612040738.ga20...@kitenet.net
