undefined | Better HN

0 pointsDwedit4y ago0 comments

How does the Kernel32 lock-down stuff work?

I can think of several things you could do to Kernel32 to try to lock it down:

* Patch out all the entry points of Kernel32 you don't want to be used. Then patch out their corresponding entry points out of NTDLL. Then remove the code that invokes the system calls inside of NTDLL. Yes, you can just simply overwrite user mode code willy-nilly as long as you have write access to the process memory.

(Regular programs use the entry points. Someone trying to do something fancy might skip the entry points. If your hackers are using things like ROP chains and gadgets, chances are they don't care about entry points.)

* Create some kind of NT security context so that nothing interesting works anymore. I don't know how this works, but many NT functions want a security context passed in.

* When you are executing code, and you have no idea where Kernel32 is, you can read the module list out of the TEB, and that finds you Kernel32 and NTDLL. Maybe something that could thwart that, but not break code.

In the end though, what could stop the process from attempting to SYSENTER from somewhere besides NTDLL?

0 comments

3 comments · 1 top-level

dblohm74y ago· 2 in thread

A lot of people don’t know this, but Firefox uses the Chromium sandbox. I should know: I rubber-stamped the commit that first imported that code into the Gecko repo (it is regularly kept in sync with upstream).

That sandbox (and others, for that matter) more or less follow steps as outlined below:

https://blogs.msdn.microsoft.com/david_leblanc/2007/07/27/pr...

https://blogs.msdn.microsoft.com/david_leblanc/2007/07/30/pr...

https://docs.microsoft.com/en-ca/archive/blogs/david_leblanc...

codethief4y ago

How does this square with Daniel Micah (of GrapheneOS) saying[0] that

> Even with [Firefox's] attempt at a sandbox […], sites aren't ever cleanly separated into different processes. […] There is no sandbox containing anything afterwards beyond the app sandbox. All sessions and data for other sites is compromised. […] [Compared to Chrome,] Firefox is easier to exploit, [has] lots more low-hanging vulnerabilities and a half-baked weak sandbox. On Android, it has no sandbox at all.

Not saying you are wrong. But maybe you could elaborate and put things into context for me: How does Firefox's sandboxing differ from Chrome's if it's using the Chrome sandbox?

While googling for an answer I found another comment of yours[1] from 5 years ago. Could you possibly speak to what has changed since then and what the current status is? (At least to your knowledge since I understand you no longer work at Mozilla.)

[0]: https://www.reddit.com/r/GrapheneOS/comments/bg03np/browsers...

[1]: https://www.reddit.com/r/firefox/comments/76dxzg/comment/doe...

dblohm74y ago

A lot can happen in five years!

Keep in mind that, in May of 2017, desktop Firefox did not even yet have full support for multiprocess under particular configurations. Obviously you cannot sandbox content processes that don't exist, so there were some prerequisites that needed to be dealt with first. That was pretty much wrapped up by the Firefox Quantum 57 release.

The other thing to note is that the Chromium Sandbox is more like a "sandbox construction kit." It features all kinds of knobs and dials that allow the developer to configure how strict it is. We used to compare adding multiprocess and sandboxing to Gecko to swapping out the warp drive on the Enterprise, while it was still at warp. You can't just flip a switch one day and be sandboxed; too much code existed under the assumption that it could access whatever OS resources it wanted, without restriction. It took time to modify that code to be aware of that restriction and act accordingly. Each time an iteration of modifications were completed, we were able to tighten the screws on the sandbox a little bit more.

Not only has that been very useful as Gecko has been migrated to running in a fully sandboxed environment, it is also a necessity even at the final stage. For example, modern browsers constrain their interactions with the GPU (and its driver) to a dedicated process. That process is sandboxed, but because that process needs access to graphics devices, it obviously needs a weaker sandbox than the other processes hosting web content.

IMHO the win32k lockdown is not "mission accomplished," but is a HUGE indicator of how much code has been migrated to support sandboxing. On desktop, Firefox processes are now site isolated and are disconnected from their platform GUI systems. That's huge -- I'm sure there are still deviations between the Chrome and Firefox sandbox configurations, but they're a lot closer now.

Firefox for Android still has a long way to go (I was working on that when I left Mozilla), but unfortunately it hasn't been treated with the same urgency as desktop. I know that they're still working on that and have been able to make a lot of progress now that site isolation for desktop has been released.

Finally, I should point out that sandboxing is a defense-in-depth measure, but a lot of armchair quarterbacks seem to only ever want to focus on comparing the sandbox between Chrome and Firefox, while completely ignoring how much more of Firefox is written using memory-safe languages. That's important too.

1 more reply

j / k navigate · click thread line to collapse