[Python-Dev] PYTHONHTTPSVERIFY env var (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Sun May 10 06:07:24 CEST 2015
- Previous message (by thread): [Python-Dev] PYTHONHTTPSVERIFY env var
- Next message (by thread): [Python-Dev] PYTHONHTTPSVERIFY env var
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [Python-Dev] PYTHONHTTPSVERIFY env var
- Next message (by thread): [Python-Dev] PYTHONHTTPSVERIFY env var
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]