Re: Package management unsafe?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steinar H. Gunderson wrote: http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html What are people's thoughts on this? It's been known for quite a while. (I asked one of the guys publishing it, and he was fully aware of that, but felt it was still important to bring light to it.) I'm the researcher that Steinar exchanged emails with. I just wanted to clarify this a bit as I believe he misunderstood something I said the other week. -- Sorry for any confusion, Steinar. These types of attacks, replay attacks[1] and endless data attacks[2], were well-known in general, but not with respect to APT or other package managers being vulnerable to them. We by no means are claiming to have discovered replay attacks, nor are we aware of previous widespread disclosure that package managers are vulnerable to these attacks. A big thank you to the various Debian security people who have helped answer questions and verify information for us recently. I believe most of the issues we disclosed are in discussion and will be addressed. [1] http://en.wikipedia.org/wiki/Replay_attack [2] http://insecure.org/stf/wietse_murphy.html - -- Justin Samuel https://www.cs.arizona.edu/~jsamuel/ gpg: 0xDDF1F3EE [66EF 84E2 F184 B140 712B 55A7 2B96 AB8F DDF1 F3EE] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIiUXsK5arj93x8+4RApbRAKCrdycZYMjKIVb8F1KLWh/mSoSL/wCgsVba +TqRksohzfEUEUL9Tiy8wn0= =Y0nc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
On Fri, Jul 11, 2008 at 07:36:44AM -0500, Ron Johnson [EMAIL PROTECTED] was heard to say: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html What are people's thoughts on this? I don't see anything new or surprising on that page. In fact, the two attacks they list (replaying old versions of an archive and taking over a mirror) were discussed at the time that archive signing was added to apt. My recollection is that the conclusion regarding replay attacks was that it wasn't clear how signing archives would prevent this (you would presumably need to somehow periodically change the archive signature, and warn the user if it was out of date). Mirror takeovers are, of course, exactly why archive signing was added to apt. I'm talking now about their use to provide unsigned and faulty packages, not to delay updates (which is just a replay attack). It's not clear whether archive signing will actually defend against this attack *in practice*; some users seem to investigate bad signatures, but I'm sure a lot just override the warning, especially because there are an unfortunately high number of false positives. But the technology itself can detect this situation. When I saw the headline I figured he was talking about actual code vulnerabilities in package managers (e.g., buffer overflows parsing the Packages file); that would be a lot more interesting and worrying. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
On Sun, 2008-07-13 at 02:13 +0200, Franklin PIAT wrote: Hello, On Sat, 2008-07-12 at 23:13 +, Joe Smith wrote: Andrei Popescu andreimpopescu at gmail.com writes: One costly solution would be to get the client the send a challenge to a trusted server, which would respond by gpg-signed the challenge + the checksum of current .Release file. How would all these schemes work with offline mirrors? eg, ones that are built, and used without an internet connection for a month. kk Franklin -- Karl Goetz [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Package management unsafe?
On Sun, 2008-07-13 at 16:19 +0930, Karl Goetz wrote: On Sun, 2008-07-13 at 02:13 +0200, Franklin PIAT wrote: Hello, On Sat, 2008-07-12 at 23:13 +, Joe Smith wrote: Andrei Popescu andreimpopescu at gmail.com writes: One costly solution would be to get the client the send a challenge to a trusted server, which would respond by gpg-signed the challenge + the checksum of current .Release file. How would all these schemes work with offline mirrors? eg, ones that are built, and used without an internet connection for a month. You would be warned that your security update server can't be contacted/validated, which is accurate. BTW, of course, the GPG wouldn't have to be Debian key, but any trusted key for that purpose (e.g including corporate, Debian derivative key). Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
On Sat,12.Jul.08, 06:12:33, Joe Smith wrote: 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. How about distributing the Release files *only* from a trusted server? Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Package management unsafe?
Andrei Popescu andreimpopescu at gmail.com writes: How about distributing the Release files *only* from a trusted server? Regards, Andrei That is problematic, as it does not deal with mirror synchronization properly. If a mirror takes a few hours to update, it's Packages files may not be up to date during those hours, resulting in apt claiming the Packages file is not validly signed. I see no benefits over re-signing the Release file daily, even if none of the Packages files (and hence the checksums and Release file itself) have changed, with apt then complaining if Release.gpg has a signature that is too old. This adds security against the published attack for testing users who do not use testing-security as well as sid users. It also helps warn users about non-malicious stale mirrors. As my post made clear, stable is already secure against the published attacked. The other attack I mentioned (the attack of attempting to exploit a flaw in any client that requests a security update) cannot be fixed in the general case, except by clients using a trusted server, or a trusted proxy that does not reveal the true requesting system's IP. Stable is safe because the security servers are trusted. Users of testing or sid should choose servers they trust or some form of trusted proxy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
Hello, On Sat, 2008-07-12 at 23:13 +, Joe Smith wrote: Andrei Popescu andreimpopescu at gmail.com writes: How about distributing the Release files *only* from a trusted server? The other attack I mentioned (the attack of attempting to exploit a flaw in any client that requests a security update) cannot be fixed in the general case, except by clients using a trusted server, or a trusted proxy that does not reveal the true requesting system's IP. Stable is safe because the security servers are trusted. Users of testing or sid should choose servers they trust or some form of trusted proxy. Stable is safe... as long as there's no man-in-the middle attack (e.g like a public wireless access-point with a transparent http proxy, if it's used over a long period of time). If we also consider the fact that the computer local time might be wrong (hwclock bug + a ntp man-in-the-middle...), re-signing the files doesn't help either [in this very specific case]. One costly solution would be to get the client the send a challenge to a trusted server, which would respond by gpg-signed the challenge + the checksum of current .Release file. Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
Joe Smith wrote: 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. It would still be possible to mount this attack if the attacker can intercept packets on the way to the official trusted security mirror and redirect them (e.g. transparent proxy) to an older copy of the mirror. Brian May -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
On Sun, Jul 13, 2008 at 02:13:08AM +0200, Franklin PIAT wrote: If we also consider the fact that the computer local time might be wrong (hwclock bug + a ntp man-in-the-middle...), re-signing the files doesn't help either [in this very specific case]. I think that your average user would notice if the time were wrong. Even if the user isn't in an environment that is time-sensitive (e.g. a network using Kerberos), most people would wonder what happened if their computer's time were suddenly several days off. I think the much more likely case is that the time is accidentally incorrect, such as when a new machine is first installed. That may affect the installation of ntp itself, perhaps. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Package management unsafe?
On Fri, Jul 11, 2008 at 07:36:44AM -0500, Ron Johnson wrote: http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html What are people's thoughts on this? It's been known for quite a while. (I asked one of the guys publishing it, and he was fully aware of that, but felt it was still important to bring light to it.) In any case, it's pretty hard to exploit as long as you have security updates on a different (trusted) server. The best thing you can do is DoS the process so the user's package management software crashes, or simply never update your mirror so users don't get updates. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
Maybe a check should be added to APT to flag a warning if there has been no updates for a significant period of time? That way if a mirror ever does that, its more detectable. Michael On Fri, Jul 11, 2008 at 8:55 AM, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Fri, Jul 11, 2008 at 07:36:44AM -0500, Ron Johnson wrote: http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html What are people's thoughts on this? It's been known for quite a while. (I asked one of the guys publishing it, and he was fully aware of that, but felt it was still important to bring light to it.) In any case, it's pretty hard to exploit as long as you have security updates on a different (trusted) server. The best thing you can do is DoS the process so the user's package management software crashes, or simply never update your mirror so users don't get updates. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
* 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. Apart from that, this is clearly a PR stunt. Next, we might see someone who tries to get into the project, with the intent to upload Trojanized packages--all in the name of academic research. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It doesn't have to have updated packages, maybe have something like this APT-Ping: *timestamp* and then push out a new packages file with just an updated timestamp in it. Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFId//JpblTBJ2i2psRAu6uAJ48+knPTzxi1InA/Wg3AN4m2Rt8WwCfa/ES rddl6+w/Kw+7UBVNQLjLplE= =fGdJ -END PGP SIGNATURE- On Fri, Jul 11, 2008 at 8:39 PM, Frank Lichtenheld [EMAIL PROTECTED] wrote: On Fri, Jul 11, 2008 at 11:48:03AM -0400, Michael Casadevall wrote: Maybe a check should be added to APT to flag a warning if there has been no updates for a significant period of time? That way if a mirror ever does that, its more detectable. That really doesn't make any sense for stable users since our point releases aren't exactly weekly ;) Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/
Re: Package management unsafe?
On Fri, Jul 11, 2008 at 11:48:03AM -0400, Michael Casadevall wrote: Maybe a check should be added to APT to flag a warning if there has been no updates for a significant period of time? That way if a mirror ever does that, its more detectable. That really doesn't make any sense for stable users since our point releases aren't exactly weekly ;) Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package management unsafe?
On Sat, 12 Jul 2008, Frank Lichtenheld wrote: On Fri, Jul 11, 2008 at 11:48:03AM -0400, Michael Casadevall wrote: Maybe a check should be added to APT to flag a warning if there has been no updates for a significant period of time? That way if a mirror ever does that, its more detectable. That really doesn't make any sense for stable users since our point releases aren't exactly weekly ;) It wouldn't be a huge deal to re-sign the package list every n days and warn if the package list was signed more than n+r days ago. [This would even be useful to handle properly mirrors which are just out of date even without nefarious behavoir.] Don Armstrong -- Quite the contrary; they *love* collateral damage. If they can make you miserable enough, maybe you'll stop using email entirely. Once enough people do that, then there'll be no legitimate reason left for anyone to run an SMTP server, and the spam problem will be solved. -- Craig Dickson in [EMAIL PROTECTED] http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
