5 ms·

the device supports software updates 'Cause they need somewhere to load in those exploits! A hypothetical device which is all read-only (except perhaps for a

the device supports software updates 'Cause they need somewhere to load in those exploits! A hypothetical device which is all read-only (except perhaps for a very carefully crafted, limited set of configurable parameters) might in some cases be more secure than the bulk of what's on the shelves today. After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which in a sense are similarly 'read-only').

moritonal 2y ago
An interesting thought is how when devices couldn't auto-update, they had to work out the gate. I imagine this encouraged companies to do much better testing to reach a gold-plate before deploying.
- jonhohle 2y ago
  Less critical, but video games are the same way. Companies will press and ship discs with known broken games and then issue a patch of dozens of GBs day one. The whole point of having a disc is when all the servers are off line, and the store have shut down, the game is still playable.
- helsinkiandrew 2y ago
  Assuming these are network devices - it can be harder to certify future working if the network services they rely on become unavailable or when the failure only occurs at scale. Case in point when 700,000 Netgear routers pinged the University of Wisconsin–Madison NTP server (harcoded IP address) every second. https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#Netgear_and_the_University_of_Wisconsin%E2%80%93Madison https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#Ne...
- kube-system 2y ago
  This is true, but mostly only relevant to the expected user functionality. User acceptance testing in waterfall development doesn't often identify security vulnerabilities.
- rkagerer 2y ago
  Agree wholeheartedly. Seems like nearly everyone seems to "cheat" these days and ship well before the product is remotely finished.
ocdtrekkie 2y ago
Yep! My Insteon home automation devices have no firmware update capabilities. They also have an extremely simple local RF protocol. They allow smart device behavior but are too stupid to be "compromised".
- wpm 2y ago
  Local RF? What protocol? Proprietary?
  - ocdtrekkie 2y ago
    It's proprietary but relatively easy to reverse engineer, the details are out there. In the US it uses like 914.5 MHz or something, and I can send instructions to devices with an extremely simple serial protocol on my computer. No Bluetooth, no Wi-Fi, no protocol sophisticated enough to distribute code. Just locally transmitted instructions.
    - kube-system 2y ago
      Do they require auth and use solid crypto? If not, they are vulnerable, it's just that the vulnerability requires the attacker to be within range. People thought old analog 900mhz cordless phones were fine until others realized you could just tune a radio to that freq and listen to your neighbors.
      - ocdtrekkie 2y ago
        They're not vulnerable in any way that matters. If you manage to get a device in range you can... turn my lights on and off? You can't program them to do malicious things over the Internet. They don't have any sensitive information you can access. There's no damage you can do them. The problem with saying you need auth and crypto is now you just added a bunch of complexity you have to maintain and update and hence now you've introduced vulnerabilities.
        kube-system 2y ago
jayd16 2y ago
Some things to realize about read-only devices is that once they are cracked, they are cracked forever. The devs have dev time to secure the device, the hackers have infinite time to crack it. Once done, the game is up. All instances are now easily exploited. The more popular the device, the more knowable upside to an exploit. If the device can be updated, then usually the exploitable timeframe is limited and its unknown if the attempt is even worthwhile. > After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which in a sense are similarly 'read-only'). Well basically because any device of consequence is trivially hacked by now. Think about game consoles or anything that would have DRM today.
- mjevans 2y ago
  A really dumb camera that just has an interface that's polled for data by a remote host is more likely to be used in a secure way than a 'smart' camera that tries to remember state and talk to an external server itself.
  - kube-system 2y ago
    Not at all. Many old mjpeg IP cameras worked this way and they ended up on the open internet. Shodan is full of them, still.
    - ndriscoll 2y ago
      So don't put them on the open Internet. It's much easier to do that than it is to secure a device that creates outbound connections to some untrusted external server (which manufacturers are). If it doesn't try to use UPnP or anything, it will not be in the open by default. If your threat model for consumer IoT devices does not include manufacturers in 2025, you are completely confused about computer security. Having a standard to encourage devices to talk to manufacturers is completely backwards. We should have certifications that devices create no outbound TCP/UDP flows.
      - comex 2y ago
kube-system 2y ago
Most software vulnerabilities aren't intentionally added backdoors, but flaws in the software that shipped on a device. > After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which in a sense are similarly 'read-only'). Quite a lot -- these are some of the easiest devices to hack. The only saving grace is that most of them are not connected to the internet so they are only vulnerable to local attacks. But garage doors, cordless phones, keyless entry, smart locks, smart home protocols, etc are notoriously vulnerable. The reason you don't hear about new vulnerabilities each week is precisely because they're aren't updatable. The fact that they don't get updates with new vulnerabilities is not an advantage when they permanently have older vulnerabilities.
- ndriscoll 2y ago
  > Most software vulnerabilities aren't intentionally added backdoors, but flaws in the software that shipped on a device. Disagree, it is extremely common for e.g. TVs and smart phones to ship with malware included. In fact it is almost impossible to buy some classes of devices that aren't intentionally compromised. Having the thing never connect to the Internet at all and never receive updates is a far better security posture, and is the common recommendation among knowledgeable people for e.g. TVs. In practice, your neighbors are almost certainly quite a bit less malicious than whatever a smart device might talk to on the Internet. Your neighbor isn't going to hack your cordless phone. Your TV manufacture is definitely going to drop malware onto it, disable functionality (i.e. damage it), etc.
  - kube-system 2y ago
    > Disagree, it is extremely common for e.g. TVs and smart phones to ship with malware included. Both are common! But there are many hundreds of thousands of known software vulnerabilities. > Having the thing never connect to the Internet at all and never receive updates is a far better security posture It might be, depending on the particular situation. But it doesn’t really matter for IoT devices, because they all, by definition, connect to the internet. “Don’t connect to the internet” is a nonsensical suggestion for IoT devices.
  - 2y ago
hn_throwaway_99 2y ago
> After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which in a sense are similarly 'read-only'). Tons and tons? I don't understand this viewpoint at all. As the saying goes "There is no 'Internet of Things', just an Internet of unpatched Linux devices." That is, the primary vector for malware is devices that aren't (or can't) be patched after vulnerabilities are discovered.
nyrikki 2y ago
You don't need access to persistent storage, especially with multi-entry executables like busybox, which are often similar to built in rootkits today. I actually just spent time last week getting rid of tftpd, telnetd, netcat etc... on some IP cameras last week. You only need a few k of ram to have a bot, especially with how it is almost the rule that embedded system run everything as root. If you have the ability to do firmware extraction, look at just how bad the industry is now.
deleted 2y ago
[deleted]

moritonal 2y ago

An interesting thought is how when devices couldn't auto-update, they had to work out the gate. I imagine this encouraged companies to do much better testing to reach a gold-plate before deploying.

jonhohle 2y ago
Less critical, but video games are the same way. Companies will press and ship discs with known broken games and then issue a patch of dozens of GBs day one. The whole point of having a disc is when all the servers are off line, and the store have shut down, the game is still playable.
helsinkiandrew 2y ago
Assuming these are network devices - it can be harder to certify future working if the network services they rely on become unavailable or when the failure only occurs at scale. Case in point when 700,000 Netgear routers pinged the University of Wisconsin–Madison NTP server (harcoded IP address) every second. https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#Netgear_and_the_University_of_Wisconsin%E2%80%93Madison https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#Ne...
kube-system 2y ago
This is true, but mostly only relevant to the expected user functionality. User acceptance testing in waterfall development doesn't often identify security vulnerabilities.
rkagerer 2y ago
Agree wholeheartedly. Seems like nearly everyone seems to "cheat" these days and ship well before the product is remotely finished.

ocdtrekkie 2y ago

Yep! My Insteon home automation devices have no firmware update capabilities. They also have an extremely simple local RF protocol. They allow smart device behavior but are too stupid to be "compromised".

wpm 2y ago
Local RF? What protocol? Proprietary?
- ocdtrekkie 2y ago
  It's proprietary but relatively easy to reverse engineer, the details are out there. In the US it uses like 914.5 MHz or something, and I can send instructions to devices with an extremely simple serial protocol on my computer. No Bluetooth, no Wi-Fi, no protocol sophisticated enough to distribute code. Just locally transmitted instructions.
  - kube-system 2y ago
    Do they require auth and use solid crypto? If not, they are vulnerable, it's just that the vulnerability requires the attacker to be within range. People thought old analog 900mhz cordless phones were fine until others realized you could just tune a radio to that freq and listen to your neighbors.
    - ocdtrekkie 2y ago
      They're not vulnerable in any way that matters. If you manage to get a device in range you can... turn my lights on and off? You can't program them to do malicious things over the Internet. They don't have any sensitive information you can access. There's no damage you can do them. The problem with saying you need auth and crypto is now you just added a bunch of complexity you have to maintain and update and hence now you've introduced vulnerabilities.
      - kube-system 2y ago

jayd16 2y ago

Some things to realize about read-only devices is that once they are cracked, they are cracked forever. The devs have dev time to secure the device, the hackers have infinite time to crack it. Once done, the game is up. All instances are now easily exploited. The more popular the device, the more knowable upside to an exploit. If the device can be updated, then usually the exploitable timeframe is limited and its unknown if the attempt is even worthwhile. > After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which in a sense are similarly 'read-only'). Well basically because any device of consequence is trivially hacked by now. Think about game consoles or anything that would have DRM today.

mjevans 2y ago
A really dumb camera that just has an interface that's polled for data by a remote host is more likely to be used in a secure way than a 'smart' camera that tries to remember state and talk to an external server itself.
- kube-system 2y ago
  Not at all. Many old mjpeg IP cameras worked this way and they ended up on the open internet. Shodan is full of them, still.
  - ndriscoll 2y ago
    So don't put them on the open Internet. It's much easier to do that than it is to secure a device that creates outbound connections to some untrusted external server (which manufacturers are). If it doesn't try to use UPnP or anything, it will not be in the open by default. If your threat model for consumer IoT devices does not include manufacturers in 2025, you are completely confused about computer security. Having a standard to encourage devices to talk to manufacturers is completely backwards. We should have certifications that devices create no outbound TCP/UDP flows.
    - comex 2y ago

kube-system 2y ago

Most software vulnerabilities aren't intentionally added backdoors, but flaws in the software that shipped on a device. > After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which in a sense are similarly 'read-only'). Quite a lot -- these are some of the easiest devices to hack. The only saving grace is that most of them are not connected to the internet so they are only vulnerable to local attacks. But garage doors, cordless phones, keyless entry, smart locks, smart home protocols, etc are notoriously vulnerable. The reason you don't hear about new vulnerabilities each week is precisely because they're aren't updatable. The fact that they don't get updates with new vulnerabilities is not an advantage when they permanently have older vulnerabilities.

ndriscoll 2y ago
> Most software vulnerabilities aren't intentionally added backdoors, but flaws in the software that shipped on a device. Disagree, it is extremely common for e.g. TVs and smart phones to ship with malware included. In fact it is almost impossible to buy some classes of devices that aren't intentionally compromised. Having the thing never connect to the Internet at all and never receive updates is a far better security posture, and is the common recommendation among knowledgeable people for e.g. TVs. In practice, your neighbors are almost certainly quite a bit less malicious than whatever a smart device might talk to on the Internet. Your neighbor isn't going to hack your cordless phone. Your TV manufacture is definitely going to drop malware onto it, disable functionality (i.e. damage it), etc.
- kube-system 2y ago
  > Disagree, it is extremely common for e.g. TVs and smart phones to ship with malware included. Both are common! But there are many hundreds of thousands of known software vulnerabilities. > Having the thing never connect to the Internet at all and never receive updates is a far better security posture It might be, depending on the particular situation. But it doesn’t really matter for IoT devices, because they all, by definition, connect to the internet. “Don’t connect to the internet” is a nonsensical suggestion for IoT devices.
- 2y ago

hn_throwaway_99 2y ago

> After all, how many widespread hacks do you read about on old, single-purpose fixed analog or digital devices (which in a sense are similarly 'read-only'). Tons and tons? I don't understand this viewpoint at all. As the saying goes "There is no 'Internet of Things', just an Internet of unpatched Linux devices." That is, the primary vector for malware is devices that aren't (or can't) be patched after vulnerabilities are discovered.

nyrikki 2y ago

You don't need access to persistent storage, especially with multi-entry executables like busybox, which are often similar to built in rootkits today. I actually just spent time last week getting rid of tftpd, telnetd, netcat etc... on some IP cameras last week. You only need a few k of ram to have a bot, especially with how it is almost the rule that embedded system run everything as root. If you have the ability to do firmware extraction, look at just how bad the industry is now.

deleted 2y ago

[deleted]