Opera blocking Tampermonkey as 'malicious'

[filbo]

I came back to my desktop after several hours away. System had been up, running Opera, display locked. On unlocking the display I saw an Opera pop-up message which I have already cleared, so I'm not sure I have the exact wording, but it was something like 'Opera has identified one of your extensions as malicious. See the Extensions Manager for details.', also with a 'Details' button.

Clicking 'Details' brought me to opera://extensions, and scrolling down the list I eventually got to:

Tampermonkey
Version 4.7.54                                                 (-) Blocked
The world's most popular userscript manager

We've identified this extension as malicious and have blacklisted it.
This means it can no longer cause any damage to your machine.
You can leave it as is, or remove it.

ID: dhdgffkkebhmkfjojejmpbldmpobfkfo

The meaning of 'we' in this statement is unclear; I can't tell if Opera-the-company manually maintain a blacklist, to which they have added Tampermonkey; if the browser subscribes to some sort of 3rd party blacklisting service; or whether the blocking was triggered by local behavior monitoring.

In any case, I am pretty sure that Tampermonkey is not itself malicious, although it may have hooks into the browser which a behavior monitor might object to; and of course one could easily install malicious userscripts into it.

Another user reported this to Opera, in a forum which I believe has a little bit of Opera developer attention, but not very much. I intend also to report it on their beta blog (specifically on the entry about the most recent release of the forward version, opera-developer); but, as I must commit one note or the other first, this one is first. I will add cross-linking once I have both links.

Note that the Tampermonkey I have installed in Opera is 4.7.54 from the Chrome 'store'; and that it is installed via the official Opera mechanism of installing it via their 'Install Chrome Extensions' extension. The other user whose post I point to above, and some other repliers, have noted that the Tampermonkey in the Opera 'store' still works (i.e. has not been tagged 'malicious'); but it is extremely backrev, version 4.2.5291, and I believe the developer of Tampermonkey has stopped submitting it to Opera for inclusion in their 'store' because Opera stopped being willing to do the safety review. So, running the Chrome build on Opera is the correct operational method; except that it is now broken by whatever 'malicious' detection method Opera is using.

(Please fill out the issue template with your details)

Expected Behavior

Tampermonkey (Chrome 'store' version) to work in Opera

Actual Behavior

Blacklisted with no apparent recourse

Specifications

• Browser: Opera 59.0.3160.0, based on Chromium 72.0.3610.2
• TM: 4.7.54 from Chrome 'store' (dhdgffkkebhmkfjojejmpbldmpobfkfo), installed via Opera extension 'Install Chrome Extensions' 2.5.7 (kipjbhgniklcnglfaldilecjomjaddfi)
• OS: LinuxMint 17.3 'rosa', based on Ubuntu 14.04 'trusty', based on Debian 8 'jessie'
• Kernel: Linux image '4.4.0-119-generic', based on kernel.org 4.4.114

[filbo]

Posted to Opera desktop team blog at https://blogs.opera.com/desktop/2019/01/opera-59-0-3187-0-developer-update/#comment-4270524260

[filbo]

Further reported directly into Opera's bug database as 'DNAWIZ-49270'

[filbo]

Opera's blacklist of extensions is here and appears to be in chronological order of addition to the list. TM is the 2nd last entry; they must have added the last two at the same moment.

There is a second discussion about the blocking on Opera's forums.

[derjanb]

I have no idea what made Opera identify Tampermonkey as malicious. I've asked this question at the opera extension page.

[derjanb]

As a workaround you can use Tampermonkey BETA for the moment. Sorry for any inconvenience.

There is a second discussion about the blocking on Opera's forums.

Thanks a lot for this link.

Important: It contains a way to re-enable Tampermonkey to be able to export your scripts.

[derjanb]

Looks like (Windows?) malware is installing Tampermonkey via Opera/Chrome's Alternative Extension Distribution Options. What I don't understand yet is, how does that help? I need to find out if an extension's storage can be modified from outside the browser. Does anyone of you know a Windows programm or installer that is installing Tampermonkey without user interaction? Thanks.

[ParticleCore]

As far as I understand there is malware that is installing TM without the user's consent.
After that it could theoretically clone Userscripts directly into the user's Chrome profile, essentially "infecting" the browser with Userscripts cloned from the attacker's environment. This way it would bypass all the user-manual steps required to effectively install a Userscript through the browser by going directly to where TM expects them to be stored at in the Chrome storage.

The implementation of a checksum + any salt that belongs to the user should prevent any more attacks through this vector, but I wonder how much impact it might have on script loading speed.

[filbo]

Complex cryptographic signatures are used all over the place and have little performance impact. (I do not mean that they are 'free', but the cost of a per-userscript signature check would be negligible compared to all the other activity going on during page load.)

It is unclear to me how a signature could be implemented which would allow TM itself to work, but prevent malware from forcibly installing TM + preloaded userscripts.

It is also entirely unclear to me that this is in any way TM's responsibility. How would you feel about 'We detected malware injecting DOS command files, so we have disabled cmd.exe for you', or 'We detected malware installing Firefox automatically and using it to attack web sites, so we have prevented your operating system from running Firefox'. TM is a tool; we do not ban hammers because someone once hurt someone with a hammer. We use them responsibly.

In particular, if a malware author wishes to inject executable script content into a user's system, and they already have file writing privileges on that system, there are an infinite number of other ways they can accomplish the goal. Opera itself (and Chrome and any other browser) has hundreds of HTML, JS, CSS etc. files which could be maliciously edited. These are attackers who already have access to the filesystem. Blocking a tool they use after gaining such access can only help for a brief moment before they adapt and move on to the next thing.

[derjanb]

It is also entirely unclear to me that this is in any way TM's responsibility.

😘

TM is a tool; we do not ban hammers because someone once hurt someone with a hammer.

But for the moment removing all hammers from the tool shop makes it more difficult for attackers. At least until they found the axes at the next rack.

[ParticleCore]

@filbo It is not a matter of blame shifting, Opera decided that TM was an attack vector they could more easily cut than doing anything else. It's just an extension and thus easily blocked while the rest is outside the scope of the browser, such as the malware itself. At this point it falls on to the developer to choose whether he wants to do something about it or not, I was simply providing a suggestion from my point of view.

I was not trying to argue anything, I only meant to give a suggestion that could possibly help if the developer wanted to take under consideration. I also do not agree with their position, but what is this going to accomplish? I can't see any progress being done unless all Opera users were to boycott it.

The comic side of this is that Chrome injects an anti-virus into the Windows users' computers without their knowledge and without their consent and runs scans at its own leisure (https://www.androidpolice.com/2017/10/16/google-rolling-anti-virus-feature-chrome-windows/) yet it still fails as we can all attest.

[filbo]

@ParticleCore I think it is sort of blame-shifting. If some sort of signature-checking cryptographic repair needs to be done, it is not the responsibility of the extension. The browser's internal dataset (its per-profile pool of installed extensions) has been attacked by these malware folks. If the browser wants to protect against that -- and I do think that's a good idea -- they should do so by noticing that an unexpected extension has been added to this user's browser profile.

Keeping a cryptographic hash of the expected set of extensions is easy and well-understood.

I sometimes fool around with those directories, e.g. restoring an extension from a system backup into a new clean browser profile. I'd want the browser to disable the unexpected extension and pop up a window telling me to either re-enable or delete it. This is similar to the case where Chromium adds a new permission to its design, then detects that some previously installed extension now requires that permission: it disables it and prompts me to go deal with it.

Would that be 100.00% effective against the current malware? Clearly not -- some users will just automatically rubber stamp anything they don't understand. But that is already the case; users who behave that way will not be able to distinguish this particular set of malware from the other 34 they're already wearing. It would be sufficiently effective to convince the malware authors to find the next unexpected method; which is as much as any mitigation is going to accomplish.

[derjanb]

The Tampermonkey Opera update to version 4.8.5890 was unlocked by Opera. https://addons.opera.com/en/extensions/details/tampermonkey-beta/

[ParticleCore]

@derjanb Does this mean they removed TM from the blacklist? If so that's great news.

[skipik]

@derjanb Are you going to update the Opera extension at their store from time to time? The previous version was outdated, that's why I'm asking. Or is it better to still use it from Chrome store as it always contains the latest version?

[derjanb]

Are you going to update the Opera extension at their store from time to time?

Yes, my plan is to update it in the future with the Firefox (stable) version.

[filbo]

They never had marked the Opera version as malicious. But I guess you've managed to get them to approve the updated TM code into their 'store' under its Opera extension ID.

This does not solve the problem for people whose TM scripts are locked inside the Chrome extension. A workaround exists (Opera forum link above); but it is too technical for many users. I guess it is sort of barely adequate.

[derjanb]

I guess it is sort of barely adequate.

I know.

BTW: users can also use this Python script or this PowerShell fork to extract the userscripts from Tampermonkey's storage.

[derjanb]

More details:

When I became aware that the Opera developers have a suspicion that Tampermonkey's Chrome Web Store version is installed and abused by malware I started to investigate what happened. I found an issue and reported it to Chrome's bug tracker 48 hours ago.

Important: What I found requires 1) some malware already running at your system and 2) the malware needs Administrator privileges.
Furthermore, as far as I can tell, the user also needs to 3) activate the Tampermonkey extension which was installed by the malware.

If all three points are fulfilled, then the malware can make Tampermonkey run foreign scripts which were not installed by the user.
This means Tampermonkey itself is not malicious, but as usual scripts can be, and you are safe if there is no malware on your PC, which is somehow obvious.

I released new versions yesterday which should make it more difficult to use the issue. A final fix, however, needs to be implemented in the Chromium engine.

[filbo]

I released new versions yesterday which should make it more difficult to use the issue.

That's version 4.7.63 on the Chrome tab of tampermonkey.net, with the changelog '2019-01-06 > General > On installation disable and blacklist all pre-installed scripts', right? But this changelog does not appear on any other tab of tampermonkey.net, including the Opera and Chrome (beta) tabs which present version 4.8.5890, also dated 2019-01-06. By 'released' you mean 'submitted to the various "stores" to be examined and (one hopes) eventually posted by the browser maintainers' ?

[filbo]

BTW, this issue has 'hit the news' with two articles (one more or less copying the other):

Opera Blacklists Tampermonkey Extension Being Installed by Malware
Tampermonkey Extension Blacklisted by Opera Due to "Malicious Activity"

Both articles mischaracterize the targeting of the blacklist as relating to the version of Tampermonkey, while in reality the difference in extension IDs is due to the separate hosting in Opera's 'store' vs. Chrome's (and in fact, Opera's store now has a newer version of TM than Chrome's, yet is still not blacklisted by Opera).

[derjanb]

https://blogs.opera.com/desktop/2019/01/opera-59-0-3192-0-developer-update/#comment-4276617687

I'll add more details soon.

[HatScripts]

https://blogs.opera.com/desktop/2019/01/opera-59-0-3192-0-developer-update/#comment-4276617687

I'll add more details soon.

Any update on this?

[derjanb]

Some more clarification: It is indeed possible to install an extension and modify the extensions storage from outside. I created a bug report for this issue, but it was closed a won't fix, because infected machines are not in Chrome's threat model. I understand this from a theoretically point of view, however this leaves the protection of the storage in the hands of the extensions, without giving the tools that are needed to achieve this.

As a first step Tampermonkey disables all scripts which are present when the "recently installed" event is fired. This protects against Tampermonkey being installed by malware and the storage modifications before the first extension start. However, this doesn't protect against late storage modification.

In order to address storage modifications while Tampermonkey is installed, I implemented a algorithm that hashes the script content using a salt and disables the scripts when modifications are detected. Even though the salt is stored as a cookie, which is stored encrypted at the hard disk, it is possible to just roll out a complete Chrome profile and there is no way for Tampermonkey to detect this. That's why the salt is extended by some hardware and browser information. This protection is enabled at Tampermonkey BETA by default, but it causes a lot of other issues:

• MacOS updates caused the hardware/browser part to change [MacOS] Tampermonkey (beta) disabled all userscripts, and unable to enable it. #672 All rules "striken out" and disabled after Mac OS Update: need to restore prior state of TamperMonkey scripts #652
• General problems with disabled scripts origin of this script cannot be determined? #659
• It's not possible to save changes in incognito mode anymore Changes made in Incognito don't stick, option for this is gone (Chrome) #656

Because of these issues I have not enabled this in general yet and I'm not sure I ever will.

[SkyNinja]

The new block on incognito changes (#656) isn't specific to the beta, it's in at least the Chrome store stable version. I'm having to run two separate userscript plugins because of the change.

[filbo]

Has this effectively been 'fixed' by syncing the Opera 'store' object named 'tampermonkey-beta' to the code you intend to ship as TM-release-for-Opera ? Because they've blacklisted the original not-beta object, and there's no useful appeal mechanism?

[derjanb]

Yes, I plan to update the Opera store version more often and regarding the blacklisting: I do have no new information since beginning of this year. That's why I think it is unlikely that this will change, even though all Tampermonkey versions share the same code.