5 ms·

Until widespread code-signing exists on the web this seems incredibly reckless to expose. Even if you require https and put it behind a modal, history has shown

Until widespread code-signing exists on the web this seems incredibly reckless to expose. Even if you require https and put it behind a modal, history has shown that both of those measures are not impenetrable barriers to attackers and raw sockets open up a whole new set of attacks. HTTPS is basically useless for authenticating dangerous code: There are thousands of https domains out there that you can easily put your own code onto, and many of them have EV/DV certificates with reputable names like GitHub attached to them so there won't be any obvious red flags other than the text of the domain name. A prompt with a textbox in it is a barrier but it's not hard to get users to paste random stuff into text fields (just look at the big message that appears when you open devtools in Discord warning people not to paste stuff in there) and I agree with the concern that eventually the text box will be made friendlier. Many existing Dangerous APIs have worst-case attacks that just do things like talk to a USB device from a small list of authorized devices or talk to a MIDI keyboard. Raw Sockets are an entire new world of attacks: Hit a router or PC on the local network with a zero day and get persistent root on it, then use that to spread through the network and perform a ransomware attack, etc. The blink team needs to accept reality and catch up with where native apps have been for over a decade: Require code signing with revocable certificates and pair that with a mechanism to ensure the code was signed by the owner of the domain.

lukevp 6y ago
Why does discord even let users access dev tools? This is trivially easy to disable in prod builds. Seems odd. Is there a valid use case?
- ddulaney 6y ago
  I assume the parent is referring to the web version, where a big warning is output on the console of the browser’s built-in dev tools. I don’t know of any way for a website to disable the browser’s dev tools.
  - lukevp 6y ago
    Makes sense, forgot there was a web client. Thanks!
- throwaways885 6y ago
  Many products show this warning e.g. Google Photos, Facebook.
- akersten 6y ago
  > Why does discord even let users access dev tools? This is trivially easy to disable in prod builds. Even if you disable the usual way to pop the dev tools open in desktop electron mode, this is a dangerous attitude. A malicious client can always edit the DOM, send arbitrary data to your server, read whatever you send back, etc. "Disabling the dev tools" is never the correct solution to any security problem.
  - lukevp 6y ago
    I didn’t say that they should do this for security of the execution environment of the code, I’m not sure how you got to that interpretation. The GP said that there is output to tell users not to compromise themselves by blindly pasting unsafe code, which is easily prevented by disabling dev tools altogether, and there is no reason for an end user to have access to dev tools in an electron app. The other replies are probably what the GP meant and were related to the web version of discord.
    - j-james 6y ago
      > there is output to tell users not to compromise themselves by blindly pasting unsafe code For reference: https://user-images.githubusercontent.com/47160230/51995729-275e2680-24ab-11e9-8b1b-470c62883ec0.png https://user-images.githubusercontent.com/47160230/51995729-... This is also present in the Electron version of Discord. > there is no reason for an end user to have access to dev tools in an electron app. Certainly there is - there are various user-made applications that take advantage of Discord being built on Electron to allow you to write your own custom styles and scripts.
jackewiehose 6y ago
> Until widespread code-signing exists on the web this seems incredibly reckless to expose. [...] HTTPS is basically useless for authenticating dangerous code: There are thousands of https domains out there that you can easily put your own code onto, and many of them have EV/DV certificates with reputable names like GitHub attached to them so there won't be any obvious red flags other than the text of the domain name How would code-signing be any better than HTTPS-certificates? That sounds like just another instance you would have to pay fees to.
- skybrian 6y ago
  You can sign the code on your own computer (which might even be offline) before deploying on some other company's server. So, it's harder for an attacker to get their code signed using your certificate. Hacking into the website would be useless; they'd have to get the code into the development environment. Or to put it another way, an HTTPS server automatically signs any file that it serves. That's too easy.
  - kevingadd 6y ago
    "an HTTPS server automatically signs any file that it serves" is a perfect way to put it. When it comes to getting access to code signing certificates, in many cases the state of the art is to have the signing certificate escrowed so aggressively that the only way to sign a binary is for it to go through a full build pipeline, because the central build servers are the only thing with access to the certificate. That significantly reduces the risk of someone managing to get your signing certificate and sign malware, which means you can focus on other vulnerabilities in your pipeline like your revision control server or your library dependencies.
  - modeless 6y ago
    You could achieve this with HTTPS and Signed Exchanges. https://developers.google.com/web/updates/2018/11/signed-exchanges https://developers.google.com/web/updates/2018/11/signed-exc...
    - 6y ago
philips 6y ago
How would code signing be helpful? How would the key end up being trusted? I do think that content pinning/notarization of web apps could be powerful. We are building some of those ideas here but and I have an interest in how this could be used to pin critical apps to an audited/approved version: https://transparencylog.com https://transparencylog.com
- kevingadd 6y ago
  The attack scenario with current https is "get a file on the server". That's all you have to do in order to get full permissions because we're gating features behind https. If features require combination of https + code signing, you now need to not only get a file on the server, but you need to sign it. For high privilege APIs you would likely also want to do certificate approval like Windows does, where it shows you the certificate and asks whether you want to approve and whether you want to trust the signer. In many cases websites are loading code off a CDN, so the domain name of the website isn't actually important: the identity of the code's author is important and its integrity is important. You could also configure your server to pin a given code signing certificate or set of certificates, and thus even if someone manages to get code onto your server that they signed, it wouldn't run. Modern web platform APIs do have a way to specify expected hashes when loading external resources, so you can protect yourself against a third party (like a CDN) being compromised - but this does nothing if your server gets compromised, because they can just change the hash.
theandrewbailey 6y ago
The closest to code-signing on the web is subresource integrity, a feature that adds an integrity hash to script and style tags.[0] There was a directive in content-security-policy that allowed you to require them for everything on a page, but that looks like it's been depreciated.[1] [0] https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/require-sri-for https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

lukevp 6y ago

Why does discord even let users access dev tools? This is trivially easy to disable in prod builds. Seems odd. Is there a valid use case?

ddulaney 6y ago
I assume the parent is referring to the web version, where a big warning is output on the console of the browser’s built-in dev tools. I don’t know of any way for a website to disable the browser’s dev tools.
- lukevp 6y ago
  Makes sense, forgot there was a web client. Thanks!
throwaways885 6y ago
Many products show this warning e.g. Google Photos, Facebook.
akersten 6y ago
> Why does discord even let users access dev tools? This is trivially easy to disable in prod builds. Even if you disable the usual way to pop the dev tools open in desktop electron mode, this is a dangerous attitude. A malicious client can always edit the DOM, send arbitrary data to your server, read whatever you send back, etc. "Disabling the dev tools" is never the correct solution to any security problem.
- lukevp 6y ago
  I didn’t say that they should do this for security of the execution environment of the code, I’m not sure how you got to that interpretation. The GP said that there is output to tell users not to compromise themselves by blindly pasting unsafe code, which is easily prevented by disabling dev tools altogether, and there is no reason for an end user to have access to dev tools in an electron app. The other replies are probably what the GP meant and were related to the web version of discord.
  - j-james 6y ago
    > there is output to tell users not to compromise themselves by blindly pasting unsafe code For reference: https://user-images.githubusercontent.com/47160230/51995729-275e2680-24ab-11e9-8b1b-470c62883ec0.png https://user-images.githubusercontent.com/47160230/51995729-... This is also present in the Electron version of Discord. > there is no reason for an end user to have access to dev tools in an electron app. Certainly there is - there are various user-made applications that take advantage of Discord being built on Electron to allow you to write your own custom styles and scripts.

jackewiehose 6y ago

> Until widespread code-signing exists on the web this seems incredibly reckless to expose. [...] HTTPS is basically useless for authenticating dangerous code: There are thousands of https domains out there that you can easily put your own code onto, and many of them have EV/DV certificates with reputable names like GitHub attached to them so there won't be any obvious red flags other than the text of the domain name How would code-signing be any better than HTTPS-certificates? That sounds like just another instance you would have to pay fees to.

skybrian 6y ago
You can sign the code on your own computer (which might even be offline) before deploying on some other company's server. So, it's harder for an attacker to get their code signed using your certificate. Hacking into the website would be useless; they'd have to get the code into the development environment. Or to put it another way, an HTTPS server automatically signs any file that it serves. That's too easy.
- kevingadd 6y ago
  "an HTTPS server automatically signs any file that it serves" is a perfect way to put it. When it comes to getting access to code signing certificates, in many cases the state of the art is to have the signing certificate escrowed so aggressively that the only way to sign a binary is for it to go through a full build pipeline, because the central build servers are the only thing with access to the certificate. That significantly reduces the risk of someone managing to get your signing certificate and sign malware, which means you can focus on other vulnerabilities in your pipeline like your revision control server or your library dependencies.
- modeless 6y ago
  You could achieve this with HTTPS and Signed Exchanges. https://developers.google.com/web/updates/2018/11/signed-exchanges https://developers.google.com/web/updates/2018/11/signed-exc...
  - 6y ago

philips 6y ago

How would code signing be helpful? How would the key end up being trusted? I do think that content pinning/notarization of web apps could be powerful. We are building some of those ideas here but and I have an interest in how this could be used to pin critical apps to an audited/approved version: https://transparencylog.com https://transparencylog.com

kevingadd 6y ago
The attack scenario with current https is "get a file on the server". That's all you have to do in order to get full permissions because we're gating features behind https. If features require combination of https + code signing, you now need to not only get a file on the server, but you need to sign it. For high privilege APIs you would likely also want to do certificate approval like Windows does, where it shows you the certificate and asks whether you want to approve and whether you want to trust the signer. In many cases websites are loading code off a CDN, so the domain name of the website isn't actually important: the identity of the code's author is important and its integrity is important. You could also configure your server to pin a given code signing certificate or set of certificates, and thus even if someone manages to get code onto your server that they signed, it wouldn't run. Modern web platform APIs do have a way to specify expected hashes when loading external resources, so you can protect yourself against a third party (like a CDN) being compromised - but this does nothing if your server gets compromised, because they can just change the hash.

theandrewbailey 6y ago

The closest to code-signing on the web is subresource integrity, a feature that adds an integrity hash to script and style tags.[0] There was a directive in content-security-policy that allowed you to require them for everything on a page, but that looks like it's been depreciated.[1] [0] https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/require-sri-for https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...