Re: [HACKERS] Re: Cancel key now ready

>
> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I have added code to the postmaster to generate a random cancel key by
> > calling gettimeofday() on postmaster startup and on the first invocation
> > of a backend, and merged the micro-seconds of the two times to seed the
> > random number generator.
>
> There were several things I didn't like about Bruce's first cut.
> His method for generating a random seed in the postmaster is good,
> but there are several security holes elsewhere.
>
> > Not sure if you can
> > predict forward, but it is probably impossible to predict randoms
> > backward on any of our supported platforms.
>
> Actually, it's not that hard. Nearly all implementations of random()
> are basically just
> seed = (seed * a + b) % c;
> return seed;
> for some constants a,b,c --- which a potential attacker could easily
> find out. So if the attacker can execute random() in a backend before
> it gets used for anything else, he can back up to the last random value
> generated in the postmaster. The most secure way to prevent this is to
> re-execute srandom() during the startup of each backend, so that it will
> have a random() sequence that's unrelated to the postmaster's.

I thought about this. I can force a re-seeding of random in the
backend on first use. Didn't get that far yet. Could re-seed on every
startup, but again, could be an expensive function.

>
> Also, Bruce was assuming that the random_seed value wouldn't be visible
> in a backend ... but the forked-off backend will have a copy just
> sitting there, readily accessible if you can figure out its address.
> Backend startup should zero out this variable to be on the safe side.

If they have access the backend address space, they can see the entire
postmaster backend structure at time of fork(), so seeing the seed is
meanless. Basically, for any user who is installing their own functions
or stuff is already able to do more severe damage than just cancel.
They can write directly into the database.

>
> Attached is a patch that fixes these leaks, and does a couple other
> things as well:
> * Computes and saves a cancel key for each backend.
> * fflush before forking, to eliminate double-buffering problems
> between postmaster and backends.

Can you elaborate on what this fixes?

> * Go back to two random() calls instead of one to generate random
> salt. I'm not sure why Bruce changed that, but it looks much
> less secure to me; the one-call way is exposing twice as many
> bits of the current random seed.

The code is similar to taking a random() and doing:

rand % 10

(rand / 10) % 10

which for a random of 123456 returns 6 and 5. In the postmaster case
the values are 62 and not 10, but the concept is the same. No reason to
call random() twice. May be an expensive function on some platforms.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)