kernel-packages team mailing list archive

[Chris J Arges <1555338@xxxxxxxxxxxxxxxxxx>]

** Changed in: linux (Ubuntu Vivid)
       Status: New => In Progress

** Changed in: linux (Ubuntu Vivid)
     Assignee: (unassigned) => Chris J Arges (arges)

** Changed in: linux-lts-utopic (Ubuntu Trusty)
       Status: New => In Progress

** Changed in: linux-lts-utopic (Ubuntu Trusty)
     Assignee: (unassigned) => Chris J Arges (arges)

** Description changed:

- [From https://code.google.com/p/google-security-
- research/issues/detail?id=758 ]
+ [Impact]
+ [From https://code.google.com/p/google-security-research/issues/detail?id=758 ]
  
  A memory corruption vulnerability exists in the IPT_SO_SET_REPLACE ioctl
  in the netfilter code for iptables support. This ioctl is can be
  triggered by an unprivileged user on PF_INET sockets when unprivileged
  user namespaces are available (CONFIG_USER_NS=y). Android does not
  enable this option, but desktop/server distributions and Chrome OS will
  commonly enable this to allow for containers support or sandboxing.
  
  In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it
  is possible for a user-supplied ipt_entry structure to have a large
  next_offset field. This field is not bounds checked prior to writing a
  counter value at the supplied offset:
  
  newpos = pos + e->next_offset;
  ...
  e = (struct ipt_entry *) (entry0 + newpos);
  e->counters.pcnt = pos;
  
  This means that an out of bounds 32-bit write can occur in a 64kb range
  from the allocated heap entry, with a controlled offset and a partially
  controlled write value ("pos") or zero. The attached proof-of-concept
  (netfilter_setsockopt_v3.c) triggers the corruption multiple times to
  set adjacent heap structures to zero.
  
  This issue affects (at least) kernel versions 3.10, 3.18 and 4.4. It
  appears that a similar codepath is accessible via
  arp_tables.c/ARPT_SO_SET_REPLACE as well.
+ 
+ [Fix]
+ http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/62150
+ 
+ [Test Case]
+ Download v3 testcase from https://code.google.com/p/google-security-research/issues/detail?id=758
+ gcc net*v3.c -o v3
+ ./v3

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-lts-utopic in Ubuntu.
https://bugs.launchpad.net/bugs/1555338

Title:
  Linux netfilter IPT_SO_SET_REPLACE memory corruption

Status in linux package in Ubuntu:
  Fix Committed
Status in linux-lts-utopic package in Ubuntu:
  Invalid
Status in linux source package in Precise:
  New
Status in linux-lts-utopic source package in Precise:
  Invalid
Status in linux source package in Trusty:
  New
Status in linux-lts-utopic source package in Trusty:
  In Progress
Status in linux source package in Vivid:
  In Progress
Status in linux-lts-utopic source package in Vivid:
  Invalid
Status in linux source package in Wily:
  In Progress
Status in linux-lts-utopic source package in Wily:
  Invalid
Status in linux source package in Xenial:
  Fix Committed
Status in linux-lts-utopic source package in Xenial:
  Invalid

Bug description:
  [Impact]
  [From https://code.google.com/p/google-security-research/issues/detail?id=758 ]

  A memory corruption vulnerability exists in the IPT_SO_SET_REPLACE
  ioctl in the netfilter code for iptables support. This ioctl is can be
  triggered by an unprivileged user on PF_INET sockets when unprivileged
  user namespaces are available (CONFIG_USER_NS=y). Android does not
  enable this option, but desktop/server distributions and Chrome OS
  will commonly enable this to allow for containers support or
  sandboxing.

  In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it
  is possible for a user-supplied ipt_entry structure to have a large
  next_offset field. This field is not bounds checked prior to writing a
  counter value at the supplied offset:

  newpos = pos + e->next_offset;
  ...
  e = (struct ipt_entry *) (entry0 + newpos);
  e->counters.pcnt = pos;

  This means that an out of bounds 32-bit write can occur in a 64kb
  range from the allocated heap entry, with a controlled offset and a
  partially controlled write value ("pos") or zero. The attached proof-
  of-concept (netfilter_setsockopt_v3.c) triggers the corruption
  multiple times to set adjacent heap structures to zero.

  This issue affects (at least) kernel versions 3.10, 3.18 and 4.4. It
  appears that a similar codepath is accessible via
  arp_tables.c/ARPT_SO_SET_REPLACE as well.

  [Fix]
  http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/62150

  [Test Case]
  Download v3 testcase from https://code.google.com/p/google-security-research/issues/detail?id=758
  gcc net*v3.c -o v3
  ./v3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1555338/+subscriptions