From: | Þórhallur Hálfdánarson <tolli(at)tol(dot)li> |
---|---|
To: | Sir Mordred The Traitor <mordred(at)s-mail(dot)com> |
Cc: | lamar(dot)owen(at)wgcr(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL |
Date: | 2002-08-26 15:42:12 |
Message-ID: | 20020826154212.U4059@tol.li |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
-*- Sir Mordred The Traitor <mordred(at)s-mail(dot)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 has been 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/authorization process 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(at)tol(dot)li
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-08-26 16:16:32 | Re: [HACKERS] TODO Done. Superuser backend slot reservations |
Previous Message | Sir Mordred The Traitor | 2002-08-26 15:34:39 | Re: btw |