by Mitja Kolsek, the 0patch Team
June 2021 Windows Updates brought a fix for another "Exploitation More Likely" memory corruption vulnerability in Scripting Engine (CVE-2021-26419) discovered by Ivan Fratric of Google Project Zero, very similar to this vulnerability discovered also discovered by Ivan and patched in May.
Ivan published details and a proof-of-concept three days ago and we took these to reproduce the vulnerability in our lab and create a micropatch for it.
Since Microsoft's patch was available, we reviewed it and found their patch for it in function ByteCodeGenerator::EmitScopeObjectInit, which Ivan also identified as the source of the flaw. An initialization loop was added to this function to initialize all members of the PropertyID array.
Our micropatch is logically identical to Microsoft's:
MODULE_PATH "..\Affected_Modules\jscript9.dll_11.00.9600.19867_32bit\jscript9.dll"
PATCH_ID 614
PATCH_FORMAT_VER 2
VULN_ID 7138
PLATFORM win32
patchlet_start
PATCHLET_ID 1
PATCHLET_TYPE 2
PATCHLET_OFFSET 0x10d189
N_ORIGINALBYTES 5
JUMPOVERBYTES 0
PIT jscript9.dll!0x10cf2d
; jscript9.dll!0x10cf2d -> SaveToPropIdArray
code_start
mov ecx, [ebp-0ch] ; get linked list
mov eax, [ecx+0x28] ;
mov esi, [eax+0x30] ;
LOOP:
test esi, esi ; is there more of PropertyID array?
jz END ; if everything is initialized, jmp to
; label END, else go into loop.
mov ecx, [esi+20h]
lea eax, [ebp-20h] ; get struct Js::PropertyIdArray *
push eax ; struct Js::PropertyIdArray *
push ebx ; struct Symbol *
mov edx, edi ; struct FuncInfo *
call PIT_0x10cf2d ; call SaveToPropIdArray
mov esi, [esi+18h] ; next element in linked list
jmp LOOP
END:
code_end
See the micropatch in action:
- Windows 7 and Windows Server 2008 R2 without Extended Security Updates,
- Windows 7 and Windows Server 2008 R2 with year 1 of Extended Security Updates.
- Windows 10 v1803
- Windows 10 v1809
No comments:
Post a Comment