Study: Attacks on package managers [LWN.net]

Study: Attacks on package managers

Posted Jul 15, 2008 6:29 UTC (Tue) by k8to (subscriber, #15413)
In reply to: Study: Attacks on package managers by JoeBuck
Parent article: Study: Attacks on package managers

The reason it doesn't inspire confidence is that this error occurs during normal operation.

Sometime this error indicates a problem of grabbing an inconsistent set of files from a
round-robin type situation.  Yes, the system has saved me from data corruption, theoretically.
Realistically, it is an embarassment that these inconsistencies are encounterable in normal
configurations.  For example, chosing a host such as http.us.debian.org will often result in
data inconsistency during updates.  Why is this advertised as a viable mirror selection if it
does not work reliably?

Sometimes, however, this error indicates a "problem" such as not bothering to run update for a
few weeks and the key has expired.  Once this error indicated that the key had expired before
the new key was even made available, and so the web of trust simply did not extend from one
administration key to the next.  Every user of debian testing encountered this during one
transition.

Perhaps you begin to see the problem?  This thing pops up all the time to suggest a problem
which is not caused by incorectly signed or unsigned files.  How will you identify a real
security issue in the noise?

(Log in to post comments)

Study: Attacks on package managers

Posted Jul 15, 2008 7:02 UTC (Tue) by MattPerry (guest, #46341) [Link]

> Sometimes, however, this error indicates a "problem" such as not
> bothering to run update for a few weeks and the key has expired.

Are the keys really being regenerated that quickly?  What is the reason for doing that rather
than keeping a key for a long time?

I wonder if that might have something to do with my problem.  I usually don't update my
servers unless I see a post on the security-announce lists indicating that there's an update
for a package that I use.  I can sometimes go for a month or two (or more) before running
apt-get update.  The Ubuntu system that I was attempting to upgrade today was last powered on
sometime in May.

> How will you identify a real security issue in the noise?

I agree.  Right now it seems like "the boy who cried wolf."

Study: Attacks on package managers

Posted Jul 15, 2008 9:45 UTC (Tue) by epa (subscriber, #39769) [Link]

The existence of flaky, corrupted mirror sites is another argument in favour of dropping
old-style mirrors and using Bittorrent or some other protocol that handles the mirroring
automatically and is robust against misbehaving nodes.

Study: Attacks on package managers

Posted Jul 15, 2008 12:07 UTC (Tue) by job (subscriber, #670) [Link]

No, it is not.

The system of signatures just prevented you from downloading data from a "misbehaving node"
(i.e. corrupted mirror), and you blame the system?

The mirroring IS handled automatically, AND you are protected from bad data. What would be
good would be failover handling in the package manager so you didn't need to see that message
at all.

It would also be desirable to protect from the attack described in the article, perhaps using
timestamped and signed package indexes?

Study: Attacks on package managers

Posted Jul 16, 2008 14:49 UTC (Wed) by epa (subscriber, #39769) [Link]

Checking the signature is a good thing and I'm not blaming that at all. I am kvetching about the corrupted mirror site existing in the first place. Removing the signature check, obviously, would not improve things. Better error reporting of 'the download failed and the file was truncated' before even attempting the signature check would be helpful, but not essential.

What would be good would be failover handling in the package manager so you didn't need to see that message at all.

Yes. Some kind of client library that automatically handles selecting an upstream server (or more than one, if the download is to be parallelized), checks for data consistency, and restarts or switches servers if the consistency check fails. Bittorrent is one example of a protocol that handles all this, with the added bonus that nodes can share data between each other (as when two machines on the same network both need to update), and that setting up a traditional mirror site using cron jobs and perl scripts is not necessary (just start up the Bittorrent program and tell it how much bandwidth and disk space to use). Some kind of intelligent http frontend would also do the job. Of course you still need to check package signatures after the download has completed successfully.

Study: Attacks on package managers

Posted Jul 16, 2008 0:44 UTC (Wed) by motk (subscriber, #51120) [Link]

Bittorrent is not a hammer, and not everything is a nail.