> 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).
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.
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.
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.
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.
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.
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 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).
The browser is Firefox, and I'm the engineer (no longer at Mozilla) who spearheaded the development of this. AMA.
Why?
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.
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.
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
> 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?
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.
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.
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.
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.
[flagged]
I am not sure that a chatgpt link asking to summarize TFA is relevant here. Everyone who needs to can do that themselves. IMHO this is spam
That’s fair. If I get downvoted or flagged I’ll take that as a lesson learned…
But the submitted article was very badly written and broke the cardinal rule and didn’t give any background or even explain acronyms on first use.
It seems well written to me, maybe you are not the target audience.