There is an issue in Chakra JIT server that can be potentially exploited to compromise the JIT process from a compromised browser content process. Bugs like this could potentially be used to bypass ACG (Arbitrary Code Guard) in Microsoft Edge. The issue has been confirmed on a ChakraCore build from source. Chakra JIT server takes bytecode as an input from the calling process. When processing the Js::OpCode::ProfiledLoopStart opcode in IRBuilder::BuildUnsigned1() function in IRBuilder.cpp there is this line this->m_saveLoopImplicitCallFlags[num] = saveOpnd; where num is client-controlled (it's an usigned char following the Js::OpCode::ProfiledLoopStart opcode). m_saveLoopImplicitCallFlags is allocated in IRBuilder.h as m_saveLoopImplicitCallFlags = (IR::Opnd**)func->m_alloc->Alloc(sizeof(IR::Opnd*) * loopCount); where loopCount is also client-controlled (workItemData->jitData->bodyData->loopCount). Thus if a client sets num larger than loopCount, an out-of-bounds write will occur....
There is an issue in Chakra JIT server that can be potentially exploited to compromise the JIT process from a compromised browser content process. Bugs like this could potentially be used to bypass ACG (Arbitrary Code Guard) in Microsoft Edge. The issue has been confirmed on a ChakraCore build from source. Chakra JIT server takes bytecode as an input from the calling process. When processing the Js::OpCode::ProfiledLoopStart opcode in IRBuilder::BuildUnsigned1() function in IRBuilder.cpp there is this line this->m_saveLoopImplicitCallFlags[num] = saveOpnd; where num is client-controlled (it's an usigned char following the Js::OpCode::ProfiledLoopStart opcode). m_saveLoopImplicitCallFlags is allocated in IRBuilder.h as m_saveLoopImplicitCallFlags = (IR::Opnd**)func->m_alloc->Alloc(sizeof(IR::Opnd*) * loopCount); where loopCount is also client-controlled (workItemData->jitData->bodyData->loopCount). Thus if a client sets num larger than loopCount, an out-of-bounds write will occur. There appear to be no bounds checks related to this array, there are some asserts that happen *after* the overrwrite already occurred and they will not be present in the Release builds. Note that there is also an integer overflow when m_saveLoopImplicitCallFlags is being allocated: sizeof(IR::Opnd*) * loopCount that's going to affect 32-bit processes. Speaking of integer overflows that will affect 32-bit processes, there are also several other similar instances such as this->tempMap = (SymID*)m_tempAlloc->AllocZero(sizeof(SymID) * tempCount); in IRBuilder.cpp (as far as I can tell tempCount is going to be controllable by the user) an probably other places.
