Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL - Mailing list pgsql-hackers

From Þórhallur Hálfdánarson
Subject Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
Date
Msg-id 20020826154212.U4059@tol.li
Whole thread Raw
In response to Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL  (Sir Mordred The Traitor <mordred@s-mail.com>)
Responses Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
List pgsql-hackers
-*- Sir Mordred The Traitor <mordred@s-mail.com> [ 2002-08-26 15:32 ]:
> >Hey, if I can connect to postmaster I can DoS it quite easily, but
> flooding it
> >with connection requests.....
> 
> Hm, that's true of course, but now i will do this with a couple of
> connections.
> Lets say, bot on a owned machine, connects to a database, 
> send a crafted packet,
> postgresql will allocate a huge amount of memory, and will be 
> happy to read anything it recvs from my bot.

Speaking of which.

If I understand correctly, a new backend is forked and the connection dispatched to that specific backend, once access
hasbeen granted (with means of user/pass authentication, ident or whatever).
 

Is there any check for connection to the postmaster that have not been dispatched to a new backend after X bytes (or
seconds?),to free resources (would that make any sense? :)
 

And another (perhaps silly) thought: Currently, if the authentication process is exploited, it would kill the
postmaster,resulting in a total crash of the whole database system.  Would it be beneficial to split the connection
handling/authorizationprocess to a seperate process, and if that process dies, the postmaster would simply start a new
one,there for not affecting any other backends that are running (for authorized users) ? Or am I way of track? :)
 


-- 
Regards,
Tolli
tolli@tol.li


pgsql-hackers by date:

Previous
From: Sir Mordred The Traitor
Date:
Subject: Re: btw
Next
From: Bruce Momjian
Date:
Subject: Re: TODO Done. Superuser backend slot reservations