Christian Heimes added the comment:
I have no plans to work on the issue any more. OpenSSL 1.1.1 has fixed the RNG
issue with a new DRBG implementation. Eventually all platforms will move to
1.1.1 because it also provides TLS 1.3.
In the mean time, application can work around the limitation
STINNER Victor added the comment:
The issue is closed. If you want to change anything, please open a new issue.
IMHO this issue is too long, it's better to start a fresh issue with up to date
info, just mention this old issue: bpo-18747.
--
___
Gabriel Corona added the comment:
Now that the default PRNG of the 'random' package is automatically reseeded at
fork, wouldn't it make sense to reseed the OpenSSL seed as well?
(At the same time the OpenSSL wiki states [1] that "The situation has changed
greatly, starting with OpenSSL
Changes by Georg Brandl ge...@python.org:
--
versions: -Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18747
___
___
Python-bugs-list
Roundup Robot added the comment:
New changeset bdf73458df5f by Christian Heimes in branch '3.2':
Issue #18747: document issue with OpenSSL's CPRNG state and fork
https://hg.python.org/cpython/rev/bdf73458df5f
--
___
Python tracker
Changes by Georg Brandl ge...@python.org:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18747
___
Changes by Berker Peksag berker.pek...@gmail.com:
--
stage: commit review - resolved
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18747
___
___
Mark Lawrence added the comment:
Is this really an enhancement request or should it be a security issue? Which
versions if any actually need work doing on them?
--
nosy: +BreamoreBoy
___
Python tracker rep...@bugs.python.org
Jeffrey Walton added the comment:
It probably is an OpenSSL bug but the declaration doesn't help us.
It's not the first time Python has to work around OpenSSL, e.g. #18709.
Sorry to dig up an old issue. But here's some reading on it if interested.
Ben Laurire pushed a patch to mix in PID and
Roundup Robot added the comment:
New changeset 4e6aa98bb11c by Christian Heimes in branch '3.3':
Issue #19227 / Issue #18747: Remove pthread_atfork() handler to remove OpenSSL
re-seeding
http://hg.python.org/cpython/rev/4e6aa98bb11c
--
___
Python
Roundup Robot added the comment:
New changeset 5942eea8cf41 by Christian Heimes in branch '3.3':
Issue #19227 / Issue #18747: Remove pthread_atfork() handler to remove OpenSSL
re-seeding
http://hg.python.org/cpython/rev/5942eea8cf41
New changeset cd4007fb9c7e by Christian Heimes in branch
Roundup Robot added the comment:
New changeset ad779da9e351 by Christian Heimes in branch '2.7':
Issue #19227 / Issue #18747: Remove pthread_atfork() handler to remove OpenSSL
re-seeding
http://hg.python.org/cpython/rev/ad779da9e351
--
___
Python
Georg Brandl added the comment:
#19227 must be solved before anything is backported to the security branches.
--
dependencies: +test_multiprocessing_xxx hangs under Gentoo buildbots
___
Python tracker rep...@bugs.python.org
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18747
___
Christian Heimes added the comment:
It's considered fixed but we have seen issues. The issues are tracked in
#19227. AFAIK the fixed hasn't landed in 3.2 yet. I'm removing 2,7, 3.3 and 3.4
from the versions list.
--
versions: -Python 2.7, Python 3.3, Python 3.4
Charles-François Natali added the comment:
Well, I don't mean to be a pain, but I still think this patch
shouldn't have been applied: it makes fork() not async-safe, which
can trigger hard to debug, random bugs (#19227 might or might not be
a direct consequence).
at the very least, I still it
Larry Hastings added the comment:
I can't follow all this. Is this considered fixed in 3.4 or not?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18747
___
Barry A. Warsaw added the comment:
After further contemplation and without objection from __ap__ and Crys on IRC,
I am de-targeting this for 2.6. I won't apply it for 2.6.9.
--
versions: -Python 2.6
___
Python tracker rep...@bugs.python.org
Barry A. Warsaw added the comment:
blocker for 2.6.9
--
nosy: +larry
priority: normal - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18747
___
Roundup Robot added the comment:
New changeset 8b962e831ff0 by Christian Heimes in branch '3.3':
Issue #18747: Fix spelling errors in my commit message and comments,
http://hg.python.org/cpython/rev/8b962e831ff0
New changeset 7b1da249ab6d by Christian Heimes in branch 'default':
Issue #18747:
STINNER Victor added the comment:
Oh i forgot that i wrote a patch for openssl:
https://bitbucket.org/haypo/hasard/src/tip/patches/openssl_rand_fork.patch
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18747
Roundup Robot added the comment:
New changeset 39c9dbed3aa1 by Christian Heimes in branch '3.3':
Issue #18747: Use a parent atfork handler instead of a child atfork handler.
http://hg.python.org/cpython/rev/39c9dbed3aa1
New changeset 25e05147d662 by Christian Heimes in branch 'default':
Issue
Vajrasky Kok added the comment:
Some typos on last commit
current time (miliseconds or seconds) and an uninitialized arry.
should be
current time (miliseconds or seconds) and an uninitialized array.
instead of a child handler because fork() is suppose to be async-signal
should be
Christian Heimes added the comment:
Thanks, that's embarrassing. :( I'm going to install a spell checker ...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18747
___
STINNER Victor added the comment:
PySSL_RAND_atfork_parent() still uses getpid(). This number is not
very random in the *parent* process :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18747
Charles-François Natali added the comment:
STINNER Victor added the comment:
PySSL_RAND_atfork_parent() still uses getpid(). This number is not
very random in the *parent* process :-)
:-)
IMO this patch has been rushed in and should be reverted for now.
It's still not async-signal safe,
STINNER Victor added the comment:
IMO this patch has been rushed in and should be reverted for now.
Agreed.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18747
___
Christian Heimes added the comment:
Am 22.08.2013 15:20, schrieb STINNER Victor:
STINNER Victor added the comment:
PySSL_RAND_atfork_parent() still uses getpid(). This number is not
very random in the *parent* process :-)
That's fine and doesn't diminish the properties of the PRNG. In
Christian Heimes added the comment:
Yet another good blog post about the issue:
OpenSSL PRNG Is Not (Really) Fork-safe
http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
IMO this patch has been rushed in and should be reverted for now.
It's still not async-signal safe, had typos, plus this problem noted
by Victor.
That's not really a problem. You merely have to *perturb* the random
state in the parent, so that the next child
Charles-François Natali added the comment:
PySSL_RAND_atfork_parent() still uses getpid(). This number is not
very random in the *parent* process :-)
That's fine and doesn't diminish the properties of the PRNG. In fact the
patch could use a hard coded value to perturb the PRNG. It's only
Barry A. Warsaw added the comment:
On Aug 21, 2013, at 11:49 AM, Christian Heimes wrote:
I have taken care of Antoine's and Victor's reviews. The fix has landed in
Python 2.7, 3.3 and 3.4. What about 2.6, 3.1 and 3.2? After all it's a
security fix (although I don't consider its severity as
Roundup Robot added the comment:
New changeset 8e1194c39bed by Christian Heimes in branch '3.3':
Issue #18747: Re-seed OpenSSL's pseudo-random number generator after fork.
http://hg.python.org/cpython/rev/8e1194c39bed
New changeset 49e23a3adf26 by Christian Heimes in branch 'default':
Issue
Christian Heimes added the comment:
I have taken care of Antoine's and Victor's reviews. The fix has landed in
Python 2.7, 3.3 and 3.4. What about 2.6, 3.1 and 3.2? After all it's a security
fix (although I don't consider its severity as high).
--
nosy: +barry, benjamin.peterson,
STINNER Victor added the comment:
3.52 +#if 0
3.53 +fprintf(stderr, PySSL_RAND_atfork_child() seeds %i
bytes in pid %i\n,
3.54 +(int)sizeof(seed), seed.pid);
3.55 +#endif
Don't you want to remove this debug code?
1.8 +def test_random_fork(self):
1.9 +
Charles-François Natali added the comment:
Christian Heimes added the comment:
I have taken care of Antoine's and Victor's reviews. The fix has landed in
Python 2.7, 3.3 and 3.4. What about 2.6, 3.1 and 3.2? After all it's a
security fix (although I don't consider its severity as high).
Christian Heimes added the comment:
Am 21.08.2013 14:08, schrieb Charles-François Natali:
And basically, because PySSL_RAND_atfork_child() is not async-signal
safe, the interpreter is now subject to random deadlocks/crash in
multi-threaded processes. I personally don't consider this a
Charles-François Natali added the comment:
Which part of the function is not async-signal safe? It doesn't interact
with any file descriptors nor does it use any syscalls except for
getpid() and time().
gettimeofday() and RAND_add()
The functions which are guaranteed to be async-signal safe
Christian Heimes added the comment:
Do you have a proposal for a better way to fix the issue? I don't think that we
can hope for a fix from OpenSSL.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18747
Antoine Pitrou added the comment:
Do you have a proposal for a better way to fix the issue? I don't
think that we can hope for a fix from OpenSSL.
Instead of reseeding in the child, you can perturb the state in the parent
after fork. As far as I understand, only the child callback in
Charles-François Natali added the comment:
2013/8/21 Antoine Pitrou rep...@bugs.python.org:
Instead of reseeding in the child, you can perturb the state in the parent
after fork.
As far as I understand, only the child callback in pthread_atfork() needs
to be async-signal-safe:
That's not
Richard Oudkerk added the comment:
On 21/08/2013 3:46pm, Charles-François Natali wrote:
Another, probably cleaner way would be to finally add the atfork()
module (issue #16500), and register this reseed hook (which could then
be implemented in ssl.py).
Wouldn't that still suffer from the
Antoine Pitrou added the comment:
[snip insightful explanation]
So it's not really safe either, although the window is narrower.
Gosh. Well, the narrower window would be fine with me :-)
--
___
Python tracker rep...@bugs.python.org
Christian Heimes added the comment:
Oh heck, signal, threads and fork really don't mix. :(
Under which condition can a non-async safe function cause trouble? Is it just
fork() inside a signal handler or can an incoming signal during fork() also
cause havoc?
The OpenSSL PRNG is only buggy when
Charles-François Natali added the comment:
Another, probably cleaner way would be to finally add the atfork()
module (issue #16500), and register this reseed hook (which could then
be implemented in ssl.py).
Wouldn't that still suffer from the double-fork() issue?
Not for the officially
Christian Heimes added the comment:
Thanks Victor, it sounds like a good suggestion. I have modified my patch to
use _PyTime_gettimeofday(). Python 2.7 doesn't have _PyTime_gettimeofday() so
I'm going to use time(NULL).
--
Added file:
Changes by Christian Heimes li...@cheimes.de:
Removed file: http://bugs.python.org/file31389/openssl_prng_atfork5.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18747
___
Changes by Christian Heimes li...@cheimes.de:
Added file: http://bugs.python.org/file31390/openssl_prng_atfork5.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18747
___
STINNER Victor added the comment:
openssl_prng_atfork5.patch:
- you should use RAND_pseudo_bytes() instead of RAND_bytes() in the unit test,
to not skip the test depending on the entropy
- the change in Misc/NEWS is strange
- please remove dead code (#if 0)
- PySSL_RAND_atfork_child() comment
Christian Heimes added the comment:
The lastest patch mixes seconds into the time field of seed.
Python 3.3+ support only NT and POSIX threads. 2.7 and 3.2 have GNU pth and
other threading API but I neither have a system to test other threading libs
nor the motivation to port my patch to an
STINNER Victor added the comment:
PySSL_RAND_atfork_child(void) can be simplified by calling
_PyTime_gettimeofday(). This function uses the most(*) accurate
function and already implements fallbacks on error.
(*) _PyTime_gettimeofday() does not use clock_gettime() because of a
linker issue:
Christian Heimes added the comment:
Here is a patch that is based on Apache's mod_ssl code. mod_ssl perturbs the
PRNG state more often but I think that's overkill for Python.
The new patch only affects the PRNG state of the child process. In my opinion
it is the better way to solve this
Antoine Pitrou added the comment:
The patch looks fine on the principle, but you should add a test.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18747
___
Charles-François Natali added the comment:
2013/8/17 Christian Heimes rep...@bugs.python.org:
Here is a patch that is based on Apache's mod_ssl code. mod_ssl perturbs the
PRNG state more often but I think that's overkill for Python.
The new patch only affects the PRNG state of the child
STINNER Victor added the comment:
openssl_prng_atfork3.patch: Why not using seconds (only micro or
nanoseconds) in the seed? Add a few more bits should not reduce the
entropy. OpenSSL does hash all these bytes anyway.
+#if 1
+fprintf(stderr, PySSL_RAND_atfork_child() seeds %i bytes in %i\n,
New submission from Christian Heimes:
A couple of reports and check-in messages like
Postgres / pgcrypto CVE-2013-1900
http://bugs.ruby-lang.org/issues/4579
http://www.exim.org/lurker/message/20130402.171710.92f14a60.fi.html
suggests that OpenSSL's PRNG should be reset or re-seeded after
Antoine Pitrou added the comment:
Are there any uses of the OpenSSL PRNG from Python?
Is the PRNG used for SSL session keys, or another mechanism?
--
nosy: +pitrou, sbt
type: security - enhancement
versions: -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +neologix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18747
___
___
Python-bugs-list mailing
Christian Heimes added the comment:
The ssl module exposes OpenSSL's PRNG and advertises the API as secure CPRNG:
http://docs.python.org/3/library/ssl.html#random-generation
OpenSSL uses its own PRNG to create (amongst others) session keys for SSL
connections.
--
Antoine Pitrou added the comment:
The ssl module exposes OpenSSL's PRNG and advertises the API as secure
CPRNG: http://docs.python.org/3/library/ssl.html#random-generation
AFAICT, Python's PRNG isn't reset after fork, so I don't think OpenSSL's
should be reset.
OTOH, multiprocessing does
Christian Heimes added the comment:
Python doesn't have a builtin PRNG. We use the OS's CPRNG such as /dev/urandom
or CryptGenRandom(). Both use a system wide state and are not affected by
process state. OpenSSL's PRNG is different because it uses an internal state.
AFAIK it only polls the
Antoine Pitrou added the comment:
Python doesn't have a builtin PRNG.
Of course it does. It's in the random module, and you can seed() it:
random.seed(5)
random.random()
0.6229016948897019
random.random()
0.7417869892607294
random.seed(5)
random.random()
0.6229016948897019
See e.g.
Christian Heimes added the comment:
Am 15.08.2013 15:14, schrieb Antoine Pitrou:
Python doesn't have a builtin PRNG.
Of course it does. It's in the random module, and you can seed() it:
Now you are nit-picking. Although random is a PRNG, it is not a CPRNG.
I'm clearly talking about the
Antoine Pitrou added the comment:
When the OpenSSL's CPRNG is already initialized before 3) than all child
processes created by 3) will have almost the same PRNG state. According
to http://bugs.ruby-lang.org/issues/4579 the PRNG will return the same
value when PID numbers are recycled.
STINNER Victor added the comment:
This issue was already discussed in the atfork issue:
http://bugs.python.org/issue16500#msg179838
See also:
http://www.openwall.com/lists/oss-security/2013/04/12/3
I believe it is wrong to fix this in PostgreSQL. Rather, this is a
bug in the OpenSSL fork
STINNER Victor added the comment:
Another link:
http://article.gmane.org/gmane.comp.encryption.openssl.user/48480/match=does+child+process+still+need+reseeded+after+fork
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18747
66 matches
Mail list logo
