[deleted]
Grammarly shared its tokens with all websites
41–50 of 176 posts
Re: Grammarly shared its tokens with all websites
#42Earlier quoted context omitted.
Aren't all password managers keyloggers too?
I am too paranoid to use them, but, from what I read (regarding the biggest one): "LastPass encrypts your Vault before it goes to the server using 256-bit AES encryption. Since the Vault is already encrypted before it leaves your computer and reaches the LastPass server, not even LastPass employees can see your sensitive data" If there is an attack still possible (even using LastPass employees) can you post it here?
Not sure if you're using the credential "autofill" feature, but somewhat recently there was an attack in which their autofill extension could be tricked into "autofilling" specific sites' credentials on a malicious webpage. (Not sure if this has been fixed by LastPass)
The fix for that was to not use autofill and revert to manually grabbing your username/password when filling out a login form.
Aside from that, I am not aware of other "hot" attack vectors.
Re: Grammarly shared its tokens with all websites
#43I blocked Grammarly at my last company, nothing like giving a company tracking access to everything you type or read, and their EULA gives them the rights to everything they track. Using Grammarly is stupid, paying them is downright insane.
We block extensions, period, on Google Chrome, as it prevents most malware outright. But then we've also discovered Grammarly's Microsoft Office plugin installs to the user folder (without requiring admin rights) as well. I've made a request to our antivirus vendor to add detection and blocking of Grammarly specifically, for the moment we're detecting it a different way.
[deleted]
Re: Grammarly shared its tokens with all websites
#44This, just like Mozilla’s screenshot addon, and all the other examples, shows why it’s an insane idea to mix addon content with the websites, and why it’s important to make sure that addon content can run on the UI layer of the browser, and not within of the content of the sites. Relying on "best practices" is always a security disaster waiting to happen, if you don’t enforce security and separation in the design of…
> it’s important to make sure that addon content can run on the UI layer of the browser, and not within of the content of the sites I don't get this thinking at all. Browser addons are trusted. That's the point - they have special privileges to adjust browser behaviour. If you go around installing malicious addons, you get no more sympathy from me than if you'd gone around installing malicious kernel modules.
The problem is the opposite.
For example, Firefox’ screenshot addon would inject HTML into the page, and then the page could take the screenshot’s data and use it.
Addons currently have no way to reliably display their own UI on top of the page, without the page intercepting it.
Re: Grammarly shared its tokens with all websites
#45Earlier quoted context omitted.
Extensions modifying pages is fine, but often an extension wants to show custom UI on top of the page. It’d be much more secure to allow the extension to do that without requiring it to put this into the page. For example, currently you have the DOM of the page, and the extension’s UI is injected into it. It would be preferable if you’d treat each tab as if it was like This way an extension that wants to show secure…
Some extensions like Google Inbox for Chrome will inject a single `iframe` that points to a `chrome-extension://` page, so while the page might notice the element, it can't access its content. I think you could use the Shadow DOM in closed mode to prevent any information from leaking. [1] [1]: https://blog.revillweb.com/open-vs-closed-shadow-dom-9f3d742...
Pages sadly could still detect this content, and change their behaviour based on it.
Ideally you’d want to allow addons to modify pages in a way that pages can not detect or interfere with.
(e.g., some newspapers used to run JS to remove the AdBlock "block this" UI whenever you tried to remove an ad)
Re: Grammarly shared its tokens with all websites
#46I have no idea if it's still an issue, but ~1.5 years ago, I was sorting through my email, and discovered that a small plain text message was taking up >3MB in my inbox.
I dug in a bit, and it turns out that Grammarly was embedding a gigantic amount of code into the email messages in the form of stylesheets and other things.
Needless to say, after raising it up the chain, we had the extension blocked company-wide.
Re: Grammarly shared its tokens with all websites
#47Earlier quoted context omitted.
> it’s important to make sure that addon content can run on the UI layer of the browser, and not within of the content of the sites I don't get this thinking at all. Browser addons are trusted. That's the point - they have special privileges to adjust browser behaviour. If you go around installing malicious addons, you get no more sympathy from me than if you'd gone around installing malicious kernel modules.
The problem is the opposite. For example, Firefox’ screenshot addon would inject HTML into the page, and then the page could take the screenshot’s data and use it. Addons currently have no way to reliably display their own UI on top of the page, without the page intercepting it.
Oh, right, I didn't get that from your original comment.
I agree, addons' workings shouldn't be exposed to untrusted websites.
Re: Grammarly shared its tokens with all websites
#48Earlier quoted context omitted.
Aren't all password managers keyloggers too?
I am too paranoid to use them, but, from what I read (regarding the biggest one): "LastPass encrypts your Vault before it goes to the server using 256-bit AES encryption. Since the Vault is already encrypted before it leaves your computer and reaches the LastPass server, not even LastPass employees can see your sensitive data" If there is an attack still possible (even using LastPass employees) can you post it here?
Project Zero has found a number of major flaws in the LastPass extension.
https://bugs.chromium.org/p/project-zero/issues/detail?id=88... https://bugs.chromium.org/p/project-zero/issues/detail?id=11... https://bugs.chromium.org/p/project-zero/issues/detail?id=12... https://bugs.chromium.org/p/project-zero/issues/detail?id=12... https://bugs.chromium.org/p/project-zero/issues/detail?id=12...
At a glance what they have in common is flaws in the scripts that the LastPass extension injects into pages. The injected scripts can communicate with the extension core with a set of RPCs. Each of these issues is a way of tricking the extension into running RPCs from untrusted JavaScript on any web page. The RPCs available allow an attacker to fetch the credentials for any site in the database or even execute arbitrary code on the host.
Re: Grammarly shared its tokens with all websites
#49I have no idea if it's still an issue, but ~1.5 years ago, I was sorting through my email, and discovered that a small plain text message was taking up >3MB in my inbox. I dug in a bit, and it turns out that Grammarly was embedding a gigantic amount of code into the email messages in the form of stylesheets and other things. Needless to say, after raising it up the chain, we had the extension blocked company-wide.
I uninstalled it a couple of years ago when I realized it was doubling the load times for every single page I visited. That embedded code is probably why.
Re: Grammarly shared its tokens with all websites
#50Earlier quoted context omitted.
It seems like it would be more fair for the headline to use the past tense.
Gotta get that HN karma tho
You are getting down votes because HN has a policy that the HN Title should match the Title on the link to prevent editorializing in almost all cases.
This prevents users from creating click bait headlines to get that karma tho, the majority of the time. Cases where the actual title is the click bait like this one, are the unintended consequence of that policy.