
//@(#) Mordred Labs advisory 0x0007

Release data: 26/08/02
Name: Remote DoS condition in PostgreSQL
Versions affected: all versions
Conditions: entry in a pg_hba.conf file that matches attacker's host.
Risk: average

---[ Description:

Upon connecting to a database, postmaster will fork a new process. 
After that, a child process will call a
src/backend/postmaster/postmaster.c:DoBackend() routine, 
which after processing a startup packet (see src/include/libpq/pqcomm.h), 
will invoke a src/backend/libpq/auth.c:ClientAuthentication() routine to
perform client authentication.
If there is an entry in pg_hba.conf file, that matches an attacker's host, 
an attacker could trigger
invocation of src/backend/libpq/auth.c:recv_and_check_password0(), which
fails to detect a DoS condition.

---[ Details:
Consider this snip of code from src/backend/libpq/auth.c:

[snip]
static int recv_and_check_password0(Port *port) {
	int32 len;
	char *buf;
 
	if (pq_getint(&len, 4) == EOF)
		return STATUS_EOF;
	len -= 4;
	buf = palloc(len); /* len is taken from a packet */
[snip]

Note, that the size of palloced memory is taken from the user's input,
which is stupid if you ask me.

--[ How to reproduce:

I dont want to provide any tools to illustrate this vulnerability.

--[ Solution

Disable network access for untrusted users.




________________________________________________________________________
This letter has been delivered unencrypted. We'd like to remind you that
the full protection of e-mail correspondence is provided by S-mail
encryption mechanisms if only both, Sender and Recipient use S-mail.
Register at S-mail.com: http://www.s-mail.com/inf/en

Mon, 26 Aug 2002 14:46:19 +0000
Sir Mordred The Traitor <mordred@s-mail.com>
@(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
On 26 Aug 2002 at 14:46, Sir Mordred The Traitor wrote:
> [snip]
> static int recv_and_check_password0(Port *port) {
> 	int32 len;
> 	char *buf;
>  
> 	if (pq_getint(&len, 4) == EOF)
> 		return STATUS_EOF;
> 	len -= 4;
> 	buf = palloc(len); /* len is taken from a packet */
> [snip]

So that should read,

 buf=palloc((len>LENMAX?SAFELEN:len));

is what you want to say? 

sounds good to me.. But if it is taken from the packet, won't that be tripped 
to MTA size? Just a naï¿½ve question. Never saw much of postgres code myself..


Bye
 Shridhar

--
Wilcox's Law:	A pat on the back is only a few centimeters from a kick in the 
pants.


Mon, 26 Aug 2002 20:25:15 +0530
"Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>
Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
Sir Mordred The Traitor <mordred@s-mail.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...

			regards, tom lane

Mon, 26 Aug 2002 11:02:56 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL 
On Monday 26 August 2002 10:46 am, Sir Mordred The Traitor wrote:
> Conditions: entry in a pg_hba.conf file that matches attacker's host.
> Risk: average

> --[ Solution
>
> Disable network access for untrusted users.

TCP/IP access must be enabled as well.  TCP/IP accessibility is OFF by 
default.

I for one thought that it was normal operating procedure to only allow access 
to trusted machines; maybe I'm odd in that regard.

Hey, if I can connect to postmaster I can DoS it quite easily, but flooding it 
with connection requests.....

But, if we can thwart this, all the better.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Mon, 26 Aug 2002 11:18:48 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
-*- Lamar Owen <lamar.owen@wgcr.org> [ 2002-08-26 15:19 ]:
> TCP/IP access must be enabled as well.  TCP/IP accessibility is OFF by 
> default.
> 
> I for one thought that it was normal operating procedure to only allow access 
> to trusted machines; maybe I'm odd in that regard.
> 
> Hey, if I can connect to postmaster I can DoS it quite easily, but flooding it 
> with connection requests.....
> 
> But, if we can thwart this, all the better.

Well, ISP's that offer webhosting and database connectivity might also be running a PostgreSQL server that only allows connections from that specific webserver (TCP port 5432 access not blocked as well as an pg_hba.conf entry).  Now, if a user with access to the webserver has privileges to open a socket connection, he could exploit this.


-- 
Regards,
Tolli
tolli@tol.li

Mon, 26 Aug 2002 15:27:57 +0000
=?iso-8859-1?Q?=DE=F3rhallur_H=E1lfd=E1narson?= <tolli@tol.li>
Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
so basically if you are an idiot admin, and leave the postgresql box
open (explicitly opening stuff), and under certian conditions, you can
get DoS'd? hrm, this may not be your biggest problem.

maybe if the dba has a clue and only explicitly allows certian ips
to even route to the box, and then certian users (1 or 2 or so) that
is not available to the public (ie, internet), they would be better off.
i would be that with the lazy/ignorant setup of the dba/admin, that a 
DoS of postgresql is not the biggest problem, sure one of their redhat
boxes has gotten rooted already...

there is nothing that is more important for security and databases than
setting them up correctly, and their place on the network. the database
is the crown jewel that should never been seen or touched except for when
_absolutely_ needed, and that must be under heavy control. 

there is a bigger problem here than postgresql, it is the dumbass factor
of people that try to run a db, and are vuln to anything... and then complain
about it... i find this very annoying. 

know what you are doing, or stfu is my opinion

-chris

ps -> note this was not directed at any one person, but to the mass of 
      people that never should run a db, and go back to eating paint chips.
-----
disclaimer: i do not speak on behalf of devis (devis.com). i speak
            on my own behalf. 
-----

</rant-mode>


Lamar Owen writes:
 > On Monday 26 August 2002 10:46 am, Sir Mordred The Traitor wrote:
 > > Conditions: entry in a pg_hba.conf file that matches attacker's host.
 > > Risk: average
 > 
 > > --[ Solution
 > >
 > > Disable network access for untrusted users.
 > 
 > TCP/IP access must be enabled as well.  TCP/IP accessibility is OFF by 
 > default.
 > 
 > I for one thought that it was normal operating procedure to only allow access 
 > to trusted machines; maybe I'm odd in that regard.
 > 
 > Hey, if I can connect to postmaster I can DoS it quite easily, but flooding it 
 > with connection requests.....
 > 
 > But, if we can thwart this, all the better.
 > -- 
 > Lamar Owen
 > WGCR Internet Radio
 > 1 Peter 4:11
 > 
 > ---------------------------(end of broadcast)---------------------------
 > TIP 3: if posting/reading through Usenet, please send an appropriate
 > subscribe-nomail command to majordomo@postgresql.org so that your
 > message can get through to the mailing list cleanly

-- 
Chris Humphries
Development InfoStructure
540.366.9809 

Mon, 26 Aug 2002 11:25:35 -0500
Chris Humphries <chumphries@devis.com>
Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
Tom Lane wrote:
> Sir Mordred The Traitor <mordred@s-mail.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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 26 Aug 2002 12:59:08 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
On Monday 26 August 2002 12:59 pm, Bruce Momjian wrote:
> Tom Lane wrote:
> > 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...

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

The pseudo-security-alert format used isn't terribly palatable here, IMHO.  On 
BugTraq it might fly -- but not here.  A simple 'Hey guys, I found a possible 
problem when.....' without the big-sounding fluff would sit better with me, 
at least.  The substance of the message is perhaps valuable -- but the 
wrapper distracts from the substance.

And dealing with a real name would be nice, IMHO.  Otherwise we may end up 
with 'SMtT' as the nickname -- Hmmm, 'SMitTy' perhaps?  :-)  Reminds me of 
'Uncle George' who did quite a bit for the Alpha port and then disappeared.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Mon, 26 Aug 2002 13:50:09 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
Lamar Owen wrote:
> And dealing with a real name would be nice, IMHO.  Otherwise we may end up 
> with 'SMtT' as the nickname -- Hmmm, 'SMitTy' perhaps?  :-)  Reminds me of 
> 'Uncle George' who did quite a bit for the Alpha port and then disappeared.

Funny you mention that.  Now knowing someone's name is troubling, but I
am not sure why.

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

Mon, 26 Aug 2002 14:14:58 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
pgman@candle.pha.pa.us (Bruce Momjian) wrote 

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


oh woe is he the man who does not use rlimits, or perhaps, concurrency 
limits?

it seems this is nothing new, all network available services are subject to 
dos or ddos attacks... and if you dont setup limits on your machine, then 
other things can be affected... inetd, bind, sendmail, finger, <insert 
favorite network accessible program here>, etc...

I do agree that pgsql should not just arbitrarily allocate memory like 
this, as defensive programming, but I cannot agree that this is a bug or 
problem in pgsql per se.

As a side note, if someone wanted to shift the discussion to allowing 
concurrency limits in pgsql, how would/could this fit into the context of 
another thread where it was discussed to be able to always allow certain 
users to login...

Mon, 26 Aug 2002 18:28:55 +0000 (UTC)
ngpg@grymmjack.com
Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL