0.0.0.0 Day - 18 Yr Old Vulnerability Let Attackers Bypass All Browser Security (cybersecuritynews.com)
from Dnb@lemmy.dbzer0.com to technology@beehaw.org on 08 Aug 2024 14:18
https://lemmy.dbzer0.com/post/25545119

#technology

threaded - newest

Boomkop3@reddthat.com on 08 Aug 2024 15:27 next collapse

Welp, I guess sandboxing a browser that has a sandbox might still be a good idea

tyler@programming.dev on 08 Aug 2024 16:04 next collapse

The article literally doesn’t explain the vulnerability at all.

drwho@beehaw.org on 08 Aug 2024 17:07 next collapse

Everybody who could explain it well is at Hacker Summer Camp right now.

unconfirmedsourcesDOTgov@lemmy.sdf.org on 09 Aug 2024 20:21 collapse

I didn’t realize DEFCON was this weekend already, but this is a solid point 😂

floofloof@lemmy.ca on 08 Aug 2024 17:57 next collapse

It keeps promising to, then goes off into more ChatGPT-style rambling. It’s a bad article. This one is more informative:

oligo.security/…/0-0-0-0-day-exploiting-localhost…

Kissaki@beehaw.org on 08 Aug 2024 18:32 collapse

notably

Windows is not impacted by this issue.

quoting the main, critical part:

  1. Under public domain (.com), the browser sent the request to 0.0.0.0.
  2. The dummy server is listening on 127.0.0.1 (only on the loopback interface, not on all network interfaces).
  3. The server on localhost receives the request, processes it, and sends the response.
  4. The browser blocks the response content from propagating to Javascript due to CORS.

This means public websites can access any open port on your host, without the ability to see the response.

biscuitswalrus@aussie.zone on 08 Aug 2024 19:29 collapse

I ended up reading it on bleeping computer since the linked site looks like an auto tldr bot saved 50% of the words. The important 50% was discarded.

bleepingcomputer.com/…/18-year-old-security-flaw-…

sirico@feddit.uk on 08 Aug 2024 16:09 next collapse

hunter2 Wow it works!

dan@upvote.au on 08 Aug 2024 16:17 next collapse

Seems like a TCP/IP stack issue rather than a browser issue… 0.0.0.0 is not supposed to be a valid address (in fact, no IPv4 address with 0 as the first octet is a valid destination IP). The network stack should be dropping those packets.

0.0.0.0 is only valid in a few use cases. When listening for connections, it means “listen on all IPs”. This is a placeholder that the OS handles - it doesn’t literally use that IP. Also, it’s used as the source address for packets where the system doesn’t have an IP yet (eg for DHCP). That’s it.

drwho@beehaw.org on 08 Aug 2024 17:07 next collapse

I’m inclined to agree. This looks like a misunderstanding of RFC 5735.

dan@upvote.au on 08 Aug 2024 17:31 collapse

From that RFC:

0.0.0.0/8 - Addresses in this block refer to source hosts on "this"
network.  Address 0.0.0.0/32 may be used as a source address for this
host on this network; other addresses within 0.0.0.0/8 may be used to
refer to specified hosts on this network ([RFC1122], Section
3.2.1.3).

(note that it only says “source address”)

which was based on RFC 1122, which states:

We now summarize the important special cases for Class A, B,
and C IP addresses, using the following notation for an IP
address:

    { <Network-number>, <Host-number> }

or
    { <Network-number>, <Subnet-number>, <Host-number> }

...

(a)  { 0, 0 }

This host on this network.  MUST NOT be sent, except as
a source address as part of an initialization procedure
by which the host learns its own IP address.

See also Section 3.3.6 for a non-standard use of {0,0}.

(section 3.3.6 just talks about it being a legacy IP for broadcasts - I don’t think that even works any more)

drwho@beehaw.org on 09 Aug 2024 16:07 collapse

Okay, I see where I went wrong. Thank you.

I don’t think 0.0.0.0 works for broadcasts anymore, either - I think those get filtered by default these days.

dan@upvote.au on 09 Aug 2024 16:46 collapse

I wasn’t disagreeing with you :) or at least I think I wasn’t. I was just quoting the RFC you linked to.

TehPers@beehaw.org on 08 Aug 2024 18:13 next collapse

While I agree, it makes connecting to localhost as easy as http://0:8080/ (for port 8080, but omit for port 80).

I worry that changing this will cause more CVEs like the octal IP addresses incident.

Edit: looks like it’s only being blocked for outgoing requests from websites, which seems like it’ll have a much more reasonable impact.

Edit 2: skimming through these PRs, at least for WebKit, I don’t see tests for shorthand IPs like 0 (and no Apple device to test with). What are the chances they missed those…?

dan@upvote.au on 08 Aug 2024 19:27 collapse

it makes connecting to localhost as easy as http://0:8080/ (for port 8080, but omit for port 80).

The thing is that it’s not supposed to work, so it’s essentially relying on undefined behaviour. Typing [::1]:8080 is nearly as easy.

skimming through these PRs, at least for WebKit, I don’t see tests for shorthand IPs like 0 (and no Apple device to test with). What are the chances they missed those…?

I haven’t seen the PRs, but IP comparison should really be using the binary form of the IPv4 address (a 32-bit number), not the human-friendly form.

AndrasKrigare@beehaw.org on 09 Aug 2024 12:12 collapse

Yeah, I just did a quick test in Python to do a tcp connection to “0.0.0.0” and it made a loopback connection, instead of returning an error as I would have expected.

ssm@lemmy.sdf.org on 08 Aug 2024 19:50 collapse

Yes! Another huge win for links2gang !links2@lemmy.sdf.org