Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

But You Told Me You Were Safe: Attacking the Mozilla Firefox Sandbox (Part 2) - 1377

Hossein LotfiPosted 1 Year Ago
  • In part one, the author used a prototype pollution vulnerability to compromise the Renderer process. In part two, they uses another prototype pollution vulnerability from their privileged position.
  • The sandboxed renderer process has various interfaces for communicating with the privileged Chrome process. Some are even directly reachable through JavaScript. One of these inferfaces is NotificationDB, which is almost only JavaScript by itself.
  • The Notification:Save() function calls into taskSave(). When saving, it checks the objects origin and notification. It performs a write like this -
    this.notifications[origin][notification.id] = notification;
    
  • If the value of origin is set to __proto__ then notification.id will also be part of the write, with the rest of the notification being the value written. Using this, any global JavaScript can be overwritten! Since is not just limited to the NotificationDB.jsm either; it affects all JavaScript modules for any Chrome-level things.
  • In the TabAttributes.jsm module, there is some code that iterates through the element of a list called data using a for. Luckily for us, this will only iterate over prototypes! Using this code, it's possible to set arbitrary HTML (typically XUL) attribute of a tab. To trigger this, there are a few ways but one of them is the most convenient - crash the tab and on automatic reinitialization the pollution happens.
  • The XUL event handlers can be used within the attributes. So, on page load when the pollution happens, we can add a JavaScript to onunderflow attributes to execute arbitrary JavaScript within the Chrome process. Since this is highly privileged process, compromise is fairly trivial.
  • To start with, they set the preference security.sandbox.content.level to 0 in order to prevent sandboxing in new tabs for the future. From there, we open a new tab and call C:\\Windows\\System32\\cmd.exe to execute arbitrary commands. Game over at this point.
  • Every language seems to have its drawbacks in terms of security. C has memory corruption issues, JavaScript has prototype pollution... Overall, a fascinating series on using a memory safe language to still compromise the browser via a logic bug.