5 ms·

Right I wasn’t saying don’t cache network topology, IO is slow, cache it. That’s why I wondered why they didn’t have LRU or some other eviction policy to deal w

Right I wasn’t saying don’t cache network topology, IO is slow, cache it. That’s why I wondered why they didn’t have LRU or some other eviction policy to deal with a full cache, stale entries, etc.

hnlmorg 3y ago
I’m not defending Microsoft here, but in fairness, we are talking about 1000s of entries when normal use might only see a few dozen over several years of Windows usage even under extreme circumstances. So I can see why cache invalidation probably wasn’t at the forefront of their mind. However, as this incident demonstrates, there’s always an edge case that breaks things.
- yencabulator 3y ago
  If it's behavior that can be triggered by untrusted network traffic, it needs to be made robust. There really is no excuse. This looks like a trivial low-packet-count DoS on every Windows machine on the network.
  - hnlmorg 3y ago
    I don’t disagree with you per se but software development is error prone and we are talking about traffic from trusted networks (if you’re on a “public network” — to use Wi does terminology — then UPnP behaves very differently). My point is: it’s very easy to post on message boards like this about what best practices should be when reviewing fuck ups from other companies. While at the same time ignoring the fact that we fuck up plenty of times ourselves too. In an ideal world software engineering would be held to the same rigour as other forms of engineering. But when software fails people don’t (usually) die. So what happens is developers end up getting overworked, given unrealistic deadlines and have to fix problems with software updates. those kind of scenarios will breed bugs like the aforementioned. So yes, you’re technically correct — but only in a universe that doesn’t have our current tech culture. This is why I’m a little more pragmatic about my criticism.
- mrussel 3y ago
  This is 100% unacceptable behavior of windows. You hmare looking at it from the wrong angle. This isn't a case of "Windows is broken because it crashes when the user does something and the work around is, 'dont do that's" The correct way to look at this is that the OP has discovered a significant flaw in the windows network stack. The correct description is: "A flaw in windows PnP discovery allows a denial of service attack against the windows networking stack. Windows PnP service track and caches the UUID and Mac address of all entities that appear in the local network and fails to purge old or outdated services until it deadlocks"
  - hnlmorg 3y ago
    > This is 100% unacceptable behavior of windows. You hmare looking at it from the wrong angle. This isn't a case of "Windows is broken because it crashes when the user does something and the work around is, 'dont do that's" That isn’t remotely what I said though. My point was: It’s both vendors fault. If youd bothered to spend even 30 seconds longer to properly read my comment instead of knee jerk reacting to anything that’s even remotely sympathetic to evil Microsoft then you’d realise that I’m not letting MS off the hook for this. I’m just saying there’s enough blame to go round on this particular fault.

hnlmorg 3y ago

I’m not defending Microsoft here, but in fairness, we are talking about 1000s of entries when normal use might only see a few dozen over several years of Windows usage even under extreme circumstances. So I can see why cache invalidation probably wasn’t at the forefront of their mind. However, as this incident demonstrates, there’s always an edge case that breaks things.

yencabulator 3y ago
If it's behavior that can be triggered by untrusted network traffic, it needs to be made robust. There really is no excuse. This looks like a trivial low-packet-count DoS on every Windows machine on the network.
- hnlmorg 3y ago
  I don’t disagree with you per se but software development is error prone and we are talking about traffic from trusted networks (if you’re on a “public network” — to use Wi does terminology — then UPnP behaves very differently). My point is: it’s very easy to post on message boards like this about what best practices should be when reviewing fuck ups from other companies. While at the same time ignoring the fact that we fuck up plenty of times ourselves too. In an ideal world software engineering would be held to the same rigour as other forms of engineering. But when software fails people don’t (usually) die. So what happens is developers end up getting overworked, given unrealistic deadlines and have to fix problems with software updates. those kind of scenarios will breed bugs like the aforementioned. So yes, you’re technically correct — but only in a universe that doesn’t have our current tech culture. This is why I’m a little more pragmatic about my criticism.
mrussel 3y ago
This is 100% unacceptable behavior of windows. You hmare looking at it from the wrong angle. This isn't a case of "Windows is broken because it crashes when the user does something and the work around is, 'dont do that's" The correct way to look at this is that the OP has discovered a significant flaw in the windows network stack. The correct description is: "A flaw in windows PnP discovery allows a denial of service attack against the windows networking stack. Windows PnP service track and caches the UUID and Mac address of all entities that appear in the local network and fails to purge old or outdated services until it deadlocks"
- hnlmorg 3y ago
  > This is 100% unacceptable behavior of windows. You hmare looking at it from the wrong angle. This isn't a case of "Windows is broken because it crashes when the user does something and the work around is, 'dont do that's" That isn’t remotely what I said though. My point was: It’s both vendors fault. If youd bothered to spend even 30 seconds longer to properly read my comment instead of knee jerk reacting to anything that’s even remotely sympathetic to evil Microsoft then you’d realise that I’m not letting MS off the hook for this. I’m just saying there’s enough blame to go round on this particular fault.