2069269 - Crashes with TubeDigger

Status: RESOLVED FIXED

(External Software Affecting Firefox :: Other, defect)

Description

[Yannis Juglaret [:yannis]]

In bug 1930472 we have blocked TubeDigger DLLs, but only up to version 1.5.9.0 and only in content processes. But we get crashes in the parent process too, including with more recent versions. More recently, :calixte has pinged me about signature tbdghook64.dll | mozilla::SandboxBroker::LaunchApp which has some volume in Nightly, also in parent processes.

https://www.tubedigger.com/contact.html has the following info:

If you have any questions or suggestions please send email to [e-mail] or [e-mail]

Comment 1

[Yannis Juglaret [:yannis]]

So regarding the new signature, they are injecting into our processes and using very unsafe ways to get called at the ResumeThread call point during our SandboxBroker::LaunchApp calls. This allows them to alter a child process while its main thread is still suspended.

The most unsafe part is that they have heuristics in place to recover where the compiler stored the process handle and the executable name for the child process in SandboxBroker::LaunchApp. This is very unreliable and crash-prone, can change with every build, and requires maintenance over time. Applying these heuristics to Nightly 157 currently results in crashes.

I suggest we block existing versions of the DLL (latest is 1.8.2.0) and contact the developers, asking to at least remove the part that tries to recover our variables. They can already safely get the thread ID because this part is stable (it is always the first argument to ResumeThread), from there they should be able to get away with GetProcessIdOfThread, OpenProcess, QueryFullProcessImageNameW, NtQueryInformationProcess and/or ProcessCommandLineInformation without having to use the crash-prone heuristics.

Comment 2

[Greg Stoll :gstoll]

That sounds like a good plan to me.

Comment 3

[Yannis Juglaret [:yannis]]

Regarding the LoadLibraryExW crash, I believe this could be caused by their remote thread creation code. It appears to only wait for less than two seconds before freeing critical memory that the remote thread needs. I'll contact them with the details.

Note that I'm not sure our block will work, what they're doing may be bypassing the blocklist already, but we can try and see.

Comment 4

[Yannis Juglaret [:yannis]]

Attachment: Bug 2069269 - Block TubeDigger DLLs up to version 1.8.2.0 in all processes. r=gstoll

Widen the existing content process block to all processes and to all
known affected versions. TubeDigger injects TbdgHook[64].dll into
Firefox and patches xul.dll code using hardcoded byte patterns and stack
frame offsets. These can break whenever Firefox is rebuilt, and now
crash the browser process within seconds of startup. A second failure
mode crashes on remote thread injection.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/463493a047c1
https://hg.mozilla.org/integration/autoland/rev/ae142363a353
Block TubeDigger DLLs up to version 1.8.2.0 in all processes. r=gstoll,win-reviewers

Comment 6

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/ae142363a353