5 ms·

> The root cause is the TV generates random UUIDs for UPNP network discovery every few minutes. That means it poses as a new device. This caused windows to add

> The root cause is the TV generates random UUIDs for UPNP network discovery every few minutes. That means it poses as a new device. This caused windows to add it to the device list (Device Association Framework, aka DAF) as a new device. This means now 1000s of devices (which is the same device) filled the device tree causing it to enumerate forever. Thus the "deadlock". Why is the TV pretending it’s a new device?

rvnx 3y ago
We can see a positive edge to that, it's like Mac address randomization, if you can't know the UUID of your TV, how can someone else know ?
- brnt 3y ago
  Because the TV signals it somewhere, just not the owners.
wutwutwat 3y ago
Pretty sure Mac randomization is part of the ipv6 spec, and our Apple products have been doing it for years now. The tv can do whatever the heck it wants because if it’s not this thing malfunctioning it’ll be your toaster. Anything concerning networking needs to handle bs like this and not fall on its face. My question would be why are windows installs tracking every device on the network? Sure file server discovery, etc, but why’s it storing them long term, esp if it is overloaded with them, why would it not be setup to do LRU or otherwise purge records. Seems silly to store entries until you have a critical failure.
- V__ 3y ago
  Probably to allow screen sharing or casting.
  - wutwutwat 3y ago
    It’s 2024 if you’re opening ports on your firewall/edge router still, you’re doing it wrong, both as a user and as an app developer.
    - brnt 3y ago
      Yes, but, embedded software...
- comprev 3y ago
  The randomisation feature of iOS was apparently not working for a long time despite Apple marketing otherwise [0] [0] https://arstechnica.com/security/2023/10/iphone-privacy-feature-hiding-wi-fi-macs-has-failed-to-work-for-3-years/ https://arstechnica.com/security/2023/10/iphone-privacy-feat...
  - wutwutwat 3y ago
    Use any mac you want I'm sure we’re being fingerprinted other ways so it doesn’t matter. Security through obscurity isn’t security, after all.
    - Nextgrid 3y ago
      MAC randomization prevents the local network from trivially tracking you based on access point logs. Of course, if your device runs software that broadcasts some unique identifier, the network may deploy some collector service to query/capture these but that's already extra effort. On iOS I don't believe apps can run a persistent network server in the background, so background tracking would actually be quite tricky even if you had a cooperating app. Fingerprinting is absolutely an issue for device-based trackers (whether apps or websites), but from the perspective of a passive network observer they're usually quite airtight and don't leak the collected data over insecure channels.
      - wutwutwat 3y ago
        Not just access point logs, this isn’t WiFi specific. It’s to make packet inspection harder to link to a device. But, if I run say an airport network and control dns for dhcp I can track your dns requests (non encrypted dns) and interface info across MAC addresses and maybe even tag packets somehow. Also, if every device that connects is routed through a dedicated vlan only containing that device, it can randomize itself all it wants, it’s on a network by itself so it can’t “hide in the crowd”. Those are just things off the top of my head and am not a network person. I’m sure it’s not preventing the motivated from tracking you if they want to.
- hnlmorg 3y ago
  We aren’t talking about MAC randomisation (which itself would cause issues if it happened every few minutes) but UUID randomisation in UPnP. It’s a completely different protocol that sits in a completely different layer on OSI to the data link layer (where MAC addresses live). UPnP is literally just a protocol that sits on top of HTTP.
  - wutwutwat 3y ago
    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.
iamleppert 3y ago
Probably just how it’s written. Takes extra effort to save a UUID vs. just generate a new one every time some function runs.
dathinab 3y ago
in general devices from time to time pretending to be a new device can be preferred as a form of privacy protection E.g. with IPv6 we have enough addresses to give every device in the world today and for decades to come unique addresses and using devices MAC you can reliably generate them collision free. So you don't need NAT so routers can well only route instead of routing and proxying IP Address/Port. Problem is that leaks a lot of private information. So a schema was added which while upholding the properties allows "randomizing" (and changing over time) addresses. But coming back to the smart TV I don't think this is the case here as it changes the address _far_ to often and it's a UPnP i.e. local network only Id. Furthermore UPnP also advertises devices descriptions so de-anonymizing randomly changed IPs is more then trivial. My guess is the UPnP software module is started anew every few minutes and generates a new uuid every time. This might be due to it not persisting the uuid. Weather that is because they just didn't bother implementing persistent device ids or weather it regenerates it after every time it crashes and it crashes every few minutes I can't say. But it looks a huge lot like a software bug. What also is a 100% a but is that this external device misbehavior can mess up Windows (through I wouldn't be surprised if it isn't just Windows which has problems with that). It means that there is a resource controlled by external events which isn't "bound" which from a security POV is always a terrible idea, even if it might at most cause a DOS attack (not just because DOS is bad but also because it's not rare that people find ways to use DOS attacks alongside other found attack vectors to more reliably succeed).

rvnx 3y ago

We can see a positive edge to that, it's like Mac address randomization, if you can't know the UUID of your TV, how can someone else know ?

brnt 3y ago
Because the TV signals it somewhere, just not the owners.

wutwutwat 3y ago

Pretty sure Mac randomization is part of the ipv6 spec, and our Apple products have been doing it for years now. The tv can do whatever the heck it wants because if it’s not this thing malfunctioning it’ll be your toaster. Anything concerning networking needs to handle bs like this and not fall on its face. My question would be why are windows installs tracking every device on the network? Sure file server discovery, etc, but why’s it storing them long term, esp if it is overloaded with them, why would it not be setup to do LRU or otherwise purge records. Seems silly to store entries until you have a critical failure.

V__ 3y ago
Probably to allow screen sharing or casting.
- wutwutwat 3y ago
  It’s 2024 if you’re opening ports on your firewall/edge router still, you’re doing it wrong, both as a user and as an app developer.
  - brnt 3y ago
    Yes, but, embedded software...
comprev 3y ago
The randomisation feature of iOS was apparently not working for a long time despite Apple marketing otherwise [0] [0] https://arstechnica.com/security/2023/10/iphone-privacy-feature-hiding-wi-fi-macs-has-failed-to-work-for-3-years/ https://arstechnica.com/security/2023/10/iphone-privacy-feat...
- wutwutwat 3y ago
  Use any mac you want I'm sure we’re being fingerprinted other ways so it doesn’t matter. Security through obscurity isn’t security, after all.
  - Nextgrid 3y ago
    MAC randomization prevents the local network from trivially tracking you based on access point logs. Of course, if your device runs software that broadcasts some unique identifier, the network may deploy some collector service to query/capture these but that's already extra effort. On iOS I don't believe apps can run a persistent network server in the background, so background tracking would actually be quite tricky even if you had a cooperating app. Fingerprinting is absolutely an issue for device-based trackers (whether apps or websites), but from the perspective of a passive network observer they're usually quite airtight and don't leak the collected data over insecure channels.
    - wutwutwat 3y ago
      Not just access point logs, this isn’t WiFi specific. It’s to make packet inspection harder to link to a device. But, if I run say an airport network and control dns for dhcp I can track your dns requests (non encrypted dns) and interface info across MAC addresses and maybe even tag packets somehow. Also, if every device that connects is routed through a dedicated vlan only containing that device, it can randomize itself all it wants, it’s on a network by itself so it can’t “hide in the crowd”. Those are just things off the top of my head and am not a network person. I’m sure it’s not preventing the motivated from tracking you if they want to.
hnlmorg 3y ago
We aren’t talking about MAC randomisation (which itself would cause issues if it happened every few minutes) but UUID randomisation in UPnP. It’s a completely different protocol that sits in a completely different layer on OSI to the data link layer (where MAC addresses live). UPnP is literally just a protocol that sits on top of HTTP.
- wutwutwat 3y ago
  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.

iamleppert 3y ago

Probably just how it’s written. Takes extra effort to save a UUID vs. just generate a new one every time some function runs.

dathinab 3y ago

in general devices from time to time pretending to be a new device can be preferred as a form of privacy protection E.g. with IPv6 we have enough addresses to give every device in the world today and for decades to come unique addresses and using devices MAC you can reliably generate them collision free. So you don't need NAT so routers can well only route instead of routing and proxying IP Address/Port. Problem is that leaks a lot of private information. So a schema was added which while upholding the properties allows "randomizing" (and changing over time) addresses. But coming back to the smart TV I don't think this is the case here as it changes the address _far_ to often and it's a UPnP i.e. local network only Id. Furthermore UPnP also advertises devices descriptions so de-anonymizing randomly changed IPs is more then trivial. My guess is the UPnP software module is started anew every few minutes and generates a new uuid every time. This might be due to it not persisting the uuid. Weather that is because they just didn't bother implementing persistent device ids or weather it regenerates it after every time it crashes and it crashes every few minutes I can't say. But it looks a huge lot like a software bug. What also is a 100% a but is that this external device misbehavior can mess up Windows (through I wouldn't be surprised if it isn't just Windows which has problems with that). It means that there is a resource controlled by external events which isn't "bound" which from a security POV is always a terrible idea, even if it might at most cause a DOS attack (not just because DOS is bad but also because it's not rare that people find ways to use DOS attacks alongside other found attack vectors to more reliably succeed).