Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 205777 (CVE-2008-0299) - dev-python/paramiko < 1.7.2 insecure use of RandomPool (CVE-2008-0299)
Summary: dev-python/paramiko < 1.7.2 insecure use of RandomPool (CVE-2008-0299)
Status: RESOLVED FIXED
Alias: CVE-2008-0299
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: High minor (vote)
Assignee: Gentoo Security
URL: http://www.lag.net/pipermail/paramiko...
Whiteboard: B3? [glsa]
Keywords:
: 207312 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-01-14 11:09 UTC by David Guerizec
Modified: 2008-03-03 21:43 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Guerizec 2008-01-14 11:09:12 UTC
Programs using paramiko that meet _either_ (or both) of the following 
criteria may be vulnerable to attacks on paramiko's random number 
generator:

     1. The program maintains multiple simultaneous paramiko connections 
        (Transport instances) via forking or threading; or
     
     2. The program uses certain Win32 builds of PyCrypto, where the 
        Crypt.Util.winrandom module is missing, thus preventing the 
        RandomPool instance from being initialized with sufficient entropy.

This message deals with primarily with the first criterion.

paramiko generates random numbers using a single instance of PyCrypto's 
RandomPool class.  Unfortunately, neither paramiko nor PyCrypto ensure 
that:

     1. after fork(), that the output of randpool.get_bytes() in the parent
        cannot be used to predict the output of randpool.get_bytes() in the 
        child, or vice versa; or
     
     2. that the state of the RandomPool instance is not corrupted by 
        multiple threads accessing it at the same time.

Consider the following Python program, which generates three separate RSA 
keys in three different child processes, and outputs the keys' 
fingerprints:

# -------[ snip here ]------------------------
from paramiko import RSAKey
import os
import time

# time.time() and time.clock() are predictable from a cryptographic standpoint,
# but make them REALLY predictable for the purposes of this demonstration.
class PredictableTime(object):
     def __init__(self):
         self.n = 0
     def __call__(self):
         self.n += 1
         return self.n

time.time = PredictableTime()
time.clock = PredictableTime()

def fork_and_generate_key():
     pid = os.fork()
     if pid != 0:
         # parent process
         os.waitpid(pid, 0)
         return
     else:
         # Child process
         k = RSAKey.generate(512)
         print "[PID %d] %s" % (os.getpid(), k.get_fingerprint().encode('hex'))
         os._exit(0)

fork_and_generate_key()
fork_and_generate_key()
fork_and_generate_key()
# -------[ snip here ]------------------------

Theoretically, each key generated using this program should be independent, 
regardless of whether the outputs of time.clock() and time.time() are 
predictable.  In reality, the program's output looks something like this:

     [PID 18872] bff46933095489d81af86493e4e9ba2f
     [PID 18873] bff46933095489d81af86493e4e9ba2f
     [PID 18874] bff46933095489d81af86493e4e9ba2f

This means that if you're using (for example) Python's 
SocketServer.ForkingTCPServer class to build an SSH server using paramiko, 
then supposedly "random" data from one session can be used to predict 
"random" data in another session.

We could try to make a thread-safe wrapper around RandomPool, and we could 
provide some API to let users randomize the pool after a fork(), but that's 
error-prone.  Also, because of a bug in PyCrypto 2.0.1 (where winrandom is 
not built), this would not be sufficient to fix the problem on Win32.

A better thing to do would be to let the operating system generate our 
random numbers for us, since it is in a far better position than we are to 
guarantee that RNG state is not leaked or reused.

The attached patch creates a new OSRandomPool class that provides a 
RandomPool-like interface, but gets its random numbers directly from the 
operating system.  It also works around the recently-published Windows 
CryptGenRandom vulnerabilities (see http://eprint.iacr.org/2007/419).

Reproducible: Always




please see related thread on paramiko's mailing list archives:

http://www.lag.net/pipermail/paramiko/2008-January/000599.html
Comment 1 Robert Buchholz (RETIRED) gentoo-dev 2008-01-15 15:24:07 UTC
Seems like lag.net is currently down.
Comment 2 Robert Buchholz (RETIRED) gentoo-dev 2008-01-15 16:03:11 UTC
As long as the site is down, the patch can also be found here:
  http://people.debian.org/~nion/nmu-diff/paramiko-1.6.4-1_1.6.4-1.1.patch
Comment 3 David Guerizec 2008-01-17 16:14:20 UTC
A CVE seems to have been created:
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-0299
Comment 4 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-01-17 16:33:09 UTC
(In reply to comment #2)
> As long as the site is down, the patch can also be found here:
>   http://people.debian.org/~nion/nmu-diff/paramiko-1.6.4-1_1.6.4-1.1.patch
> 

python herd, please provide an updated ebuild.
Comment 5 David Guerizec 2008-01-24 20:06:26 UTC
Please note that a new paramiko release is available, fixing this issue.

see http://www.lag.net/pipermail/paramiko/2008-January/000604.html
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2008-01-24 20:38:34 UTC
*** Bug 207312 has been marked as a duplicate of this bug. ***
Comment 7 Ali Polatel (RETIRED) gentoo-dev 2008-01-31 15:32:41 UTC
paramiko-1.7.2 is in CVS.
Comment 8 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-01-31 16:20:20 UTC
> paramiko-1.7.2 is in CVS.

Arches, please test and mark stable. Target "amd64 ~hppa ia64 ~ppc sparc x86 ~x86-fbsd"
Comment 9 Christian Faulhammer (RETIRED) gentoo-dev 2008-01-31 18:40:27 UTC
x86 stable
Comment 10 Raúl Porcel (RETIRED) gentoo-dev 2008-01-31 19:09:58 UTC
ia64/sparc stable
Comment 11 Santiago M. Mola (RETIRED) gentoo-dev 2008-02-11 00:09:56 UTC
amd64 stable, closing.
Comment 12 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-02-11 10:57:17 UTC
please don't close security bugs...
time for GLSA decision. I vote YES.
Comment 13 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2008-02-11 18:32:14 UTC
Voting YES and filing.
Comment 14 Peter Volkov (RETIRED) gentoo-dev 2008-02-23 18:17:55 UTC
Fixed in release snapshot.
Comment 15 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-03-03 21:43:57 UTC
GLSa 200803-07