4 ms·

what are the security implications of permanently running chrome in remote debug mode? a bit more than half a year ago I started playing around with this and w

by aloer 7y ago

what are the security implications of permanently running chrome in remote debug mode? a bit more than half a year ago I started playing around with this and was surprised how on the one hand there are really really good tools nowadays for self archiving but how on the other hand there hasn't been any progress in implementing these in a, for end users, comfortable way My working theory right now is that saving every request/response as well as every interaction on a page should allow us to completely restore web site state at any point in time and will open up some super interesting use cases around our interaction with information found online But in order to do this it seems necessary to go through the remote debug protocol like this project here is doing. And since this is somewhat of an unusual approach I could not find much information about the security aspect of running every site at any time with remote debugging activated. Common web scrapers/archiving tools will instead only use remote chrome debug to open and capture specific urls Storage is so dirt cheap today that there is zero reason why we shouldn't have reliable historic website state for everything we have ever looked at And judging by the HN front pages of the last months, many here are interested in this and related use cases (search/index/annotations/collaborative browsing)

sneak 7y ago
> Storage is so dirt cheap today that there is zero reason why we shouldn't have reliable historic website state for everything we have ever looked at I agree entirely, but I do about half my reading on mobile, and the phone company and the ad company have both decided that I shouldn’t be able to run extensions of any kind in the browsers available on my phone company phone or my ad company phone. I’m not really sure of the solution. I had planned to start a business around this, but without mobile support it is probably a nonstarter.
- gildas 7y ago
  For your information, SingleFile can run on Firefox for Android [1]. [1] https://github.com/gildas-lormeau/SingleFile https://github.com/gildas-lormeau/SingleFile
  - sneak 7y ago
    All of my contacts use iMessage; Signal is starting to be viable with their iPad release now though. I am concerned about switching from Chrome to Firefox still on security grounds, but this may be sufficient to make me switch.
    - skinnymuch 7y ago
      Wait why is Chrome good for security and Firefox not?
      - sneak 7y ago
        Chrome’s sandboxing is unparalleled in the browser space. No other browser comes close, unless you are running something in Qubes or suchlike. Then it doesn’t much matter.
        wildfire 7y ago
        Do you have a link which might give further information about how the sandboxing that Firefox offers and the one that Chrome offers are different? I was under the impression that they were very similar.
- alistproducer2 7y ago
  Run your phone traffic through a proxy and have the proxy cache stuff.
  - highmastdon 7y ago
    Proxy can't intercept https, if I'm correct
- stazz1 7y ago
  There's something there -- if you can translate time or resource savings into value
archivist1 7y ago
> What are the security implications of running in remote debugging mode? Great question. First up, as long as you don't put --remote-debugging-address=0.0.0.0 you are only exposed locally, so the debugging endpoint can only be accessed from your local machine. That leaves open the possibility that a web page can access that. There's two possibilities: - fetch('http://localhost:9222/json' http://localhost:9222/json') which errors or is opaque because it is non CORS, or - connecting directly to the websockets for targets, which have addresses like, http://localhost:9222/devtools/page/<128_bit_hex_string> http://localhost:9222/devtools/page/<128_bit_hex_string> Interestingly, you can connect to the websocket, you just need to know the random identifier. There are probably some DevTools zero days, but apart from those it looks like it's OK unless: 0) the identifier is not random, 1) you can get past CORS on the localhost which might be possible with an exploited extension, 3rd party software or plugin or 2) you can guess the websocket 128-bit identifier. (Guessing should only take 500 billion years. Even so 128 bits seems quite short relative to some encryption keys but there's probably a reason for that.) Regarding 0) checking the Chromium source it appears that these ids are passed in to the constructor of "DevToolsAgentHostImpl": https://cs.chromium.org/chromium/src/content/browser/devtools/devtools_agent_host_impl.cc?sq=package:chromium&dr=C&g=0&l=93 https://cs.chromium.org/chromium/src/content/browser/devtool... and are either "GUID"s or "tokens" and in the former case they are created here: https://cs.chromium.org/chromium/src/base/guid.cc?sq=package:chromium&dr=C&g=0&l=47 https://cs.chromium.org/chromium/src/base/guid.cc?sq=package... and in the latter case by a class revealingly named "unguessabletoken.h": https://cs.chromium.org/chromium/src/base/unguessable_token.h?sq=package:chromium&dr=C&g=0&l=50 https://cs.chromium.org/chromium/src/base/unguessable_token.... which in each case appears to rely on getting random bytes from a file descriptor to "urandom" which I think is an operating system level randomness primitive.
- oefrha 7y ago
  Is it possible to send a no-cors POST that causes side effects (regardless of the opaque response)? I have only used the DevTools protocol through puppeteer, so don’t know anything about its authentication. Could it be vulnerable?
  - 7y ago
deleted 7y ago
[deleted]
HerpDerpLerp 7y ago
I mean your using chrome so presumably you are not that fussed about sharing your data with a mega corp... why worry about anyone else seeing it?

by aloer 7y ago

sneak 7y ago

> Storage is so dirt cheap today that there is zero reason why we shouldn't have reliable historic website state for everything we have ever looked at I agree entirely, but I do about half my reading on mobile, and the phone company and the ad company have both decided that I shouldn’t be able to run extensions of any kind in the browsers available on my phone company phone or my ad company phone. I’m not really sure of the solution. I had planned to start a business around this, but without mobile support it is probably a nonstarter.

gildas 7y ago
For your information, SingleFile can run on Firefox for Android [1]. [1] https://github.com/gildas-lormeau/SingleFile https://github.com/gildas-lormeau/SingleFile
- sneak 7y ago
  All of my contacts use iMessage; Signal is starting to be viable with their iPad release now though. I am concerned about switching from Chrome to Firefox still on security grounds, but this may be sufficient to make me switch.
  - skinnymuch 7y ago
    Wait why is Chrome good for security and Firefox not?
    - sneak 7y ago
      Chrome’s sandboxing is unparalleled in the browser space. No other browser comes close, unless you are running something in Qubes or suchlike. Then it doesn’t much matter.
      - wildfire 7y ago
        Do you have a link which might give further information about how the sandboxing that Firefox offers and the one that Chrome offers are different? I was under the impression that they were very similar.
alistproducer2 7y ago
Run your phone traffic through a proxy and have the proxy cache stuff.
- highmastdon 7y ago
  Proxy can't intercept https, if I'm correct
stazz1 7y ago
There's something there -- if you can translate time or resource savings into value

archivist1 7y ago

> What are the security implications of running in remote debugging mode? Great question. First up, as long as you don't put --remote-debugging-address=0.0.0.0 you are only exposed locally, so the debugging endpoint can only be accessed from your local machine. That leaves open the possibility that a web page can access that. There's two possibilities: - fetch('http://localhost:9222/json' http://localhost:9222/json') which errors or is opaque because it is non CORS, or - connecting directly to the websockets for targets, which have addresses like, http://localhost:9222/devtools/page/<128_bit_hex_string> http://localhost:9222/devtools/page/<128_bit_hex_string> Interestingly, you can connect to the websocket, you just need to know the random identifier. There are probably some DevTools zero days, but apart from those it looks like it's OK unless: 0) the identifier is not random, 1) you can get past CORS on the localhost which might be possible with an exploited extension, 3rd party software or plugin or 2) you can guess the websocket 128-bit identifier. (Guessing should only take 500 billion years. Even so 128 bits seems quite short relative to some encryption keys but there's probably a reason for that.) Regarding 0) checking the Chromium source it appears that these ids are passed in to the constructor of "DevToolsAgentHostImpl": https://cs.chromium.org/chromium/src/content/browser/devtools/devtools_agent_host_impl.cc?sq=package:chromium&dr=C&g=0&l=93 https://cs.chromium.org/chromium/src/content/browser/devtool... and are either "GUID"s or "tokens" and in the former case they are created here: https://cs.chromium.org/chromium/src/base/guid.cc?sq=package:chromium&dr=C&g=0&l=47 https://cs.chromium.org/chromium/src/base/guid.cc?sq=package... and in the latter case by a class revealingly named "unguessabletoken.h": https://cs.chromium.org/chromium/src/base/unguessable_token.h?sq=package:chromium&dr=C&g=0&l=50 https://cs.chromium.org/chromium/src/base/unguessable_token.... which in each case appears to rely on getting random bytes from a file descriptor to "urandom" which I think is an operating system level randomness primitive.

oefrha 7y ago
Is it possible to send a no-cors POST that causes side effects (regardless of the opaque response)? I have only used the DevTools protocol through puppeteer, so don’t know anything about its authentication. Could it be vulnerable?
- 7y ago

deleted 7y ago

[deleted]

HerpDerpLerp 7y ago

I mean your using chrome so presumably you are not that fussed about sharing your data with a mega corp... why worry about anyone else seeing it?