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
release.
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 EnterpriseDB http://www.enterprisedb.com