4 ms·

I glossed over it being upnp. Ok, but the questions till remains why is windows tracking things to the point of deadlocks surely the folks at MS are aware that

I glossed over it being upnp. Ok, but the questions till remains why is windows tracking things to the point of deadlocks surely the folks at MS are aware that rouge misconfigured or malicious devices can exist on a computer network (they wrote the OS used by a majority of them after all), especially one which is doing upnp, the firewall hole poking protocol.

hnlmorg 3y ago
Caching is a pretty reasonable thing for software to do. Windows could have done a better job with cache invalidation (if it’s even doing any at all) but retaining a cache of available devices via UPnP is a perfectly reasonable expectation. For one thing, it massively speeds up device discovery. However having a device randomise their UUID isn’t a reasonable expectation. This why I said in a different comment that both Windows and Hisense are at fault. Windows could have handled this kind of edge case much better but that doesn’t absolve Hisense TVs responsibility for behaving badly too.
- wutwutwat 3y ago
  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.
- dathinab 3y ago
  As far as I understand it's not a cache (but I have not touched Windows for a long time and haven't developed UPnP devices yet). It's more similar to how you have a list of all paired Bluetooth devicees, even if they are currently not connected. Or a list of networks configs for every network you connected to, even if it was a public one. But there are 2 issues: - it's automatically set by "external" local network "events" (which isn't the case for the things I mentioned above, as long as you don't automatically connect to public networks, never do so) - it's not bound, which is in general not the best idea but in context of the 1st point is really really bad. I.e. it should have some bound related to it's resource cost and expected usage. (If I have to widely guess a bound of 250 or so would be over the top enough to accommodate all edge cases and not lead to issues, most users would be more then fine with idk. 25 or so). Through what to do if the count is exceeded needs some careful considerations, i.e. you would need to drop the "oldest unused entry" but for that you need to determine and propagate what "unused" means here. To be fair I wouldn't be surprised if that isn't just a problem for Windows. Like e.g. I have heard multiple times people arguing that UPnP shouldn't be enabled (by Windows/Linux/Mac) as it wasn't designed for a modern security context where you can't just trust your local network a lot.
  - deleted 3y ago
    [deleted]
- RecycledEle 3y ago
  > Caching is a pretty reasonable thing for software to do. Every software that saves something needs to have a way to deal with too many things being saved. It's called testing software. Maybe Microsoft should try it.
  - hnlmorg 3y ago
    I get it’s cool to be critical of FAANG and point out their obvious (from hindsight) mistakes but the fact is engineer teams are a finite resource and this bug is an edge case from a misbehaving service on a trusted network (UPnP wouldn’t work like this on a “public network”, by Windows definition). We’ve all, yourself included, made plenty worse fuck ups in our career. So let’s show a modicum of pragmatism here please. What we should be more critical of is how this gets reported and handled by Microsoft and Hisense. Do they choose to ignore this bug / close it as “Won’t fix” (working as intended)? Or is this something that will be patched in a relatively recent software update?
dathinab 3y ago
both are bugged tbh. MS shouldn't have anything "unbound" which can increase due to external events, even if it's limited to the same local network (but MS (and probably not just them) has also a long history with security issues on local network exposed interfaces). At the same time regenerating a new UUID for UPnP every few minutes is buggy to a point it can be seen as a DOS attack. So ... also not okay. (It also doesn't add any relevant degree of privacy to "very frequently regenerate UPnP ids for devices always there in the same fixed local network AFIK.)
- deleted 3y ago
  [deleted]

hnlmorg 3y ago

Caching is a pretty reasonable thing for software to do. Windows could have done a better job with cache invalidation (if it’s even doing any at all) but retaining a cache of available devices via UPnP is a perfectly reasonable expectation. For one thing, it massively speeds up device discovery. However having a device randomise their UUID isn’t a reasonable expectation. This why I said in a different comment that both Windows and Hisense are at fault. Windows could have handled this kind of edge case much better but that doesn’t absolve Hisense TVs responsibility for behaving badly too.

wutwutwat 3y ago
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.
dathinab 3y ago
As far as I understand it's not a cache (but I have not touched Windows for a long time and haven't developed UPnP devices yet). It's more similar to how you have a list of all paired Bluetooth devicees, even if they are currently not connected. Or a list of networks configs for every network you connected to, even if it was a public one. But there are 2 issues: - it's automatically set by "external" local network "events" (which isn't the case for the things I mentioned above, as long as you don't automatically connect to public networks, never do so) - it's not bound, which is in general not the best idea but in context of the 1st point is really really bad. I.e. it should have some bound related to it's resource cost and expected usage. (If I have to widely guess a bound of 250 or so would be over the top enough to accommodate all edge cases and not lead to issues, most users would be more then fine with idk. 25 or so). Through what to do if the count is exceeded needs some careful considerations, i.e. you would need to drop the "oldest unused entry" but for that you need to determine and propagate what "unused" means here. To be fair I wouldn't be surprised if that isn't just a problem for Windows. Like e.g. I have heard multiple times people arguing that UPnP shouldn't be enabled (by Windows/Linux/Mac) as it wasn't designed for a modern security context where you can't just trust your local network a lot.
- deleted 3y ago
  [deleted]
RecycledEle 3y ago
> Caching is a pretty reasonable thing for software to do. Every software that saves something needs to have a way to deal with too many things being saved. It's called testing software. Maybe Microsoft should try it.
- hnlmorg 3y ago
  I get it’s cool to be critical of FAANG and point out their obvious (from hindsight) mistakes but the fact is engineer teams are a finite resource and this bug is an edge case from a misbehaving service on a trusted network (UPnP wouldn’t work like this on a “public network”, by Windows definition). We’ve all, yourself included, made plenty worse fuck ups in our career. So let’s show a modicum of pragmatism here please. What we should be more critical of is how this gets reported and handled by Microsoft and Hisense. Do they choose to ignore this bug / close it as “Won’t fix” (working as intended)? Or is this something that will be patched in a relatively recent software update?

dathinab 3y ago

both are bugged tbh. MS shouldn't have anything "unbound" which can increase due to external events, even if it's limited to the same local network (but MS (and probably not just them) has also a long history with security issues on local network exposed interfaces). At the same time regenerating a new UUID for UPnP every few minutes is buggy to a point it can be seen as a DOS attack. So ... also not okay. (It also doesn't add any relevant degree of privacy to "very frequently regenerate UPnP ids for devices always there in the same fixed local network AFIK.)

deleted 3y ago
[deleted]