known TCP vulnerability ??

Don Lewis truckman at
Sun Jul 3 00:35:59 GMT 2005

On 11 Feb, Andre Oppermann wrote:
> "Li, Qing" wrote:
>>         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) {

                 * 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 ;-)

freebsd-current at mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe at"

More information about the freebsd-net mailing list