Re: [HACKERS] Query cancel and OOB data
Bruce Momjian <maillist@candle.pha.pa.us>
From: Bruce Momjian <maillist@candle.pha.pa.us>
To: tih+mail@Hamartun.Priv.NO (Tom Ivar Helbekkmo)
Cc: tgl@sss.pgh.pa.us, byronn@insightdist.com, hackers@postgreSQL.org
Date: 1998-05-25T03:57:58Z
Lists: pgsql-hackers
> > 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)