Re: known TCP vulnerability ??

On 11 Feb, Andre Oppermann wrote:
> "Li, Qing" wrote:
>> 
>>         http://www.kb.cert.org/vuls/id/464113
>> 
>>         http://www.linuxsecurity.com/content/view/104980/98/
>> 
>>         Ran the packet tests against FreeBSD 5.3 and 6-CURRENT and both
>>         respond to the SYN+FIN packets with SYN+ACK.
> 
> This is expected behaviour because of FreeBSD used to implement T/TCP
> according to RFC1644.  I haven't removed this part from TCP because
> I have a better reincarnation of T/TCP without the previous shortcomings
> almost ready which uses this again.
> 
> The CERT article describes how dumb firewalls with poor stateful
> inspection may get fooled by this and other flag combinations.
> All I can say is it's not our fault.  The SYN+FIN combination is
> described in RFC1644 and if the firewall gets it wrong...  Well,
> the real world sucks.

We won't try to accept a new connection of either RST or ACK bits are
set along with the SYN.

                /*
                 * If the state is LISTEN then ignore segment if it contains
                 * a RST.  If the segment contains an ACK then it is bad and
                 * send a RST.  If it does not contain a SYN then it is not
                 * interesting; drop it.
                 *
                 * If the state is SYN_RECEIVED (syncache) and seg contains
                 * an ACK, but not for our SYN/ACK, send a RST.  If the seg
                 * contains a RST, check the sequence number to see if it
                 * is a valid reset segment.
                 */
                if ((thflags & (TH_RST|TH_ACK|TH_SYN)) != TH_SYN) {
                        if ((thflags & (TH_RST|TH_ACK|TH_SYN)) == TH_ACK) {
                [snip]
                
                }

                /*
                 * Segment's flags are (SYN) or (SYN|FIN).
                 */


The FIN flag should be harmless if it accompanies a SYN, but if it makes
you feel more comfortable, you can compile your kernel with the
TCP_DROP_SYNFIN option which gives you a sysctl knob that controls
whether or not these packets get dropped.  Typically this is done to
confuse software that attempts to identify a remote host OS by seeing
how it responds to various packets.  You might find that enabling this
option makes a host running FreeBSD look like it is running Microsoft
Windows and invite a horde of attempts to exploit various Windows
vulnerabilities ;-)