The cost of zero-day exploits has always been high, especially if they allow an attacker to remotely execute code on a host machine. But why pay hundreds of thousands of dollars for an 0-day when a relatively simple drive-by attack doesn’t need one and can achieve much the same result? That’s what interested an Imperva security researcher who has published a report on new drive-by attack using something called the Evil Code Editor. Here’s what you need to know.
Attacking Google Chrome Users With The Evil Code Editor Exploit
“A remote code execution chain in Google Chrome, which allows an attacker to execute code on the host machine, can cost anywhere from $250,000 to $500,000,” Ron Masas, a security researcher at Imperva, said in a Nov. 07 report. With that kind of spending power reserved mostly for spy agencies and state-sponsored attackers, Masas pondered, where does that leave the “average script kiddie” who was using similar methods years ago? Java drive-by downloads were relatively commonplace back in 2008, when Masas started his coding security career, using small Java applets embedded into web pages. Fast forward to 2022 and Masas started exploring the file system API which enables websites to read and write certain files as selected by the user. “With some notable exceptions,” Masas noted, “being what Chrome considers to be system files.”
Affecting all Chromium-based web browsers, Masas said that the API bypasses both Windows and macOS security mechanisms, although the report specifically focuses on macOS. Gatekeeper on macOS is a security feature that prevents users from running untrusted software, and macOS has an additional app sandbox that limits app access to system resources and data. “The Chrome browser does not use this sandboxing feature,” Masas said, “which is another reason the File System Access API can be so dangerous.” If a user is interacting with the File System Access API on a website they will be prompted to approve write access, get this wrong and, Masus pointed out, “all previous security boundaries are bypassed.“
So, what about the com.apple.quarantine attribute, added by the API, which flags the file as not trustworthy as downloaded from the internet? “A limitation of macOS Gatekeeper,” Masus said, is that “it does not recheck this binary when executed by another application, which in our case is Google Chrome itself.”
Google Chrome Blocklist Bypass And Exploitation
Although Chrome restricts write access to files by way of a blocklist, Masus discovered he could bypass this by dragging and dropping a file that was not then apparently checked. The TL;DR is that to succeed in exploiting this vulnerability, the attacker has to get a user to grant write access to the file concerned. Masus homed in on the Google Chrome Helper to, erm, help with this. Acting as a go-between for Chrome and installed plugins, the helper process can get created “to manage the necessary external interactions and resources required for those actions” when something like a window print command is executed. “That’s why overwriting it provides us with immediate code execution,” Masus said, and created proof of concept by way of a supposed browser AI helper and a fake web-based integrated development environment that he named Evil Code Editor.
Google Responds To Chrome Drive-By Disclosure
Masus disclosed the blocklist drive-by bypass to Google, which said it was aware of the issue and was working on a fix. However, Matus said that since it has now been more than 10 months since that disclosure, that’s why Imperva opted to publish details of the vulnerability now.
I have reached out to Google for a statement and will update this article soon. Meanwhile, Masus said that “Google informed us that they plan to restrict the File System Access API to the Chrome application bundle, which should mitigate the specific attacks discussed in this blog post. These changes are expected to be implemented in Chrome 132.”
