Comment by Someone1234 | Hacker News Reader

Comment by Someone1234 | Hacker News Reader

Conceptually embedded devices shouldn't even have writeable storage for malware to persist. This doesn't require a special operating system or a kernel patch, Linux (which is popular for these types of devices) natively supports read only storage.

You can have a small read/write volume where update bins are placed. Upon reboot, a pre-boot environment checks the bin's cryptographic signature, and if it passses it then extracts the bin, overwriting the the read only filesystem and a second reboot occurs allowing normal boot into the updated OS where the file system is again read only.

This is how e.g. the Playstation works. Amongst several vehicle manufacturer's infotainment units. Even Windows uses a pre-boot environment to write certain "hard lock" files and registry areas. This is not wild "pie in the sky" thinking, this is an industry norm or was.

Why does a smart TV that's meant primarily for streaming content directly from the internet need a R/W file system? Settings? Couldn't that be stored in a micro-volume without execute flag and SELinux limits?

>> Why does a smart TV that's meant primarily for streaming content directly from the internet need a R/W file system?

Downloading Ads. I read that these TVs run their own ads, sometimes via "partner" apps (IIRC something like a TV-network app) that Samsung disclaims responsibility for. For these reasons, my Samsung TV has never been connected to the internet and never will be. TV should be a monitor + tuner, nothing more. If it didn't work without a network connection I would have returned it as defective.

BTW, the 55" curved 4k TV makes an excellent monitor and is cheap at Walmart.

You need persistent storage for OTT applications to store authentication tokens. Without this storage users will have to re-authenticate every time they start an OTT application, usually this means entering their email and password using an on-screen keyboard.

Some streaming devices do come pretty close to what you're proposing, though. One technique is to unpack apps from persistent, (sometimes) read-only storage into a RAM filesystem at boot time, then run the app from there.

Or the device sends a signed request to the third party servers for your app, you verify the request through your account on the server, and your device never needs local storage.

There would be tradeoffs, but rhat could be made to work. It is different from how things work in practice today.

And what if the cryptographic hashes are broken, stolen, or whatever? Once you're in the system, if there's rewriteable storage at all, it can be compromised.

If you want to stream, the apps need to be updated as streaming service providers update their systems from time to time.

> And what if the cryptographic hashes are broken, stolen, or whatever?

You've still improved the scope of exploitation from:

- Need an RCE (remote code execution) in any service on the device for a persistent threat

To:

- You need an RCE in any service on the device

- You also need to be able to generate a cryptographically signed update which will install for persistent threat

That's a win. That's a BIG win. Particularly as regular updates can replace compromised cryptographic credentials.

You're essentially arguing the "if the solution is imperfect, we should do nothing" fallacy. You haven't proposed a better alternative, just argued that no action is better than an action that falls below perfection.

> If you want to stream, the apps need to be updated as streaming service providers update their systems from time to time.

Which may require a reboot. It is unfortunate, but makes the device more secure and less susceptible to hardware originated data corruption (since the volumes can be completely verified for correctness, compared to the source images which can also be verified for correctness via HMAC).

There's no specific set standard for how bin updates work. They can range from complete file system updates to incremental updates.

I really don't get what you're saying. None of your proposals would solve the problem being discussed. Are cryptographic hashes not already completely common-place? That was standard even 10 years ago, if only just to make sure the files are not corrupt.

In actuality, running virus checks is a fine idea, particularly if the process can be automated and updated for newer threats.

Once an attacker has control of the firmware, faking virus scan results is trivial.

It seems you're conflating cryptographic hash with a digital signature.

Digitally signed updates via pre-boot environment with a read only post-boot environment is an effective way to solve the problem being discussed.

needing to forge signatures/hashes isn't a particularly small speed bump for malware . . . this is obviously a big step up from unprotected space.

Reply on news.ycombinator.com