[UNIX] IRC Connection Tracking Helper Module (Patch Available)
From: support@securiteam.comDate: 03/02/02
- Previous message: support@securiteam.com: "[UNIX] Cobalt RaQ Cross Site Scripting, Directory Traversal and DoS Vulnerabilities"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Date: Sat, 2 Mar 2002 19:26:08 +0100 (CET)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
IRC Connection Tracking Helper Module (Patch Available)
------------------------------------------------------------------------
SUMMARY
A security vulnerability in NetFilter has been found. The vulnerability
would allow an attacker utilizing the DCC CHAT/SEND protocol to open
otherwise blocked ports for inbound connections form an untrusted network
to the internal network.
DETAILS
Vulnerable systems:
All Linux kernel versions from 2.4.14 to 2.4.18-pre8
The NetFilter subsystem in Linux kernels >= 2.4.14 contains a connection
tracking helper module for the IRC DCC protocol. The purpose of this
module is to monitor outgoing DCC CHAT/SEND requests and issue so-called
'conntrack expectations' about the respective inbound DCC connections.
A bug in the implementation of this module causes the conntrack
expectation to be less precise than it should, this would result in
unwanted ports for inbound connections opened on the firewall.
The conntrack expectation is described by a tuple (layer 4 protocol,
source ip, source port, destination IP, destination port) and mask
indicating which parts of the tuple need to match with a new connection in
order to be fulfilled.
With IRC DCC, we can only tell the destination IP and port, thus we need
an expectation "expect related connection from any IP / any port to this
particular port number X at this particular IP address Y".
Due to the implementation bug, however, the mask was too wide. The
conntrack helper really says "expect related connection from any IP / any
port to this particular port X at ANY IP".
As a result, incoming connection requests are only matched on the
destination port number, and nothing else.
This does not always need to result in this unwanted incoming connection
request to be allowed. It always depends on the ruleset, since connection
tracking only decides on the state of a packet.
Implications:
The implications depend on the rule set, since connection tracking only
assigns state to packets. What to do with this state information is up to
the user.
However, a big number of installation seem to have a very permissive "-m
state --state RELATED -j ACCEPT" rule. In this case, as soon as somebody
from inside the private network issues an IRC DCC request, a single
connection from the outside network to the port number stated in the DCC
request on any (internal) IP address will be accepted.
Solution:
Update to a >= 2.4.18-pre9 kernel OR apply the following patch:
- --- linux-2.4.18-pre8-plain/net/ipv4/netfilter/ip_conntrack_irc.c Sat
Dec 22 18:52:16 2001
+++ linux-2.4.18-pre8-nfpom/net/ipv4/netfilter/ip_conntrack_irc.c Tue Feb
5 15:55:29 2002
@@ -1,8 +1,8 @@
- -/* IRC extension for IP connection tracking, Version 1.20
- - * (C) 2000-2001 by Harald Welte
+/* IRC extension for IP connection tracking, Version 1.21
+ * (C) 2000-2002 by Harald Welte
* based on RR's ip_conntrack_ftp.c
*
- - * ip_conntrack_irc.c,v 1.20 2001/12/06 07:42:10 laforge Exp
+ * ip_conntrack_irc.c,v 1.21 2002/02/05 14:49:26 laforge Exp
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -112,9 +112,9 @@
struct ip_ct_irc *info = &ct->help.ct_irc_info;
- - memset(&mask, 0, sizeof(struct ip_conntrack_tuple));
- - mask.dst.u.tcp.port = 0xFFFF;
- - mask.dst.protonum = 0xFFFF;
+ mask = ((struct ip_conntrack_tuple)
+ { { 0, { 0 } },
+ { 0xFFFFFFFF, { 0xFFFF }, 0xFFFF }});
DEBUGP("entered\n");
/* Can't track connections formed before we registered */
ADDITIONAL INFORMATION
The information has been provided by Jozsef Kadlecsik.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: support@securiteam.com: "[UNIX] Cobalt RaQ Cross Site Scripting, Directory Traversal and DoS Vulnerabilities"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
