lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
From: martin.macok at (Martin Mačok)
Subject: Re: SEARCH web attack (IP address spoofed?)

On Thu, Apr 01, 2004 at 03:07:10PM +0200, Martin Ma?ok wrote:

> Well, I'm not 100% sure what happens with eventual data sent in TCP
> SYN packet ...

I should clarify myself a bit (wondering if it is sane to do so).

It is "legitimate" to send data in TCP SYN packet but those will
not be delivered to application until the handshake is over (see
RFC793 Transmission Control Protocol, Section 3.4 Establishing
a connection). So, if the attacker cannot guess TCP ISN and does not
see the replies, she can't complete the handshake and such data won't
be delivered to application.

Another question is, if such data will be delivered to application at
all after the handshake is completed. Comments from
linux-2.4/net/ipv4/tcp_input.c:tcp_rcv_state_process() puts some light
on it:

[socket in TCP_LISTEN state, receiving SYN packet]

    /* Now we have several options: In theory there is 
     * nothing else in the frame. KA9Q has an option to 
     * send data with the syn, BSD accepts data with the
     * syn up to the [to be] advertised window and 
     * Solaris 2.1 gives you a protocol error. For now 
     * we just ignore it, that fits the spec precisely 
     * and avoids incompatibilities. It would be nice in
     * future to drop through and process the data.
     * Now that TTCP is starting to be used we ought to 
     * queue this data.
     * But, this leaves one open to an easy denial of
     * service attack, and SYN cookies can't defend
     * against this problem. So, we drop the data
     * in the interest of security over speed.

Martin Ma?ok
IT Security Consultant

Powered by blists - more mailing lists