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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]) > > ________________________________________________________________________ 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
