[Pythonmac-SIG] Package Manager idea, adding a URL scheme
gandreas at delver.com
Fri Oct 3 19:11:50 EDT 2003
>On Friday, Oct 3, 2003, at 17:21 America/New_York, Glenn Andreas wrote:
>>Though SSL is more than just an encryption mechanism, it also
>>provides an authentication mechanism . But I definitely agree that
>>it is easier to compromise a server than aquire a private key.
>Yes but AFAIK you can't get to this information without M2Crypto or
>some other OpenSSL wrapper. The SSL certificate authentication
>mechanism, in my opinion, should be for the user's eyes to trust
>when they look at a page containing the public key and URL of a
>particular PackMan database.
And I'm guessing using OS-X specific libraries is out...
>>I'm clearly missing something here, because if we have the
>>databases come from a trusted source (python.org) using SSL, we
>>should be able to trust that they are correct when we get them
>>(since part of the purpose of SSL is so that you know who you are
>>talking to). If nothing changes them, and if the "user experience
>>code" is trusted, they should reliably reflect if the packages
>>downloaded from non-trusted hosts are valid.
>But using a cryptographic signature on the PackMan database is a
>little more secure, and is much easier and less expensive than SSL.
>I think the SSL trusted site should be used to acquire public keys
>and locations for PackMan databases that should be trusted. After
>the public key is acquired safely, the user can download the PackMan
>database files from untrusted communication channels because they
>can verify whether the person who signed it is who you think it is.
So there is _one_ (or possibly _a few_) public key, obtained from a
known & trusted location (python.org) via a trusted transport (SSL),
so we know that those signatures are valid according to "python.org"
as being able to sign PackMan databased.
>>This may require retrieving the database from python.org every time
>>that PackMan is run (though if anything can change the databases,
>>it can change PackMan or whatever the "user experience code" is
>>that verifies the intergrity), but I don't see what more is needed
>The database has to be retrieved every time PackMan is run to check
>for new packages.
And it (or possibly "they") can be obtained from different untrusted
locations (e.g. scapegoat.com), correct? The packages themselves
then come from third party untrusted locations (e.g.
mythirdpartypackage.com). Do hash on package, compare hash to data
base entry (where the database itself has been authenticated by
signature, which would have to be done outside of PackMan since core
Python has no digital signature support, just like it has no SSL
support), and if we match, everything is golden.
So if the master public keys on python.org are subverted (either by
recovery of private keys, or hacking of python.org to replace the
key), then all bets are off, or if PackMan at some point is subverted
(or a bunch of other trusted points on the user machine), similar
issues abound. But if PackMan & friends are good to start with, and
the packages themselves aren't subversive (or introduce other holes),
everything seems pretty reasonable. The only other obvious
vulnerability would be faking the hash (which is doable with weaker
hashes like simple CRCs).
There are "out of band" issues - for example, EvilHacker manages to
compromise mythirdpartypackage.com, makes a new trojan version that
package, sends mail to scapegoat ("Hey dude, got a new version,
here's the hash") and then scapegoat updates the database with the
now tainted version of the package, and the user thinks everything is
dandy until they use ThirdPartyPackage which turns their machine into
a toaster, but those are policy level issues.
There is also the chance for some sort of "buffer overrun" (or other
PackMan vulnerability) which would be used to subvert PackMan when
downloading ThirdPartyPackage from the (now compromised by
EvilHacker) mythirdpartypackage.com, or some other "man in the
middle" scheme to activate the buffer overrun bug (during either the
retrieval of the database or the package).
The use of digital signatures could be avoided, but at the cost of
keeping a hash of the valid databases on python.org, retrieved via
SSL whenever the databases are updated. (And then that hash validates
the database, just like the hash in the database validates the
package), but then a new database require retrieving a new set of
hashes which require a new SSL transaction which can't currently be
done in the core Python (and we assume that OS-X specific libraries
All in all, it seems that PackMan itself is the biggest vulnerability
with this scheme (i.e, what happens with invalid databases are fed to
it, or invalid packages, or are there other ways to get PackMan to
execute untrusted code), since the rest of the system relies on
existing mechanism that are "well travelled".
I'm still not sure what mechanism would be used to verify the
signature (without something like PyCrypto), but those are "details".
Glenn Andreas gandreas at delver.com
Theldrow, Blobbo, Cythera, oh my!
Be good, and you will be lonesome
More information about the Pythonmac-SIG