On Fri, Dec 21, 2012 at 10:05:30PM -0500, Tom Lane wrote: > This new patch looks pretty reasonable from here, > modulo the question of whether it adds "enough" entropy.
More brains reviewing that question will be good. > I'm not entirely sold on whether it does. ISTM that any attack based on > this line of thinking already assumes that the attacker has complete > knowledge of how many backends have been launched (else he doesn't know > which sequence a targeted session will get). pg_stat_activity.pid will do. > If he knows that much, > mightn't he also know *when* they were launched? Alternatively: if he > can know the session's start time (which we helpfully make available...) > how much harder is this really making it for him to deduce the session's > seed? If he has access to his own fork-time seed, he can indeed estimate the seeds of other sessions. That seed is currently invisible to non-native code, and a user able to deploy a C function already has the access needed to compromise all sessions. The assumption that the fork-time seed stays buried is a source of unease, though. > On top of which: what exactly will he do with the seed once he's got it > that would amount to a security problem? > > Or to put it in different terms, I'm not quite convinced that there's a > plausible threat model that this patch blocks effectively. The examples could be as numerous as the algorithms that specify use of a cryptographically secure PRNG. Here's a simple one: an application generates long-term private encryption keys by connecting, issuing "SELECT gen_random_bytes(16)", and disconnecting. Long-term, across postmaster restarts, there are still almost 2^128 possible keys. However, backends of any given postmaster can only generate 2^15 possible keys. An attacker can attempt to acquire, over time, a backend with every PID in the system. The script I gave earlier is an example of doing so. He won't manage to visit literally every PID, sure, but he'll easily get 95% of them. By issuing "SELECT pg_backend_pid(), gen_random_bytes(16)" in each session, he assembles a dictionary of most possible keys under this postmaster. If he repeats this after each postmaster restart, he might acquire a dictionary covering months or years of key generation. Given a ciphertext based on a key presumed to be made during that time, he can try his relatively-small dictionary with a high chance of success. nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers