On 24 Feb 2016, at 12:19, M.-A. Lemburg <mal@egenix.com> wrote:
On 24.02.2016 12:28, Cory Benfield wrote:
On 24 Feb 2016, at 10:32, Nick Coghlan <ncoghlan@gmail.com> wrote:
Security Considerations -----------------------
Relative to the behaviour in Python 3.4.3+ and Python 2.7.9->2.7.11, this approach does introduce a new downgrade attack against the default security settings that potentially allows a sufficiently determined attacker to revert Python to the default behaviour used in CPython 2.7.8 and earlier releases. However, such an attack requires the ability to modify the execution environment of a Python process prior to the import of the ``ssl`` module, and any attacker with such access would already be able to modify the behaviour of the underlying OpenSSL implementation.
I’m not entirely sure this is accurate. Specifically, an attacker that is able to set environment variables but nothing else (no filesystem access) would be able to disable hostname validation. To my knowledge this is the only environment variable that could be set that would do that.
An attacker with access to the OS environment of a process would be able to do lots of things. I think disabling certificate checks is not one of the highest ranked attack vectors you'd use, given such capabilities :-)
Think of LD_PRELOAD attacks, LD_LIBRARY_PATH manipulations, shell PATH manipulations (think spawned processes), compiler flag manipulations (think "pip install sourcepkg"), OpenSSL reconfiguration, etc.
Probably much easier than an active attack would be to simply extract sensitive information from the environ and use this for more direct attacks, e.g. accessing databases, payment services, etc.
To be clear, I’m not suggesting that this represents a reason not to do any of this, just that we should not suggest that there is no risk here: there is, and it is a new attack vector. Cory