6 ms·

Browsers don’t let you send raw UDP packets for the same reason they don’t let you send raw TCP packets: because devices in home and business networks implicitl

Browsers don’t let you send raw UDP packets for the same reason they don’t let you send raw TCP packets: because devices in home and business networks implicitly trust many packets coming from inside your network. A short list of things you could do with raw TCP / UDP capabilities: - Reconfigure a user’s router (if they have the default password) - Print to a network printer - Poison the home network ARP table - Various network level DOS attacks (ICMP echo flooding attacks, etc) - Control smart home appliances - Access network shares - Insanely invasive fingerprinting (including figuring out the make and model of other devices in the user’s house). So no, it’s a terrible idea. I don’t want webpages printing things, turning my lights on and off or knowing anything else about me. If you want the benefits of UDP through your browser, use webrtc or wait for HTTP3 or Webtransport. The author seems to want the OS to have no knowledge or involvement in the network protocol, for unknown reasons. But they obviously think the user’s web browser is fine. From the point of view of a web application, what’s the difference? And again - what actual benefits would there be to raw UDP access? The article is very light on specifics.

xxs 4y ago
The connectivity to any address/host would be a bad idea, what about restricting only to the same host of document's origin. Edit: Java's applets used to have the bog standard TCP (and UDP) and since late 90s. While Java/applets were a security nightmare, as all of them run in the same process and the impl. of SecurityManager (and its checks) was not up to the task [along with various deserialization exploits], the connectivity was not an issue.
- teraflop 4y ago
  Same-origin isn't sufficient, because an attacker who controls the DNS resolution of their domain can create a DNS record with the same origin that points to an internal target address. (And before you ask, no, the browser can't reliably distinguish internal from external IP addresses.) If the attacker is restricted to performing HTTP requests, then things like the Host and Origin headers allow servers to defend against this. If you allow web pages to make raw TCP connections, those protections evaporate. And I'm pretty sure that if Java applets allowed raw TCP, they would have had the same vulnerability; it's just that typical attackers weren't quite as sophisticated in the 1990s.
  - feanaro 4y ago
    > And before you ask, no, the browser can't reliably distinguish internal from external IP addresses. Why can't it?
    - jhugo 4y ago
      Because you could be (and many high-value targets likely are) using your own IP address space "internally", rather than RFC1918. (Plus, IPv6.)
    - oefrha 4y ago
      In fact Chrome is doing just that: https://developer.chrome.com/blog/private-network-access-preflight/ https://developer.chrome.com/blog/private-network-access-pre... https://wicg.github.io/private-network-access/ https://wicg.github.io/private-network-access/
      - teraflop 4y ago
        That's a defense-in-depth measure; it can't be relied on. The exact same attack can be used against targets on a corporate network that doesn't use the RFC1918 address ranges.
        fulafel 4y ago
        I wouldn't associate those mainly with corporate networks. The prevalence of RFC1918 use is an artifact of IPv4 and address shortage. IPv6 usage is already at 40% today. Also hosts are increasingly multihomed, devices are likely tohave 2-3 network interfaces, with v4/v6 addresses for each. VPNs are run in "split tunnel" mode where some traffic goes via VPN and some not, so both un-tunneled and tunneled traffic is allowed simultaneously, etc.
    - avianlyric 4y ago
      How would it? IP has no concept of “Internal IP addressees”. There are reserved private address spaces, reserved local address spaces, and reserved public address spaces. Both the private and public address spaces can be used for “Internal Addresses”. The fact that we frequently use NATs and private address spaces to work around IPv4 exhaustion does not mean you can expect all “Internal Addresses” to be in a private range. The second you start using IPv6, or your in an old internet environment like a University, the DoD etc who has huge IPv4 address space, then you’ll find every machine has a IP address in a public range, there’s just firewalls preventing inbound connections, but you can’t easily detect those firewalls from the client.
- oefrha 4y ago
  HTTP has Host and Origin. Raw TCP/UDP do not. “The same host of document’s origin” can host any number of completely unrelated websites/services thanks to vhosting.
- WatchDog 4y ago
  I think the connectivity issues were simply overshadowed by the deficiencies of the SecurityManager.
fulafel 4y ago
Amusingly half of those things have been modernized to run on HTTP, so browsers can already do them.
- rocqua 4y ago
  Except the very complicated 'same origin policy' makes it generally forbidden by browsers to do HTTP against local adresses.
  - fulafel 4y ago
    It's not generally something browsers can do as there's no distinction about local addresses in IP (except localhost and IPv6 link-local addresses...) Also see DNS rebinding attacks: https://unit42.paloaltonetworks.com/dns-rebinding/ https://unit42.paloaltonetworks.com/dns-rebinding/
    - capableweb 4y ago
      CORS doesn't generally care if the final IP was resolved from localhost or example.com (or any other DNS entry), if the host doesn't have the right response to OPTIONS requests, you won't be able to communicate with it in the browser, unless your on the same IP/DNS as you're trying to talk to.
      - fulafel 4y ago
        There are CORS bypass techniques, CSRF exploitation via methods which are not checked by CORS such as img tags, and common exploitable misconfigurations (and maybe you can race the preflight check with dns rebinding attack?) - but the question of local address handling playing a part was the main point of my response. Here's some typical cases of csrf based vulnerabilities: https://seclists.org/fulldisclosure/2015/Mar/49 https://seclists.org/fulldisclosure/2015/Mar/49 https://www.ciscozine.com/cisco-linksys-wag54gs-csrf-change-admin-password/ https://www.ciscozine.com/cisco-linksys-wag54gs-csrf-change-... https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2021-016.txt https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2021-01... Remember, the S in IoT stands for security!
anonymoushn 4y ago
In TFA, it says > If DDoS was the concern, just require that UDP packets be sent exclusively within the same domain as the originating code. So you couldn't do any of these things. > And again - what actual benefits would there be to raw UDP access? The article is very light on specifics. It seems like writing game netcode without setting up a WebRTC server should be reason enough.
- chii 4y ago
  > It seems like writing game netcode without setting up a WebRTC server should be reason enough. this begs the question - is the browser really the right platform for a game where netcode like that is needed? Why make the browser even more complex, when the original design of it is meant to only display documents? If we keep going down this road, you'd end up with an operating system inside the browser.
  - anonymoushn 4y ago
    If we're going to have games and audio on the web, which we do, we could at least have them work without mountains of additional latency or WebRTC servers. I would also like it if web sites would display documents, allow the browser's "find" feature to work, and not use "responsive UI" to delete the form that I'm halfway done filling out when I resize my window, but I don't think my preferences have much weight here.
    - fulafel 4y ago
      WebRTC is peer-to-peer so there's no additional network latency from the protocol. There's the TURN fallback for when the participants can't reach each other, in which case bouncing through a proxy is the best you can do anyway. (If some implementations have high processing latency on top of the network latency, this can be fixed without changing the protocol).
  - mattnewton 4y ago
    > when the original design of it is meant to only display documents? Ship sailed, horse out of barn, etc etc on this point.
vbezhenar 4y ago
Hide it under prompt and that's about it. Alternative is that user will install some sketchy exe file which will do the same, but without any prompts. Browser could make it more secure.
forrestthewoods 4y ago
The article states that, just like microphone access, users would have to approve UDP access and it would only be allowed to a single server. I think that solves your router/printer/etc issue? > what actual benefits would there be to raw UDP access Author appears to want to control the whole stack. Based on their calling out HTTPS and friends as way too complex to implement. This is the HandmadeHero author afterall. And the standard answer to “why UDP?” is “required for game dev”. TCP is a non-option for many types of games.
junon 4y ago
Small nit, you cannot do ICMP with TCP or UDP.
- rubatuga 4y ago
  Also ARP isn't over TCP or UDP.
lucideer 4y ago
Every one of your threat vectors listed would be prevented by appropriate browser origin policies (which already exist for existing protocols). The only slight exception might be fingerprinting, as new APIs always extend this surface area somewhat, but not in the way you're describing (enumeration of local network devices) given aforementioned origin policies.
- iancarroll 4y ago
  How do you enforce an origin policy on raw TCP? CORS/SOP are heavily built on HTTP semantics, and you cannot easily map this back to raw TCP sockets. Even just allowing a TCP socket to the page origin's IP address is unsafe, because it might be a CDN and allow skipping CORS for other sites.
  - lucideer 4y ago
    True, it wouldn't be as straightforward as HTTP, as there would need to be new semantics (e.g. a handshake protocol for locally-cached IP allowlists or similar), but I guess my general point here is that the gp cited a large list of vectors that are all essentially the same problem & could be tackled with a single targetted (very conceivable) solution. Any new such solution would of course come with its own incorrect-implementation dangers - increased attack surface is increased attack surface. The sibling commenter rightfully points out these are still a potential issue with HTTP (servers not checking Host). But spec-wise a solution is still very doable.
- benmmurphy 4y ago
  Browser origin policies are difficult to use to protect something that listens to an IP address rather than a host due to DNS rebinding. This can happen implicitly if the victim service doesn’t check the host header. This is already a big problem with HTTP but with UDP or raw TCP there is no host header so anything that trusted the network would be broken.
arpa 4y ago
ARP and ICMP are protocols separate from TCP/UDP.

xxs 4y ago

The connectivity to any address/host would be a bad idea, what about restricting only to the same host of document's origin. Edit: Java's applets used to have the bog standard TCP (and UDP) and since late 90s. While Java/applets were a security nightmare, as all of them run in the same process and the impl. of SecurityManager (and its checks) was not up to the task [along with various deserialization exploits], the connectivity was not an issue.

teraflop 4y ago
Same-origin isn't sufficient, because an attacker who controls the DNS resolution of their domain can create a DNS record with the same origin that points to an internal target address. (And before you ask, no, the browser can't reliably distinguish internal from external IP addresses.) If the attacker is restricted to performing HTTP requests, then things like the Host and Origin headers allow servers to defend against this. If you allow web pages to make raw TCP connections, those protections evaporate. And I'm pretty sure that if Java applets allowed raw TCP, they would have had the same vulnerability; it's just that typical attackers weren't quite as sophisticated in the 1990s.
- feanaro 4y ago
  > And before you ask, no, the browser can't reliably distinguish internal from external IP addresses. Why can't it?
  - jhugo 4y ago
    Because you could be (and many high-value targets likely are) using your own IP address space "internally", rather than RFC1918. (Plus, IPv6.)
  - oefrha 4y ago
    In fact Chrome is doing just that: https://developer.chrome.com/blog/private-network-access-preflight/ https://developer.chrome.com/blog/private-network-access-pre... https://wicg.github.io/private-network-access/ https://wicg.github.io/private-network-access/
    - teraflop 4y ago
      That's a defense-in-depth measure; it can't be relied on. The exact same attack can be used against targets on a corporate network that doesn't use the RFC1918 address ranges.
      - fulafel 4y ago
        I wouldn't associate those mainly with corporate networks. The prevalence of RFC1918 use is an artifact of IPv4 and address shortage. IPv6 usage is already at 40% today. Also hosts are increasingly multihomed, devices are likely tohave 2-3 network interfaces, with v4/v6 addresses for each. VPNs are run in "split tunnel" mode where some traffic goes via VPN and some not, so both un-tunneled and tunneled traffic is allowed simultaneously, etc.
  - avianlyric 4y ago
    How would it? IP has no concept of “Internal IP addressees”. There are reserved private address spaces, reserved local address spaces, and reserved public address spaces. Both the private and public address spaces can be used for “Internal Addresses”. The fact that we frequently use NATs and private address spaces to work around IPv4 exhaustion does not mean you can expect all “Internal Addresses” to be in a private range. The second you start using IPv6, or your in an old internet environment like a University, the DoD etc who has huge IPv4 address space, then you’ll find every machine has a IP address in a public range, there’s just firewalls preventing inbound connections, but you can’t easily detect those firewalls from the client.
oefrha 4y ago
HTTP has Host and Origin. Raw TCP/UDP do not. “The same host of document’s origin” can host any number of completely unrelated websites/services thanks to vhosting.
WatchDog 4y ago
I think the connectivity issues were simply overshadowed by the deficiencies of the SecurityManager.

fulafel 4y ago

Amusingly half of those things have been modernized to run on HTTP, so browsers can already do them.

rocqua 4y ago
Except the very complicated 'same origin policy' makes it generally forbidden by browsers to do HTTP against local adresses.
- fulafel 4y ago
  It's not generally something browsers can do as there's no distinction about local addresses in IP (except localhost and IPv6 link-local addresses...) Also see DNS rebinding attacks: https://unit42.paloaltonetworks.com/dns-rebinding/ https://unit42.paloaltonetworks.com/dns-rebinding/
  - capableweb 4y ago
    CORS doesn't generally care if the final IP was resolved from localhost or example.com (or any other DNS entry), if the host doesn't have the right response to OPTIONS requests, you won't be able to communicate with it in the browser, unless your on the same IP/DNS as you're trying to talk to.
    - fulafel 4y ago
      There are CORS bypass techniques, CSRF exploitation via methods which are not checked by CORS such as img tags, and common exploitable misconfigurations (and maybe you can race the preflight check with dns rebinding attack?) - but the question of local address handling playing a part was the main point of my response. Here's some typical cases of csrf based vulnerabilities: https://seclists.org/fulldisclosure/2015/Mar/49 https://seclists.org/fulldisclosure/2015/Mar/49 https://www.ciscozine.com/cisco-linksys-wag54gs-csrf-change-admin-password/ https://www.ciscozine.com/cisco-linksys-wag54gs-csrf-change-... https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2021-016.txt https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2021-01... Remember, the S in IoT stands for security!

anonymoushn 4y ago

In TFA, it says > If DDoS was the concern, just require that UDP packets be sent exclusively within the same domain as the originating code. So you couldn't do any of these things. > And again - what actual benefits would there be to raw UDP access? The article is very light on specifics. It seems like writing game netcode without setting up a WebRTC server should be reason enough.

chii 4y ago
> It seems like writing game netcode without setting up a WebRTC server should be reason enough. this begs the question - is the browser really the right platform for a game where netcode like that is needed? Why make the browser even more complex, when the original design of it is meant to only display documents? If we keep going down this road, you'd end up with an operating system inside the browser.
- anonymoushn 4y ago
  If we're going to have games and audio on the web, which we do, we could at least have them work without mountains of additional latency or WebRTC servers. I would also like it if web sites would display documents, allow the browser's "find" feature to work, and not use "responsive UI" to delete the form that I'm halfway done filling out when I resize my window, but I don't think my preferences have much weight here.
  - fulafel 4y ago
    WebRTC is peer-to-peer so there's no additional network latency from the protocol. There's the TURN fallback for when the participants can't reach each other, in which case bouncing through a proxy is the best you can do anyway. (If some implementations have high processing latency on top of the network latency, this can be fixed without changing the protocol).
- mattnewton 4y ago
  > when the original design of it is meant to only display documents? Ship sailed, horse out of barn, etc etc on this point.

vbezhenar 4y ago

Hide it under prompt and that's about it. Alternative is that user will install some sketchy exe file which will do the same, but without any prompts. Browser could make it more secure.

forrestthewoods 4y ago

The article states that, just like microphone access, users would have to approve UDP access and it would only be allowed to a single server. I think that solves your router/printer/etc issue? > what actual benefits would there be to raw UDP access Author appears to want to control the whole stack. Based on their calling out HTTPS and friends as way too complex to implement. This is the HandmadeHero author afterall. And the standard answer to “why UDP?” is “required for game dev”. TCP is a non-option for many types of games.

junon 4y ago

Small nit, you cannot do ICMP with TCP or UDP.

rubatuga 4y ago
Also ARP isn't over TCP or UDP.

lucideer 4y ago

Every one of your threat vectors listed would be prevented by appropriate browser origin policies (which already exist for existing protocols). The only slight exception might be fingerprinting, as new APIs always extend this surface area somewhat, but not in the way you're describing (enumeration of local network devices) given aforementioned origin policies.

iancarroll 4y ago
How do you enforce an origin policy on raw TCP? CORS/SOP are heavily built on HTTP semantics, and you cannot easily map this back to raw TCP sockets. Even just allowing a TCP socket to the page origin's IP address is unsafe, because it might be a CDN and allow skipping CORS for other sites.
- lucideer 4y ago
  True, it wouldn't be as straightforward as HTTP, as there would need to be new semantics (e.g. a handshake protocol for locally-cached IP allowlists or similar), but I guess my general point here is that the gp cited a large list of vectors that are all essentially the same problem & could be tackled with a single targetted (very conceivable) solution. Any new such solution would of course come with its own incorrect-implementation dangers - increased attack surface is increased attack surface. The sibling commenter rightfully points out these are still a potential issue with HTTP (servers not checking Host). But spec-wise a solution is still very doable.
benmmurphy 4y ago
Browser origin policies are difficult to use to protect something that listens to an IP address rather than a host due to DNS rebinding. This can happen implicitly if the victim service doesn’t check the host header. This is already a big problem with HTTP but with UDP or raw TCP there is no host header so anything that trusted the network would be broken.

arpa 4y ago

ARP and ICMP are protocols separate from TCP/UDP.