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.
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.
Red Hat would like to thank the PostgreSQL project for reporting this issue. Upstream acknowledges Marko Kreen as the original issue reporter.
Created postgresql tracking bugs for this issue
Affects: fedora-all [bug 948312]
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.
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.
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.
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.
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.
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.
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