Lucene search
K

Microsoft Edge Chakra CFG Bypass Due To Bug In ServerFreeAllocation Vulnerability

🗓️ 06 Dec 2017 00:00:00Reported by Google Security ResearchType 
zdt
 zdt
🔗 0day.today👁 41 Views

Microsoft Edge Chakra CFG Bypass Vulnerability Due To Bu

Related
Code
ReporterTitlePublishedViews
Family
ATTACKERKB
CVE-2017-11863
15 Nov 201703:29
attackerkb
ATTACKERKB
CVE-2017-11872
15 Nov 201703:29
attackerkb
ATTACKERKB
CVE-2017-11874
15 Nov 201703:29
attackerkb
CNVD
Microsoft Windows Edge ChakraCore Security Bypass Vulnerability
16 Nov 201700:00
cnvd
CVE
CVE-2017-11874
15 Nov 201703:00
cve
Cvelist
CVE-2017-11874
15 Nov 201703:00
cvelist
EUVD
EUVD-2017-3471
7 Oct 202500:30
euvd
Microsoft KB
November 14, 2017—KB4048954 (OS Build 15063.726 and 15063.728)
14 Nov 201708:00
mskb
Microsoft KB
November 14, 2017—KB4048955 (OS Build 16299.64)
14 Nov 201708:00
mskb
Kaspersky
KLA11140 Multiple vulnerabilities in Microsoft Edge and Internet Explorer
14 Nov 201700:00
kaspersky
Rows per page
Chakra: CFG bypass due to a bug in ServerFreeAllocation 

CVE-2017-11874


Chakra JIT server exposes a ServerFreeAllocation() method that can be used to free an existing JIT allocation (for example when the corresponding function gets freed).

The simplified function's implementation is:

context->SetValidCallTargetForCFG((PVOID)codeAddress, false);
context->GetCodeGenAllocators()->emitBufferManager.FreeAllocation((void*)codeAddress);

First, the implementation makes sure that the CFG flag for the codeAddress is set to 0 and then frees the allocation at this address.

The problem is that FreeAllocation is too permissive. Below is the simplified code of FreeAllocation():

while(allocation != nullptr)
{
    if (address >= allocation->allocation->address && address < (allocation->allocation->address + allocation->bytesUsed))
    {
        ...
        this->allocationHeap.Free(allocation->allocation);
        return true;
    }
    previous = allocation;
    allocation = allocation->nextAllocation;
}

This means that the allocation will get freed not only if codeAddress points to the beginning of the allocation but also if codeAddress points *anywhere inside* the allocation.

So, if an attacker is able to change the codeAddress being used as an argument to ServerFreeAllocation() (e.g. with a read/write primitive inside a Content Process) and they increase codeAddress (but still let it point inside the same allocation), the allocation will get freed, but the CFG flag for the function will not be cleared correctly (the CFG flag will be cleared for the wrong address).

Later, if executable memory is allocated over the same (freed) space, the CFG target will still be valid, even if the new allocation will not be alligned perfectly with the old allocation.


This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available, the bug report will become
visible to the public.

#  0day.today [2018-01-03]  #

Data

Build on a solid foundation with Vulners data

We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data

Api

Power your application with Vulners API

The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access

App

Assess and manage vulnerabilities with Vulners tools

Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation