Tom Lane wrote:
> Sir Mordred The Traitor <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] | (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 [EMAIL PROTECTED]
