[Python-Dev] PYTHONHTTPSVERIFY env var

[Nick Coghlan]

On 11 May 2015 at 18:04, M.-A. Lemburg <mal at egenix.com> wrote:
> On 10.05.2015 05:04, Robert Collins wrote:
>> On 10 May 2015 at 11:44, Chris Angelico <rosuav at gmail.com> wrote:
>>> On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>>>> By providing a way to intentionally switch off the new default,
>>>> we do make people aware of the risks and that's good enough,
>>>> while still maintaining the contract people rightly expect of
>>>> patch level releases of Python.
>>>
>>> Just as long as it's the sysadmin, and NOT some random attacker over
>>> the internet, who has the power to downgrade security. Environment
>>> variables can be attacked in various ways.
>>
>> They can, and the bash fun was very good evidence of that.
>>
>> OTOH if someones environment is at risk, PATH and PYTHONPATH are
>> already very effective attack vectors.
>
> If an attacker has access to the process environment, you're doomed
> anyway, so that's not really an argument for or against using
> environment variables :-)

The core issue lies in managing the "user" vs "administrator"
permissions split. Even for self-administered systems, it's
recommended practice to run *without* administrative permissions
normally, and only elevate when you need them. One of the things
you're watching out for in such cases is that it shouldn't be possible
for an attacker to make a change to the user environment, and have
that propagate to have an effect on a process running with
administrative access. One of the recommended hardening measures
against that kind of attack vector is to *turn off* Python's
environment variable processing when launching Python processes with
administrative access.

We didn't care about that in the hash randomisation case, as the
compatibility concern there applied on a per application basis, and
caring about hash order was technically a bug in its own right. By
contrast, in the situation we're worried about for certificate
verification compatibility, the issue is environmental: certificate
management in many private intranets isn't yet to the same standard as
that on the public internet, so administrators may have a valid reason
for defaulting Python back to the old behaviour, and redistributors
may feel obliged to provide an opt-in period prior to switching the
default behaviour to opt-out. Having the new setting be ignored in
Python processes run under a hardened configuration means that an
environment variable based solution won't have the desired effect in
providing that smoother migration path to the more hardened
configuration.

I've now written a draft "recommendations to redistributors" PEP for
Robert's configuration file based design:
https://www.python.org/dev/peps/pep-0493/ (exact file names & config
setting names TBD)

I wouldn't be opposed to seeing that as an upstream Python 2.7.x
feature, but agreement amongst redistributors on using a file-based
approach is the main outcome I'm looking for.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia