Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 15 Jun 2015 10:32:37 +0200
From: Pierre Schweitzer <>
To: Bastian Blank <>,
Subject: Re: PostgreSQL - Predictable cancel key

Hash: SHA256


How is it really exploitable?

I had a look at glibc random implementation, they got rid of the old
LCG they were using for a "nonlinear additive feedback" PRNG which
uses a 31 numbers state. That means that knowing a number in the
pseudo-random stream you cannot recover the whole generator state to
compute the next PRN, as it was possible with a LCG.

So, basically, if I'm right (correct otherwise!) knowing your cancel
key and your PID makes it really hard to know which key belongs to
other PIDs. Because you still lack two pieces of information: the
initial state (deduced from the knowledge of the seed) and the state
of the generator when it generated your key (or perhaps knowing just
one state would be enough? Anyway, it's missing).

So, I feel like that it's really hard for a PID to hijack another PID.

But, for my reasoning, I used the hypothesis that random() is
implemented with a robust PRNG. This is actually really libc quality
dependent. I'm not sure if some implementations still rely on a LCG.

Correct me if I'm wrong or if I missed something.


On 06/13/2015 11:33 AM, Bastian Blank wrote:
> Hi
> PostgreSQL postmaster uses predictable random numbers from
> random(). The PRNG is seeded once during its lifetime with
> srandom().  The seed is generated as following, also zero is
> explicitely excluded:
> | random_seed = random_start_time.tv_usec ^ |
> ((random_stop_time.tv_usec << 16) | |
> ((random_stop_time.tv_usec >> 16) & 0xffff));
> So we have at most 1,000,000 different seeds.
> A so called cancel key is generated with random() for every new
> backend used by client connections and for autovacuum childs.  This
> key together with the PID is used for asynchronous cancelation of
> queries in client backends.  This values are transmitted to the
> client after successful authentication.
> The information needed to cancel other queries is the (sequential,
> at least on Linux) pid and a predicable (secret) key.
> Another set of four calles to random() are used to generate the
> salt for the md5-authentication.  This value is given to the client
> before the authentication.  One call per byte is done, excluding
> zero bytes:
> | md5Salt[0] = (random() % 255) + 1; | md5Salt[1] = (random() %
> 255) + 1; | md5Salt[2] = (random() % 255) + 1; | md5Salt[3] =
> (random() % 255) + 1;
> Timeline: - 2015-02-13: Reported upstream, considered no problem -
> 2015-06-13: Published
> Regards, Bastian

- -- 
Pierre Schweitzer <>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Version: GnuPG v2


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.