Bug 929255 (CVE-2013-1900) - CVE-2013-1900 postgresql: Improper randomization of pgcrypto functions (requiring random seed)
Summary: CVE-2013-1900 postgresql: Improper randomization of pgcrypto functions (requi...
Keywords:
Status: NEW
Alias: CVE-2013-1900
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=low,public=20130404,reported=2...
Depends On: 947204 948312 1017833 1017835 1017836 1017837
Blocks: 907896 929332 1011266
TreeView+ depends on / blocked
 
Reported: 2013-03-29 15:35 UTC by Jan Lieskovsky
Modified: 2019-06-08 19:30 UTC (History)
8 users (show)

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:
Clone Of:
Environment:
Last Closed: 2013-04-08 17:45:43 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:1475 normal SHIPPED_LIVE Moderate: postgresql and postgresql84 security update 2013-10-29 23:43:31 UTC

Description Jan Lieskovsky 2013-03-29 15:35:13 UTC
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.

References:
[1] http://www.postgresql.org/message-id/CACMqXCJRoyko5dCys5mzW_F3WJtw_v46fEYX39cusFAZDvocwg@mail.gmail.com

Comment 2 Jan Lieskovsky 2013-03-29 15:38:59 UTC
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 15:41:02 UTC
Acknowledgements:

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 14:42:36 UTC
Created postgresql tracking bugs for this issue

Affects: fedora-all [bug 948312]

Comment 6 Tomas Hoger 2013-04-04 14:56:02 UTC
Upstream announcement:

http://www.postgresql.org/about/news/1456/

Comment 7 Tomas Mraz 2013-04-04 15:42:59 UTC
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 15:56:35 UTC
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 16:59:18 UTC
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 22:59:27 UTC
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 23:11:40 UTC
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 15 Fedora Update System 2013-04-20 19:59:31 UTC
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 19:44:55 UTC
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


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