How is my Browser blocking RWX execution? | Hacker News Reader

How is my Browser blocking RWX execution?

rwxstoned.github.io

48 pointslucasRW33 comments

> this is probably a mitigating control which would make exploit development much harder in case an exploit chain attempted to leverage one of those RWX areas for execution

This didn't pass the sniff test for me - this doesn't do anything to protect existing RWX regions, and a theoretical attacker that has the ability to inject arbitrary DLLs into the browser process already has access far beyond what the browser could protect.

Fortunately, because the browser in question (Firefox) is open source, we can find the change that added this code. This is a bit of a pain because the file has been renamed twice, but here it is: https://hg.mozilla.org/mozilla-central/rev/7d2e74c69253e57fd...

And if we read the associated bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1322554) we can see this is described as "policy decision", and this entire section of the code isn't exploit mitigation, but rather intended to block broken third party programs from injecting their buggy and poorly written DLLs into Firefox and causing bugs that users report to Mozilla.

> And if we read the associated bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1322554) we can see this is described as "policy decision", and this entire section of the code isn't exploit mitigation, but rather intended to block broken third party programs from injecting their buggy and poorly written DLLs into Firefox and causing bugs that users report to Mozilla.

Indeed -- in fact, I was tech lead for an entire project dedicated to dealing with this situation (InjectEject).

> This is a bit of a pain because the file has been renamed twice, but here it is: https://hg.mozilla.org/mozilla-central/rev/7d2e74c69253e57fd...

tig [0] cane make this a breeze to inspect. It'll give you history following file moves (assuming git knows about them):

    tig file

tig: https://jonas.github.io/tig/

They just use the acronym EDR without introducing it, it's "Endpoint Detection and Response"

Similarly RWX. I guess if the article were meant for me, I'd know all the terms already.

Read Write Execute

The browser is Firefox, and I'm the engineer (no longer at Mozilla) who spearheaded the development of this. AMA.

Why?

It looks like they concurred [0] with this comment [1].

[0]: https://news.ycombinator.com/item?id=42636362 [1]: https://news.ycombinator.com/item?id=42630520

Yup. At the time, third-party DLL injection was one of the single biggest causes of Firefox stability issues.

While security software and antivirus deserve all the injection blocking they may get, we must also consider how to bypass these mechanism when it's about reenabling adblocking by injecting DLLs in the browser for request blocking etc.

Don't use DLL injection -- use extension APIs. Too many products use DLL injection as a golden hammer.

Just the other day I saw a shitpost from someone to the effect that if "BDR" is a thing they're going to quit cybersecurity entirely. Did you know there is a company actually offering BDR? Apparently that's true.

> Note: this may be overzealous but to avoid legal issues I will not name that browser or the files/functions involved

Curious, anyone else want to name the browser?

it's probably not chrome because they are using this third party library: (https://github.com/fmtlib/fmt). also, it might be that this sink is actually meant to write a message to the console but due to configuration options its a noop. though, i guess its unlikely the registers would have a string view [?] so maybe it is meant to be a noop.

This looks like it, I think:

https://searchfox.org/mozilla-central/source/toolkit/xre/dll...

This feels like excessive concern for OSS. Mozilla gets touchy about trademarks generally not code

Third party DLLs injected into browser processes cause all kinds of crash spikes.

Looks like firefox: https://searchfox.org/mozilla-central/source/toolkit/xre/dll... (via https://searchfox.org/mozilla-central/source/toolkit/xre/dll... )

I'd assumed it would be Edge since the author was crawling through decompiled output and worrying about litigiousness, but the above code in a BaseThreadInitThunk() interceptor matches what the author is describing.

Some horrible code in there too:

https://searchfox.org/mozilla-central/source/toolkit/xre/dll...

Indiscriminate blocking of any DLL in the world with 12/6 hex digit filenames.

Reading the bug report https://bugzilla.mozilla.org/show_bug.cgi?id=973138 feels reasonable.

It must be hard to be in a position to be blamed for someone else's bad code - or even malware - one comment said it was 1/3 of the total crashes on Vista at the time.

As a GPU driver dev I 100% understand this position - no user cares that gamedevs are hacking things left and right, they care if it runs.

There's plenty of blame to go around, really. My current project has a workaround for a user-mode graphics driver that sets the thread name without checking if D3D11_CREATE_DEVICE_SINGLETHREADED is set -- so there's code to detect this and call SetThreadDescription() to change it back so the main thread can be found in the debugger again.

There also used to be a problem with a release DLL in Windows 10 that would output to OutputDebugString() with an encoding mismatch, thus spamming the debug output window with random kanji.

I've heard that the Office team has resorted to detouring SetUnhandledExceptionFilter() since even they had problems with third party DLLs unhooking their in-process crash handler.

> There's plenty of blame to go around, really. My current project has a workaround for a user-mode graphics driver that sets the thread name without checking if D3D11_CREATE_DEVICE_SINGLETHREADED is set -- so there's code to detect this and call SetThreadDescription() to change it back so the main thread can be found in the debugger again.

I hope that wasn't the one I worked on :P Though I'm surprised that changed much there - the flag just means we can avoid wrapping some state in mutexes (and in many paths is a NOP as the driver still uses multiple threads internally, not worth the gain for the few things they won't touch), I'm surprised that makes it rename the user thread.

From what I can tell, the driver author simply assumed that the user-mode graphics driver was running on a dedicated worker thread, and unconditionally set the thread name. However, when single-threaded mode is in use, it gets invoked on the application's thread -- and thus changes the name of the main thread instead.

CEF had this issue as well, and the result was that initializing the WebBrowser plugin in Unreal would rename the main thread there too.

That's why I'm surprised - that flag doesn't mean we don't spawn worker threads for the driver, just that user API calls only come from a single thread.

I suspect this is someone assuming the flag actually mean "the driver should only use one thread" - or more likely a popular app assumed that and relied on that behavior, and the driver ended up having to emulate that behavior and you app just happened to hit whatever heuristics enabled that option.

It feels like half the driver size is due to nonsense "workarounds" like that - like the recent Fallout3/New Vegas issue was due to the app trying to autodetect the driver and versions and doing something slightly different (which hasn't really been "valid" since soon after release) - so when a version number or driver ID changes a little too much for it to cope with it completely fails - so we added an entire new "fake" driver that just lies about it's name and version.

It's honestly a PITA and something I've hit on different vendor's driver in my own projects - you can rename the executable and get completely different behavior.

It's probably not surprising that GPU drivers are hundreds of megabytes in size, even compressed :P

The thread description is only for debugging purposes, though, and is only available on newer versions of Windows 10 anyway. I'm more inclined to believe it's an oversight as games seldom request non-thread-safe operation.

As for detecting the driver, yeah, it's easy to get that wrong. IIRC, GL drivers on Windows had to limit their reported extensions because GLQuake would overflow a buffer if the extension string was too long. I also saw a game where the telemetry code had a bug and would crash if the driver description was too long. Then there was the extreme weirdness with early hybrid devices where you'd bring up DXDiag and it'd say that the system had an Intel Integrated Graphics adapter driven by an ATI graphics driver DLL!

The root of all of this is that modern GPUs/drivers/graphics APIs are hugely complex. These days, drivers have entire compilers built into them, that are expected to run as fast as possible under demanding conditions while generating efficient shaders. But again, anyone who thinks the fault mainly is on one side is getting an incomplete picture. I remember the DirectX team complaining about how in the early days of Vista about how a large %age of their driver crashes were from NVIDIA drivers. On the other hand, NVIDIA said that they had to redesign and rewrite six full drivers from scratch on top of a new architecture with incomplete documentation that was changing up to the last minute.

Anyone naming their DLL with random hex digits is definitely up to no good.

It's a very common security technique to avoid being targeted by malware. I believe even the Microsoft KSLDriver drops randomly named DLL and device drivers along with creating a randomly named system service. Uses 8 hex characters.

Several third-party vendors use the same technique, mostly security vendors.

I'm the engineer who spearheaded adding the blocking technique outlined by OP. Security vendors are some of the worst offenders when it comes to injecting buggy DLLs into processes.

A brilliant idea, maybe all software should block DLL without English names. Could even incorporate the new technique into the operating system.

Reply on news.ycombinator.com