Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

Tom Lane wrote:
> Sir Mordred The Traitor <mordred@xxxxxxxxxx> writes:
> > Note, that the size of palloced memory is taken from the user's input,
> > which is stupid if you ask me.
> 
> Beyond causing an "out of memory" error during the handshake, I fail to
> see how there can be any problem.  palloc is considerably more robust
> than malloc.
> 
> > I dont want to provide any tools to illustrate this vulnerability.
> 
> Perhaps you haven't tried.
> 
> It may indeed make sense to put a range check here, but I'm getting
> tired of hearing the words "dos attack" applied to conditions that
> cannot be exploited to cause any real problem.  All you are
> accomplishing is to spread FUD among people who aren't sufficiently
> familiar with the code to evaluate the seriousness of problems...

Sir-* does have a point.  A valid host in pg_hba.conf can cause DOS by
just connecting over and over, but allocating almost all of the memory
on the machine would affect other applications running on the machine,
even non-networked applications, as well as PostgreSQL, while a
connection DOS effects only PostgreSQL.

It isn't fun to have our code nit-picked apart, and Sir-* is over-hyping
the vulnerability, but it is a valid concern.  The length should
probably be clipped to a reasonable length and a comment put in the code
describing why.

There are a whole host of vulnerability scenarios that we have not
explored.  In fact, with 7.2.2, we got into the data-based crash vs.
query-based crash issue that we have not discussed before in detail. 

With this report, we have a non-authorized user causing possible memory
exhaustion for all applications on the server.  This is a greater
vulnerability than the random query argument because in such cases the
user is authorized to issue queries.

So, Sir-* and others, please understand that databases have their own
vulnerability envelope that is much more complex than a standard network
application like ftp.  There is almost an entirely new vocabulary for
describing such vulnerabilities which we have been crafting as we
discuss it.  This vocabulary includes:

        connection-enabled hosts vs. any host
        authenticated vs. non-authenticated users
        users with data insertion access
        users with query access

I think the last group can not be protected from malevolent queries, but
the former can be tightened, and Sir-* is working on that.  Sir-*, when
describing vulnerabilities, especially in public forums, please try to
use this language so people are not overly agitated by your warnings.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@xxxxxxxxxxxxxxxx               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@xxxxxxxxxxxxxx