6 ms·

All Chrome extensions can execute remote code in their own context

85 points by nitrohorse 7y ago

arkadiyt 7y ago
Even without this issue all chrome extensions can execute code in their own context by explicitly setting a blob script-src rather than relying on the default, or by skipping the middle step and adding a domain they control to the script-src and directly linking a javascript file (why bother with blobs?), or even by pushing a new version which Chrome will automatically install for users. The title makes this issue sound severe but it's just a missing best practice.
- kevingadd 7y ago
  I think "best practice" is a mistake in this context since it's an undocumented (?) change that has allowed malicious extensions to hide in plain sight - the default policy should not allow the naughty stuff they got up to, but it did because someone on the Chromium team weakened the security policy. Why audit for something that's impossible? (Obviously, thorough security screening WOULD audit for the impossible.) This is worsened by the fact that the Play Store has near-zero security controls and no review so it's easy for malicious code to sneak into basically any high-install-count extension, especially if (as many extensions do) it requested lots of permissions it doesn't need.
  - bscphil 7y ago
    Maybe I'm misunderstanding the nature of the problem, but is there any way to fix the issue without breaking extensions like Greasemonkey?
    - kevingadd 7y ago
      Well, you can start by requiring the extensions to actually request all the permissions they use. Chrome does that now but has very coarse-grained permissions which makes it easier to hide malicious behavior, and in this case the permissions just weren't working so you could do something bad without the permission. The way extension permissions work in Chrome also means that extensions tend to request permissions they don't currently use, which means they can quietly pick up nasty behavior later on. In the end an extension like Greasemonkey is implicitly unsafe because it's designed to run third-party content. You can't really fix that at an extension store/distribution platform level - so you put that dangerous footgun behind a permission and make sure users know what they're in for when installing it. I'm not sure what else you could really do since greasemonkey scripts rely on the ability to muck with page content.
gruez 7y ago
Can someone screenshot the page? I'm getting "permission denied" followed by a redirect to google sign in.
- nexuist 7y ago
  I'm guessing this was quickly hidden by Google staff based on its severity? Unless this was released following responsible disclosure practices, in which case I don't know what I'm talking about.
  - kowdermeister 7y ago
    Or it was that kind of bug report where the reporter made a normal thing sound dangerous. I remember one case when someone suggested that JS should be turned off by default because "arbitrary code execution" :) Edit: with chrome extensions, I can inject a script tag from any domain to any page. I used that to inject a lib from CDN JS, but recognized it's silly and imported the package instead.
    - domnomnom 7y ago
      But wait that’s actually a good point
- nitrohorse 7y ago
  Yeah, looks like the report is hidden now. Unfortunately it wasn't captured in the wayback machine.
  - sam1r 7y ago
    What happens to those that are still curious? One may ask.
    - edoceo 7y ago
      We wait for a post-mortem
FloatArtifact 7y ago
Is any browser that utilizes WebKit extensions at risk or just chrome?
hughes 7y ago
What legitimate use case is there for a blob script-src in a browser extension?
- Sephr 7y ago
  Development-related extensions will need that when replacing some assets, among other use cases.
nitrohorse 7y ago
Here's the proof-of-concept extension by gorhill for anyone interested: https://gist.github.com/gorhill/b0316e35d4e7e4a44df39e8b7fa5ac20 https://gist.github.com/gorhill/b0316e35d4e7e4a44df39e8b7fa5.... Looks like his tweets regarding this have also been deleted.
- deleted 7y ago
  [deleted]
- btown 7y ago
  If this is as severe as I think it is, you may seriously want to consider taking down this link. Google and @gorhill have likely made things private for a reason.
  - jakeogh 7y ago
    Why? The model is wrong. There are always going to be severe bugs in deliberately complicated software. Hiding them behind terms that pretend the issue is about responsible disclosure is much more harmful in the long run because the real problem does not get fixed. Instead, due to a dependence on bad software, the problem can be used to attack speech.
  - 0az 7y ago
    Not necessary: between when I loaded this page five minutes ago and when I logged in to comment, the gist was pulled.
- kretor 7y ago
  This has been reported before, though not for extensions specifically: https://bugs.chromium.org/p/chromium/issues/detail?id=329125 https://bugs.chromium.org/p/chromium/issues/detail?id=329125 The result back then was that the reported behavior is in accordance with the CSP spec, so the issue was closed. Maybe Chrome should change their default CSP for extensions that haven't declared one though to disallow blob: URLs.
- doc_gunthrop 7y ago
  That link is returning a 404 now, but an archive was posted: https://archive.is/hi5o1 https://archive.is/hi5o1
tonetheman 7y ago
I think this is by design maybe https://developer.chrome.com/extensions/contentSecurityPolicy https://developer.chrome.com/extensions/contentSecurityPolic... Look at the section named "Evaluated Javascript"

85 points by nitrohorse 7y ago

Even without this issue all chrome extensions can execute code in their own context by explicitly setting a blob script-src rather than relying on the default, or by skipping the middle step and adding a domain they control to the script-src and directly linking a javascript file (why bother with blobs?), or even by pushing a new version which Chrome will automatically install for users. The title makes this issue sound severe but it's just a missing best practice.

kevingadd 7y ago
I think "best practice" is a mistake in this context since it's an undocumented (?) change that has allowed malicious extensions to hide in plain sight - the default policy should not allow the naughty stuff they got up to, but it did because someone on the Chromium team weakened the security policy. Why audit for something that's impossible? (Obviously, thorough security screening WOULD audit for the impossible.) This is worsened by the fact that the Play Store has near-zero security controls and no review so it's easy for malicious code to sneak into basically any high-install-count extension, especially if (as many extensions do) it requested lots of permissions it doesn't need.
- bscphil 7y ago
  Maybe I'm misunderstanding the nature of the problem, but is there any way to fix the issue without breaking extensions like Greasemonkey?
  - kevingadd 7y ago
    Well, you can start by requiring the extensions to actually request all the permissions they use. Chrome does that now but has very coarse-grained permissions which makes it easier to hide malicious behavior, and in this case the permissions just weren't working so you could do something bad without the permission. The way extension permissions work in Chrome also means that extensions tend to request permissions they don't currently use, which means they can quietly pick up nasty behavior later on. In the end an extension like Greasemonkey is implicitly unsafe because it's designed to run third-party content. You can't really fix that at an extension store/distribution platform level - so you put that dangerous footgun behind a permission and make sure users know what they're in for when installing it. I'm not sure what else you could really do since greasemonkey scripts rely on the ability to muck with page content.

gruez 7y ago

Can someone screenshot the page? I'm getting "permission denied" followed by a redirect to google sign in.

nexuist 7y ago
I'm guessing this was quickly hidden by Google staff based on its severity? Unless this was released following responsible disclosure practices, in which case I don't know what I'm talking about.
- kowdermeister 7y ago
  Or it was that kind of bug report where the reporter made a normal thing sound dangerous. I remember one case when someone suggested that JS should be turned off by default because "arbitrary code execution" :) Edit: with chrome extensions, I can inject a script tag from any domain to any page. I used that to inject a lib from CDN JS, but recognized it's silly and imported the package instead.
  - domnomnom 7y ago
    But wait that’s actually a good point
nitrohorse 7y ago
Yeah, looks like the report is hidden now. Unfortunately it wasn't captured in the wayback machine.
- sam1r 7y ago
  What happens to those that are still curious? One may ask.
  - edoceo 7y ago
    We wait for a post-mortem

FloatArtifact 7y ago

Is any browser that utilizes WebKit extensions at risk or just chrome?

hughes 7y ago

What legitimate use case is there for a blob script-src in a browser extension?

Sephr 7y ago
Development-related extensions will need that when replacing some assets, among other use cases.

nitrohorse 7y ago

Here's the proof-of-concept extension by gorhill for anyone interested: https://gist.github.com/gorhill/b0316e35d4e7e4a44df39e8b7fa5ac20 https://gist.github.com/gorhill/b0316e35d4e7e4a44df39e8b7fa5.... Looks like his tweets regarding this have also been deleted.

deleted 7y ago
[deleted]
btown 7y ago
If this is as severe as I think it is, you may seriously want to consider taking down this link. Google and @gorhill have likely made things private for a reason.
- jakeogh 7y ago
  Why? The model is wrong. There are always going to be severe bugs in deliberately complicated software. Hiding them behind terms that pretend the issue is about responsible disclosure is much more harmful in the long run because the real problem does not get fixed. Instead, due to a dependence on bad software, the problem can be used to attack speech.
- 0az 7y ago
  Not necessary: between when I loaded this page five minutes ago and when I logged in to comment, the gist was pulled.
kretor 7y ago
This has been reported before, though not for extensions specifically: https://bugs.chromium.org/p/chromium/issues/detail?id=329125 https://bugs.chromium.org/p/chromium/issues/detail?id=329125 The result back then was that the reported behavior is in accordance with the CSP spec, so the issue was closed. Maybe Chrome should change their default CSP for extensions that haven't declared one though to disallow blob: URLs.
doc_gunthrop 7y ago
That link is returning a 404 now, but an archive was posted: https://archive.is/hi5o1 https://archive.is/hi5o1

tonetheman 7y ago

I think this is by design maybe https://developer.chrome.com/extensions/contentSecurityPolicy https://developer.chrome.com/extensions/contentSecurityPolic... Look at the section named "Evaluated Javascript"