exploit-db-mirror/exploits/windows/dos/41365.txt
Offensive Security ed0e1e4d44 DB: 2018-09-25
1979 changes to exploits/shellcodes

Couchdb 1.5.0 - 'uuids' Denial of Service
Apache CouchDB 1.5.0 - 'uuids' Denial of Service

Beyond Remote 2.2.5.3 - Denial of Service (PoC)
udisks2 2.8.0 - Denial of Service (PoC)
Termite 3.4 - Denial of Service (PoC)
SoftX FTP Client 3.3 - Denial of Service (PoC)

Silverstripe 2.3.5 - Cross-Site Request Forgery / Open redirection
SilverStripe CMS 2.3.5 - Cross-Site Request Forgery / Open Redirection

Silverstripe CMS 3.0.2 - Multiple Vulnerabilities
SilverStripe CMS 3.0.2 - Multiple Vulnerabilities

Silverstripe CMS 2.4 - File Renaming Security Bypass
SilverStripe CMS 2.4 - File Renaming Security Bypass

Silverstripe CMS 2.4.5 - Multiple Cross-Site Scripting Vulnerabilities
SilverStripe CMS 2.4.5 - Multiple Cross-Site Scripting Vulnerabilities

Silverstripe CMS 2.4.7 - 'install.php' PHP Code Injection
SilverStripe CMS 2.4.7 - 'install.php' PHP Code Injection

Silverstripe Pixlr Image Editor - 'upload.php' Arbitrary File Upload
SilverStripe CMS Pixlr Image Editor - 'upload.php' Arbitrary File Upload

Silverstripe CMS 2.4.x - 'BackURL' Open Redirection
SilverStripe CMS 2.4.x - 'BackURL' Open Redirection

Silverstripe CMS - 'MemberLoginForm.php' Information Disclosure
SilverStripe CMS - 'MemberLoginForm.php' Information Disclosure

Silverstripe CMS - Multiple HTML Injection Vulnerabilities
SilverStripe CMS - Multiple HTML Injection Vulnerabilities

Apache CouchDB 1.7.0 and 2.x before 2.1.1 - Remote Privilege Escalation
Apache CouchDB 1.7.0 / 2.x < 2.1.1 - Remote Privilege Escalation

Monstra CMS before 3.0.4 - Cross-Site Scripting
Monstra CMS < 3.0.4 - Cross-Site Scripting (2)

Monstra CMS < 3.0.4 - Cross-Site Scripting
Monstra CMS < 3.0.4 - Cross-Site Scripting (1)
Navigate CMS 2.8 - Cross-Site Scripting
Collectric CMU 1.0 - 'lang' SQL injection
Joomla! Component CW Article Attachments 1.0.6 - 'id' SQL Injection
LG SuperSign EZ CMS 2.5 - Remote Code Execution
MyBB Visual Editor 1.8.18 - Cross-Site Scripting
Joomla! Component AMGallery 1.2.3 - 'filter_category_id' SQL Injection
Joomla! Component Micro Deal Factory 2.4.0 - 'id' SQL Injection
RICOH Aficio MP 301 Printer - Cross-Site Scripting
Joomla! Component Auction Factory 4.5.5 - 'filter_order' SQL Injection
RICOH MP C6003 Printer - Cross-Site Scripting

Linux/ARM - Egghunter (PWN!) + execve(_/bin/sh__ NULL_ NULL) Shellcode (28 Bytes)
Linux/ARM - sigaction() Based Egghunter (PWN!) + execve(_/bin/sh__ NULL_ NULL) Shellcode (52 Bytes)
2018-09-25 05:01:51 +00:00

77 lines
No EOL
2.8 KiB
Text

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1012
DxgkDdiSubmitCommandVirtual is the function implemented by the kernel mode driver
responsible for submitting a command buffer to the GPU. One of the arguments passed
contains vendor specific data from the user mode driver. The kernel allocates a single
buffer for this purpose for all submit calls for the same context.
NVIDIA implements this data as:
struct NvPrivateHeader {
DWORD magic;
WORD unknown_4;
WORD unknown_6;
DWORD unknown_8;
DWORD size;
};
struct NvPrivateData {
NvPrivateHeader header;
DWORD unknown_0;
DWORD unknown_1;
DWORD some_size;
DWORD unknown_2;
PVOID a_gpu_address_maybe;
BYTE unknown[1220];
};
In one of the functions that process this data, there appears to be code to
shift around the contents of this user private data.
// |len| is controlled by the user. can come from the |some_size| field if the
|a_gpu_address_maybe| field is 0.
if ( len ) {
if ( 8 * len >= pCommand_->DmaBufferPrivateDataSize - 0x4E8 )
do_debug_thingo(); // doesn't stop the memcpy
priv_data = (NvSubmitPrivateData *)pCommand_->pDmaBufferPrivateData;
src = (char *)priv_data + priv_data->header.size; // unchecked length
priv_data = (NvSubmitPrivateData *)((char *)priv_data + 1256);
*(_QWORD *)&v4->unknown_0[256] = priv_data;
// potential bad memcpy
memcpy(priv_data, src, 8 * len);
}
There are two main problems here: the |len| value is checked, but that appears
to only call a debug logging function and not actually stop the memcpy that
occurs afterwards.
Also, the |size| field from the header is not properly
checked to be smaller than the actual size of the data (this is also checked in
the calling function but once again only calls do_debug_thingo()).
This lets an attacker specify an arbitrary length for the copy, as well as
specify an arbitrary 32-bit offset to copy from, leading to pool memory corruption.
Crashing context with PoC (Win 10 x64, driver version 375.95):
PAGE_FAULT_IN_NONPAGED_AREA (50)
...
rax=0000000000000008 rbx=0000000000000000 rcx=ffffb2087fe8f4f0
rdx=0000000041413c59 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8035fc15b00 rsp=ffffd88179edd1a8 rbp=0000000000000080
r8=00000000020a0a08 r9=0000000000105050 r10=0000000000000000
r11=ffffb2087fe8f4f0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
nvlddmkm+0x5e5b00:
fffff803`5fc15b00 f30f6f040a movdqu xmm0,xmmword ptr [rdx+rcx] ds:ffffb208`c12a3149=????????????????????????????????
Resetting default scope
Proof of Concept:
https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/41365.zip