Magellan and the Security Pitfalls of Third-Party Code

The Security Pitfalls of Third-Party Code

  • As the web evolves, webpages are offering new powerful and interactive features
  • Vulnerabilities in these features may allow remote attackers to run malware on your machine
  • Bromium uses hardware-enforced isolation to protect against these attacks by design

The recent Magellan vulnerability in SQLite allows attackers to exploit affected applications and run malicious code on your machine. One such application is the Chrome browser, which uses SQLite as the backend for several of its components, including WebSQL. WebSQL allows any JavaScript-enabled webpage to run arbitrary SQL queries on your machine – so if SQLite has a vulnerability, then malicious webpages can exploit it.

Unpacking the Magellan Vulnerability

Though the Tencent Blade Team haven’t yet disclosed full details of the vulnerability, Zhuowei Zhang has already been able to reverse-engineer the fix to produce a Proof of Concept. With just a few lines of JavaScript, the demo webpage can crash the browser tab in affected versions of Chrome.

A quick look at a bit of the vulnerable SQLite code in the stack frame above the memcpy() crash:

vulnerable SQLite code in the stack frame above the memcpy() crash

Note the integer comparison on the first line. This contains a classic integer overflow vulnerability, and that’s used by the proof of concept code. In a debugger:

Integer comparison on the first line contains a classic integer overflow vulnerability

Notice the region of memory in blue, which is the same as the string in the PoC code:

Region of memory in blue is the same as the string in the PoC code

Also note the 0xFFFFFFFF (underlined in red); this is INT_MAX, so when the value of nSuffix (which is 2) is added to it, it results in an overflow, producing a negative result, so the comparison results in an erroneous skip of the early return.

A little more work would be required to exploit this, and even so, thanks to Chrome’s architecture, the attacker would have achieved Remote Code Execution only within the sandbox. If the attacker were able to additionally exploit some other vulnerability in the Chrome sandbox or the Windows kernel, then they may be able to do more nefarious things such as install ransomware. There have been dozens of Chrome sandbox escapes over the years, and plenty more Windows kernel exploits that may be used.

The nastiest aspect of browser exploits is clearly that user interaction is not required. Bromium has been tracking an increase in Exploit Kit activity throughout 2018, and has noted a particular use of CVE-2018-8174 (IE Remote Code Execution) and Flash CVE-2018-4878 to deliver ransomware without user interaction. Even in the past few days, CVE-2018-8653 has reportedly been exploited to perform RCE in Internet Explorer.

One such infection vector that we see often, is when a user receives an email or tweet with a link to an infected website. This message can easily pass through all the layers of email security within the organization, as the destination is generally not known as malicious. Attackers frequently use websites of a small company or organization that has been compromised and is being used to host the attack, as this is less likely to arise suspicion of the security tools than if they had been using a newly registered domain.

Upon clicking the link, the website is immediately able to run the exploit, without any user interaction.

Bromium users are inherently protected against browser exploits like these, since we run each browser task in its own lightweight, hardware-isolated container. With Bromium, malware is separated from the host machine and other browser tabs, which allows us to continue execution of the malicious code with no risk to the user. In the Magellan demo it simply crashes the tab, and this is immediately fed back to our customer’s security team. For example, in the classic Proof of Concept with a calc.exe launching from IE the security team would see this:

Security team view for Bromium users

And with all malware, all process and network activity, filesystem and registry modifications, etc. will be captured and made available for analysis.

The fact that the Magellan bug was found in such a thoroughly-tested, widely-used library demonstrates that vulnerabilities are inevitable, and will continue to exist.

Bromium users remain protected because the attack unfolds inside the micro-VM container where it doesn’t actually matter what the malware does. With Bromium, the malicious code is completely isolated from the host operating system and is destroyed as soon as the user closes the browser tab. There’s nothing to steal, no way to move laterally, and no ability to persist.

If you want to learn more about Bromium Secure Platform, contact us to request a demo.

Bromium blogger Matthew Rowen also contributed to this post. 

The post Magellan and the Security Pitfalls of Third-Party Code appeared first on Bromium.

*** This is a Security Bloggers Network syndicated blog from Bromium authored by Jack Walker. Read the original post at: