[Pythonmac-SIG] Package Manager idea, adding a URL scheme

Glenn Andreas 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 
>>there.
>
>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 
aren't usable).

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 mailing list