Replay attack of query cancel

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Replay attack of query cancel
Date: 2008-08-08 18:55:25
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

It occurred to me a while ago that our query cancel messages are sent
unencrypted, even when SSL is otherwise used. That's not a big issue on
its own, because the cancellation message only contains the backend PID
and the cancellation key, but it does open us to a replay attack. After
the first query in a connection has been cancelled, an eavesdropper can
reuse the backend PID and cancellation key to cancel subsequent queries
on the same connection.

We discussed this on the security list, and the consensus was that this
isn't worth a quick fix and a security release, because
- it only affects applications that use query cancel, which is rare
- it only affects SSL encrypted connections (the point is moot
non-encrypted connections, as you can just snatch the cancel key from
the initial message)
- it only let's you cancel queries, IOW it's only a DOS attack.
- there's no simple fix.

However, it is something to keep in mind, and perhaps fix for the next

One idea for fixing this is to make cancellation keys disposable, and
automatically issue a new one through the main connection when one is
used, but that's not completely trivial, and requires a change in both
the clients and the server. Another idea is to send the query cancel
message only after SSL authentication, but that is impractical for libpq
because we PQcancel needs to be callable from a signal handler.

Heikki Linnakangas


Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2008-08-08 19:15:19 Re: Replay attack of query cancel
Previous Message Tom Lane 2008-08-08 17:16:50 Re: autovacuum and TOAST tables