[SECURITY] Local Netfilter / IPTables IP Queue PID Wrap Flaw

[SECURITY] Local Netfilter / IPTables IP Queue PID Wrap Flaw

[James Morris]

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


                  Netfilter Core Team Security Advisory
                  
Subject:

  Local Netfilter / IPTables IP Queue PID Wrap Flaw

Released:

  December 3, 2002.

Effects:

  Under limited circumstances, an unprivileged local user may be able
  to read a limited amount of arbitrary IPv4 or IPv6 traffic.

Estimated Severity:

  Low.

Remotely Exploitable:

  No.
  
Systems Affected:

  Linux 2.4 kernels up to and including 2.4.19, and Linux 2.5 kernels
  up to and including 2.5.31, where Netfilter / IPTables is enabled,
  and where either of the experimental IP queuing modules (ip_queue,
  ip6_queue) are in use.

Solution:

  Upgrade to Linux kernels 2.4.20 (stable), and 2.5.32 (development).

Details:

  Under Linux 2.4 and 2.5, an experimental IP packet queuing feature is
  available as part of Netfilter / IPTables.  This consists of kernel
  modules and a userspace library which allow userspace mediation and
  modification of IPv4 and IPv6 packets.

  A userspace mediation process must normally be privileged (requiring
  NET_ADMIN capability) to process packets from the kernel.  To commence
  mediating packets, a userspace process typically sends a Netlink message
  to the associated kernel module, specifying queuing parameters. The
  kernel module captures the Unix process ID (PID) of the process to ensure
  reliable queuing and delivery of packets.

  If the privileged mediation process exits, an unprivileged process
  re-using the same PID may be able to receive a limited amount of
  network traffic.

  This would only occur if no network traffic was queued between the exit
  of the privileged process and the establishment of the unprivileged
  process, as the kernel module will reset the queuing session upon
  transmission error to userspace.

  The kernel module will only transmit a limited number of packets to
  the userspace process without acknowledgment.  As all transmissions
  from userspace to the kernel module require NET_ADMIN capability,
  the unprivileged process will not be able to acknowledge packets.
  Thus, the maximum number of packets that the unprivileged process
  can read is limited to the queue length (default 1024 packets).
  The unprivileged process can also only read packets which have been
  selected for queuing via IPTables by a privileged process.

  This flaw is theorized to be difficult and somewhat invasive to exploit,
  probably requiring a combined use of DoS attacks.  It was discovered by
  the author of the code, and no exploits are known to exist.

  Fixing the flaw involved implementing a reliable mechanism for detecting
  when the Netlink control socket of a privileged mediation process is
  closed, and resetting the kernel queuing session state upon such events.

Credits:
  The fix was implemented by the Netfilter Core Team, with contributions
  from Jamal Hadi Salim and Alexey Kuznetsov.

Contact:
  coreteam@netfilter.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE97I4yKVbBrEQtqycRAmlnAJwN5ifTaixuLhi3qv8FVicmaNpYagCffdOu
Mc8UiYh/FUhiZbjXctyaoxg=
=nnt5
-----END PGP SIGNATURE-----

[SECURITY] Local Netfilter / IPTables IP Queue PID Wrap Flaw

[James Morris]

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


                  Netfilter Core Team Security Advisory
                  
Subject:

  Local Netfilter / IPTables IP Queue PID Wrap Flaw

Released:

  December 3, 2002.

Effects:

  Under limited circumstances, an unprivileged local user may be able
  to read a limited amount of arbitrary IPv4 or IPv6 traffic.

Estimated Severity:

  Low.

Remotely Exploitable:

  No.
  
Systems Affected:

  Linux 2.4 kernels up to and including 2.4.19, and Linux 2.5 kernels
  up to and including 2.5.31, where Netfilter / IPTables is enabled,
  and where either of the experimental IP queuing modules (ip_queue,
  ip6_queue) are in use.

Solution:

  Upgrade to Linux kernels 2.4.20 (stable), and 2.5.32 (development).

Details:

  Under Linux 2.4 and 2.5, an experimental IP packet queuing feature is
  available as part of Netfilter / IPTables.  This consists of kernel
  modules and a userspace library which allow userspace mediation and
  modification of IPv4 and IPv6 packets.

  A userspace mediation process must normally be privileged (requiring
  NET_ADMIN capability) to process packets from the kernel.  To commence
  mediating packets, a userspace process typically sends a Netlink message
  to the associated kernel module, specifying queuing parameters. The
  kernel module captures the Unix process ID (PID) of the process to ensure
  reliable queuing and delivery of packets.

  If the privileged mediation process exits, an unprivileged process
  re-using the same PID may be able to receive a limited amount of
  network traffic.

  This would only occur if no network traffic was queued between the exit
  of the privileged process and the establishment of the unprivileged
  process, as the kernel module will reset the queuing session upon
  transmission error to userspace.

  The kernel module will only transmit a limited number of packets to
  the userspace process without acknowledgment.  As all transmissions
  from userspace to the kernel module require NET_ADMIN capability,
  the unprivileged process will not be able to acknowledge packets.
  Thus, the maximum number of packets that the unprivileged process
  can read is limited to the queue length (default 1024 packets).
  The unprivileged process can also only read packets which have been
  selected for queuing via IPTables by a privileged process.

  This flaw is theorized to be difficult and somewhat invasive to exploit,
  probably requiring a combined use of DoS attacks.  It was discovered by
  the author of the code, and no exploits are known to exist.

  Fixing the flaw involved implementing a reliable mechanism for detecting
  when the Netlink control socket of a privileged mediation process is
  closed, and resetting the kernel queuing session state upon such events.

Credits:
  The fix was implemented by the Netfilter Core Team, with contributions
  from Jamal Hadi Salim and Alexey Kuznetsov.

Contact:
  coreteam@netfilter.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE97I4yKVbBrEQtqycRAmlnAJwN5ifTaixuLhi3qv8FVicmaNpYagCffdOu
Mc8UiYh/FUhiZbjXctyaoxg=
=nnt5
-----END PGP SIGNATURE-----

Re: [SECURITY] Local Netfilter / IPTables IP Queue PID Wrap Flaw

[James Morris]

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

Just an update on this, someone has pointed out that the recommended
2.4.20 kernel has a ext3 data corruption bug (which fortunately will not
affect most users).

The changset comments for the ext3 bug are at:
<http://linux.bkbits.net:8080/linux-2.4/cset@1.793?nav=index.html|ChangeSet@-1d>

Please be careful if updating to 2.4.20, or wait until 2.4.21.


- - James
- -- 
James Morris
<jmorris@intercode.com.au>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE97LGqKVbBrEQtqycRAnyaAJ9xMP2FFhMiB4EHQlEdCQ2Kf7z2bwCeLq2J
IS9YvQzsHYCJILYLo6vsbmo=
=V9f/
-----END PGP SIGNATURE-----

Re: [SECURITY] Local Netfilter / IPTables IP Queue PID Wrap Flaw

[James Morris]

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

Just an update on this, someone has pointed out that the recommended
2.4.20 kernel has a ext3 data corruption bug (which fortunately will not
affect most users).

The changset comments for the ext3 bug are at:
<http://linux.bkbits.net:8080/linux-2.4/cset@1.793?nav=index.html|ChangeSet@-1d>

Please be careful if updating to 2.4.20, or wait until 2.4.21.


- - James
- -- 
James Morris
<jmorris@intercode.com.au>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE97LGqKVbBrEQtqycRAnyaAJ9xMP2FFhMiB4EHQlEdCQ2Kf7z2bwCeLq2J
IS9YvQzsHYCJILYLo6vsbmo=
=V9f/
-----END PGP SIGNATURE-----

Re: [SECURITY] Local Netfilter / IPTables IP Queue PID Wrap Flaw

[Arnt Karlsen]

On Wed, 4 Dec 2002 00:29:11 +1100 (EST), 
James Morris <jmorris@intercode.com.au> wrote in message 
<Mutt.LNX.4.44.0212040025010.28607-100000@blackbird.intercode.com.au>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Just an update on this, someone has pointed out that the recommended
> 2.4.20 kernel has a ext3 data corruption bug (which fortunately will
> not affect most users).
> 
> The changset comments for the ext3 bug are at:
> <http://linux.bkbits.net:8080/linux-2.4/cset@1.793?nav=index.html|Cha
> ngeSet@-1d>
> 
> Please be careful if updating to 2.4.20, or wait until 2.4.21.

..and meanwhile alias 'umount' to 'sync && umount', 
you may want to chuck in a 'sleep 45' to play safer.

..url to a fix patch, anyone?


-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: [SECURITY] Local Netfilter / IPTables IP Queue PID Wrap Flaw

[Maciej Soltysiak]

> ..url to a fix patch, anyone?
http://marc.theaimsgroup.com/?l=linux-kernel&m=103884408631368&w=2

Regards,
Maciej Soltysiak

Re: [SECURITY] Local Netfilter / IPTables IP Queue PID Wrap Flaw

[Arnt Karlsen]

On Wed, 4 Dec 2002 11:28:33 +0100 (CET), 
Maciej Soltysiak <solt@dns.toxicfilms.tv> wrote in message 
<Pine.LNX.4.44.0212041127550.1841-100000@dns.toxicfilms.tv>:

> > ..url to a fix patch, anyone?
> http://marc.theaimsgroup.com/?l=linux-kernel&m=103884408631368&w=2
> 
> Regards,
> Maciej Soltysiak

..thanks. 

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: [SECURITY] Local Netfilter / IPTables IP Queue PID Wrap Flaw

[James Morris]

On Wed, 4 Dec 2002, Maciej Soltysiak wrote:

> > ..url to a fix patch, anyone?
> http://marc.theaimsgroup.com/?l=linux-kernel&m=103884408631368&w=2
> 

The ext3 fix is apparently still being worked on, the latest patch from 
Andrew Morton is at 
http://marc.theaimsgroup.com/?l=ext2-devel&m=103897994905702&w=2



- James
-- 
James Morris
<jmorris@intercode.com.au>