Re: Replay attack of query cancel

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Replay attack of query cancel
Date: 2008-08-16 02:15:37
Message-ID: 200808160215.m7G2Fbj22749@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Added to TODO:

* Prevent query cancel packets from being replayed by an attacker,
especially when using SSL

http://archives.postgresql.org/pgsql-hackers/2008-08/msg00345.php

---------------------------------------------------------------------------

Heikki Linnakangas 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.
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2008-08-16 03:43:42 Re: stat() vs cygwin
Previous Message Bruce Momjian 2008-08-16 01:57:06 Re: compilig libpq with borland 5.5