Re: [Python-Dev] PEP 493: HTTPS verification migration tools for Python 2.7

[Nick Coghlan]

On 25 February 2016 at 07:14, M.-A. Lemburg  wrote:
> On 24.02.2016 21:39, Cory Benfield wrote:
>>
>>> On 24 Feb 2016, at 12:19, M.-A. Lemburg  wrote:
>>>
>>> On 24.02.2016 12:28, Cory Benfield wrote:
 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.
>>
>> 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.
>
> Fair enough :-)

I tweaked the explanation of that security caveat:
https://hg.python.org/peps/rev/a24451715d84 (and then tweaked the
tweak to replace "the main" with "a key").

I didn't mention the prospect of reading sensitive data from the
environment, as the specific problem we're introducing is with write
access, and I believe certainly flavours of vulnerability can give the
ability to do blind writes to the environment without necessarily
gaining the ability to dump arbitrary details about that environment.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 493: HTTPS verification migration tools for Python 2.7

[M.-A. Lemburg]

On 24.02.2016 21:39, Cory Benfield wrote:
> 
>> On 24 Feb 2016, at 12:19, M.-A. Lemburg  wrote:
>>
>> On 24.02.2016 12:28, Cory Benfield wrote:
>>>
 On 24 Feb 2016, at 10:32, Nick Coghlan  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.

Fair enough :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Feb 24 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/

2016-02-19: Released eGenix PyRun 2.1.2 ...   http://egenix.com/go88

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 493: HTTPS verification migration tools for Python 2.7

[Cory Benfield]

> On 24 Feb 2016, at 12:19, M.-A. Lemburg  wrote:
> 
> On 24.02.2016 12:28, Cory Benfield wrote:
>> 
>>> On 24 Feb 2016, at 10:32, Nick Coghlan  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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 493: HTTPS verification migration tools for Python 2.7

[M.-A. Lemburg]

On 24.02.2016 12:28, Cory Benfield wrote:
> 
>> On 24 Feb 2016, at 10:32, Nick Coghlan  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.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Feb 24 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/

2016-02-19: Released eGenix PyRun 2.1.2 ...   http://egenix.com/go88

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 493: HTTPS verification migration tools for Python 2.7

[Nick Coghlan]

On 24 February 2016 at 21:28, Cory Benfield  wrote:

>
> > On 24 Feb 2016, at 10:32, Nick Coghlan  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.


... for SSL contexts that aren't explicitly enabling it.


> To my knowledge this is the only environment variable that could be set
> that would do that.
>
> It’s just worth noting here that this potentially opens a little crack in
> Python’s armour.
>

Only in Python 2.7's, and there we have a much bigger problem with folks
not upgrading past 2.7.8, and with a number of redistributors considering
the change too disruptive to backport as a security fix.

I do think you're right though, so I'll tweak the wording of that section
accordingly.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 493: HTTPS verification migration tools for Python 2.7

[Cory Benfield]

> On 24 Feb 2016, at 10:32, Nick Coghlan  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.

It’s just worth noting here that this potentially opens a little crack in 
Python’s armour.

Cory



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 493: HTTPS verification migration tools for Python 2.7

[Nick Coghlan]

Hi folks,

Since the last discussion back in November (just after the RHEL 7.2
release), I've rewritten PEP 493 to be a standards track PEP targeting
Python 2.7.12. Barry also kindly volunteered to serve as BDFL-Delegate, so
we have a clear path to pronouncement if nobody notices any new problems or
concerns that didn't come up in previous discussions :)

The PEP now focuses on adding two new configuration mechanisms to the PEP
476 backport in Python 2.7:

* turning off default certificate verification through a Python API
* turning off default certificate verification through an environment
variable

Both of these are defined in such a way that if backported to a version
where default verification is still off by default, they can be used to
turn it *on*.

The original file based configuration proposal to change the default
behaviour of older versions is also still covered, but moved to a clearly
optional section. (The gist of that section is now "If you backport this
capability, aim to stay consistent with already existing backports of it")

Regards,
Nick.

==
PEP: 493
Title: HTTPS verification migration tools for Python 2.7
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan ,
Robert Kuska ,
Marc-André Lemburg 
BDFL-Delegate: Barry Warsaw
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 10-May-2015
Python-Version: 2.7.12
Post-History: 06-Jul-2015, 11-Nov-2015, 24-Nov-2015, 24-Feb-2016


Abstract


PEP 476 updated Python's default handling of HTTPS certificates in client
modules to align with certificate handling in web browsers, by validating
that the certificates received belonged to the server the client was
attempting
to contact. The Python 2.7 long term maintenance series was judged to be in
scope for this change, with the new behaviour introduced in the Python 2.7.9
maintenance release.

This has created a non-trivial barrier to adoption for affected Python 2.7
maintenance releases, so this PEP proposes additional Python 2.7 specific
features that allow system administrators and other users to more easily
decouple the decision to verify server certificates in HTTPS client modules
from the decision to update to newer Python 2.7 maintenance releases.


Rationale
=

PEP 476 changed Python's default behaviour to align with expectations
established by web browsers in regards to the semantics of HTTPS URLs:
starting with Python 2.7.9 and 3.4.3, HTTPS clients in the standard library
validate server certificates by default.

However, it is also the case that this change *does* cause problems for
infrastructure administrators operating private intranets that rely on
self-signed certificates, or otherwise encounter problems with the new
default
certificate verification settings.

To manage these kinds of situations, web browsers provide users with "click
through" warnings that allow the user to add the server's certificate to the
browser's certificate store. Network client tools like ``curl`` and ``wget``
offer options to switch off certificate checking entirely (by way of
``curl --insecure`` and ``wget --no-check-certificate``, respectively).

At a different layer of the technology stack, Linux security modules like
`SELinux` and `AppArmor`, while enabled by default by distribution vendors,
offer relatively straightforward mechanisms for turning them off.

At the moment, no such convenient mechanisms exist to disable Python's
default certificate checking for a whole process.

PEP 476 did attempt to address this question, by covering how to revert to
the
old settings process wide by monkeypatching the ``ssl`` module to restore
the
old behaviour. Unfortunately, the ``sitecustomize.py`` based technique
proposed
to allow system administrators to disable the feature by default in their
Standard Operating Environment definition has been determined to be
insufficient in at least some cases. The specific case that led to the
initial creation of this PEP is the one where a Linux distributor aims to
provide their users with a
`smoother migration path <
https://bugzilla.redhat.com/show_bug.cgi?id=1173041>`__
than the standard one provided by consuming upstream CPython 2.7 releases
directly, but other potential challenges have also been pointed out with
updating embedded Python runtimes and other user level installations of
Python.

Rather than allowing a plethora of mutually incompatibile migration
techniques
to bloom, this PEP proposes an additional feature to be added to Python
2.7.12
to make it easier to revert a process to the past behaviour of skipping
certificate validation in HTTPS client modules. It also provides additional
recommendations to redistributors backporting these features to versions of
Python prior to Python 2.7.9.

Alternatives


In the absence of clear upstream guidance and recommendations, commercial
redistributors will