Bug 152836

Summary: CAN-2004-0986 iptables May Fail to Automatically Load Some Modules
Product: [Retired] Fedora Legacy Reporter: David Lawrence <dkl>
Component: Package requestAssignee: Fedora Legacy Bugs <bugs>
Status: CLOSED WORKSFORME QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: pekkas, rob.myers
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: 1, LEGACY, rh73, rh90
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Lawrence 2005-03-30 23:29:09 UTC
http://www.securitytracker.com/alerts/2004/Nov/1012025.html

A vulnerability was reported in iptables. In certain configurations, some
modules may not load automatically.

It is reported that in certain situations, the software may fail to load the
required modules. As a result, some rules may not be properly enforced.

The flaw resides in 'iptables.c' and 'ip6tables.c'.

CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0986

Mandrake fixes iptables-1.2.5 to 1.2.9.
http://secunia.com/advisories/13096/



------- Additional Comments From michal 2004-11-09 21:01:56 ----

Created an attachment (id=918)
patch to prevent possible "forgetting" of iptables modules

That patch comes without any changes from iptables-1.2.8-2.1.92mdk.src.rpm
Mandrake security fix.	It applies with minor line offsets to
iptables-1.2.8-8.72.3.src.rpm (updates to RH7.3) and clearly to other version
too.  It is "obviously correct" as it just zeros out a freshly allocated
memory; 'calloc()' could be used equally well.	Other chunks in this
patch fix a simple spelling mistake.



------- Additional Comments From pekkas 2004-12-19 10:19:32 ----

Reviewed the patch and the need for new packages; applies to all of RHL73, RHL9,
and FC1.  This is pretty low-priority issue though.  



------- Additional Comments From pekkas 2004-12-21 07:27:29 ----

Umm.  This is a weird one:

RHL9 (no update): 132942 Feb 24  2003 iptables-1.2.7a-2.src.rpm
RHL7.3 update: 162843 Aug 19  2003 iptables-1.2.8-8.72.3.src.rpm
RHL8 update: 162702 Dec 21 19:21 iptables-1.2.8-8.80.2.src.rpm
FC1: 203260 Feb  4  2004 iptables-1.2.9-1.0.src.rpm

The weird thing is that currently RHL9's version number is smaller than RHL7.3's
or RHL8's.  I think this is a problem, right?

A suggested solution: for RHL9 update, update to using the RHL8 package as a
basis. This will be non-security update, though.  Is this the way to handle this?




------- Additional Comments From rob.myers.edu 2004-12-22 12:30:36 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
i made new iptables rpms to QA for rh73, rh9, and fc1:
 
- - should fix CAN-2004-0986, with patch from FC-3
- - the rh9 src.rpm is the same as the rh73 src.rpm
 
changelogs:
 
rh73:
* Wed Dec 22 2004 Rob Myers <rob.myers.edu> 1.2.8-8.73.1.legacy
- - apply patch for CAN-2004-0986 (FL #2252)
- - rebuild for rh73
 
rh9:
* Wed Dec 22 2004 Rob Myers <rob.myers.edu> 1.2.8-8.90.1.legacy
- - apply patch for CAN-2004-0986 (FL #2252)
- - rebuild for rh90
 
fc1:
* Wed Dec 22 2004 Rob Myers <rob.myers.edu> 1.2.9-1.0.1.legacy
- - apply patch for CAN-2004-0986 (FL #2252)
 
 
this file is available at:
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/2252.txt.asc
 
files:
 
rh73:
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/iptables-1.2.8-8.73.1.legacy.src.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/iptables-1.2.8-8.73.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/iptables-ipv6-1.2.8-8.73.1.legacy.i386.rpm
 
rh9:
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/iptables-1.2.8-8.90.1.legacy.src.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/iptables-1.2.8-8.90.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/iptables-debuginfo-1.2.8-8.90.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/iptables-ipv6-1.2.8-8.90.1.legacy.i386.rpm
 
fc1:
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/iptables-1.2.9-1.0.1.legacy.src.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/iptables-1.2.9-1.0.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/iptables-debuginfo-1.2.9-1.0.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/iptables-devel-1.2.9-1.0.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/iptables-ipv6-1.2.9-1.0.1.legacy.i386.rpm
 
sha1sums:
 
rh73:
f5f9fcb0ec99827e3f6e6fe298b2338170f80643  iptables-1.2.8-8.73.1.legacy.i386.rpm
61c4db7fb707dd8656406e0415caea17bf039b0f  iptables-1.2.8-8.73.1.legacy.src.rpm
0c5ad5b957310647c4cd68de2eab8138a00c8785  iptables-ipv6-1.2.8-8.73.1.legacy.i386.rpm
 
rh9:
e1680640356a43577f7d8fe2fe404f4d83e9d8f2  iptables-1.2.8-8.90.1.legacy.i386.rpm
23cf66dd5d24fd01ba45f36cc196c015bb7441ca  iptables-1.2.8-8.90.1.legacy.src.rpm
94e75379126dad9c3f5e91313f6308497e050493 
iptables-debuginfo-1.2.8-8.90.1.legacy.i386.rpm
5e786d39d0cd570ea8aa186b9a714120f63e2209  iptables-ipv6-1.2.8-8.90.1.legacy.i386.rpm
 
fc1:
5a7ce3e99220d80c99d6c835413ea7f6b7bf6d9b  iptables-1.2.9-1.0.1.legacy.i386.rpm
a6173e626494e2610ff9cdd82dab5793d4b8c49b  iptables-1.2.9-1.0.1.legacy.src.rpm
b62cfd7b081778f1536656659218cead4437445d 
iptables-debuginfo-1.2.9-1.0.1.legacy.i386.rpm
4d0fd905bcf158cb4948b12950562285d0c0278e  iptables-devel-1.2.9-1.0.1.legacy.i386.rpm
3a63d347a8c15136aec989b5b1eba7dcd1c358a1  iptables-ipv6-1.2.9-1.0.1.legacy.i386.rpm
 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
 
iD8DBQFByfSktU2XAt1OWnsRAuJNAJ9kbbLkUa5WqU8kTpbFHQ9tSa2BuACdHkWq
dFq0+d/l5gTrVkDWWGtRb88=
=8yws
-----END PGP SIGNATURE-----




------- Additional Comments From pekkas 2004-12-22 20:49:36 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

QA for all Rob's packages w/ rpm-build-compare.sh
 - match sources OK
 - spec file changes good for all (more on RHL9 below)
 - patches verified to come from the CVS
 - RHL9 version is basically the same the latest RHL8
 - RHL9 version is similar to the last RHL8 version, so
   forward porting the RHL73 should work OK.

I also rebuilt RHL9 version, installed it and did a few basic tests OK.

+PUBLISH RHL73, RHL9, FC1

61c4db7fb707dd8656406e0415caea17bf039b0f  iptables-1.2.8-8.73.1.legacy.src.rpm
23cf66dd5d24fd01ba45f36cc196c015bb7441ca  iptables-1.2.8-8.90.1.legacy.src.rpm
a6173e626494e2610ff9cdd82dab5793d4b8c49b  iptables-1.2.9-1.0.1.legacy.src.rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFBympRGHbTkzxSL7QRAiLRAKC5NWXLwCliLp41HmgNBY+5hgDxrgCeLPfK
1ziPIzVDWcUtH0GgKrz36C0=
=1mGL
-----END PGP SIGNATURE-----




------- Additional Comments From marcdeslauriers 2005-02-04 16:26:25 ----

Packages were built and pushed to updates-testing.



------- Additional Comments From mschout 2005-02-04 18:22:53 ----

installs on 7.3, did basic testing, everything works as expected.

+VERIFY 7.3



------- Additional Comments From madhatter 2005-02-04 23:15:54 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Installed on RH9.  30-line ruleset, using several extensions, loads fine.
Rules list fine, packet counts look sane.
 
+VERIFY RH9
 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
 
iD8DBQFCBI6UePtvKV31zw4RAgK0AKCJrSpYPSFZ6V8uQq6mo6ej+KEKhwCfUBdt
CQ6n8xS/pGmTKnskQwTQ1AY=
=igDp
-----END PGP SIGNATURE-----




------- Additional Comments From madhatter 2005-02-05 07:45:36 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
sorry, should have added that tested version was
iptables 1.2.8-8.90.1.legacy.i386
 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
 
iD8DBQFCBQWYePtvKV31zw4RAsr9AJ95kF/+AvqyFxDWpRp9LTvFpz8B0gCdG0kg
XVpA1mB+YVmMTrlGVCPDIow=
=+Kch
-----END PGP SIGNATURE-----




------- Additional Comments From mschout 2005-02-05 15:11:33 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sorry, I didn't know I was supposed to GPG sign my comment in bugzilla.

The above VERIFY for 7.3 was indeed from me.  The packages installed fine, and
passed rpm --checksig tests, and ipchains rules were working properly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)

iD8DBQFCBW6t+CqvSzp9LOwRAtkLAJ9rc1qk8HLZ7CwL6SgJ62esVfIprACghTPB
3jeFS524yMTtcjL+kYAr4hU=
=mDHQ
-----END PGP SIGNATURE-----




------- Additional Comments From jimpop 2005-02-06 12:48:44 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

+VERIFY RH73

Related modules load/unload properly and rules work as intended.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCBp5Yuhh7yV/E9I4RAhq3AJ0SC0Fz4811KGwlammp1JLMTdzyDgCdHpki
9tuImEdX4gtv7yRA36Fwr9U=
=4UkX
-----END PGP SIGNATURE-----




------- Additional Comments From jimpop 2005-02-06 12:50:27 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


+VERIFY RH73

Related modules load/unload properly and rules work as intended.

83895bb3697fc2c0a6442a12a481e5670a4c4e36 iptables-1.2.8-8.73.1.legacy.i386.rpm

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCBp79uhh7yV/E9I4RAvG/AKCK1c9UYTdnBnJ03B9PFwz2C7ZgJQCfQghS
YxNtgIVKfordOUCqnwje/vI=
=rNbz
-----END PGP SIGNATURE-----




------- Additional Comments From keb 2005-02-07 10:40:31 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

QA for RH9 iptables package:

sha1sum:
1bf551072cb97cb4dfcec90530dbe5f71d3eb4b0  iptables-1.2.8-8.90.1.legacy.i386.rpm

Installed, loaded and unloaded iptables, tested that accept/reject/log entries work.

+VERIFY RH9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFCB9Gu/9i/ml3OBYMRAidFAJ9PE/sedu6J4zeEeQthsLRUK3AZlgCfeQMU
LMtH6Wt+Pd7I+4hXJZ1QHI4=
=rubO
-----END PGP SIGNATURE-----



------- Additional Comments From keb 2005-02-08 07:01:01 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

QA for FC1 iptables package:

sha1sum:
87484b5ab4fed7ddaeea720d5303e7f9eca88d16  iptables-1.2.9-1.0.1.legacy.i386.rpm

Installed, loaded and unloaded iptables, tested that accept/reject/log entries work.

+VERIFY FC1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFCCPAZ/9i/ml3OBYMRAm0zAJ4/cxevjurnMvFGZRq2Jsr/XicfDwCfc77a
QlOg/qPs1kFFKUqG2qrqFXI=
=0C/o
-----END PGP SIGNATURE-----



------- Additional Comments From marcdeslauriers 2005-02-10 13:05:38 ----

Packages were officially released.



------- Additional Comments From marcdeslauriers 2005-02-19 03:37:43 ----

The following was posted to fedora-legacy-list:

Hi,

After upgrading to iptables-1.2.8-8.90.1.legacy for Red Hat 9, I have found
that ip_conntrack_ftp is not working on some interfaces of my system (it has 
4 physical interfaces). It no longer recognizes the data sessions associated 
with an ftp control session. When I open the high ports in iptables, the 
data session will work.

Downgrading to iptables-1.2.7a-2 makes the problem disappear again. Kernel 
version is 2.4.20-37.9.legacy.

Is this the right place to address this issue, or should I send a report 
elsewhere?

Regards
Bart Westra



------- Additional Comments From marcdeslauriers 2005-03-04 12:00:31 ----

The released packages work.

Resolution

With the new iptables package, you have to manually add
"ip_conntrack_ftp" to the IPTABLES_MODULES="" variable in
the /etc/sysconfig/iptables-config file and
uncomment the line.




------- Bug moved to this database by dkl 2005-03-30 18:29 -------

This bug previously known as bug 2252 at https://bugzilla.fedora.us/
https://bugzilla.fedora.us/show_bug.cgi?id=2252
Originally filed under the Fedora Legacy product and Package request component.

Attachments:
patch to prevent possible "forgetting" of iptables modules
https://bugzilla.fedora.us/attachment.cgi?action=view&id=918

Unknown priority P2. Setting to default priority "normal".
Unknown platform PC. Setting to default platform "All".
Unknown operating system Windows 2000. Setting to default OS "Linux".
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here, dkl.
   Previous reporter was fedora-legacy-bugzilla-2004.
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.