Re: [HACKERS] Query cancel and OOB data (fwd)
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Query cancel and OOB data (fwd) |
Дата | |
Msg-id | 199805270425.AAA02670@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Query cancel and OOB data (fwd) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Query cancel and OOB data (fwd)
|
Список | pgsql-hackers |
> > 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)
В списке pgsql-hackers по дате отправления: