iptables "recent" match broken

Bug #365539 reported by Roman Hoog Antink
4
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

Binary package hint: linux-image-2.6.28-11-server

Note: This bug is security relevant, since it breaks the expected iptables behaviour and might lead to accepted packets that should be dropped. (I didn't hit the checkbox for "contact security team", since Jaunty is still beta.)

In Jaunty Beta the iptables rule
    iptables -A INPUT -p icmp -s <someIP> -m recent --rcheck --seconds 1800 --name "rtest" --rsource -j DROP
should drop such ICMP packets, after adding someIP to the recent list by
    echo +someIP >/proc/net/xt_recent/rtest

However, ICMP ping replies from someIP are still accepted, as if the recent list was empty.

Negating the rule as follows leads to the wrong behaviour too:
    iptables -A INPUT -p icmp -s <someIP> -m recent ! --rcheck --seconds 1800 --name "rtest" --rsource -j DROP
Now packets are dropped, regardless whether the recent list contains someIP.

Furthermore, removing entries from the recent list fails. After
    echo -someIP >/proc/net/xt_recent/rtest
someIP remains in the list. You can even cause duplicate list entries with successive
    echo +someIP >/proc/net/xt_recent/rtest
See cat /proc/net/xt_recent/rtest for the wrong result.

I guess, both misbehaviours are caused in the kernel module xt_recent.ko. So the bug is in the linux-image package.

uname -a: Linux ubuntu 2.6.28-11-server #42-Ubuntu SMP Fri Apr 17 02:48:10 UTC 2009 i686 GNU/Linux
apt-cache policy linux-image-2.6.28-11-server: 2.6.28-11.42
iptables: 1.4.1.1-4ubuntu3
hardware: vmware (dual CPU)

On Intrepid (kernel 2.6.27), the recent match works fine. But there the recent match is the elder code, creating the proc files in /proc/net/ipt_recent.

Revision history for this message
Roman Hoog Antink (rha-ubuntu) wrote :

This morning (after a good night's rest) I refined my tests and came to this pattern:

with Kernel 2.6.28: /proc/net/xt_recent/* have no effect on iptables rules. I did not test /proc/net/ipt_recent/* (requires Kernel option CONFIG_NETFILTER_XT_MATCH_RECENT_PROC_COMPAT which is not set in Jaunty)

with Kernel 2.6.29:
/proc/net/xt_recent/* works fine in any way, but /proc/net/ipt_recent/* has no effect on iptables rules.

Revision history for this message
Roman Hoog Antink (rha-ubuntu) wrote :

There is a patch for kernel 2.6.29 that fixes the compat path issue (thanks to Jan Engelhardt and the Netfilter team).

Revision history for this message
Amit Kucheria (amitk) wrote :

Roman, has this patch been sent upstream? Could you provide me with a pointer? If so, I could cherry-pick that patch into 9.04

Changed in linux (Ubuntu):
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
Roman Hoog Antink (rha-ubuntu) wrote :

Please ask Jan Engelhardt (jengelh at medozas de) whether there is a patch for 2.6.28. Since it perfectly works with kernel 2.6.29, a diff of xt_recent.c might reveal the required changes (see attachment).
I think, the struct to union transition is a good point to start.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Based on Roman's comment that a patch was merged for 2.6.29, I've confirmed this patch is indeed in the latest Karmic Alpha kernel (see commit id below). I'm marking this Fix Released for Karmic which will target a 2.6.31 kernel and has most recently rebased with 2.6.31-rc2 from upstream. Images are available for testing at http://cdimage.ubuntu.com/daily-live/current/ . Thanks.

ogasawara@emiko:~/ubuntu-karmic$ git log 37e55cf0ceb8803256bf69a3e45bd668bf90b76f
commit 37e55cf0ceb8803256bf69a3e45bd668bf90b76f
Author: Jan Engelhardt <email address hidden>
Date: Fri Apr 24 17:05:21 2009 +0200

    netfilter: xt_recent: fix stack overread in compat code

    Related-to: commit 325fb5b4d26038cba665dd0d8ee09555321061f0

    The compat path suffers from a similar problem. It only uses a __be32
    when all of the recent code uses, and expects, an nf_inet_addr
    everywhere. As a result, addresses stored by xt_recents were
    filled with whatever other stuff was on the stack following the be32.

    Signed-off-by: Jan Engelhardt <email address hidden>

    With a minor compile fix from Roman.

    Reported-and-tested-by: Roman Hoog Antink <email address hidden>
    Signed-off-by: Patrick McHardy <email address hidden>

Changed in linux (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.