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

[Bob Ippolito]

On Friday, Oct 3, 2003, at 19:11 America/New_York, Glenn Andreas wrote:

>> 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...

Well I think that PackMan should be allowed to use Win32 specific 
libraries on Windows if available, OpenSSL on OS X and other posix 
systems if available, or command line utilities.  But it has to know 
how to get along insecurely.  The problem is distributing a version of 
Python contains crypto is not always feasible.  I suppose we could 
distribute a module that dynamically links to one of these libraries if 
it exists (in a clean way), otherwise it does not import and PackMan 
would fall back to something else or get along insecurely.

>>> 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.

Yup, or the user could add a public key to their PackMan "trust ring" 
if they choose to, however they obtained it.

>>> 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.

Exactly, thanks for explaining this in a clear way.

> 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).

Well, the first time the user downloads the trusted key list from 
python.org it should remember it and pop up a big nasty warning if it 
changes.  Recovery of private keys is just something we have to hope 
does not happen.  Replacing the key on python.org is only a problem for 
users who are using PackMan for the first time post-replace.  Also, a 
replaced key would probably not match a more secure scapegoat.com's 
key.  Although, if they can hack python.org and replace the key then 
they could add arbitrary databases.

> 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.

Yeah, we have to trust scapegoats.  On a lighter note, I think that 
some of our computers would work perfectly well as a toaster, if only 
there was a slot for bread.

> 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).

We are using Python.. this would almost have to be a kernel level 
exploit, I've never seen nor heard of any python socket over or 
underruns.  If there happen to be any at some point, I seriously doubt 
that there's anything we could've done in anticipation (other than 
audit the code).

> 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).

This is Jack's suggestion.  I guess we should support both, and use 
whatever makes sense for the capabilities of the system.  If SSL is not 
available, it will ask the user to use a SSL capable web browser and 
paste the appropriate hash into an input box in the PackMan UI.  Or of 
course, just ignore the potential security risk, because they may not 
be allowed to use SSL or may not have any SSL capable software at their 
disposal.

> 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".

We do have lots of options (pycrypto, Microsoft APIs, OpenSSL,  OS X 
APIs, potentially there will be command line utilities available) 
however there is always the chance that zero of the options are 
available on some unlucky person's computer.  We just have to keep that 
in mind, I guess.

-bob