IE Script Engine at Risk for Attacks

Wednesday, June 18, 2014 @ 05:06 PM gHale


While exploit mitigation techniques available in Internet Explorer keep the browser strong in face of memory exploits, other types of attacks could end up hitting a victim through the script interpreter engine.

Scripts can be as efficient as a shellcode and malicious scripts could actually run via a script interpreter engine on a target machine with escalated privileges, based on the discoveries of Yang Yu (CanSecWest 2014 presentation), Yuki Chen and Yuange (Chinese), said Fortinet security researcher Zhenhua Liu in a blog post.

RELATED STORIES
Big Patch Tuesday for Microsoft
Another IE Zero Day
Extreme Risk: SMBs Still Using XP
Warning over XP Update Trap

Liu said “the safety of the IE script engine relies solely on one single byte — the SafetyOption flag.” Getting elevated privileges requires modifying the flag to 0 (zero) or in JScript and 0 (zero) in VBScript.

The COleScript::CanCreateObject and ColeScript::CanObjectRun are the functions that perform separate checks on the SafetyOption flag to decide if it is safe to create and run a given ActiveX object.

Penetrating the protection layers is not that simple, though. For the trick to work, the attacker needs to know the memory address of the flag, hence full process memory access is a requirement, which is not actually impossible (Zero Day vulnerabilities still continue to pop up).

On the other hand, if the attacker gains full process memory access, he or she can modify the SafetyOption flag and execute malicious scripts with elevated privilege.

The researcher said the exploit model works with Internet Explorer 11, too, but the flag can only end up modified in VBScript because the protection for the JScript engine became stronger with the introduction of a 0x20-byte hash value.

As such, when “the SafetyOption flag is used, the function ScriptEngine::GetSafetyOptions is called to generate a new hash that is then compared with the original hash value, which is stored in memory.”

It appears the two functions checking the flag for permission are still responsible for enabling elevated privileges and even if SafetyOption returns a non-zero value, the action can end up completed by modifying the application data in the ScriptEngine object.

The researcher predicts more Zero Day vulnerabilities to appear, “since the only prerequisite for using this is a vulnerability for an arbitrary write (which is common nowadays), we can anticipate more Zero Days that will use this technique in the near future.”



Leave a Reply

You must be logged in to post a comment.