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

holes in secure apt

reopen 749795


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

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

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


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

Reply to: