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
Unpacking the Magellan Vulnerability
A quick look at a bit of the 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:
Notice the region of memory in blue, which 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:
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.
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: https://www.bromium.com/magellan-vulnerability-sqlite-exploit-chrome/