Bug 11491 - python-pycrypto - PRNG not correctly reseeded in some situations (CVE-2013-1445)
: python-pycrypto - PRNG not correctly reseeded in some situations (CVE-2013-1445)
Status: RESOLVED FIXED
Product: Mageia
Classification: Unclassified
Component: Security
: 3
: i586 Linux
: Normal Severity: normal
: ---
Assigned To: QA Team
: Sec team
: http://lwn.net/Vulnerabilities/571138/
: MGA2TOO MGA3-64-OK MGA3-32-OK MGA2-64...
: validated_update
:
:
  Show dependency treegraph
 
Reported: 2013-10-18 09:17 CEST by Oden Eriksson
Modified: 2013-10-25 23:24 CEST (History)
4 users (show)

See Also:
Source RPM: python-pycrypto
CVE:
Status comment:


Attachments

Description Oden Eriksson 2013-10-18 09:17:10 CEST
http://lists.dlitz.net/pipermail/pycrypto/2013q4/000702.html

"In PyCrypto before v2.6.1, the Crypto.Random pseudo-random number
generator (PRNG) exhibits a race condition that may cause it to generate
the same 'random' output in multiple processes that are forked from each
other.  Depending on the application, this could reveal sensitive
information or cryptographic keys to remote attackers.

An application may be affected if, within 100 milliseconds, it performs
the following steps (which may be summarized as "read-fork-read-read"):

1. Read from the Crypto.Random PRNG, causing an internal reseed;
2. Fork the process and invoke Crypto.Random.atfork() in the child;
3. Read from the Crypto.Random PRNG again, in at least two different
     processes (parent and child, or multiple children).

Only applications that invoke Crypto.Random.atfork() and perform the
above steps are affected by this issue.  Other applications are
unaffected.

Note: Some PyCrypto functions, such as key generation and PKCS#1-related
functions, implicitly read from the Crypto.Random PRNG.

== Technical details ==

Crypto.Random uses Fortuna[1] to generate random numbers.  The flow of
entropy looks something like this:

      /dev/urandom  -\
                      +-> "accumulator" --> "generator" --> output
      other sources -/   (entropy pools)     (AES-CTR)

- The "accumulator" maintains several pools that collect entropy from
    the environment.

- The "generator" is a deterministic PRNG that is reseeded by the
    accumulator.  Reseeding normally occurs during each request for random
    numbers, but never more than once every 100 ms (the "minimum reseed
    interval").

When a process is forked, the parent's state is duplicated in the child.
In order to continue using the PRNG, the child process must invoke
Crypto.Random.atfork(), which collects new entropy from /dev/urandom and
adds it to the accumulator.  When new PRNG output is subsequently
requested, some of the new entropy in the accumulator is used to reseed
the generator, causing the output of the child to diverge from its
parent.

However, in previous versions of PyCrypto, Crypto.Random.atfork() did
not explicitly reset the child's rate-limiter, so if the child requested
PRNG output before the minimum reseed interval of 100 ms had elapsed, it
would generate its output using state inherited from its parent.

This created a race condition between the parent process and its forked
children that could cause them to produce identical PRNG output for the
duration of the 100 ms minimum reseed interval.

== Demonstration ==

Here is some sample code that illustrates the problem:

      from binascii import hexlify
      import multiprocessing, pprint, time
      import Crypto.Random

      def task_main(arg):
          a = Crypto.Random.get_random_bytes(8)
          time.sleep(0.1)
          b = Crypto.Random.get_random_bytes(8)
          rdy, ack = arg
          rdy.set()
          ack.wait()
          return "%s,%s" % (hexlify(a).decode(),
                            hexlify(b).decode())

      n_procs = 4
      manager = multiprocessing.Manager()
      rdys = [manager.Event() for i in range(n_procs)]
      acks = [manager.Event() for i in range(n_procs)]
      Crypto.Random.get_random_bytes(1)
      pool = multiprocessing.Pool(processes=n_procs,
                                  initializer=Crypto.Random.atfork)
      res_async = pool.map_async(task_main, zip(rdys, acks))
      pool.close()
      [rdy.wait() for rdy in rdys]
      [ack.set() for ack in acks]
      res = res_async.get()
      pprint.pprint(sorted(res))
      pool.join()

The output should be random, but it looked like this:

      ['c607803ae01aa8c0,2e4de6457a304b34',
       'c607803ae01aa8c0,af80d08942b4c987',
       'c607803ae01aa8c0,b0e4c0853de927c4',
       'c607803ae01aa8c0,f0362585b3fceba4']

== Solution ==

The solution is to upgrade to PyCrypto v2.6.1 or later, which properly
resets the rate-limiter when Crypto.Random.atfork() is invoked in the
child.

== Files ==

PyCrypto v2.6.1 may be downloaded from the PyCrypto website[2], from 
PyPI, or using your operating system's package manager or ports tree.  

The official tarball has the following SHA256 sums:

f2ce1e989b272cfcb677616763e0a2e7ec659effa67a88aa92b3a65528f60a3c *pycrypto-2.6.1.tar.gz
c2ab0516cc55321e6543ae75e2aa6f6e56e97432870f32a7799f3b89f467dc1b *pycrypto-2.6.1.tar.gz.asc

The git repository is here: https://github.com/dlitz/pycrypto/
The v2.6.1 tag id is: ebb470d3f0982702e3e9b7fb9ebdaeed95903aaf
The v2.6.1 commit id is: 7fd528d03b5eae58eef6fd219af5d9ac9c83fa50

For informational purposes, patches against pycrypto v2.6 and v2.1.0 are 
attached.  Distributors patching older versions of the library, please 
remember to run the test suite before releasing a modified package:

    # From the source tree
    python setup.py build test

    # After installation
    python -m Crypto.SelfTest.__init__

== Thanks ==

Thanks to Yves-Alexis Perez and Sebastian Ramacher for helping to 
coordinate the release of this fix.

== References ==

[1] N. Ferguson and B. Schneier, _Practical Cryptography_,
      Indianapolis: Wiley, 2003, pp. 155-184.

[2] https://www.dlitz.net/software/pycrypto/ or http://www.pycrypto.org/

-- 
Dwayne C. Litzenberger <dlitz at dlitz.net>
    OpenPGP: 19E1 1FE8 B3CF F273 ED17  4A24 928C EC13 39C2 5CF7"


Reproducible: 

Steps to Reproduce:
Comment 1 Oden Eriksson 2013-10-18 09:18:33 CEST
python-pycrypto-2.3-2.2.mga2 and python-pycrypto-2.6-2.1.mga3 has been submitted where this is fixed.

python-pycrypto-2.6.1 has been committed to cauldron, needs someone to submit it.
Comment 2 David Walser 2013-10-18 15:32:41 CEST
Thanks Oden.  Thomas submitted it for Cauldron.

Advisory:
========================

Updated python-pycrypto package fixes security vulnerability:

In PyCrypto before v2.6.1, the Crypto.Random pseudo-random number
generator (PRNG) exhibits a race condition that may cause it to generate
the same 'random' output in multiple processes that are forked from each
other.  Depending on the application, this could reveal sensitive
information or cryptographic keys to remote attackers (CVE-2013-1445).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1445
http://lists.dlitz.net/pipermail/pycrypto/2013q4/000702.html
========================

Updated packages in core/updates_testing:
========================
python-pycrypto-2.3-2.2.mga2
python-pycrypto-2.6-2.1.mga3

from SRPMS:
python-pycrypto-2.3-2.2.mga2.src.rpm
python-pycrypto-2.6-2.1.mga3.src.rpm
Comment 3 roelof Wobben 2013-10-19 17:01:31 CEST
I can confirm the bug but cannot test the update because I work on M3 and it cannot found the new package.

Roelof
Comment 4 roelof Wobben 2013-10-19 17:21:51 CEST
Found it. 

Before it shows 4 times the same key.
After installing the new package , I see this output :

[u'0a7273a36885218f,9b0fa767674f6ffe',
 u'3ea61dd74843e3eb,87e2fa2a2e8b8ce4',
 u'8a6a332f7c575185,f66ee10f3f69ac4b',
 u'a4a551023b1a79bf,424a2fd40a84a3fd']


So for me M3 x86_64 Oke.

Roelof
Comment 5 roelof Wobben 2013-10-21 16:22:02 CEST
Tested on M3 32 bit on Virtualbox and it's oke.

Roelof
Comment 6 David Walser 2013-10-21 19:22:43 CEST
Debian has issued an advisory for this on October 18:
http://www.debian.org/security/2013/dsa-2781
Comment 7 Zoltan Balaton 2013-10-23 22:17:59 CEST
Tested on mga2 x86_64

installing python-pycrypto-2.3-2.1.mga2.x86_64.rpm from /var/cache/urpmi/rpms  
$ python testpycrypt.py 
[u'0451a503cf21b8a6,0dbb34d8ba5acc47',
 u'0451a503cf21b8a6,25d75cf3e63022ef',
 u'0451a503cf21b8a6,3d10502e4eff4202',
 u'0451a503cf21b8a6,a21c2ceba5e904da']

installing python-pycrypto-2.3-2.2.mga2.x86_64.rpm from /var/cache/urpmi/rpms  
$ python testpycrypt.py 
[u'309918ec4b4bc9d4,c16d5acca6d14fb4',
 u'8f0031c20eaf0e53,62e24d7442e25bf0',
 u'c665173390bd2057,91e31804caddcac1',
 u'd73d79849b9b3dc1,a1da431af14673d1']
Comment 8 Zoltan Balaton 2013-10-23 22:24:32 CEST
Tested on mga2 i586

with python-pycrypto-2.3-2.1.mga2
$ python testpycrypt.py 
[u'12c2c82f78ebc991,32c121228f5f2719',
 u'61ed9476d0548c5d,b67b9204af623dc8',
 u'8eb9fdf4bb535966,e8261a70d322bbda',
 u'e1feb326ced6fc8c,13554f85b6ec5556']

with python-pycrypto-2.3-2.2.mga2
$ python testpycrypt.py 
[u'133d7b007cf6d18f,6971a564092c1c19',
 u'6623426de4b263c9,5b932662229966d3',
 u'ede1e88ac06fe5c8,6b2d745a5073ac57',
 u'f7603c3f06ce425a,3f092973fd159610']

(seems to be OK even without the updated package but also after the update)

Could someone please do the validation procedure based on the testing results above?
Comment 9 claire robinson 2013-10-24 08:10:28 CEST
Advisory uploaded. Validating.

Could sysadmin please push from 2&3 core/updates_testing to updates

Thanks!
Comment 10 Thomas Backlund 2013-10-25 23:24:29 CEST
Update pushed:
http://advisories.mageia.org/MGASA-2013-0319.html

Note You need to log in before you can comment on or make changes to this bug.