Internet Control Message Protocol (ICMP) Remote Code Execution Vulnerability | Hacker News Reader

Internet Control Message Protocol (ICMP) Remote Code Execution Vulnerability

nvd.nist.gov

56 pointsamenghra12 comments

How the hell is there an RCE in ICMP in 2023?

I remember exploiting fragmented ICMP packets on Windows 95 in like 1996 to blue-screen people using the IcEbx extension for the BitchX IRC client, I think the exploit was called sping maybe? The fact that a such a vulnerability can even exist in such fundamental code these days is mind boggling, especially when bugs in the same family were around in that stack 25+ years ago.

Between this and today's TPM exploit, I have to admit the RiiR folks are starting to have a point.

ssping and good ol' winnuke ah and 'land'.. ... oh memories.

It's a buffer overflow error, not a lifetime management error.

So one more thing that Rust fixes, got it.

I was going to say "surely this is against a specific implementation" and would offer that linking to the Microsoft page would convey both pieces of information: the original link and to whom it applies: https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...

tl;dr

> An attacker could send a low-level protocol error containing a fragmented IP packet inside another ICMP packet in its header to the target machine. To trigger the vulnerable code path, an application on the target must be bound to a raw socket.

Do you have any more insight as to how that might work? I'm not really grokking it, I work in networking and wonder if this is going to be a big patching effort soon. It's already a constant battle for us to have ICMP traffic allowed everywhere.

According to https://blog.talosintelligence.com/microsoft-patch-tuesday-f... it's an out of bounds write, which I interpret to mean it is luck of the draw about the "RCE" part, but almost certain about the Availability component of the CVSS score

While TFA didn't mention the Patch Tuesday part, the Talos blog said the fix is included in the March release, along with some other venomous looking ones

Wasn’t Steve Gibson trying to tell us that raw sockets were the end of the world more than 20 years ago? Maybe he is finally right.

Does or does this not limit the impact of this RCE in ping, which could easily be rewritten in Rust?:

  chmod ugo-sS /bin/ping
  setcap cap_net_raw+ep /bin/ping

Exploit Code Maturity This metric measures the likelihood of the vulnerability being attacked, and is typically based on the current state of exploit techniques, exploit code availability, or active, 'in-the-wild' exploitation. Unproven No exploit code is available, or an exploit is theoretical.

Since this involves an out-of-bounds write, anyone care to answer a shower thought?

How much harder is it to turn a typical OOB access to a stack-allocated buffer into a RCE if the stack grows up instead of down?

If the stack buffer is allocated in any frame except the leaf frame, just as easy.

    void outer() {
        char buff[64];
        read_data(buff);
        process_data(buff);
    }

    void process_data(char* buff) {
        // buffer overflow here is just as bad, even if stack grows up
    }

Reply on news.ycombinator.com