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. Nowadays, such powers are typically reserved for governments and spy agencies. But not so long ago, similar capabilities were accessible to the average script kiddie.
Java Drive-By
When I was just getting into coding and security back in 2008, I learned about a technique known as “drive-by download,” particularly “Java drive-by.” At that time, you could embed Java applets which are small applications written in the Java programming language into web pages. While these applets were intended to enhance web functionality, they also allowed attackers to run arbitrary code on a user’s machine.
Signed applets, compared to unsigned ones, differed significantly in terms of their security sandbox and level of privilege. Essentially, signed applets could operate with the same level of access as desktop applications, even though they ran within the browser.
However, the signature would not be verified because it lacks a trusted certificate authority’s endorsement. This results in a security warning popup, leaving the user with at least a 50% chance of making the wrong choice. Clicking the “run” button could immediately compromise your system.
This wasn’t a vulnerability, it was simply a bad idea.
JavaScript Drive-By
In 2022, I started looking into the File System Access API. This API allows websites to read and write to files selected by the user, with some notable exceptions being what Chrome considers to be system files. I even reported one vulnerability related to the way it handled symbolic links, which Google fixed.
But even after the vulnerability was fixed, something still bothered me. This API is just too powerful. To understand why, we must first understand the operating system security boundaries. This API bypasses both Windows and macOS security mechanisms, but for the purpose of this post, I’ll focus on macOS.
It’s important to note that this issue affects not only Google Chrome but also all Chromium-based browsers, such as Microsoft Edge, Brave, and Opera, as they all share the same underlying architecture and APIs.
Gatekeeper
Gatekeeper on macOS is a security feature that prevents users from running untrusted software. It involves three main steps:
- File Quarantine: Introduced in 2007, it warns users before executing files downloaded from the internet.
- Gatekeeper: Built on File Quarantine in OSX Lion (10.7), it checks if downloaded apps are from identified developers, blocking those that aren’t.
- Notarization: Introduced in macOS Catalina (10.15), it requires apps to be scanned and approved by Apple before running.
Additionally, macOS includes an App Sandbox to limit apps access to system resources and user data. The Chrome browser does not use this sandboxing feature, which is another reason the File System Access API can be so dangerous.
When a user interacts with a website using the File System Access API, they are prompted to approve write access. At this point, the user becomes the only line of defense. If they mistakenly grant access to the wrong files, all previous security boundaries are bypassed. While the File System Access API correctly adds the com.apple.quarantine attribute, indicating that the file was downloaded from the internet and should not be trusted, a limitation of macOS Gatekeeper is that it does not recheck this binary when executed by another application, which in our case is Google Chrome itself.
This brings back memories of the old Java drive-by download, where a single misclick could lead to a compromised system.
Bypassing The Chrome Blocklist
Chrome does restrict write access to files and directories based on a blocklist. However, I found that if the user drags and drops a file, Chrome seems to not check it against the blocklist.
With that said, I don’t think that fixing this bypass would solve the underlying issue with the File System Access API. There are just too many files one could overwrite to gain code execution, you would always miss one.
Similar to the Java applets, there is no vulnerability one could point to, so instead, the remainder of this post will focus on how the File System Access API could be abused to hack people.
Exploitation & Symlinks
Successful exploitation hinges on our ability to convince the user to grant us write access to a specific target file. Many files can be leveraged to achieve code execution, but my favorite one is the Google Chrome Helper.
The Google Chrome Helper acts as an intermediary between Chrome and any installed plugins, facilitating their operation by launching processes for external content such as video players, extensions, or embedded content. When certain actions, like the window.print() command, are executed, a Google Chrome Helper process may be created to manage the necessary external interactions and resources required for those actions. That’s why overwriting it provides us with immediate code execution.
The next step is to craft a convincing story or reason for the user to feel safe while granting this access. The best method I’ve found involves using symlinks – essentially, pointers that redirect to another file or directory. Symlinks are great for this because most people don’t understand what they are, and even those who do often overlook them. They are ideal for this purpose because they create an illusion of safety from the user’s perspective. It’s easy to assume there’s no risk: “I’m just giving the website write access to a file I downloaded from it—what could possibly go wrong?”
Proof of Concept
As the web platform offers more advanced applications such as IDEs, 3d editors, and others, granting read and write access to files becomes more and more acceptable.
To demonstrate the impact, I’ve developed two proof of concepts, and with all the hype around AI, I went with the first one as a website claiming to be a browser AI helper, which works well with our target file, “Google Chrome Helper.”
The second PoC is a fake web-based IDE called “Evil Code Editor.” In this demonstration, users are prompted to download an example project and open it to familiarize themselves with the editor.
You can find the code for both over at:
https://github.com/ron-imperva/javascript-drive-by
As shown in the accompanying videos, if users follow these steps, attackers could execute arbitrary commands on their machines. In our case, we simply open the calculator, but any command could be executed outside Chrome and the macOS sandbox.
The only vulnerability we exploit here is the bypass of the Chrome blocklist, which typically blocks read and write access to the /Applications folder on macOS. However, many other files that are not in the blocklist can be used to achieve similar results.
Responsible Disclosure and Conclusion
We reported the blocklist bypass to Google, who validated this bug and indicated they were already aware of it and are working on a fix. At the time of writing this post, this bypass remains unpatched. Since it’s been more than 10 months, we have decided to publish the vulnerability details and the proof of concept code.
One way Google could address this, in our view, is by removing the execute permission from files modified by the File System Access API. We recommended this solution to the Chromium team, but at the time of writing, it remains in the backlog for consideration.
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.
In conclusion, the rapid advancement of web technologies continues to push the boundaries of what’s possible online. However, as demonstrated by the risks associated with the File System Access API, this progress comes with its own set of challenges, highlighting the delicate balance between functionality and security.
Just like in the old days of Java drive-by downloads, even today, a few wrong clicks can open the door to serious security issues. Stay alert and think twice before allowing access to your files.
The post Java(Script) Drive-By, Hacking Without 0days appeared first on Blog.
