Hello to the list and RA guard evasion technique

[Janos Mohacsi]

On 6/2/11 11:34, Marc Heuse wrote:
> Am 01.06.2011 06:26, schrieb Fernando Gont:
>> On 05/29/2011 08:58 AM, Steinar H. Gunderson wrote:
>>> Den 29. mai 2011 13:53 skrev Eric Vyncke (evyncke) <evyncke at cisco.com> følgende:
>>>> But, you obviously have found a work-around around the work-around: overlapping fragments. Especially if hosts accept it... (which is weird BTW but what can we do?).
>>> An open question is whether one should treat this as a bug in the end
>>> systems. Shouldn't packets with overlapping fragments just be treated
>>> as malformed and dropped? Or would checking for this have a
>>> significant performance cost?
>> As far as the current specs are concerned, overlapping fragments are not
>> allowed, and hosts received them should discard them.
> I checked all major OS on this one this week.
> All of them (linux, osx, freebsd, openbsd, windows, solaris, qnx) accept
> overlapping fragments.
After checking the source code of FreeBSD 8.2. It seems to me that
FreeBSD 8.2 is dealing almost correctly the overlapping fragments. I
suspect, the same holds for all the KAME based implementation (FreeBSD,
NetBSD, OpenBSD and Mac OS X). FreeBSD 8.2 kernel keeps the fragments
arriving earlier, and drops the fragments arriving later. In this case
the attack vector could be, if the attacker can send similar segment
earlier to the receiver than the real sender. So my recommendation would
be to comment back the logging in the kernel code (Commented as /*
suppress the noisy log */). This way the administrator of the
destination machine could identify, if their machine was target of
overlapping fragment reassembly attack…

I can push this in FreeBSD to get back the commented part of kernel code.

Best Regards,
Janos Mohacsi



>
> And there is a simple reason for that - there are a lot of tcp/ip
> implementations in the world that are broken. if you harden your stack,
> it means that you prevent communication to some system types. thats why
> all the vendors allow overlapping fragments among other things.
>
> but there should be at least a sysctl setting to enable dropping of
> overlapping fragments.
>
> But until then (and/or the droppage of ND/RA with extension headers) it
> must be clearly communicated that RA Guard is an effective measure only
> for accidental RAs, not for malicious ones.
> pointing fingers and saying "if the OS guys would implement rfc a, b and
> c" is not a good excuse why your $$$ security mechanism is not working.
>
> Greets,
> Marc
>
> --
> Marc Heuse
> Mobil: +49 177 9611560
> Fax: +49 30 37309726
> www.mh-sec.de
>
> Marc Heuse - IT-Security Consulting
> Winsstr. 68
> 10405 Berlin
>
> Ust.-Ident.-Nr.: DE244222388
> PGP: FEDD 5B50 C087 F8DF 5CB9  876F 7FDD E533 BF4F 891A