OK, public apology time - I've taken a look at this again.
The urgent point is not an IP option (as I had understood), but a TCP
option. Hence, the 'IP Options' stuff in FW-1 hence doesn't apply and the
packets will get through.
For the record, however, FW-1 does drop all packets with IP header options
as none of these should be used nowadays (manual page 295).
Sorry for adding confusion.
Cheers,
Daniel
On Thu, 5 Jun 1997, Craig Brozefsky wrote:
> On Thu, 5 Jun 1997, Daniel Strawson wrote:
>
> > Hang on a moment.
> >
> > Let me put this in perspective.
> >
> > As I understand it, this problem results from sending packets with a
> > particular IP option set in the header. (Please confirm I'm right here
> > someone).
> >
> > Firewall _SHOULD_ drop all packets with IP options set. This would mean
> > that all Firewall-1 systems and systems behind Firewall-1 are impervious
> > to this attack. (something for Checkpoint to be proud of).
>
> Uhm, I don't have any RFCs or source code in front of me right now, but
> my understanding was that several options would need to get thru, OOB
> being one of them, as some applications make use of it, telnet for
> instance if I'm not mistake (tho I may be and invite correction).
>
> > Note that it is not as such a FW-1 insecurity - you cannot get FW-1 to
> > crash, you get the NT system that it is running on to crash, so it is not
> > an insecurity, but a claimed feature that doesn't work.
>
> Not how I would interpret it. I would consider this the responsibility
> of he FW vendor. They are responsible for the TCP/IP stack IMO. If they
> aren't replacing it, then they are assumign the OS vendor is competent,
> not something I would agree with.
>
> Craig Brozefsky craig @
onshore .
com
> onShore Inc. http://www.onshore.com/~craig
> Development Team p_priority=PFUN+(p_work/4)+(2*p_cash)
>
>
References:
|
|
