On Sun, Jun 6, 2010 at 1:37 AM, Michael Gilbert <michael.s.gilb...@gmail.com> wrote: > All of the issues raised in this paper can be mitigated by a "proactive" > user. Malicious mirror activity can be detected by paying attention to > debsecan and the security tracker [0]. debsecan displays all known > vulnerable packages on a particular system, and the security tracker > displays all known vulnerable packages. Differences between the two for > a period longer than about a week would be a sign that the mirror is > intentionally holding back vulnerable packages. > > Of course the major flaw with this statement is that there aren't a > whole these "proactive" users. However, if there are enough, some will > spot the activity, and raise concern, which will ultimately protect > others when the evil mirror is shut down.
Agreed. I'd like to point out that since we sign root metadata, it's impossible to keep some packages outdated (say, daemons facing the internet) while others are up-to-date. What this means is that a replay or freeze attack is very unlikely to go unnoticed. Lots of packages being downgraded, no updates for too long, things like that stand out. If an admin doesn't notice that, I find it unlikely that he or she will notice a stale mirror warning either. Moreover, as people have said already, stable is safe because security updates come directly from security.debian.org, not from mirrors. The remaining issues I see are: 1. Man-in-the-middle attacks between clients and security update servers 2. Denial-of-service attacks to the security updates infrastructure 3. No trusted servers for security updates for testing and unstable Using HTTPS for the security update infrastructure could solve #1, but not much can be done about #2 (though such an attack would be Hollywood-esque in scale). Now if we had a timestamp in the root metadata updated on a daily basis, that would solve #1 and #3 (or anything else related to replay attacks), and it doesn't sound too hard to implement (of course, talk is cheap). #2 is not quite under our control. Another idea would be actively comparing mirrors to make sure evil or dead mirrors are removed from our list of mirrors (if that isn't the case already). Not much can be done if the end user isn't being notified, though. Coupled to that, maybe some sort of PKI could make it possible to revoke the hability of the mirror to advertise itself as a trusted, up-to-date mirror. The bottomline seems to be that stable is safe enough, whereas if you use something else you're on your own as usual, but I believe we can improve this situation. I'm neither a security guy nor a Debian infrastructure guy, so please take my words with a grain of salt. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin08k1oam2-qbnqqmununf6_fvmx6-_7mjyg...@mail.gmail.com
