Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
От | Þórhallur Hálfdánarson |
---|---|
Тема | Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL |
Дата | |
Msg-id | 20020826154212.U4059@tol.li обсуждение исходный текст |
Ответ на | Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL (Sir Mordred The Traitor <mordred@s-mail.com>) |
Ответы |
Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
|
Список | 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 по дате отправления: