1259489 - Trusteer Rapport should be blocked

Status: RESOLVED WONTFIX

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Sylvestre Ledru [:Sylvestre]]

Trusteer has been causing a lot of crashes lately (like 9 crashes into the top 15).
We have been in contact with them for the last 3 months. They are fixing bugs but causing others all the time.
I believe we should block them now until they find a better way to plug into our product.
Some examples:
bug 1254527
bug 1255026
bug 1242393

Note that, besides crashes, it is also causing bugs like bug 1238620 (not possible to upload files bigger than 500k)

Comment 1

[Jorge Villalobos [:jorgev] (he/him)]

Is this an add-on or just an application injecting binaries? Also, is there any reason to keep this bug private?

Comment 2

[Sylvestre Ledru [:Sylvestre]]

I think it is an "application injecting binaries".
About private, yes, it might have some legal implications.

Comment 3

[Sylvestre Ledru [:Sylvestre]]

Benjamin, could you find someone to write the patch? Thanks

Comment 4

[Andrew Williamson [:eviljeff]]

Can you expand on 'legal implications'?  All the crash bugs you've referenced are public, and they contain a lot more detail than this one.

Comment 5

[Sylvestre Ledru [:Sylvestre]]

Blocking Trusteer rapport could make IBM unhappy.

Comment 6

[Benjamin Smedberg]

Attachment: part B - Add Trusteer Rapport DLLs to the blocklist,

MozReview-Commit-ID: K3NPE0eOmCl

Comment 8

[Marco Castelluccio [:marco]]

Other examples:
https://bugzilla.mozilla.org/show_bug.cgi?id=1295600 (440 crashes over the last week)
https://bugzilla.mozilla.org/show_bug.cgi?id=1281803
https://bugzilla.mozilla.org/show_bug.cgi?id=1276921

Older:
https://bugzilla.mozilla.org/show_bug.cgi?id=985428
https://bugzilla.mozilla.org/show_bug.cgi?id=716390
https://bugzilla.mozilla.org/show_bug.cgi?id=699776
https://bugzilla.mozilla.org/show_bug.cgi?id=629351

Comment 9

[Marco Castelluccio [:marco]]

Could we test that blocklisting works? This way we're prepared in case we have spiking crashes in the future.

Comment 10

[Marco Castelluccio [:marco]]

Also bug 1303531.

Comment 11

[Benjamin Smedberg]

Carl, could you test this? With bug 1370807 and our new no-dll-injection policy we should be able to deploy this now without issue.

Comment 12

[Carl Corcoran [:ccorcoran]]

I'll take a look.

Comment 13

[Carl Corcoran [:ccorcoran]]

Our dll blocklist is not enough to block this, at least the latest version which I installed. Launching firefox.exe in a debugger shows this module load order:

> ModLoad: 00007ff6`e5110000 00007ff6`e51e1000   firefox.exe
> ModLoad: 00007ff8`7f240000 00007ff8`7f41b000   ntdll.dll
> ModLoad: 00007ff8`7dcf0000 00007ff8`7dd9e000   C:\Windows\System32\KERNEL32.DLL
> ModLoad: 00007ff8`7b930000 00007ff8`7bb79000   C:\Windows\System32\KERNELBASE.dll
> ModLoad: 00007ff8`5fcf0000 00007ff8`5fecf000   c:\program files (x86)\trusteer\rapport\bin\x64\rooksbas_x64.dll
> ModLoad: 00007ff8`7d070000 00007ff8`7d0c1000   C:\Windows\System32\SHLWAPI.dll
> ...

No Firefox code has run yet, so the DLL block list is too late.

I am not sure how rooksbas_x64 is loaded so early in process initialization, but it's not the first time I've seen this exact module load order.

Comment 14

[Marco Castelluccio [:marco]]

In an email thread we have with them, they said they are planning to move to an extension-based solution.

Comment 15

[Sylvestre Ledru [:Sylvestre]]

Less of an issue lately, will move to a webextension, wontfix it.