lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
From: John.Airey at rnib.org.uk (John.Airey@...b.org.uk)
Subject: A new TCP/IP blind data injection technique
	?

> -----Original Message-----
> From: Michael Gale [mailto:michael@...esuperman.com]
> Sent: 15 December 2003 18:47
> To: Michal Zalewski
> Cc: full-disclosure@...ts.netsys.com
> Subject: Re: [Full-Disclosure] A new TCP/IP blind data injection
> technique?
> 
> 
> Hello,
> 
> 	I misunderstood ... from my knowledge the BorderWare 
> Firewall drops all
> fragmented packets and there is NO option to change this.
> 
> You can change the MTU size on the interfaces which should 
> allow you to
> correct any problems.
> 
> I am not sure about Cisco Pix :(
> 
> I have never found a problem with any services running behind the
> firewall or connecting to any services out side the firewall with the
> settings to drop all fragmented packets.
> 
> Now according to your injection vulnerability even if a firewall
> recreated all the packets before sending it to the end client the
> vulnerability could still occur unless the firewall did some 
> strong form
> of application level filtering and then some how found out that one
> piece of data did not belong.
> 
> So with all this said how is it unwise not to drop fragmented packets
> and not necessary ?
> 
> Michael.
> 
> 
The Cisco Pix has an IP fragment database. 

According to Cisco Documentation "The fragment command provides additional
management of packet fragmentation and improves compatibility with NFS." 

The command "show fragment" gives output like this:

Interface: outside
    Size: 200, Chain: 24, Timeout: 5
    Queue: 0, Assemble: 0, Fail: 0, Overflow: 0
Interface: inside
    Size: 200, Chain: 24, Timeout: 5
    Queue: 0, Assemble: 0, Fail: 0, Overflow: 0

Dropping fragments is only a bad idea if you also drop all ICMP packets. The
bare minimum is to allow in "echo-reply", "source-quench", "unreachable" and
"time-exceeded", although you could probably survive without the first one
if you don't mind being unable to check connectivity using ping.

Basically, receiving fragments may be a sign that your MTU setting is too
small. The ICMP packets that you would also receive in this instance can be
used by the TCP/IP stacks to  adjust the packet size at each end. Having
never been able to use NFS across a Pix Firewall, I have no idea how these
settings help with NFS.

- 
John Airey, BSc (Jt Hons), CNA, RHCE
Internet systems support officer, ITCSD, Royal National Institute of the
Blind,
Bakewell Road, Peterborough PE2 6XU,
Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 John.Airey@...b.org.uk 

There is more historical evidence for the existence of Jesus Christ than for
either Henry VIII or Julius Caesar.

- 
DISCLAIMER: 

NOTICE: The information contained in this email and any attachments is 
confidential and may be privileged. If you are not the intended 
recipient you should not use, disclose, distribute or copy any of the 
content of it or of any attachment; you are requested to notify the 
sender immediately of your receipt of the email and then to delete it 
and any attachments from your system. 

RNIB endeavours to ensure that emails and any attachments generated by 
its staff are free from viruses or other contaminants. However, it 
cannot accept any responsibility for any  such which are transmitted.
We therefore recommend you scan all attachments. 

Please note that the statements and views expressed in this email and 
any attachments are those of the author and do not necessarily represent 
those of RNIB. 

RNIB Registered Charity Number: 226227 

Website: http://www.rnib.org.uk 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ