On 8/8/08, Heikki Linnakangas <heikki@enterprisedb.com> wrote:
> 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.
Why not establish SSL before sending cancel key?
That way potential SSL auth is also enforced.
I'm not against improving cancel protocol generally, also for non-SSL
clients, but this seems orthogonal to SSL issue - if client uses SSL then
I'd expect cancel packet also be sent over SSL.
--
marko
