[Python-Dev] PYTHONHTTPSVERIFY env var

[Nick Coghlan]

On 10 May 2015 at 13:04, Robert Collins <robertc at robertcollins.net> 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.

Right, which is why -E is an important existing hardening technique
for protecting privileged services against local attackers. Isolated
mode in Python 3.4+ is easier to use, but you can get a functional
equivalent in Python 2 using:

* running from a directory under /usr (Program Files on Windows)
rather than your home directory (to protect against sys.path[0] based
attacks)
* running with -E (to protect against PYTHON* environment variable attacks)
* running with -S (to protect against site.py and sitecustomize.py
based attacks)
* running with -s (to protect against hostile packages in the user
site directory)

That's how I came to the conclusion that adding a new environment
variable to turn off a network security hardening feature isn't a good
idea:

* it significantly increases the attack surface area if you're *not*
using -E when running a privileged service
* it doesn't work at all if you *are* using -E when running a privileged service

That was OK when we were dealing with the hash randomisation problem,
mostly because the consequence of that vulnerability was "denial of
service", and the question of whether or not hash randomisation caused
problems came up on an application-by-application basis, rather than
being related to the way an entire network environment was managed.
The question becomes very different when the failure mode we're
talking about is transparent interception of nominally confidential
communication.

Instead, we want a configuration file stored in a protected directory,
such that for an attacker to modify it they *already* need to have
achieved a local privilege escalation, in which case, they can just
attack the system certificate store directly, rather than messing
about downgrading Python's default HTTPS verification settings.

In my case, I don't actually need the *feature itself* in upstream
CPython, but I *would* like to have upstream CPython's blessing of the
design as a recommendation to redistributors that need a capability
like this to meet the needs of their end users. I've been talking
about "someone" putting together a PEP to that effect, so given this
discussion, I'll go ahead and do that myself, with Robert Kuska listed
as co-author (since he came up with the general design I'm advocating
for).

Cheers,
Nick.

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