-
Notifications
You must be signed in to change notification settings - Fork 907
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please stop recommending extensions from the Google Web Store #1336
Comments
Hi there. I understand and admire your concern, but The Marvelous Suspender is significantly safer in design than The Great Suspender, and if you want to keep using an extension with this functionality, and are scared of "developer tools", than it is the best option. First of all, The Marvelous Suspender cannot snoop form data. Those API permissions were removed, as they were wholly unnecessary. An update to add those back is possible, but would prompt the user to grant these additional powers. Furthermore, the extension is incapable of communicating with the outside world. It defines a very strict content security policy, which means that even if it does harvest all of your passwords, it cant do anything with them. This also blocks the obfuscation technique used by The Great Suspender, which loaded the malicious script rather than bundling it in the extension. Any change to this policy would also require a prompt to the user. So, while it is possible for an attacker to use The Marvelous Suspender, such an attack would require either a direct prompt to users asking for additional powers, or a major Chrome security vulnerability. If a prompt asking you to grant an extension a slew of additional powers doesn't make you check over why, then updating from GitHub won't save you. And if an exploit chain exists that can escape the sandboxing imposed on extensions, than that exploit is likely also capable of escaping the sandboxing imposed on a tab: meaning that our theoretical attacker could just post a webpage and steal the passwords of all who visit it. |
That's besides the point. Once again: Any extension from Web Store can ask for any permission (which virtually all users blindly agree with) and will auto-update ... most (all?) extensions that turned malicious later also started "honest" and "safe". Safe/honest/open-source/known/non-snooping/etc didn't stop hundreds of thousands (millions?) of users of "The Great Suspender" to auto-update to malicious code as they all wanted the convenience of a Web Store extension.
Again, the idea is to manually update after others review it or you inspect it yourself. If you have no programming skills to understand the code yourself, then don't update to master, and allow some time for others to report problems, just like they did with this incident, there is no real urgency to update a browser extension. As long as the current one still works then you don't need to update. If you don't want to put up with that, then you take on the risk of an auto-updating Web Store extension turning malicious without you being able to detect it before harm is done. It's not rocket science. |
Fully agreed with OP. The whole Web Store is a cesspool of malicious stuff that nobody really reviews before damage is caused - the level of scrutiny for these extensions is far inferior to the one Google itself applies to Android apps on Google Play (Apple on appstore, etc). |
That is very accurate. It is also very accurate that users who blindly consent to all permissions are not users who review the source code of their extensions. Advising them that installing it unpacked will protect them simply wouldn't help.
That's just it: in order for the malicious update to be executed, you would need to consent to additional permissions. Until you press "allow" on the Chrome prompt that says "The Marvelous suspender wants to communicate with outside servers and inspect all your data", no code from the malicious update is executed. You can take that time to manually investigate the code, switch to an unpacked version, ect. The update is not capable of doing harm without notifying you that it wishes to do harm. Lastly, here is a key question: how good are you at analyzing extensions? Are you confident that you could detect malware? Because even after there was a web store update that added code not in GitHub, it still took us a week to be certain of malice as opposed to incompetence. The additional code was nothing more than innocent analytics, after all: open source analytics at that. We had a very narrow target, and were all looking very closely at it. Do you really think you could do the same, and spot a malicious change across an entire extension? What about all your other extensions, too? How many hours are you dedicating to this project? It's much easier to allow all extensions that lack powerful permissions to just auto-update, and only investigate those that posses r request larger permissions. The Marvellous Suspender does not request any privacy-violating permissions, and if such permissions were newly requested, Chrome would alert you first. Therefore, you might as well just save yourself the regular effort of updating, and just use the Web Store version. |
To clarify abundantly as I see the discussion deviated from the actual point, the issue is using Web Store extensions. I edited the title to remove possible confusion, seeing the above user picked up on the name rather than the actual issue. Fine to use the Github version of "the marevelous suspender" in the manner I described above - update to github source code manually and rarely enough, relying on your own skills or on others' skills to identify malicious code in the diffs. |
Are you sure? The code that fires on every key press looks like it's still in there:
Regardless of the added fake-analytics, it already gets permissions for creating tabs and injecting scrips into all websites; it absolutely could read data out of the above listener and
Extensions shouldn't require thousands of lines of code (not counting the npm packages it pulls in as dependencies which is a whole other thing) to wrap a timer around |
I agree with @aleqx 's points. If you use auto-updating extensions from the Web Store then you accept it can turn malicious at any point. However, recommending such stuff as safe, for whatever reason, is misguided or misguiding. The recommendations in this thread are sound and I can add my voice to the following, from experience:
It is more hassle for those lacking experience, but it does keep you safe. Those who did that would have caught the problem with this Suspender extension before being affected. I was pleasantly surprised over the years to see new Chromium core code preserving extensions compatibility. Firefox became dreadful in that regard. |
The content script in both TGS and Marvelous is fully packaged with the extension, with no remote dependencies (not that it could load them, per the CSP). References to the form data don't leave that function: the only code that can access the webpage is in that file. That code is a needed part of one of my favorite pieces of functionality: the ability to avoid discarding tabs that have form information in them (like, say, a half-complete application).
Marvellous requests it's website access permissions as optional: that means you can deny it access to some sites, or limit it to only specific sites. Chrome's GUI for this is... less than ideal, but it is possible
Full disclosure: I overlooked that particular technique. I did, however, establish (using Mozilla's docs, which are better at describing Chrome behavior than Google's) that the content script is incapable of making outside requests. Chrome sandboxing blocks direct requests by the content script in almost all cases: one would probably need to navigate to a cooperating website in order to such requests through. However, that technique COULD work, and bypass the CSP (though it would depend: but it wouldn't be as simple as a one-lijne change to the content script. The extension would need to receive changes to the heavily-scruitinized content script (so that the data would actually leave the listener), and then send the form data through to the extension. The created tab would be fairly visible: even if it closed itself ASAP, there would be a noticeable flash. Lastly, there isn't a way to do that without being painfully obvious: if google so much as glances at a given update, they'd notice it. It isn't simply a matter of slipping a single line of code in: this requires several changes, and a significant amount of new logic, that would all need to be bundled in with the rest of the extension.
This is The Great Suspender, not AutoTabDiscard. It has many more features than simply calling tabs.discard after a preset time. I could go into depth, but you probably know that already. |
Life is full of things that are more hassle, but keep you more safe. How many users have a password manager? How many enable two-factor authentication? Those are tiny measures compared to auditing the complete codebase of every one of the numerous extensions you might have installed. Telling people "you aren't safe unless you are willing to spend a few hours a day carefully auditing every piece of code you run" isn't productive. Most people don't need absolute security. At some point, you need to say "okay, I'm secure enough". If The Marvellous Suspender became malicious, it wouldn't be able to obfuscate itself in the same way that The Great Suspender did. And while the chrome web store might not do much review, I think they do at least a little: otherwise there wouldn't have been any need for the levels of indirection seen in almost every malicious web extension to date.
Funny you should say that, what with the current Manifest V3 mess. At the end of the day, when The Marvelous Suspender was released on the chrome store, I was faced with a choice. Either tell those reading that they would need to follow this long list of steps in order to be safe, or tell them to just go and install this other extension that isn't actively malicious. If I did the former, most users would simply continue using the extension as-is. While doing your own security audits is great, it often isn't enough to protect you, and will eat up time better spent, say, designing patches to let Chrome fully lock down extensions. Saying "extensions shouldn't need so much code" or "you only need to update when the extension breaks" isn't appealing to users, and it doesn't do anything to create security. The average user only barely cares about their privacy: it is our task as security-conscious individuals to help them to be as private as possible. Telling users them that the only way to have any privacy that is to learn JavaScript and manually audit all code, then they will decide that privacy is overrated, and continue their unsafe habits. The most followed security recommendations are also the easiest: and there is no point in making them if they aren't followed. |
You are giving out bad vibes and are cherry picking comments to seemingly make a case for your own extension (are also making some contradicting statements). The speech is the sort that would worry one of those security conscious persons you mentioned, if they were honest. You may be genuinely trying to help, but if I was an author then recommending that my or any other Web Store extension is going to be safe in the future would simply feel dishonest and unwise. As much as you are promoting your Web Store extension, it is unarguably better from a usability-safety-risk ratio standpoint to load-unpacked from source which either enough others approved or I audited myself, then update manually on the same terms rarely (if a future browser update breaks it is a good recommendation). First, it's a common mistake (and reckless) to measure security by probability and omit cost -- it's the product of probability and cost of failure that matters, not probability alone. The real risk here is the author turning from an honest person to a malicious one, like so many extensions did. That has a cost incomparably greater than not using 2fa or a password manager (you are intentionally comparing malicious code after intrusion occurred, to suboptimal security before intrusion). When a high cost event happens then everyone is suddenly kicking themselves for not having put up with a little hassle in the past. Complacency and convenience are currencies for attackers. Second, It's a browser extension, not an OS kernel. Let's stop pretending there are important security implications if browser extensions are not kept up to date automatically, there is clearly more documented risk auto-updating than not, given they come from a known infected cesspool. Let's also stop pretending that pushing a web store version is intended to promote security when the reality is the exact opposite: Web Store extensions have enabled more (an explosion or!) malicious actions and less and worse (not more and better) security practice in users. I'm spectacularly uninspired seeing "The Real Great Suspender - The Real Original, Trust me, I'm Marvelously Honest" on Web Store. As with all things, security principles are not absolute: they should be adapted to the conditions of the problem, which must take cost into account. p.s. "Funny you should say that, what with the current Manifest V3 mess." - FF has been notorious, orders of magnitude worse, in terms of broken addon code by core code updates (even authors of some of the most popular addons gave up on it), but somehow attracted less malicious activity. |
I guess, but many people don't want or need every pet feature that deanoemcke added over many years, and as a developer I think the code suffers from a lack of focus. For example, if it had been written differently, users wouldn't have lost data when the extension was remote uninstalled - instead it's implemented in such a way that locks people in and makes it harder to switch to other solutions later on. I still have thousands of messed up TGS links in old OneTab* exports and chrome backups, for example. Anyway, I don't see the various forks as having enough momentum or the right incentives to really fix much. It's fine that Gioxx wants to run a fork as a hobby project, but the issues are basically identical as when Dean ran a hobby project. If people want to use a hobby project, fine, but let's be honest about what it is. It isn't "safe", merely "a bit less risky than the last thing, for now, as far as we can tell." And that's fine for a hobby project. And maybe that is good enough for whoever Calum is recommending it to. But I do need tools for my work, and I'd rather not lose any more data (or time) because I trusted it to a random hobby project from the internet; I will be using professional tools instead. Unfortunately on GitHub (and the Chrome Web Store) there's no real way to signal which projects are professional and which are hobbies.
|
This. The clear form of what I was implying regarding honesty above.
Over the years I developed anti-bodies to sentences such as "My project will always be free/safe/kept-out-of-reach-of- This last incident prompted me to think more about this very aspect: hobby projects turning popular then almost invariably abandoned or turned malicious, etc ... tons of examples. Rather than pushing a 17th version of "The Awesome Suspender - For Realz" to web store, I'm thinking of a "proof-of-community". Even a risk or alert score (that some might abuse) shown in Web Store when updating extensions, extracted from github issue comments restricted to those analyzing code, that also prevent auto-updates, would be more useful to me than the current cesspool of suspicious extensions and reviews that the Web Store is now.
It has the right idea but an annoying approach to it. FF had an addon a long while back (forgot the name) that would close tabs into a vertical sidebar so you could see and better read a ton of them, and save memory as they were all closed tabs into bookmarks - basically what OneTab should have been IMO. |
Responding to @aleqx
I'm not cherry picking: just trying to keep things legible by quoting only the relevant parts. Also, note that I am not related to The Marvelous Suspender in any way other than as a user. If it seems I am making contradictory statements, then that may be because I am writing as I go and fact-check myself against various sources. Please tell me so I can make any needed fixes.
I would absolutely agree: for you or me, people who are reasonably technically competent. But there are a whole lot more people in the world who aren't, and asking them to install git, enable developer tools, and load unpacked extensions isn't in a good place in that ratio of usability to risk (not sure why you have safety as separate). Our theoretical user isn't a JavaScript programmer, remember: so telling them to audit the code themselves is a non-starter. And asking them to rely on strangers on the internet as each individually verifying code? Where do you find those people, and how do you trust that they aren't just the attacker playing with sockpuppets? Our current conversation, and all related discussions, have had the advantage of working against a very passive attacker. @greatsuspender could, at any point, delete this and all other related GitHub issues. You cannot determine if a given extension is benevolent simply by visiting a website: while there are reliable infosec sources that document known-bad extensions, there is nothing similar for known-good. There is no way for a user to verify code as legitimate short of either auditing it, or waiting four months to see if it was malware. (PS: Yes, I see you posted another comment. It's not really viable)
I agree: AFAIK, I never did otherwise. To keep thing clear, lets define both before we continue:
I am unclear on your logic here. Carefully vetting the code of all your extensions and using mitigation techniques like 2fa and password managers are both precautions taken to reduce the chance of a severe compromise. They both require some effort compared to the alternative (installing from the web store and using "password123" on all sites, respectively), though 2fa and managers require less. However, while a password-stealing extension is a fairly rare event, a compromised website is not: and while vetting extension code provides protection only against password stealing extensions, 2fa and password managers provide protection against both compromising extensions and compromised websites. Further, the potential cost is actually quite similar: an attacker gaining control of your online accounts. These are sandboxed web extensions we are talking about: they have a completely different threat profile than traditional malware, which can't (easily) snoop web requests but can install permanent rootkits. Remote attackers don't get arbitrary and unlimited code execution (in the traditional sense) just because they can run their code in an extension: they live in a heavily-limited sandbox, just like every website you visit.
I never said that not updating your browser extension was a security risk: in fact, I was quite careful about not saying that, as we both know it's false. However, life isn't all about security: if I stopped updating uBlock Origin, I would eventually stop being able to block ads, as the filter lists are upgraded to use newer syntax. Features that get added and bugs that are fixed make up a key component of every update: pretending that the only use of an update is security is disingenuous. For you, security clearly comes as an absolute first: for many others, minor risks are acceptable in exchange for usability. I am not saying those views are correct: but they are certainly common, and will not be changed by a few nerds talking to themselves on Github.
Completely agreed. Which is why I think that code auditing is not a viable solution to this problem. The problem of maintainers become malicious is hardly new to the world of software. There is a population of people who built all the code on their machine from scratch. There is another, larger population[1] who exclusively run code that they can build from scratch, or otherwise inspect, at any time. But there is only a tiny number of people who have managed to audit every line of code on their machine. And not one of those people can turn around and post on a forum like GitHub. Why? Because a modern web browser is a beast of code complexity, and no single person could audit all of it. I'll get more into why the 'line of trust' should probably be on the other side of webstore extensions with over a million users when I address @nfultz's comment, but it boils down to the fact that 'hobby projects' make up the bulk of what is done. [1]: of which I am a member, baring a few legally-mandated binary blobs |
Replying to @nfultz
That's life? The Great Suspender isn't a lightweight tab suspender: it's a heavyweight background tab manager. If you want software without the fluff of extra features, then switch. I'm not sure what else to say.
In order to implement certain portions of it's functionality (portions which I use!), it needs to take over the tab in the way it does. Simply discarding the tab results in the tab being reloaded if you control-tab past it: which is not desirable behavior. Furthermore, the screen capturing functionality 100% requires this behavior. Also, the technique you are thinking of? Didn't exist when the extension was created. Chrome's ability to discard tabs in a sane way came after this extension was already an established player, and Google blog posts say that it was made in consultation with Dean.
I don't think I ever obscured that fact: I didn't even mention The Marvelous Suspender in the top post until after TGS's removal, IIRC. But if your standard for 'extensions you are willing to install' excludes hobby projects, boy have I got news for you. The extension marketplace is not a profitable one: if you are not asked to buy a subscription to unlock features, the extension author isn't making a living off direct contributions. The extension is either abusing your bandwidth, violating your privacy in technically-legal ways, or is the result of a hobby project. If it's open source, then it probably is a hobby project (there are open-source professional extensions, such as Bitwarden, but once again, those require a subscription for certain features). As for the question of entrusting your internet to a hobby project: I'm afraid you already do. Until a 2014 bug left the internet vulnerable, OpenSSL was maintained by two guys in their spare time. Chrome might be a vertically-integrated titan of vendored dependencies, but that doesn't mean that all those dependencies aren't, at the end of the day, hobby projects. Of course, that isn't a bad thing. Professional products are just as likely to be buggy and flawed as hobby projects, if not more so: but bugs in the hobbyists work are easy to track down, while you need to wait for the corporation to move if you want you professional product fixed. |
This is very true and sad. I wrote a replacement for the features from TGS I actually wanted (fairly close to v4.42 of TGS), posted it on kickstarter, and only raised $14. My session manager earned $6, and my proxy switcher extension $0. The economics just aren't there. Anyway, I prefer the page to load on ctrl-tab automatically, so probably not for you. And I'm not arguing against open source, I contribute to many open projects. Just because a project is open source and free does not mean it is a hobby project - GNU R is written by professional statisticians for statisticians, for example, and is substantially more advanced of it's commercial competitor, SAS and has a healthier ecosystem. But hobby projects probably shouldn't be one-click-installed by 1M+ people without anyone taking responsibility for it, especially if there's big potential downside. The Chrome Web Store has none of the transparency or governance that makes open-source actually work well, and the developer experience is atrocious. Now that Google has demonetized it, it will only get even less resources and staffing from them and continue to get worse. Really the best hope is for some of the features to get implemented in to chromium properly, but then I'd have to deal with gerrit again. |
Unless you meant specifically the tab suspending feature, then hoping for core code to include various extensions is far less likely than the proof-of-community idea I saw proposed above, not that said idea is overly hopeful either. Google could automate some extra security for extensions, e.g. execute them to determine if they make any HTTP calls to hosts different to the visited webpage, list said hosts, etc, presenting more info on the Web Store download page. Currently most extensions seem to like requesting all permissions. |
https://crxcavator.io/ already has risk scores, for whatever that's worth. Someone should write an extension to put the risk scores on the store page, ha. I would be surprised if Google puts any significant development or ops/support resources into CWS but chromium continues to be a reasonably healthy project. I pretty much suspect 80% of extensions will just get deleted when they turn off Manifest 2 later this year/early next year, some people will be upset for a few days and then move on. |
Neat - I didn't know of crxcavator.io, thanks for the pointer. I think @aleqx was thinking of risk scores from actual alerts/audits from guthub users, rather than automated, but crxcavator.io is useful for the "Potential External Communication" section ... this stuff should be automated by Google and displayed on Web Store for each extension. Agreed on 80% of extensions becoming obsolete when manifest 2 is banned, though the malicious extensions are more likely to be in the 20% than in the 80%. It's usually the hobby ones that are abandoned. |
I would conclude the best practice would be to load local src to Chrome in developer mode to avoid unwanted changes brought by addon's auto-update. In this issue, gioxx#23, some people seemed to have reviewed the Marvelous Suspender source code and conclude the current version is ok to use. I think the OP @aleqx and @TheMageKing would agree that if we were to use the Marvelous Suspender and not wanting it to auto-update, load the src code from https://github.com/gioxx/MarvellousSuspender/releases/tag/7.1.6.1 would be the way to go (which is what I did now). Strangely when I load the src, the version should show up as 7.1.6.1, but I see in the extension menu it is 7.1.6.2. Not sure why (I don't know about addon development, could be a typo in manifest.json). |
Reading this little lot had given me a headache as now I just don't know if to use the GitHub version or the Chrome Store version. Therefore I think I won't use either. |
I'm baffled at the huge number of people recommending to install alternative extensions still from Google Web Store, such as "The Marvelous Suspender" (*). Please realize that the same thing can happen again. You have no control over what the extension will do in the next update on the Web Store, who the author will sell it to, how many chinese/russian/etc dudes/dudettes will snoop on your form data and urls afterwards.
If you care about your privacy and security, given the high cost, then please stop using and recommending extensions from Web Store that have critical permissions, and consider putting up with the inconvenience of loading an unpacked version from source that you fetch from github which either (1) others confirmed is safe or (2) you can inspect yourself, and then manually update. If you don't have the skills then don't update yet but check the issues section and/or wait for others to reveal any issues, just like they did with this one, that's why it's open source.
These things can read your passwords off of submitted form data as most are not client side encrypted (using SSL doesn't help you) and you'll have no idea it happens until you hear of it months later in an obscure news article, if ever.
(*) Edit: To clarify, the issue is the Web Store version, not the Github version. I edited the title to remove possible confusion, seeing the developer picked on the name, rather than the actual issue. Fine to use the Github version of "the marevelous suspender" in the manner described above.
The text was updated successfully, but these errors were encountered: