Thread

1. Re: [HACKERS] Query cancel and OOB data (fwd)

   Tom Lane <tgl@sss.pgh.pa.us> — 1998-05-26T23:14:51Z

   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
   
   

2. Re: [HACKERS] Query cancel and OOB data (fwd)

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-05-27T04:25:10Z

   > 
   > 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)
   
   

3. Re: [HACKERS] Query cancel and OOB data (fwd)

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-05-27T04:39:11Z

   > 
   > 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)
   
   

4. Re: [HACKERS] Query cancel and OOB data (fwd)

   David Gould <dg@illustra.com> — 1998-05-31T08:50:12Z

   > > 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.
   
   

5. Re: [HACKERS] Query cancel and OOB data (fwd)

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-06-01T04:53:21Z

   > 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)
   
   

6. Re: [HACKERS] Query cancel and OOB data (fwd)

   Hal Snyder <hal@enteract.com> — 1998-06-01T05:33:35Z

   > 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].
   
   
   

7. Re: [HACKERS] Query cancel and OOB data (fwd)

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-06-01T14:12:22Z

   > 
   > > 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)
   
   

8. Re: [HACKERS] Query cancel and OOB data (fwd)

   ocie@paracel.com — 1998-06-01T21:32:17Z

   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