Skip site navigation (1) Skip section navigation (2)

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
Message-ID: (view raw, whole thread or download thread mbox)
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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group