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

Re: Debian mirrors and MITM

On Fri, May 30, 2014 at 10:03 AM, Hans Spaans <hans@dailystuff.nl> wrote:
> What basically is missing for a running system is repository signing key
> pinning for packages that would "prevent" that a third party repository
> could upgrade components provided by the base OS. How many of us didn't
> added debian-multimedia.org repositories and their PGP-keys to our
> systems in the past? How many of us didn't added some weird PPA? And who
> did remove remove both repo-lines AND PGP-keys when not needed anymore?
> And how many of those keys have proper rollover/revoke/maintenance
> procedure?
> Currently Debian checks if a package is signed by a trusted source, but
> not if the package is trusted for the package that you're going to
> update. Looks like a fun excise to offer a new apt package through the
> debian-multimedia infra for example and see who will notice. Or a
> modified openssh-server/client package through a populair PPA-repo.

Thanks for bringing that issue! I feel the same way when I install a
packet from a non-official PPA.

It's definitely a problem of trust: I trust this PPA to install (say)
firefox beta but I don't trust it enough to replace openssh.
In this case you could think that pinning openss-server on the
"official" repository would make the work but since the PPA could also
rewrite a library used by openssh-server, it could inject code into it
easily without alarming anyone (who cares when a PPA updates libfreebl

To "protect" openssh-server you would need to prevent modification of
its dependency. But the PPA could just install a program that
overrides the openssh-server manually (without doing that from APT).
In this case, unless you run debsums you wouldn't notice it.

In the end, the PPA can do pretty much whatever it wants from your
system and this is scary. This is a hard problem to protect against
and the only protection I see is... only install PPAs you can trust.


Reply to: