Comment by aloer | Hacker News Reader

Comment by aloer | Hacker News Reader

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)

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

For your information, SingleFile can run on Firefox for Android [1].

[1] https://github.com/gildas-lormeau/SingleFile

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.

Wait why is Chrome good for security and Firefox not?

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.

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.

Run your phone traffic through a proxy and have the proxy cache stuff.

Proxy can't intercept https, if I'm correct

There's something there -- if you can translate time or resource savings into value

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

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

and in the latter case by a class revealingly named "unguessabletoken.h":

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.

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?

your browser will refuse to send the xhr post when the preflight options request does not allow it with CORS headers.

POST requests don’t necessarily trigger preflight. But now that I think about it, the DevTools protocol most likely does not accept application/x-www-form-urlencoded, so good point.

Besides the websocket, the protocol has a couple of HTTP endpoints, you can see commands here:

https://cs.chromium.org/chromium/src/content/browser/devtool...

which looks like it ignores the HTTP verb and acts only on the path. I confirmed this with tests: fetch('http://localhost:9222/json/new') and fetch('http://localhost:9222/json/new, {method:'POST', body:''}) do the same thing, as does using verb 'DELETE'.

All these open a new tab. Without knowing a 128-bit target identifier, it looks like opening a new tab is the only thing you can do if someone is running DevTools.

> - fetch('http://localhost:9222/json') which errors or is opaque because it is non CORS, or

What about DNS rebinding attacks?

It looks like this was patched a few months back, around ~M66

https://bugs.chromium.org/p/chromium/issues/detail?id=813540

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?

Reply on news.ycombinator.com