|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: DO NOT USE THAT PATCH (Re: IP firewalling bugs)
der Mouse (mouse
Collatz.McRCIM.McGill.EDU)Wed, 23 Aug 1995 15:59:42 -0400
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Tom Fitzgerald: "Re: DO NOT USE THAT PATCH (Re: IP firewalling bugs)"
- Previous message: Darren Reed: "DO NOT USE THAT PATCH (Re: IP firewalling bugs)"
- Maybe in reply to: Darren Reed: "DO NOT USE THAT PATCH (Re: IP firewalling bugs)"
- Next in thread: Tom Fitzgerald: "Re: DO NOT USE THAT PATCH (Re: IP firewalling bugs)"
>> Send an IP fragment 0 acceptable to the firewall
>> Send an IP fragment at offset 8 to rewrite most of the header
>> and all the data
> that isn't the main bug. sigh
Seems to me that there's no reason to use the "new" data rather than
the "old" data when a new fragment arrives that overlaps
already-collected data. They're supposed to be the same; any
difference indicates that at least one of them is definitely corrupted
in a way that beat the checksum, or else you're under attack. In
either case, dropping both the incoming packet and the collected
fragments is probably the best response, seems to me. If you don't
want to compare the bytes, then just make sure old data takes
precedence over new. (But comparing the bytes when there's overlap is
probably cheap enough to do; the only way it will happen in normal use
is when a fragmented datagram is retransmitted.)
der Mouse
mouse
collatz.mcrcim.mcgill.edu
- Next message: Tom Fitzgerald: "Re: DO NOT USE THAT PATCH (Re: IP firewalling bugs)"
- Previous message: Darren Reed: "DO NOT USE THAT PATCH (Re: IP firewalling bugs)"
- Maybe in reply to: Darren Reed: "DO NOT USE THAT PATCH (Re: IP firewalling bugs)"
- Next in thread: Tom Fitzgerald: "Re: DO NOT USE THAT PATCH (Re: IP firewalling bugs)"