Re: LuaSocket: No way to protect against fuzzing attacks?

[HyperHacker <hyperhacker@...>]

On Tue, Oct 11, 2011 at 02:37, Peter Pimley <peter.pimley@gmail.com> wrote:
> Could you repeatedly call option 2 (up to newline) but with a timeout
> of zero?  It'll return the partial result, which you can buffer up
> until you get the actual end-of-line.
>
>

Hmm, according to the manual, receive() should return the partial
result after the error message, but I'm getting inconsistent results.
If I use *l, it always returns the full result, but *l strips the line
break character, so I can't tell if the line has actually ended. If I
use *a or a large number (e.g. 1024), it never returns any result. If
I use a small number (e.g. 16), it returns partial results only in
some cases. It looks as if the last n bytes never get returned - some
sort of bug?


On Tue, Oct 11, 2011 at 02:56, Sean Conner <sean@conman.org> wrote:
>  Unfortunately, the low level socket interface doesn't offer said methods
> either (at least under Unix; I have no idea how Windows handle sockets at
> the lower levels).  The three low level (read: this is what is ultimately
> called) functions to receive data from a socket are:
>
>        read    (int fd,void *buf,size_t count);
>        recv    (int fd,void *buf,size_t count,int flags);
>        recvfrom(int fd,void *buf,size_t count,int flags,struct sockaddr *addr,socklen_t *addrlen);
>
>  The first parameter is the socket connection, the next two describe the
> destination to read the data into and how much; flags modify what type of
> data to read and usually this paramater is 0 but could be, at least under
> Linux:
>
>        MSG_PEEK        read incoming data, but the data returns is still
>                        treated as unread
>        MSG_OOB         retreive out of band data.  Protocol specific.
>        MSG_WAITALL     wait for all the data specified to be returned
>
>  The last two parameters for recvfrom() fill in the remote address.
>
>  Your possible answers still have issues:
>
> 1) peeking into the buffer is still subject to denial of service attack.  As
> an attacker, all I need to do is:
>
>        while(1)
>        {
>          write(yourwebserver,"x",1);
>          sleep(1);
>        }
>
> And not only will you never see a line return, but I've tied up one
> connection for a *very* long time until you consider I've sent a "very long
> line".  Also, using the MSG_PEEK for this means memory is wasted in kernel
> space buffering and thus may be a bad thing, depending upon the operating
> system in question.
>

MSG_PEEK would do the trick nicely, and such "slow fuzzing" attacks
are trivially defeated by rejecting any requests that take too long to
fully receive. (If your connection is slow enough that even a simple
HTTP request takes so long, you're probably not going to receive the
reply any time soon either...)

-- 
Sent from my toaster.