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: 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: 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: 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: 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: 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: 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
