Full Report
Chrome extensions have lots of power but do have limitations. They can read the DOM but they can't execute exe files, change settings or many other things. Securing Chrome Extensions from taking over your computer is an important security model of the browser. File extensions are weird. Extensions can't read files, unless the "allow access to file URLs" flag is turned on. Some apps, like Text App, are able to edit local files as well. Being able to read or write to arbitrary files would be real bad for the system. ChromeOS is a super weird OS based upon Chrome. There are no executable files and you do everything in your browser. Since the OS settings are coupled, a user accesses files through chrome://file-manager or settings through chrome://os-settings. If an extension can run code within the context of one of these pages on chrome:// it can do whatever it wants to the system. The author was poking around the chrome://file-manager page when they saw the URL filesystem:chrome://file-manager/external/Downloads-878f28a3486b11359f7db348414fed3b5a15e573/file.txtt in local storage of the website. Functinoality, this is just like the file:// URL but not with as many restrictions. From this, they started playing to see what permissions this had and what could be done. They opened a file that had HTML and simple JavaScript tags in it. To his surprise, it worked! No CSP blocked it or anything else. This is super weird, especially considering the creation of trusted types and other things. With XSS on the super privileged URI chrome://, they knew this could be a big one. So, they dove into what this page had access to. They could read other pages, issue requests to preferences, read/write local files and more. Hype! But how do we get the user to execute this, especially with the random hash in the file name? A Chrome extension can easily download files; so, this isn't a problem. To get the hash, it's simply a hash of the username that can be queried from the standard Chrome extension APIs. With this, they could download a file, read the hash, open the file and perform very bad actions on the device. Awesome! While reviewing other sections, they found a very similar bug on the filesystem:chrome-extension URI that is specific to each chrome extension. The URL can read from chrome://resources. The more important thing is that it can execute scripts in the context of this page as well, giving another Chrome XSS! This bug existed for 7 years within Chrome! That's pretty wild for how impactful this bug is. But why does this occur? ChromeOS extended the legacy filesystem URL but didn't consider that this could be rendered from the browser since it was never meant to be. Since protections were never put in place, it led to an easy XSS. The privilege escalation itself was a change made to make the filesystem:chrome:// a real Chrome URI, giving it access to more features. This small change allowed for the XSS to go too far. The author has a great takeaway from this... "I think this type of bug is really interesting because it shows that vulnerabilities don't always come from simple mistakes; sometimes, decade-long design choices in massive and complex projects like Chrome/ChromeOS can be exploited in creative ways. "
Analysis Summary