what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

ipchains_patch.txt

ipchains_patch.txt
Posted Sep 21, 1999

Linux 2.2.10 ipchains vulnerability description and patch

tags | exploit
systems | linux
SHA-256 | 3309c11da64edcfdd1bb0c2e6b430290973e704d510d6468068d6a3190979683

ipchains_patch.txt

Change Mirror Download
Subject:      Linux 2.2.10 ipchains Advisory
To: BUGTRAQ@SECURITYFOCUS.COM


Linux ipchains Firewall Vulnerability
data protect GmbH - Advisory #2
July 27, 1999


Authors: Thomas Lopatic <tl@dataprotect.com>
John McDonald <jm@dataprotect.com>


Overview
--------


data protect has discovered a potential vulnerability in the Linux ipchains
firewall implementation. In certain situations, it is possible for an
attacker to bypass the packet filter when communicating with machines that
allow incoming packets to specific ports. This attack is a variation
of previously discussed fragmentation attacks, where the attacker uses
fragments to rewrite parts of the TCP or UDP protocol header. In this case
port information is rewritten in order to gain access to ports that should
be blocked by the firewall.


Included in this advisory is a patch to the 2.2.10 Linux kernel that corrects
this vulnerability, and a pointer to example code that demonstrates the
problem.


Problem Description
-------------------


The Linux ipchains firewall code has special provisions for IP fragments that
do not contain enough information for transport protocol header analysis.
Fragments that start at offset 0, and are not long enough to provide complete
transport header information are treated like fragments with an offset > 0
(> 1 in the TCP case). This is the relevant code from ip_fw.c:


if (offset == 0) {
unsigned int size_req;
switch (ip->protocol) {
case IPPROTO_TCP:
/* Don't care about things past flags word */
size_req = 16;
break;


case IPPROTO_UDP:
case IPPROTO_ICMP:
size_req = 8;
break;


default:
size_req = 0;
}
offset = (ntohs(ip->tot_len) < (ip->ihl<<2)+size_req);
}


As mentioned above, fragments with an offset of 0, that are too short to
provide a full transport protocol header, are treated like non-first fragments.
This allows an attacker to perform the following port rewriting attack:


1. Attacker sends a fragment, with offset 0, a set IP_MF bit, and a full
transport protocol header which meets the packet filter and is passed to
the victim machine.


2. Attacker sends a fragment, with offset 0, a set IP_MF bit, and a length of
4 bytes. This contains the (blocked) ports that the attacker wishes to
access on the victim machine. This fragment will be accepted by the
firewall and overlap - in the victim machine's reassembly chain - the port
information contained in the fragment sent in step 1.


3. Attacker sends a fragment with a cleared IP_MF bit, starting where the first
fragment left off, that completes the set of fragments.


Depending on the defragmentation strategy of the victim machine's operating
system, it might be necessary to swap steps 1 and 2.


It is important to note that there are two conditions that must be met for a
particular ipchains packet filter to be vulnerable:


1. The packet filter must not be configured with the Linux kernel option
CONFIG_IP_ALWAYS_DEFRAG. If the packet filter reassembles the fragments
before doing the firewall checks, then this attack will fail.


2. The packet filter must have a rule to allow non-first fragments to pass.
The Linux ipchains how-to suggests that either an administrator selects
CONFIG_IP_ALWAYS_DEFRAG, or implements such a rule. This rule was considered
to be safe because fragments with an offset of 1 are blocked by the packet
filter, which prevents attacks based on rewriting the TCP flags.


Fix Information
---------------


The following Linux kernel patch (against version 2.2.10) will close this
vulnerability by blocking packets that could be used to rewrite header
information in this fashion.


It is also possible to reconfigure the ipchains machine to always defragment
packets, or to remove any rule which passes non-first IP fragments through the
firewall ("-f" option of the "ipchains" command). The latter, however, might
introduce incompatibilities, e.g. with applications that transmit large UDP
datagrams across the firewall and hence cause IP fragmentation.


*** linux.old/net/ipv4/ip_fw.c Wed Jun 9 05:33:07 1999
--- linux/net/ipv4/ip_fw.c Fri Jul 23 19:20:45 1999
***************
*** 37,42 ****
--- 37,45 ----
* 19-May-1999: Star Wars: The Phantom Menace opened. Rule num
* printed in log (modified from Michael Hasenstein's patch).
* Added SYN in log message. --RR
+ * 23-Jul-1999: Fixed small fragment security exposure opened on 15-May-1998.
+ * John McDonald <jm@dataprotect.com>
+ * Thomas Lopatic <tl@dataprotect.com>
*/


/*
***************
*** 644,650 ****
default:
size_req = 0;
}
! offset = (ntohs(ip->tot_len) < (ip->ihl<<2)+size_req);
}


src = ip->saddr;
--- 647,666 ----
default:
size_req = 0;
}
!
! /* If it is a truncated first fragment then it can be
! * used to rewrite port information, and thus should
! * be blocked.
! */
!
! if (ntohs(ip->tot_len) < (ip->ihl<<2)+size_req)
! {
! if (!testing && net_ratelimit()) {
! printk("Suspect short first fragment.\n");
! dump_packet(ip,rif,NULL,NULL,0,0,0,0);
! }
! return FW_BLOCK;
! }
}


src = ip->saddr;


Demonstration Code
------------------


fragrouter, a component of Nidsbench, has been updated to perform this attack
transparently. This is an excellent open source tool for testing intrusion
detection systems and packet filters provided by Anzen Computing. The version
of fragrouter that performs this attack should be available shortly, at
http://www.anzen.com/research/nidsbench/.


Additional Information
----------------------


data protect would like to thank Dug Song <dugsong@anzen.com> for his help in
implementing this attack.


For information regarding this advisory, please contact
Thomas Lopatic <tl@dataprotect.com> or John McDonald <jm@dataprotect.com>.


The contents of this advisory are Copyright (C) 1999 data protect GmbH,
and may be distributed freely provided that no fee is charged for
distribution, and that proper credit is given.
Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close