Re: [HACKERS] Query cancel and OOB data

>
> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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)