1023239 - crashes in libinject2.dll and libredir2.dll (V-Bates)

Status: VERIFIED FIXED

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Robert Kaiser]

This seems to be the next incarnation of bug #1002748.

See bug 1002748 comment #17, those files seem to belong to a software called "V-Bates". Looking at Google, this seems to be adware and might even occur in combination with something called SearchProtect (yes, sigh, see bug 1022471).

I wonder if it makes sense to try and get a hold of those binaries and submit them to AV vendors as malware, see https://www.techsupportalert.com/content/how-report-malware-or-false-positives-multiple-antivirus-vendors.htm for how to do that.

Comment 1

[(Away)]

Moving this to Windows 8.1 for lack of a general "Windows" option.

Comment 2

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

We already blocked one ID of this add-on on bug 964594. Do you have other add-on IDs associated with it?

Comment 3

[(Away)]

There were two IDs in bug 964594 but only one of them got blocked. The ID that I've been seeing recently was the second one, 21EAF666-26B3-4a3c-ABD0-CA2F5A326744.

(Though it's unclear whether blocking from the addon side will keep the .dll's out. They might be loading those through some other means.)

Comment 4

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

The extension is blocked now. This might not be enough to resolve the crashes, however.

Comment 5

[u279076]

Looking at this crash over the last 3 days:

5060 crashes in libinject2.dll@0x169fd
4845 crashes in libinject2.dll@0x16aff
4574 crashes in libredir2.dll@0x2b84
910 crashes in nptnt2.dll@0x2099
======================================
15389 crashes in total

Based on this data I do not think the blocklist has worked.

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Top crash. Tracking!

Comment 7

[Sylvestre Ledru [:Sylvestre]]

FYI, we are waiting to get a copy of the DLL.

Comment 8

[Robert Kaiser]

David, I wonder if we still should add those libs to the blocklist. I know it's a bit of a whack-a-mole game here and we shouldn't go too far with that, but I wonder if we should at least try another one here, given the high volume. What do you think?


We should still try to get a hold of the DLL(s) and submit to AV vendors via the instructions on https://www.techsupportalert.com/content/how-report-malware-or-false-positives-multiple-antivirus-vendors.htm in any case.

Comment 9

[(Away)]

I don't think another round of blocks will really help us. We may see some very temporary relief, but it will just prompt a new round of DLLs, and then we'll have even more binaries that we need to hunt down and submit to AVs.

Can we do any support-after-crash here?

I'd like to observe this DLL under a debugger; maybe we can find some other way not to crash. I haven't been able find a copy though.

Comment 10

[Robert Kaiser]

(In reply to David Major [:dmajor] from comment #9)
> I don't think another round of blocks will really help us. We may see some
> very temporary relief, but it will just prompt a new round of DLLs, and then
> we'll have even more binaries that we need to hunt down and submit to AVs.

Given the volume, the temporary relief is already worthwhile in my eyes.

> Can we do any support-after-crash here?

We do not have any infrastructure for that at this point, AFAIK. We are working on something for the future, though.

> I'd like to observe this DLL under a debugger; maybe we can find some other
> way not to crash. I haven't been able find a copy though.

Getting a copy of the DLL into our hands has been an issue so far, unfortunately. :(

Comment 11

[Sylvestre Ledru [:Sylvestre]]

(In reply to Robert Kaiser (:[e-mail]) from comment #10)
> (In reply to David Major [:dmajor] from comment #9)
> > I don't think another round of blocks will really help us. We may see some
> > very temporary relief, but it will just prompt a new round of DLLs, and then
> > we'll have even more binaries that we need to hunt down and submit to AVs.
> 
> Given the volume, the temporary relief is already worthwhile in my eyes.
Ditto. David, if that is ok with you, could you prepare a patch today (Monday) to have this in beta 6? thanks

Comment 12

[(Away)]

I am opposed to an unconditional block of libinject2. These guys are determined to circumvent our blocking mechanisms. Their next move would only make the situation worse in the long run.

Now for some good news. I think they've fixed the crash in their latest update:
    Image name: libinject2.dll
    Timestamp:        Thu Jun 19 22:47:11 2014 (53A2BFAF)
I found this version by searching for crashes that happened outside of libinject2, presumably crashes that would have happened anyway.

They don't use version numbers, but we could block based on the file's build timestamp. That ought to stop the crashy versions without another round of arms race.

Comment 13

[(Away)]

By the way, nptnt2 is not part of V-Bates. It usually goes like: C:\Users\...\AppData\Local\TNT2\...

Are they high enough volume to track on their own? If so, let's get a separate bug for those.

Comment 14

[(Away)]

Attachment: Block based on timestamp

Comment 15

[Robert Kaiser]

(In reply to David Major [:dmajor] from comment #13)
> By the way, nptnt2 is not part of V-Bates. It usually goes like:
> C:\Users\...\AppData\Local\TNT2\...
> 
> Are they high enough volume to track on their own? If so, let's get a
> separate bug for those.

No, their volume is significantly lower than the others, let's ignore them for now.

Comment 16

[Benjamin Smedberg]

Comment on attachment 8447847 [details] [diff] [review]
Block based on timestamp

This function is getting big and gnarly. Next time we touch it, I think we should consider splitting it into more helpers or an object somehow.

Comment 17

[(Away)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b409824b125d

Comment 18

[Carsten Book [:Tomcat]]

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

Comment 19

[Sylvestre Ledru [:Sylvestre]]

David, could you fill the uplift request? I would like to have the fix for beta 7. (Thursday). Thanks

Comment 20

[(Away)]

Comment on attachment 8447847 [details] [diff] [review]
Block based on timestamp

Approval Request Comment
[Feature/regressing bug #]: V-Bates binary extension
[User impact if declined]: Topcrash
[Describe test coverage new/current, TBPL]: Stepped through locally, not yet in a nightly build
[Risks and why]: For users without V-Bates this is very low risk. For users with V-Bates, we don't yet know whether this will stop the crashes or have adverse effects.
[String/UUID change made/needed]: None

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/8a2ea552dfd1
https://hg.mozilla.org/releases/mozilla-beta/rev/e1abcffb2799

Comment 22

[u279076]

I just wanted to report that this has dropped off 2.83% over the last week.

Comment 23

[Robert Kaiser]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #22)
> I just wanted to report that this has dropped off 2.83% over the last week.

There has been a general drop due to them shipping the non-crashing version. In addition, this has hugely dropped into low-volume land with the blocklisting patch in 31.0b7 (I guess file dates are not 100% reliable, so that's why we still have a small volume left).

Comment 24

[(Away)]

I only see four crashes on 31b7, and they're on newer versions of libinject2. (It doesn't surprise me that this binary might still have some crashy corner cases, as long as the volume is orders of magnitude lower)

Comment 25

[u279076]

I'm marking this bug verified fixed based on stats.

There are still plenty of crashes being reported but they are all with older builds. Additionally, there are some new signatures popping up with newer versions of libinject2.dll but they are extremely low volume. I'm not sure if there's something we can do to help these remaining people (in case they're stuck) but maybe that should be dealt with separately.

Stats from the last week:
libinject2.dll@0x16aff has 2830 crashes, 0 with builds after this was fixed.
libinject2.dll@0x169fd has 2641 crashes, 0 with builds after this was fixed.
libinject2.dll@0xc104 has 20 crashes, 0 with builds after this was fixed.
libinject2.dll@0xb6e4 has 13 crashes, 4 with builds after this was fixed.
libinject.dll@0x1e1dd has 4 crashes, 3 with builds after this was fixed.
libinject2.dll@0xac8c has 2 crashes, 1 with builds after this was fixed.
libinject2.dll@0x17462 has 1 crash, 1 with builds after this was fixed.
libinject2.dll@0x8d4b has 1 crash, 0 with builds after this was fixed.

Source:
https://crash-stats.mozilla.com/query/?product=Firefox&version=Firefox%3A33.0a1&version=Firefox%3A32.0a2&version=Firefox%3A31.0b&range_value=1&range_unit=weeks&date=07%2F09%2F2014+21%3A00%3A00&query_search=signature&query_type=contains&query=ibinject&reason=&release_channels=&build_id=&process_type=any&hang_type=any