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

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)

Attachment: signature.asc
Description: Digital signature

Reply to: