Re: Replay attack of query cancel

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> Tom Lane wrote:
>> * Server accepts two different styles of cancel messages, identified
>> by different protocol numbers.

> With the additional point that there is a GUC variable to turn this off
> or warn about it, right?

I see pretty much no value in that.

>> The main drawback I can see to keeping this backward-compatible is that
>> keeping the cancel key to 32 bits could still leave us vulnerable to
>> brute force attacks: once you've seen a cancel message, just try all
>> the possible keys till you get a match, and then you can generate a
>> cancel that will work. Can we refine the HMAC idea to defeat that?
>> Otherwise we're assuming that 2^32 HMACs take longer than the useful
>> life of a cancel key, which doesn't seem like a very future-proof
>> assumption.

> Well, you're also going to have to increment <n> every time. We could
> just cap <n> at <arbitrary level>. Say you can only cancel queries on a
> single connection a million times or so. It's not perfect, but it gets
> you somewhere.

Once you've brute-forced the secret key, you can just use an <n> that's
somewhat more than the last one the client used, assuming you've been
sniffing the connection the whole time. Or use one that's just a bit
less than what you can predict the server will take.

Not only do you get to kill the current query, but you'll have prevented
the client from issuing legitimate cancels after that, since it won't
know you bumped the server's <n> value. So the idea still needs work.

> Another option would be to send a new, longer, cancel key as part of the
> separate parameter we're sending during startup (when we're indicating
> which version we support). Then we'll use the longer cancel key if we're
> dealing with "new style cancel" but keep the old 32-bit one for
> backwards compatibility.

Yeah. So then we just need one added parameter: secure_cancel_key =
string.

BTW, should we make all of this conditional on the use of an SSL
connection? If the original sending of the cancel key isn't secure
against sniffing, it's hard to see what anyone is buying with all the
added computation.

regards, tom lane