known TCP vulnerability ??
Don Lewis
truckman at FreeBSD.org
Fri Feb 11 14:59:52 PST 2005
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 ;-)
More information about the freebsd-net
mailing list