headers
Yasuyuki Kozakai | 1 Jul 2004 08:17
Picon

[PATCH]: the latest nf_conntrack


Hi, all,

This is pom-ng style patch which enables layer 3 independent connection
tracking (nf_conntrack). In nf_conntrack, core module is generalized so that
other layer 3 protocols are easily implemented. In now, IPv4, IPv6, TCP, UDP,
ICMP, ICMPv6 and FTP can be tracked.

In this version, nf_conntrack can handle fragmented IPv6 packets as follows.

	- Fragmented IPv6 packets(fragments) belong to connection which tuple
	  is represented by IPv6 addresses, ID in Fragmented Header, and so on.

	- nf_conntrack_proto_frag6.c queues fragments, and reassembles
	  clone of them when all fragments are gathered.

	- The reassembled packet is tracked by nf_conntrack. In the result, 
	  the reassembled packet is binded with the true layer 4 protocol
	  connection.

		fragments -> frag conntrack -> reassembled packet

		-> tcp conntrack

	- nf_conntrack_l3proto_ipv6.c passes the original fragments to the next
	  network processing. This avoid sending "packet too big" ICMPv6 error
	  due to try to forward reassembled big packets.

	- In the result, other modules (e.g. ip6tables.ko) can refer
	  the reassembled packet from fragments.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jozsef Kadlecsik | 1 Jul 2004 10:59
Picon

Re: Remote DoS vulnerability in Linux kernel 2.6.x (fwd)

Hi,

On Wed, 30 Jun 2004, James Morris wrote:

> ---------- Forwarded message ----------
> Date: Wed, 30 Jun 2004 12:57:17 +0200
> From: Adam Osuchowski <adwol <at> polsl.gliwice.pl>
> To: bugtraq <at> securityfocus.com
> Subject: Remote DoS vulnerability in Linux kernel 2.6.x
>
> 1. Overview
> -----------
>
> There is a remotely exploitable bug in all Linux kernel 2.6 series due to
> using incorrect variable type. Vulnerability is connected to netfilter
> subsystem and may cause DoS. It's disclosed only when using iptables with
> rules matching TCP options (i.e.  --tcp-option). There is no difference
> what action is taking up by matching rule.
>
> Vulnerability was detected on i386 architecture. The other ones weren't tested
> but it seems to be vulnerable too.

I have added the patch to the patch-o-matic-ng cvs, so one can apply it
easily using our repository.

Best regards,
Jozsef
-
E-mail  : kadlec <at> blackhole.kfki.hu, kadlec <at> sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harald Welte | 1 Jul 2004 11:10
Favicon

Re: Remote DoS vulnerability in Linux kernel 2.6.x (fwd)

On Wed, Jun 30, 2004 at 02:42:30PM -0700, David S. Miller wrote:

> This bug only came up because up the huge change Rusty and Harald did
> to make these modules not access the SKB header data directly, and
> instead to use local on-stack copies and skb_copy_bits().

A change we had to make in order not to assume fully linearized packet
including the tcp header.

I suppose the trivial fix has already been pushed upstream...

Very unfortunate that vendors weren't informed in advance :(

--

-- 
- Harald Welte <laforge <at> netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie
Permalink | Reply | 0 comments |
headers
Mikkel Christiansen | 1 Jul 2004 14:31
Picon
Picon

question: hook/unhook

Hi

We're working with an efficient packet filter
(see http://www.cs.auc.dk/~mixxel/cf). 

In the implementation we would like to block
all arriving packets while moving from one filter
to another. I.e. something like:

block_all_packets();
nf_unregister_hook(some_nf_hook_ops_struct);
nf_register_hook(some_other_nf_hook_ops_struct);
unblock_all_packets();

Does netfilter provide functions for doing this or can anyone
recommend a proper way to do this?

Cheers & thanks
    Mikkel
Permalink | Reply | 0 comments |
headers
Atanu.Mondal | 2 Jul 2004 11:20

Calling multiple times ip_nat_mangle_tcp_packet()

Hi,
I am mangling SIP Message Header and data and for this I am calling
ip_nat_mangle_tcp_packet() funtion for
each line which need to adjust its IP Address.. The problem I am facing
is with TCP seq numbering..
The ip_nat_resize_packet() function takes care of the seq numbering
inside ip_nat_mangle_tcp_packet() but
it takes care of the adjustment for only the 1st call.. Any subsequent
call to ip_nat_mangle_tcp_packet 
does not adjust the offset_before and offset_after parameters and the it
remains what it was in the first
call. 
In the return direction the ack and seq no is adjusted as per the offset
set in the 1st call..which is wrong.

Can somebody help me out in understanding how to do it... Or do I need
to writeout my  own function. ???

Atanu
Permalink | Reply | 1 comment |
headers
Lukas Ruf | 2 Jul 2004 15:51

iptables 1.2.11 and kernel 2.6.7


Today, I realized two problems: with kernel 2.6.7 when builing iptables
1.2.11 for ipv4 and ipv6:

In the files:
    include/libiptc/libip6tc.h
    include/libiptc/libiptc.h

1. : __user is not known as found in both
    include/linux/netfilter_ipv6/ip6_tables.h:261
    include/linux/netfilter_ipv4/ip_tables.h:255

2. : DECLARE_MUTEX() is not known outside of the kernel for both
    DECLARE_MUTEX(ip6t_mutex) and DECLARE_MUTEX(ipt_mutex)
    as defined in the same files:
    include/linux/netfilter_ipv6/ip6_tables.h
    include/linux/netfilter_ipv4/ip_tables.h

I fixed the problems by #define'ing __user ifndef before in the
libiptc files, and moving DECLARE_MUTEX() into the #ifdef __KERNEL__
statement in the ip_tables.h files.

Has anyone experienced the same problems?  I could not find any answer
in the archive.

If anyone would be interested in patch, please indicate and I will
create one.

Thanks.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tobias DiPasquale | 2 Jul 2004 16:05
Picon

Re: iptables 1.2.11 and kernel 2.6.7

On Fri, 2 Jul 2004 15:51:47 +0200, Lukas Ruf <ruf <at> rawip.org> wrote:
> Has anyone experienced the same problems?  I could not find any answer
> in the archive.
> 
> If anyone would be interested in patch, please indicate and I will
> create one.

The patch in the following post fixes (at least) the DECLARE_MUTEX()
problem for me. The issue was that the system headers were being used
and not the headers in the kernel source tree:

http://lists.netfilter.org/pipermail/netfilter/2004-June/053639.html

However, the build process then fails during
extensions/libipt_recent.c in the following manner:

fearless:~/iptables-1.2.11> make KERNEL_DIR=/usr/src/linux
Extensions found: IPv4:recent IPv6:ah IPv6:esp IPv6:frag
IPv6:ipv6header IPv6:hbh IPv6:dst IPv6:rt
gcc -O2 -Wall -Wunused -Iinclude/ -DIPTABLES_VERSION=\"1.2.11\"  -fPIC
-o extensions/libipt_ah_sh.o -c extensions/libipt_ah.c
ld -shared  -o extensions/libipt_ah.so extensions/libipt_ah_sh.o
gcc -O2 -Wall -Wunused -Iinclude/ -DIPTABLES_VERSION=\"1.2.11\"  -fPIC
-o extensions/libipt_connlimit_sh.o -c extensions/libipt_connlimit.c
ld -shared  -o extensions/libipt_connlimit.so extensions/libipt_connlimit_sh.o
gcc -O2 -Wall -Wunused -Iinclude/ -DIPTABLES_VERSION=\"1.2.11\"  -fPIC
-o extensions/libipt_connmark_sh.o -c extensions/libipt_connmark.c
ld -shared  -o extensions/libipt_connmark.so extensions/libipt_connmark_sh.o
gcc -O2 -Wall -Wunused -Iinclude/ -DIPTABLES_VERSION=\"1.2.11\"  -fPIC
-o extensions/libipt_conntrack_sh.o -c extensions/libipt_conntrack.c
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lukas Ruf | 2 Jul 2004 16:22

Re: iptables 1.2.11 and kernel 2.6.7

> Tobias DiPasquale <codeslinger <at> gmail.com> [2004-07-02 16:07]:
>
> On Fri, 2 Jul 2004 15:51:47 +0200, Lukas Ruf <ruf <at> rawip.org> wrote:
> > Has anyone experienced the same problems?  I could not find any answer
> > in the archive.
> >
> > If anyone would be interested in patch, please indicate and I will
> > create one.
>
> The patch in the following post fixes (at least) the DECLARE_MUTEX()
> problem for me. The issue was that the system headers were being used
> and not the headers in the kernel source tree:
>
> http://lists.netfilter.org/pipermail/netfilter/2004-June/053639.html
>
> However, the build process then fails during
> extensions/libipt_recent.c in the following manner:
>
> fearless:~/iptables-1.2.11> make KERNEL_DIR=/usr/src/linux
> Extensions found: IPv4:recent IPv6:ah IPv6:esp IPv6:frag
> IPv6:ipv6header IPv6:hbh IPv6:dst IPv6:rt
> gcc -O2 -Wall -Wunused -Iinclude/ -DIPTABLES_VERSION=\"1.2.11\"  -fPIC
> -o extensions/libipt_ah_sh.o -c extensions/libipt_ah.c
> ld -shared  -o extensions/libipt_ah.so extensions/libipt_ah_sh.o
[...]
> gcc -O2 -Wall -Wunused -Iinclude/ -DIPTABLES_VERSION=\"1.2.11\"  -fPIC
> -o extensions/libipt_recent_sh.o -c extensions/libipt_recent.c
> extensions/libipt_recent.c:9:45: linux/netfilter_ipv4/ipt_recent.h: No
> such file or directory
> extensions/libipt_recent.c: In function `init':
(Continue reading)

Permalink | Reply | 0 comments |
headers
Muhammad R. Sami | 2 Jul 2004 20:19
Picon

RE: information

I got the libipq/QUEUE part working but the problem is that it only works
for the first time. For example, if I want to drop all icmp packets, it
will, but if I change the nfmark from drop to accept and then recompile my
libipq program, it does not work and the dropping policy is maintained. Same
for the other way around. 
Regards,

Muhammad R. Sami 
Research Assistant, 
Computer Engineering Department 
P.O.Box 354 
King Fahd University of Petroleum & Minerals 
Dhahran 31261 
Saudi Arabia. 
Tel: +96638601423 
Cell: +96657982951 
www.ccse.kfupm.edu.sa/sami

-----Original Message-----
From: Babar Qaisrani [mailto:baqb03 <at> student.bth.se] 
Sent: Friday, July 02, 2004 6:03 PM
To: Muhammad R. Sami
Subject: RE: information

well
install the missing module !

most probably either ui have to recompile the Kernel or install module
....depending on ur Linux distro
im using Debian
(Continue reading)

Permalink | Reply | 5 comments |
headers
Henrik Nordstrom | 3 Jul 2004 03:08

RE: information

On Fri, 2 Jul 2004, Muhammad R. Sami wrote:

> I got the libipq/QUEUE part working but the problem is that it only works
> for the first time. For example, if I want to drop all icmp packets, it
> will, but if I change the nfmark from drop to accept and then recompile my
> libipq program, it does not work and the dropping policy is maintained. Same
> for the other way around. 

Please explain what you refer to by "change the nfmark from drop to 
accept".

nfmark does not have a concept of drop/accept, just value.

Is you perhaps speaking about the verdict set by the userspace telling if
the packet should be accepted (passed on to next hook) or dropped? This is
just a verdict and not related to nfmark.

Regards
Henrik
Permalink | Reply | 4 comments |

Gmane