Hacker News Reader

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

Except the very complicated 'same origin policy' makes it generally forbidden by browsers to do HTTP against local adresses.

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/

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.

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://www.ciscozine.com/cisco-linksys-wag54gs-csrf-change-... https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2021-01...

Remember, the S in IoT stands for security!

>OPTIONS requests

OPTIONS requests only happen for cross-origin requests. With DNS rebinding, there are no cross-origin requests, so there will be no OPTIONS requests.

But that requires you to load the page resource from that origin already, so if you're already in control of it, what would you want to do that you couldn't already?

Here's how DNS rebinding works:

1. You have the victim user open a tab to your page at attacker.com .

2. After the page loads, you change the DNS record for attacker.com to make it point to 127.0.0.1 .

3. Javascript on the page makes requests to attacker.com and can now read and interact with whatever servers are running on the victim user's machine.

Alternatively use 192.168.1.1 to attack the victim user's router.

This attack will be blocked if the victim servers check the Host request header. Often they don't.

Sites don't have to prevent browsers accessing other addresses. It's only protection against XSS, not against malicious sites.

I mean it's nowhere as bad, and for legacy stuff usually CORS/SOP helps.

New implementations that use websocket as their root (mostly for web browser compatibility) seem to take security more seriously out of the box, I use a couple apps in my day-to-day which expose APIs over Websocket and don't trust by default.

- Vtube Studio has a auth dialog that pops up on first connection you must accept before commands are executed

- obs-websocket by default requires a password to be used.

There's always outliers sadly, for example "beefweb" (Foobar plugin) has auth but it's not enabled by default.

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.

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.

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.

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.

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.

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.

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.

> And before you ask, no, the browser can't reliably distinguish internal from external IP addresses.

Why can't it?

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.

>IP has no concept of “Internal IP addressees”.

IPv4 has defined 10/8, 172.16/12, 192.168/16 as site-local (or internal). IPv6 has similar concept with fec0:/10

Those v4 examples are really ambiguous addresses, orthogonal to local-ness. Same goes for ambiguous addresses used in CGNAT. More importantly, the complement: you don't know that a non-rfc1918 address isn't local. This is important because the latter is actually the definition the proposed "only allow non-local" use case would require.

(Also fec00::/10 was deprecated 15+ years ago - there are still some special prefixes like ULA but for IPv6 their usage is marginal since there's no shortage of normal address space)

The argument was about having a concept, not ensuring any address is publicly available.

Only if you completely ignore the preceding discussion about same-origin policies, and how browsers can’t provide a guarantee that a host at particular IP address is a public system or an internal-only system.

A host with an IP in a private range might always be internal, but a host with an IP in a public range isn’t always external. And as the stated goal is to avoid browsers being a trampoline to attack internal equipment, not being able to guarantee that a particular host is an internal host is problematic.

Many organizations use “real” publicly routable addresses on their hosts for IPv4 (rare) and IPv6 (common), without NAT devices. Stateful firewalls don’t require the use of NAT.

In fact Chrome is doing just that:

https://developer.chrome.com/blog/private-network-access-pre...

https://wicg.github.io/private-network-access/

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.

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.

Because you could be (and many high-value targets likely are) using your own IP address space "internally", rather than RFC1918. (Plus, IPv6.)

Actually Java resolved the host to the same IP to prevent that type of attacks... which has other issues.

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.

I think the connectivity issues were simply overshadowed by the deficiencies of the SecurityManager.

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.

Restricting origins doesn’t work thanks to a fun little trick called DNS rebinding. Let’s say you get the user to browse your site, say, attacker.com. They lookup your DNS and see that it’s 1.2.3.4, with a TTL of (say) 5 seconds.

Five seconds later, the user’s DNS cache entry expires. Your page triggers a new request to attacker.com. Since the TTL has expired, they do another DNS lookup - and you serve them a different IP address, say, 192.168.1.1. Now they make a new request to that IP believing that they’re still accessing attacker.com.

With HTTP requests there’s at least the possibility of detecting these attacks via the Host header (even if that doesn’t usually happen in practice). With raw UDP, however, the attacking packets would be indistinguishable from legitimate ones.

This could be resolved by having the browser cache the IP and refresh it for child operations. Sure, this is a change in current behavior - but for a new feature like UDP, or arbitrary TCP, it could work.

As others have pointed out caching the DNS past the TTL is it’s own security problem.

I think the fix is actually to disallow resolution when the TTL is too short (eg <1 hour) and refusing new outbound requests once the IP address changes without a refresh of the page. However, I’m not a security / network expert so there may be a critical flaw in that idea.

Have a page load up a script from <nonce>.relevantdomain.tld, once the script sends back a packet to <nonce>.relevantdomain.tld, have the dns settings change subdomain to 192.168.0.1, and then etc

the war between safe things and unsafe things is endless, so we shouldn't be adding a massive unsafe thing and then bodging patches onto it to make it "safer" than completely unsafe

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

> If we keep going down this road, you'd end up with an operating system inside the browser.

Arguably, we're already there. I stopped pretending the web wasn't going to be the common platform of the future when WebUSB dropped and I learned you can root a Nintendo Switch from Chrome OS. Without the Linux part.

If you build something today, without too many resources backing you up, and you want it to run anywhere, you build something that resembles a PWA with Electron wrappers. (resembling because it could also be something like Flutter).

> when WebUSB dropped

You mean when Google implemented it in their EEE fork of the web.

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.

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

While I may personally agree with your line of thinking there, we are about 15 years too late to argue that point I think.

> when the original design of it is meant to only display documents?

Ship sailed, horse out of barn, etc etc on this point.

> this begs the question - is the browser really the right platform for a game where netcode like that is needed?

Yes, it works pretty well using established technologies in the browser already.

DDOS is essentially the exact opposite of what the parent comment is talking about.

Can you explain how "require that UDP packets be sent exclusively within the same domain as the originating code" does not address any of that comment's concerns, or are you just nitpicking?

evil.example.com can easily set up a subdomain such that 192-168-2-44.home.evil.example.com resolves to 192.168.2.44, so requiring that UDP packets be sent exclusively within the same domain as the originating code doesn't help at all.

That wouldn't work, the same way CORS can't be bypassed that way. It was to be the exact same origin.

CORS work because the target is HTTP and exposes permissions in headers.

There is no HTTP headers for raw UDP.

You can rebind the exact same origin then.

Same domain is pretty meaningless until all browsers mitigate DNS rebinding, which as far as I know they still don't. And even that would presumably only help with private IPs.

Oops, I misunderstood "same domain", sorry.

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.

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

Also ARP isn't over TCP or UDP.

ARP and ICMP are protocols separate from TCP/UDP.