Thread

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

   Tom Lane <tgl@sss.pgh.pa.us> — 1998-05-24T15:29:42Z

   Bruce Momjian <maillist@candle.pha.pa.us> writes:
   > I was trying to avoid the
   > 'magic cookie' solution for a few reasons:
   
   > 	1) generating a random secret codes can be slow (I may be wrong)
   
   Not really.  A typical system rand() subroutine is a multiply and an
   add.  For the moment I'd recommend generating an 8-byte random key with
   something like
   
   	for (i=0; i<8; i++)
   		key[i] = rand() & 0xFF;
   
   which isn't going to take enough time to notice.
   
   The above isn't cryptographically secure (which means that a person who
   receives a "random" key generated this way might be able to predict the
   next one you generate).  But it will do to get the protocol debugged,
   and we can improve it later.  I have Schneier's "Applied Cryptography"
   and will study its chapter on secure random number generators.
   
   > 	2) the random key is sent across the network with a cancel
   > request, so once it is used, it can be used by a malcontent to cancel
   > any query for that backend.
   
   True, if you have a packet sniffer then you've got big troubles ---
   on the other hand, a packet sniffer can also grab your password,
   make his own connection to the server, and wreak much more havoc
   than just issuing a cancel.  I don't see that this adds any
   vulnerability that wasn't there before.
   
   > 	3) I hesitate to add the bookkeeping in the postmaster and libpq
   > of that pid/secret key combination.  Seems like some bloat we could do
   > without.
   
   The libpq-side bookkeeping is trivial.  I'm not sure about the
   postmaster though.  Does the postmaster currently keep track of
   all operating backend processes, or not?  If it does, then another
   field per process doesn't seem like a problem.
   
   > 	4) You have to store the secret key in the client address space,
   > possibly open to snooping.
   
   See password.  In any case, someone with access to the client address
   space can probably manage to send packets from the client, too.  So
   "security" based on access to the client/backend connection isn't any
   better.
   
   > This basically simulates OOB by sending a message to the postmaster,
   > which is always listening, and having it send a signal, which is
   > possible because they are owned by the same user.
   
   Right.
   
   Maybe we should look at this as a fallback that libpq uses if it
   tries OOB and that doesn't work?  Or is it not a good idea to have
   two mechanisms?
   
   			regards, tom lane
   
   

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

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-05-24T17:20:27Z

   > 
   > Bruce Momjian <maillist@candle.pha.pa.us> writes:
   > > I was trying to avoid the
   > > 'magic cookie' solution for a few reasons:
   > 
   > > 	1) generating a random secret codes can be slow (I may be wrong)
   > 
   > Not really.  A typical system rand() subroutine is a multiply and an
   > add.  For the moment I'd recommend generating an 8-byte random key with
   > something like
   > 
   > 	for (i=0; i<8; i++)
   > 		key[i] = rand() & 0xFF;
   > 
   > which isn't going to take enough time to notice.
   
   Actually, just sending a random int as returned from random() is enough.
   random() returns a long here, but just cast it to int.
   
   > 
   > The above isn't cryptographically secure (which means that a person who
   > receives a "random" key generated this way might be able to predict the
   > next one you generate).  But it will do to get the protocol debugged,
   > and we can improve it later.  I have Schneier's "Applied Cryptography"
   > and will study its chapter on secure random number generators.
   
   Yes, that may be true.  Not sure if having a single random() value can
   predict the next one.  If we just use on random() return value, I don't
   think that is possible.
   
   > 
   > > 	2) the random key is sent across the network with a cancel
   > > request, so once it is used, it can be used by a malcontent to cancel
   > > any query for that backend.
   > 
   > True, if you have a packet sniffer then you've got big troubles ---
   > on the other hand, a packet sniffer can also grab your password,
   > make his own connection to the server, and wreak much more havoc
   > than just issuing a cancel.  I don't see that this adds any
   > vulnerability that wasn't there before.
   
   Yes.
   
   > 
   > > 	3) I hesitate to add the bookkeeping in the postmaster and libpq
   > > of that pid/secret key combination.  Seems like some bloat we could do
   > > without.
   > 
   > The libpq-side bookkeeping is trivial.  I'm not sure about the
   > postmaster though.  Does the postmaster currently keep track of
   > all operating backend processes, or not?  If it does, then another
   > field per process doesn't seem like a problem.
   
   Yes.  The backend does already have such a per-connection structure, so
   adding it is trivial too.
   
   > 
   > > 	4) You have to store the secret key in the client address space,
   > > possibly open to snooping.
   > 
   > See password.  In any case, someone with access to the client address
   > space can probably manage to send packets from the client, too.  So
   > "security" based on access to the client/backend connection isn't any
   > better.
   
   Yep.
   
   > 
   > > This basically simulates OOB by sending a message to the postmaster,
   > > which is always listening, and having it send a signal, which is
   > > possible because they are owned by the same user.
   > 
   > Right.
   > 
   > Maybe we should look at this as a fallback that libpq uses if it
   > tries OOB and that doesn't work?  Or is it not a good idea to have
   > two mechanisms?
   
   You have convinced me.  Let's bag OOB, and use this new machanism.  I
   can do the backend changes, I think.
   
   -- 
   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

   Tom Ivar Helbekkmo <tih+mail@hamartun.priv.no> — 1998-05-24T18:47:01Z

   Tom Lane <tgl@sss.pgh.pa.us> writes:
   
   > on the other hand, a packet sniffer can also grab your password,
   > make his own connection to the server, and wreak much more havoc
   > than just issuing a cancel.  I don't see that this adds any
   > vulnerability that wasn't there before.
   
   Ahem.  Not true for those of us who use Kerberos authentication.
   We never send our passwords over the network, instead using them
   as (part of) a key that's used to encrypt other data.
   
   -tih
   -- 
   Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"
   
   

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

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-05-25T03:57:58Z

   > 
   > Tom Lane <tgl@sss.pgh.pa.us> writes:
   > 
   > > on the other hand, a packet sniffer can also grab your password,
   > > make his own connection to the server, and wreak much more havoc
   > > than just issuing a cancel.  I don't see that this adds any
   > > vulnerability that wasn't there before.
   > 
   > Ahem.  Not true for those of us who use Kerberos authentication.
   > We never send our passwords over the network, instead using them
   > as (part of) a key that's used to encrypt other data.
   
   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.
   
   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)
   
   

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

   Tom Ivar Helbekkmo <tih+mail@hamartun.priv.no> — 1998-05-25T05:30:35Z

   Bruce Momjian <maillist@candle.pha.pa.us> writes:
   
   > 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?]
   
   True.  Encrypted communication should be an option, though.  With
   Kerberos, the ability to do this securely is already there in the
   library, so it would be natural to use it.  Adding encryption to the
   communication between client and postmaster is probably a good thing
   even if we don't (yet) encrypt that between client and backend, and
   would also be a good, simple way to start implementing it.
   
   -tih
   -- 
   Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"
   
   

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

   ocie@paracel.com — 1998-05-26T21:00:57Z

   Tom Lane wrote:
   > 
   > Bruce Momjian <maillist@candle.pha.pa.us> writes:
   > > I was trying to avoid the
   > > 'magic cookie' solution for a few reasons:
   > 
   > > 	1) generating a random secret codes can be slow (I may be wrong)
   > 
   > Not really.  A typical system rand() subroutine is a multiply and an
   > add.  For the moment I'd recommend generating an 8-byte random key with
   > something like
   > 
   > 	for (i=0; i<8; i++)
   > 		key[i] = rand() & 0xFF;
   > 
   > which isn't going to take enough time to notice.
   > 
   > The above isn't cryptographically secure (which means that a person who
   > receives a "random" key generated this way might be able to predict the
   > next one you generate).  But it will do to get the protocol debugged,
   > and we can improve it later.  I have Schneier's "Applied Cryptography"
   > and will study its chapter on secure random number generators.
   
   A neat feature of linux is that it has a kernel random number
   generator which is fed random data from interrupt times.  The only
   drawback is that this is sort of a "pool", so whn the pool is full,
   drawing 8 bytes from it is not a problem, but when the pool is
   drained, it can take some time to generate more data.  At any rate, it
   might be a good starting point for a postgres random number generator
   -- sample usage of shared memory and perform a hash on this.  From
   "applied cryptography":
   
   "In effect, the system degrades gracefully from perfect to practical
   randomness when the demand exceeds the supply.  In this case it
   becomes theoretically possible .. to determine a previous or
   subsequent result.  But this requires inverting MD5, which is
   computationally infeasible"
   
   applied cryptography, 2nd eddition, p427.
   
   This is sort of what we want.  As random as the key can be, but able
   to generate a pseudo-random key if we're short on time.
   
   Ocie
   
   

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

   Brett McCormick <brett@work.chicken.org> — 1998-05-26T21:11:18Z

   /dev/urandom performs a similar function without the wait.  of course
   not all of the data is new, but it should still be pretty secure.
   
   On Tue, 26 May 1998, at 14:00:57, ocie@paracel.com wrote:
   
   > A neat feature of linux is that it has a kernel random number
   > generator which is fed random data from interrupt times.  The only
   > drawback is that this is sort of a "pool", so whn the pool is full,
   > drawing 8 bytes from it is not a problem, but when the pool is
   > drained, it can take some time to generate more data.  At any rate, it
   > might be a good starting point for a postgres random number generator
   > -- sample usage of shared memory and perform a hash on this.  From
   > "applied cryptography":