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:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	hhorak, mpoole, security-response-team
Target Milestone:	---	Keywords:	Reopened, Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
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:	2021-10-19 22:00:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	947204, 948312, 1017833, 1017835, 1017836, 1017837
Bug Blocks:	907896, 929332, 1011266

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 12 Tomas Hoger 2013-04-09 08:13:56 UTC

Upstream commit:

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0d1ecd6300191a450978ca2fcd12bbbb7c5e65e6

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