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 по дате отправления:

Предыдущее
От: Sir Mordred The Traitor
Дата:
Сообщение: Re: btw
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: TODO Done. Superuser backend slot reservations