The point is really simple.
Allocate a huge chunk of memory (no sense to cause out of memory error,
as palloc will bail is a requested size > 1 gb). The postgres will be ready
to suck your input,
via pg_getbytes(), now in a loop send junk to postgresql.
Of course you can fork a number of processes to improve your effect.
The issues is that postgres allocate a chunk of memory and reads data,
using an
user's input, which has not completed authentication.
This is badly anyway.
Of course i tried, and wrote proggy for that,
but i can repeat, i dont want to provide it here.
>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
>
>---------------------------(end of broadcast)---------------------------
>TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
>
________________________________________________________________________
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
