COMMAND

	linux 2.4.x ip_conntrack_irc opens unwanted ports

SYSTEMS AFFECTED

	Linux kernels  between 2.4.14 and 2.4.18 pre 9

PROBLEM

	netfilter project has published  an  advisory  regarding  irc  connexion
	tracking module :
	

	

	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 <kadlec@netfilter.org>, 

		 Harald Welte <laforge@netfilter.org>

	

	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 <laforge@gnumonks.org>

	+/* IRC extension for IP connection tracking, Version 1.21

	+ * (C) 2000-2002 by Harald Welte <laforge@gnumonks.org>

	  * 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.