Bug 929255 (CVE-2013-1900)

Summary: CVE-2013-1900 postgresql: Improper randomization of pgcrypto functions (requiring random seed)
Product: [Other] Security Response Reporter: Jan Lieskovsky <jlieskov>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: NEW --- QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: bdunne, hhorak, jfrey, jrafanie, kseifried, mpoole, obarenbo, security-response-team, tmraz
Target Milestone: ---Keywords: Reopened, Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=low,public=20130404,reported=20130327,source=upstream,cvss2=4.3/AV:N/AC:M/Au:N/C:P/I:N/A:N,rhel-5/postgresql=defer,rhel-5/postgresql84=affected,rhel-6/postgresql=affected,fedora-all/postgresql=affected,cfme-5/postgresql=wontfix
Fixed In Version: PostgreSQL 8.4.17, PostgreSQL 9.0.13, PostgreSQL 9.1.9, PostgreSQL 9.2.4 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-08 13:45:43 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 947204, 948312, 1017833, 1017835, 1017836, 1017837    
Bug Blocks: 907896, 929332, 1011266    

Description Jan Lieskovsky 2013-03-29 11:35:13 EDT
A security flaw was found in the way pgcrypto contrib module of PostgreSQL, an advanced Object-Relational database management system, performed (re)initialization of its internal random number generator [if the server was configured with ssl=on option, and incoming session did not actually use the SSL encryption, the OpenSSL random number generator was initialized only in the moment of the PostgreSQL server startup, and not in the moment of child process(es) fork]. As a result, certain pgcrypto module functions (those requiring random seed) would produce weaker results, possibly allowing attackers to conduct other attacks.

[1] http://www.postgresql.org/message-id/CACMqXCJRoyko5dCys5mzW_F3WJtw_v46fEYX39cusFAZDvocwg@mail.gmail.com
Comment 2 Jan Lieskovsky 2013-03-29 11:38:59 EDT
This issue affects the versions of the postgresql and postgresql84 packages, as shipped with Red Hat Enterprise Linux 5.


This issue affects the version of the postgresql package, as shipped with Red Hat Enterprise Linux 6.


This issue affects the versions of the postgresql package, as shipped with Fedora release of 17 and 18.
Comment 3 Jan Lieskovsky 2013-03-29 11:41:02 EDT

Red Hat would like to thank the PostgreSQL project for reporting this issue. Upstream acknowledges Marko Kreen as the original issue reporter.
Comment 5 Vincent Danen 2013-04-04 10:42:36 EDT
Created postgresql tracking bugs for this issue

Affects: fedora-all [bug 948312]
Comment 6 Tomas Hoger 2013-04-04 10:56:02 EDT
Upstream announcement:

Comment 7 Tomas Mraz 2013-04-04 11:42:59 EDT
This is of very low severity unless you have access to the internal RNG state of the OpenSSL in the main process. Thanks to the diversification by the PID it is impossible (of course based on the irreversibility of the hash function that is used in the RNG output) to find out the internal state (and future random numbers generated) from the output of the RNG in the other processes which share the parent RNG state.
Comment 8 Tom Lane 2013-04-04 11:56:35 EDT
The problem is that the PID "diversification" is limited to 32K distinct PIDs.

The scenario that was discussed upstream is that the attacker (assumed to have valid access to the database) could repeatedly connect and request random numbers, and over enough trials build up a complete dictionary of all 32K random sequences that are possible given the parent RNG state.  After that, he has a pretty good chance of brute-force cracking passwords or whatever that are generated in other sessions using those random numbers, especially if the modus operandi of the generating app is to connect, do a security-critical operation, and disconnect, so that the part of the sequence it's using is predictable.  His dictionary is only good till the next postmaster restart, but that could be months, and anyway it's not hugely expensive to make a new one.

I'd be the first to admit that this scenario is a bit hypothetical, but the claim above that it's impossible to do anything without internal access is just wrong.
Comment 9 Tomas Mraz 2013-04-04 12:59:18 EDT
You're right I misunderstood that in your situation the parent process does not pull any random bytes out of the RNG - yes, in that case it is possible to build the dictionary of random sequences and try to brute force generated passwords. This is still not easy as the sequences will differ based on the amount of data requested from the RNG in an individual call but nevertheless it might be possible.

Unfortunately the regular RNG does not mix in the gettimeofday() value (the FIPS RNG mixes it in) into the state, if it did, this attack would be prevented.
Comment 10 Fedora Update System 2013-04-05 18:59:27 EDT
postgresql-9.2.4-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 11 Fedora Update System 2013-04-05 19:11:40 EDT
postgresql-9.1.9-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 14 Huzaifa S. Sidhpurwala 2013-04-09 05:48:49 EDT

This issue affects the version of postgresql as shipped with Red Hat Enterprise Linux 5 and 6. This issue affects the version of postgresql84, as shipped with Red Hat Enterprise Linux 5.  Red Hat Security Response Team has rated this issue as having low security impact. A future update might address this flaw.
Comment 15 Fedora Update System 2013-04-20 15:59:31 EDT
postgresql-9.2.4-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 errata-xmlrpc 2013-10-29 15:44:55 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6
  Red Hat Enterprise Linux 5

Via RHSA-2013:1475 https://rhn.redhat.com/errata/RHSA-2013-1475.html