Re: Package management unsafe?
Florian Weimer <fw <at> deneb.enyo.de> writes:
>
> * Ron Johnson:
>
> >
http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html
> >
> > What are people's thoughts on this?
>
> HTTPS doesn't help against non-trusted mirrors.
>
> The difficult question is how to tell an APT source which is not updated
> regularly from an APT source that has been rolled back in a replay
> attack.
Actually the attack works just fine without rolling back for a replay attack.
I have my mirror stop updating. If I can assume that most clients use only my
mirror, and not others, then once a major security flaw comes out in a package
version my mirror uses, then I have a list of IP addresses (from my server logs)
that may be exploitable.
So there is no reason to differentiate between a stale mirror and a potential
attack mirror. Any mirror more than say 7-days out of date should be considered
potentially unsafe, and the user should be warned that the mirror is stale,
which may be an attack attempt, and that they should consider choosing a new
mirror. Having the signature on the package file update daily, even if the
package file contents have not changed would be an easy way to detect a stale
mirror. Just add a check on the signature time-stamp as part of checking the
package signature, and warning if signature is too old.
But the attack is not really applicable to Debian, where security updates come
from trusted security mirrors, and not the general mirrors. If this were not the
case, then the following statement from the site would be concerning:
>For example, it is known that an earlier version of OpenSSL for Debian has a
>security flaw. The list of files from the repository that previously included
>this package is still correctly signed. Using this old signed file list, a
>malicious mirror can keep a client on the insecure version of OpenSSL by
>responding to the client's package manager with the old list of files.
As it is, the mirror can do no such thing. (Only a security mirror could do
this) This is a very good thing.
Indeed there is a second possible attack vector if the general mirrors were used
for security updates. I could set my mirror up to watch for people requesting a
specific security update. While the file is being downloaded, a script could
automatically attempt to exploit the vulnerability on the system that requested
the update. The idea is that there is a high probability that the system
requesting the update has the insecure version installed, and is thus
exploitable.
However, if the security updates come from trusted security mirrors rather than
a general mirror, that attack would fail too. So with the exception of Sid or
Testing users that do not use the testing-security system to receive security
updates, Debian really is not terribly vulnerable to this.
But I still strongly recommend the signature time-stamp solution (which Don
Armstrong suggested first) as it would let us notify users that a mirror is
stale regardless of whether this is malicious, and it would help protect Sid and
testing users. It would even add some additional security to Debian-derived
distros that do not use a separate security mirror system. (Although they would
still be vulnerable to the exploit while downloading issue.)
Reply to: