Thread: Re: [HACKERS] Query cancel and OOB data (fwd)
> OK, lets review this, with thought about our various authentication > options: > > trust, password, ident, crypt, krb4, krb5 > > As far as I know, they all transmit queries and results as clear text > across the network. They encrypt the passwords and tickets, but not the > data. [Even kerberos does not encrypt the data stream, does it?] > > So, if someone snoops the network, they will see the query and results, > and see the cancel secret key. Of course, once they see the cancel > secret key, it is trivial for them to send that to the postmaster to > cancel a query. However, if they are already snooping, how much harder > is it for them to insert their own query into the tcp stream? If it is > as easy as sending the cancel secret key, then the additional > vulnerability of being able to replay the cancel packet is trivial > compared to the ability to send your own query, so we don't loose > anything by using a non-encrypted cancel secret key. Can someone answer this for me? > > Of course, if the stream were encrypted, they could not see the secret key > needs to be accepted and sent in an encrypted format. > > -- > Bruce Momjian | 830 Blythe Avenue > maillist@candle.pha.pa.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) > -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.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)
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> However, if they are already snooping, how much harder
>> is it for them to insert their own query into the tcp stream?
> Can someone answer this for me?
Well, that depends entirely on what your threat model is --- for
example, someone with read access on /dev/kmem on a relay machine
might be able to watch packets going by, yet not be able to inject
more. On the other hand, someone with root privileges on another
machine on your local LAN could likely do both.
My guess is that most of the plausible cases that allow one also
allow the other. But it's only a guess.
regards, tom lane
>
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> >> However, if they are already snooping, how much harder
> >> is it for them to insert their own query into the tcp stream?
>
> > Can someone answer this for me?
>
> Well, that depends entirely on what your threat model is --- for
> example, someone with read access on /dev/kmem on a relay machine
> might be able to watch packets going by, yet not be able to inject
> more. On the other hand, someone with root privileges on another
> machine on your local LAN could likely do both.
>
> My guess is that most of the plausible cases that allow one also
> allow the other. But it's only a guess.
Ok, I agree. If someone sees the cancel secret going over the wire,
they almost just as easily can send their own query on the wire.
Remember, the cancel is going directly to the postmaster as a separate
connection, so it is a little easier than spoofing a packet.
So, with that decided, the only issue is how the postmaster should
generate the random key. Currently, to get the password salt, which
does not have to be un-guessable, RandomSalt() seeds the random number
generator with the current time, and then just continues to call random.
If we continue that practice, someone can guess the first cancel
password by finding out when the first postgres backend needed a random
number, and use that time in seconds to figure out the new random
number. We could load/save the seed on postmaster start/exit, and
somehow seed that value during install or initdb. Perhaps the
completion time of initdb can be used. Maybe a:
'date +%s' >/pgsql/data/pg_random
and have the postmaster load it on startup, and write it on exit.
Because initdb takes some time to run, we could put it in between two of
the initdb commands that take some time to run. Their timestamp of
activity is burried in pgsql/data and only postgres read-able.
Comments?
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.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)
> > Bruce Momjian <maillist@candle.pha.pa.us> writes: > >> However, if they are already snooping, how much harder > >> is it for them to insert their own query into the tcp stream? > > > Can someone answer this for me? > > Well, that depends entirely on what your threat model is --- for > example, someone with read access on /dev/kmem on a relay machine > might be able to watch packets going by, yet not be able to inject > more. On the other hand, someone with root privileges on another > machine on your local LAN could likely do both. > > My guess is that most of the plausible cases that allow one also > allow the other. But it's only a guess. > Oh, yes, one more thing. When generating the cancel key, We will have to call random twice and return part of each so users will not see our current random values. When I remove the exec(), people will be able to call random() in the backend to see the random value. May need to reset the seed on backend startup. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.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)
> > Bruce Momjian <maillist@candle.pha.pa.us> writes: > > >> However, if they are already snooping, how much harder > > >> is it for them to insert their own query into the tcp stream? > > > > > Can someone answer this for me? > > > > Well, that depends entirely on what your threat model is --- for > > example, someone with read access on /dev/kmem on a relay machine > > might be able to watch packets going by, yet not be able to inject > > more. On the other hand, someone with root privileges on another > > machine on your local LAN could likely do both. > > > > My guess is that most of the plausible cases that allow one also > > allow the other. But it's only a guess. > > Ok, I agree. If someone sees the cancel secret going over the wire, > they almost just as easily can send their own query on the wire. > Remember, the cancel is going directly to the postmaster as a separate > connection, so it is a little easier than spoofing a packet. > > So, with that decided, the only issue is how the postmaster should > generate the random key. Currently, to get the password salt, which > does not have to be un-guessable, RandomSalt() seeds the random number > generator with the current time, and then just continues to call random. Just do time and pid. But get the time from gettimeofday so it will be down to the millisecond or so. Anything more is overkill for this application. > If we continue that practice, someone can guess the first cancel > password by finding out when the first postgres backend needed a random > number, and use that time in seconds to figure out the new random > number. We could load/save the seed on postmaster start/exit, and > somehow seed that value during install or initdb. Perhaps the > completion time of initdb can be used. Maybe a: > > 'date +%s' >/pgsql/data/pg_random > > and have the postmaster load it on startup, and write it on exit. > Because initdb takes some time to run, we could put it in between two of > the initdb commands that take some time to run. Their timestamp of > activity is burried in pgsql/data and only postgres read-able. > > Comments? See Mr Dodds excellent post. This is getting too elaborate. One possibility, make it configurable to allow cancels at all. Then if someone really had a spurious cancel problem they could work around it by turning cancels off. But hey, I think we should just use TCP only and then we could count on OOB. Btw, on my P166 at work, lmbench says Linux 2.1.101 can do round trip tcp in 125 microseconds. That is pretty quick. -dg David Gould dg@illustra.com 510.628.3783 or 510.305.9468 Informix Software 300 Lakeside Drive Oakland, CA 94612 - A child of five could understand this! Fetch me a child of five.
> Just do time and pid. But get the time from gettimeofday so it will be > down to the millisecond or so. Anything more is overkill for this application. You have given me exactly what I needed. If I run gettimeofday() on postmaster startup, and run it when the first backend is started, I can use the microseconds from both calls to generate a truely random seed. Even if the clock is only accurate to 10 ms, I still get a 10,000 random keyspace. I can mix the values by taking/swapping the low and high 16-bit parts so even with poor resolution, both get used. The micro-second times are not visible via ps, or probably even kept in the kernel, so these values will work fine. Once random is seeded, for each backend we call random twice and return a merge of the two random values. I wonder if we just call random once, and XOR it with our randeom seed, if that would be just as good or better? Cryptologists? Comments? Sounds like a plan. The thought of giving the users yet another option to disable cancel just made me squirm. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.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)
> From: Bruce Momjian <maillist@candle.pha.pa.us> > Date: Mon, 1 Jun 1998 00:53:21 -0400 (EDT) ... > > Just do time and pid. But get the time from gettimeofday so it will be > > down to the millisecond or so. Anything more is overkill for this application. > > You have given me exactly what I needed. If I run gettimeofday() on > postmaster startup, and run it when the first backend is started, I can > use the microseconds from both calls to generate a truely random seed. > Even if the clock is only accurate to 10 ms, I still get a 10,000 random > keyspace. I can mix the values by taking/swapping the low and high > 16-bit parts so even with poor resolution, both get used. > > The micro-second times are not visible via ps, or probably even kept in > the kernel, so these values will work fine. > > Once random is seeded, for each backend we call random twice and return > a merge of the two random values. I wonder if we just call random once, > and XOR it with our randeom seed, if that would be just as good or > better? Cryptologists? > > Comments? Sounds like a plan. The thought of giving the users yet > another option to disable cancel just made me squirm. For FreeBSD and Linux, isn't /dev/urandom the method of choice for getting random bits? [I've been away from this thread awhile - please excuse if this option was already discussed].
> > > From: Bruce Momjian <maillist@candle.pha.pa.us> > > Date: Mon, 1 Jun 1998 00:53:21 -0400 (EDT) > ... > > > Just do time and pid. But get the time from gettimeofday so it will be > > > down to the millisecond or so. Anything more is overkill for this application. > > > > You have given me exactly what I needed. If I run gettimeofday() on > > postmaster startup, and run it when the first backend is started, I can > > use the microseconds from both calls to generate a truely random seed. > > Even if the clock is only accurate to 10 ms, I still get a 10,000 random > > keyspace. I can mix the values by taking/swapping the low and high > > 16-bit parts so even with poor resolution, both get used. > > > > The micro-second times are not visible via ps, or probably even kept in > > the kernel, so these values will work fine. > > > > Once random is seeded, for each backend we call random twice and return > > a merge of the two random values. I wonder if we just call random once, > > and XOR it with our randeom seed, if that would be just as good or > > better? Cryptologists? > > > > Comments? Sounds like a plan. The thought of giving the users yet > > another option to disable cancel just made me squirm. > > For FreeBSD and Linux, isn't /dev/urandom the method of choice for > getting random bits? [I've been away from this thread awhile - please > excuse if this option was already discussed]. Not available on most/all platforms. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.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)
Hal Snyder wrote: > > > From: Bruce Momjian <maillist@candle.pha.pa.us> > > Date: Mon, 1 Jun 1998 00:53:21 -0400 (EDT) > ... > > > Just do time and pid. But get the time from gettimeofday so it will be > > > down to the millisecond or so. Anything more is overkill for this application. > > > > You have given me exactly what I needed. If I run gettimeofday() on > > postmaster startup, and run it when the first backend is started, I can > > use the microseconds from both calls to generate a truely random seed. > > Even if the clock is only accurate to 10 ms, I still get a 10,000 random > > keyspace. I can mix the values by taking/swapping the low and high > > 16-bit parts so even with poor resolution, both get used. > > > > The micro-second times are not visible via ps, or probably even kept in > > the kernel, so these values will work fine. > > > > Once random is seeded, for each backend we call random twice and return > > a merge of the two random values. I wonder if we just call random once, > > and XOR it with our randeom seed, if that would be just as good or > > better? Cryptologists? > > > > Comments? Sounds like a plan. The thought of giving the users yet > > another option to disable cancel just made me squirm. > > For FreeBSD and Linux, isn't /dev/urandom the method of choice for > getting random bits? [I've been away from this thread awhile - please > excuse if this option was already discussed]. I believe /dev/random is guaranteed to be "random", while /dev/urandom is guaranteed to return a certain number of psuedorandom bytes in a given time. These are not universally available though. Seeding with bits taken from the pid and hi-res time should be OK. Something I did on a similar task was to set up a max-keys-per-key and max-elapsed-time-per-key. Basically, seed the random number generator when the postmaster starts, and reseed after every 10 keys, or if 10 minutes have elapsed since the random number generator was las seeded. This way, the would be attacker can't know for sure when the random number generator was last reseeded. Ocie Mitchell