Re: [HACKERS] Query cancel and OOB data

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