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

Tom Lane wrote:
> Sir Mordred The Traitor <mordred(at)s-mail(dot)com> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073