[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 deity@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

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


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: