Study: Attacks on package managers
Study: Attacks on package managers
Posted Jul 14, 2008 17:14 UTC (Mon) by DeletedUser32991 ((unknown), #32991)Parent article: Study: Attacks on package managers
Debian uses signed package files and includes security.d.o (administered by Debian itself) in the default configuration. The latter seems to exclude the possibility of keeping things insecure by using old package files on the mirror. And the suggestion to use HTTPS... Bad research at its best.
Posted Jul 15, 2008 10:18 UTC (Tue)
by nhippi (subscriber, #34640)
[Link] (1 responses)
Posted Jul 15, 2008 18:49 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Jul 17, 2008 17:20 UTC (Thu)
by justincappos (guest, #52950)
[Link]
Study: Attacks on package managers
To put it more plainly:
The attacker cannot use a malicious mirror inject old content against security.debian.org,
since security.debian.org isn't mirrored by third parties.
Testing users could become vulnerable. Mitigating against this would be relatively easy to
implement, as the Signed "Release" file already has A "Date" field. - Just check that it isn't
older than X days. As a added bonus, users will start noticing if their mirror has problems
getting updates.
One option the attacker has is transparent proxies, but then again you are in big trouble
anyway (mmm.. cookies..) if a cracker manages to root your ISP's transparent proxy.
Study: Attacks on package managers
`X' days doesn't work for any fixed value of X. A better check is to check
that the package date is not much older than the last time you downloaded
a set of updates which should have included that package (`much'
introduced to allow time for the package to be uploaded, inter-mirror
propagation delays, et al).
Downside: this means that after Debian's ftpmasters sit on a package for
five hundred years they have to get it re-signed before putting it into
the repo ;) and I'm not sure what implications it has for
automatically-promoted repositories such as Debian testing: perhaps the
Date header should be updated, and the signing repeated, by the (trusted)
software with a silly name which does the promotion (I can't remember that
name right now, it always drops out of my head). If attackers take *that*
over, we're all dead anyway.
(sorry for the jab at ftpmasters gone, I couldn't resist ;} )
Debian security
(Disclosure: I'm an author of the study)
I agree with you that using a security repository significantly reduces the vulnerability to
attack. This doesn't protect against the "endless data" attack we describe that can be used
by a mirror to crash clients, but this is not as big of a threat as compromising the client.
(Does Debian need to contact so many mirrors by default?)
There are several other minor issues that remain and may impact Debian users that we didn't
see discussed here. First, there is no authentication that you are talking with the security
repo, so a MITM attacker can still launch attacks by masquerading as the repo. HTTPS with
correct certificate checking would prevent this, hence the HTTPS ("Bad research at its best")
suggestion. :)
Second if the security repo fails or is not contactable from a client (non-transitive
connectivity, etc.) then the mirrors can attack clients by replaying content from the security
repo.
Third, clients who use netselect-apt, etc. should be aware that they are likely to remove the
security repo from their list of mirrors and thus become vulnerable.
In general we found that Debian's practice of using a security repository is effective in
protecting their users from replay / freeze attacks in the majority of cases for users with
default configurations.
There is another issue with Debian that we didn't bring up on the web pages because we felt
there was already too much loosely connected content. We briefly looked at the developer
update process and if I understand correctly from reading the documentation any developer can
update any package (they are encouraged not to except in extreme situations but have the
ability to). Furthermore, if I understand correctly there are thousands of keys in the
developer database so really this means that a compromise of any key allows an attacker to
upload any package. Also there are keys as short as 768 bits and as old as 1993. I'm not a
crypto expert so I don't really know how to quantify risk, but both of those numbers trigger a
mental alarm. Anyways, I was hoping that you could also clarify / correct / confirm any of
this information as well.
Thanks,
Justin Cappos