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. +
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 |