fyi - openssl vulnerability - likely in our windows builds
FYI - there is a network exploitable vulnerability in OpenSSL - http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2110
Our windows builds likely need updating. At the very least make sure openssl is updated before the next time we produce binaries. Its up to the release managers if they want to make a new windows only sub-release to include the updated version of openssl.
-gps
2012/4/23 Gregory P. Smith greg@krypto.org
FYI - there is a network exploitable vulnerability in OpenSSL - http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2110
Our windows builds likely need updating. At the very least make sure openssl is updated before the next time we produce binaries. Its up to the release managers if they want to make a new windows only sub-release to include the updated version of openssl.
The OpenSSL Security Advisory says: http://www.openssl.org/news/secadv_20120419.txt """ Affected functions are of the form d2i_*_bio or d2i_*_fp, for example d2i_X509_bio or d2i_PKCS12_fp. """
I don't see any occurrence of these functions in the various versions of the _ssl module. Is Python really affected by this vulnerability?
-- Amaury Forgeot d'Arc
I don't see any occurrence of these functions in the various versions of the _ssl module. Is Python really affected by this vulnerability?
We use SSL_CTX_use_certificate_chain_file, which ultimately uses d2i_X509_AUX_fp (I think).
However, I fail to see how this constitutes are remote vulnerability: one would have to inject a bad PEM file into an application to trigger this.
http://isc.sans.edu/diary.html?storyid=13018
claims that this is *not* exploitable over TLS (and I agree); they warn that it can be exploited e.g. when Apache reads server certificates from untrusted users. Even in the local case, you need a Python application running under one account that reads certificate files belonging to a different (Unix) account to create an exploit.
So I propose that for the regular bugfix releases, we upgrade the OpenSSL version, but otherwise take no action at this point.
Regards, Martin
Le lundi 23 avril 2012 à 23:42 +0200, martin@v.loewis.de a écrit :
I don't see any occurrence of these functions in the various versions of the _ssl module. Is Python really affected by this vulnerability?
We use SSL_CTX_use_certificate_chain_file, which ultimately uses d2i_X509_AUX_fp (I think).
However, I fail to see how this constitutes are remote vulnerability: one would have to inject a bad PEM file into an application to trigger this.
http://isc.sans.edu/diary.html?storyid=13018
claims that this is *not* exploitable over TLS (and I agree); they warn that it can be exploited e.g. when Apache reads server certificates from untrusted users. Even in the local case, you need a Python application running under one account that reads certificate files belonging to a different (Unix) account to create an exploit.
So I propose that for the regular bugfix releases, we upgrade the OpenSSL version, but otherwise take no action at this point.
Agreed.
Regards
Antoine.
On Apr 23, 2012, at 5:48 PM, Antoine Pitrou wrote:
[mvl] So I propose that for the regular bugfix releases, we upgrade the OpenSSL version, but otherwise take no action at this point.
Agreed.
With two such august opinions I, at least, feel confident we are unlikely to have to scramble to remove a dangerous vulnerability.
Do we need to address this publicly? If nobody is asking any questions then remaining silent and implementing Martin's suggestion seems like the best option.
S
Steve Holden steve@holdenweb.com, Holden Web, LLC http://holdenweb.com/ Python classes (and much more) through the web http://oreillyschool.com/
On Mon, Apr 23, 2012 at 2:42 PM, martin@v.loewis.de wrote:
I don't see any occurrence of these functions in the various versions of
the _ssl module. Is Python really affected by this vulnerability?
We use SSL_CTX_use_certificate_chain_**file, which ultimately uses d2i_X509_AUX_fp (I think).
However, I fail to see how this constitutes are remote vulnerability: one would have to inject a bad PEM file into an application to trigger this.
http://isc.sans.edu/diary.**html?storyid=13018http://isc.sans.edu/diary.html?storyid=13018
claims that this is *not* exploitable over TLS (and I agree); they warn that it can be exploited e.g. when Apache reads server certificates from untrusted users. Even in the local case, you need a Python application running under one account that reads certificate files belonging to a different (Unix) account to create an exploit.
So I propose that for the regular bugfix releases, we upgrade the OpenSSL version, but otherwise take no action at this point.
give that, agreed.
participants (5)
-
Amaury Forgeot d'Arc -
Antoine Pitrou -
Gregory P. Smith -
martin＠v.loewis.de -
Steve Holden