[Someone1234]

If they're attacking you from an internal vector they likely already have code execution within that internal context, making this bug largely redundant. The more common case is gaining entry to a poorly secured edge or cloud server, rather than a bad actor sitting on your LAN.

But sure, I suppose, that niche edge case (local context without local code execution) could hypothetically exist somewhere, but patching this won't make you secure.

[AstralStorm]

The internal remote hole can be thought of as a force multiplier. An attacker that bypasses the edge in any way gets every machine in your network. It takes any other remote bug or anyone getting to any badness on the Internet. And then if your domain controller is owned, it's everything...

A simple virus could even do it. It takes only one instance for this bug to completely take over your network if you're Windows based. Remember Windows XP time? That's how it is.

Unless you completely cut off internal network everywhere. Good luck with that policy.

You wouldn't even know you have been owned completely and expect only a router issue if the breach is from there. Or not even spot anything out of ordinary.

About the only real way is to presume internal network is compromised and keep diversity and backups to reduce impact. Compartmentalize, do not centralize, no matter how much money you'd save that way. If a man has to go to fix an issue instead of remote login, so be it.

[Riverheart]

It's not a niche edge case, there is an entire industry that revolves around securing BYOD devices. If I bring a compromised device on your network and it uses some rdp flaw to access another machine it's gotten a foothold in the network where it could spread further. I don't need code execution from an existing internal resource.

And yes, security is a layered approach. That's why we recognize that the internet isn't the only threat vector out there.

Edit: Why wouldn't you patch internal servers for this anyway? Let's say there is an existing threat with code execution like you say. Now he can trivially access all machines on the network because they share a common vulnerability. At least make him work for it.

[Someone1234]

> If I bring a compromised device on your network

Then I'm in real trouble with or without this. A compromised device can sniff the network, masquerade, inject network traffic (inc. DNS), and can attack every other device on that same segment.

> I don't need code execution from an existing internal resource.

If you cannot execute code in an internal context then you cannot exploit this bug, you'd effectively be an external attacker. Your own example had you running code on a locally connected "BYOD" device. Therefore you're already executing code in that context.

> Why wouldn't you patch internal servers for this anyway?

Nobody suggested that. In fact quite to the contrary.

By the way while we're discussing niche edge cases, what's your strategy to protect against Van Eck phreaking? Seems about as concrete as the attack vector you're proposing (local network access with no way to execute code).

[Riverheart]

Okay I think I've either poorly communicated or you've misconstrued what I meant. All I was trying to imply was that threats can surface within the network. I'm not saying some magic will take advantage of the exploit with no connection to the target's network. You said

"If they're attacking you from an internal vector they likely already have code execution within that internal context, making this bug largely redundant."

I was disagreeing that this is redundant. This vulnerability is a remote code exploit that could give an attacker control over the target just by sending a specially crafted packet. It is not some Apache misconfiguration affecting a couple servers, it's baked into all versions of Windows.