text: Docs |
  Forums |
  Lists |
  Bugs |
  Planet |
  Store |
  GMN |
  Get Gentoo!
  Not eligible to see or edit group visibility for this bug.
  View Bug Activity
  |
  Format For Printing
  |
  XML
  |
  Clone This Bug
  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).
  Reproducible: Always
  please see related thread on paramiko's mailing list archives:
  Seems like lag.net is currently down.
  As long as the site is down, the patch can also be found here:
  A CVE seems to have been created:
  (In reply to comment #2)
  > As long as the site is down, the patch can also be found here:
  >
  >
  python herd, please provide an updated ebuild.
  Please note that a new paramiko release is available, fixing this issue.
  see
  *** Bug 207312 has been marked as a duplicate of this bug. ***
  paramiko-1.7.2 is in CVS.
  > paramiko-1.7.2 is in CVS.
  Arches, please test and mark stable. Target "amd64 ~hppa ia64 ~ppc sparc x86
  ~x86-fbsd"
  x86 stable
  ia64/sparc stable
  amd64 stable, closing.
  please don't close security bugs...
  time for GLSA decision. I vote YES.
  Voting YES and filing.
  Fixed in release snapshot.
  GLSa 200803-07