I have no credit on this whatsoever, I just though I'd forward it here FYI. regards ---------- Forwarded Message ---------- Subject: [ANNOUNCE] Security Advisory about IRC DCC connection tracking Date: Wed, 27 Feb 2002 15:05:09 +0100 From: Harald Welte <laforgeat_private> To: Netfilter Announcement List <netfilter-announceat_private>, Netfilter Mailinglist <netfilterat_private>, Netfilter Development Mailinglist <netfilter-develat_private> Hi! It is my duty to inform you about this very unfortunate security issue in the IRC DCC connection tracking code. The following mail has just been sent to bugtraq, Linux Vendors have been informed two weeks in advance in order to prepare their advisories. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Important security announcement of the netfilter project, 25 Feb 2002 (http://www.netfilter.org/security/2002-02-25-irc-dcc-mask.html). SUBJECT: IRC connection tracking helper module SUMMARY: IRC connection tracking opens unwanted ports SYSTEM: All Linux kernel versions from 2.4.14 to 2.4.18-pre8 SOLUTION: Apply attached patch CREDITS: Jozsef Kadlecsik <kadlecat_private>, Harald Welte <laforgeat_private> The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0060 to this issue. DESCRIPTION =========== 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, resulting 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 to 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 ruleset, 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 a IRC DCC request, a single connection from the outside network to the port number stated in the DCC request on any (internal) IP adddres will get 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 <laforgeat_private> +/* IRC extension for IP connection tracking, Version 1.21 + * (C) 2000-2002 by Harald Welte <laforgeat_private> * 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 */ CREDITS ======= Jozsef Kadlecsik has discovered this bug initially, Harald Welte has written the patch. COPYRIGHT ========= This advisory is copyright (C) 2002 by the netfilter core team. Redistribution is permitted after 25 Feb 2002, provided the contents of the advisory is not modified in any way. Live long and prosper - - Harald Welte / laforgeat_private http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8fOP0NfqJzMqajVsRAsSUAJoDzbvV6eoAgzff3pgKmhxUFPMXrgCgoIka jec/ptqtuYwqyh8CEN419nU= =nuYQ -----END PGP SIGNATURE----- -- Live long and prosper - Harald Welte / laforgeat_private http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*) -------------------------------------------------------
This archive was generated by hypermail 2b30 : Wed Feb 27 2002 - 18:30:57 PST