Researchers at Oligo Security have discovered an 18-year-old critical vulnerability, dubbed "0.0.0.0 Day, bypass bowers security.
  • dan@upvote.au
    52·
    4 months ago

    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.

      • dan@upvote.au
        15·
        4 months ago

        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)

        • The Doctor@beehaw.orgEnglish
          1·
          4 months ago

          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
            2·
            4 months ago

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

    • AndrasKrigare@beehaw.org
      4·
      4 months ago

      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.

    • TehPers@beehaw.orgEnglish
      3·
      4 months ago

      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
        6·
        4 months ago

        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.