Most linux distributions can be run on read-only filesystems (same as from cd) BUT the only true security hole is running them as root, because volumes can be remounted in rw mode on the fly. I'm using this strategy on my raspberryPi that is running the game console emulators for the kids. They don't do no shutdown, they just pull the plug/wallwart. Roms are stored on etx4 USB, mounted read-only. This one is just mounted in rw mode on the PC, to manage the roms and emulator binaries.
Just make sure you run linux as unprivileged user. Privilege escalation is a thing though, but unlikely on patched systems. However, when you're not connected to the net, i doubt there is a fair chance of catching a successful exploit via USB.
Again, your postulated security described above is utterly dependent upon the rando USB device implementing only a storage class endpoint.
Whatevs. Good luck with that.
I would care less if i am running as unpriv. user on a system that is not network connected. I didn't mention that i'd never use a host with actual user data on it. I thought that would be clear because i was replying to Dabs' "frozen sysimage" approach. I would definitely not use a guest VM but a dedicated box that i can reset via dd or similar disc imaging tools, i wasn't clear on that, as i just recognize while typing this.
And yes, it's part of the very basics: there is no 100% security, only 100% security against certain (and therefor known) attack vectors.
I’m gonna say this one last time. Your postulated recovery is weaksauce against anything other than a disk-resident vector.
dd ain’t gonna do nothing for you if malware-containing USB infects the BIOS.
Forget about badUSB/badBIOS as it has already been perfectly documented and evidenced... Maybe you are the right person to ask this, depending on how low level your work or knowledge goes... I have always thought another theoretical attack vector would be in the HD firmware from which it would be possible to on-the-fly replace a call to the boot sector adding some payload to it. I still think so but... have you ever seen any real practical example/exploit of that? Even as a PoC "lab test"?
Well, if you can program new drive FW, and you can get it programmed into the drive’s FW store, then yes - that would be trivial.
Indeed, I’ve shipped devices that provided canned boot sector data before - not as an exploit, but because the operating environment needed such in order to function. Of course, that was a ‘from the factory’ thing, not a field exploit.
However, drive FW development is non-trivial. Embedded computers without public data on memory maps, peripheral specs, etc. Nonstandard SoCs, built on various ISAs, dependent upon lots of in-house developed tools. Very difficult. Albeit doable in theory.
However^2, most (all?) contemporary drives will not load FW that does not have a valid crypto signature. I have never heard of any case of a successful exploit of a drive’s FW sig being cracked.
Though drive companies are just collections of people, and some people in the chain of custody for the root certs may not fully understand their responsibilities. I could see the possibility of a leak of keys happening some day by some vendor or another. At which point, such an exploit again becomes plausible.
Nice. Good to know it is something that hasn't been seen in the wild yet even though I guess, from your description, it is not something completely out of reach for a determined (and resourceful) enough attacker.
It also sounds as something that YOU (or someone you know) could probably do given enough time and motivation. And when I say YOU, I can perfectly mean some/many others. So the risk is real. I guess the real reason it hasn't happened yet is mainly because there are plenty of WAY more cost effective attack vectors. If it were the only one, it would be exploited for sure.
Quote
Indeed, I’ve shipped devices that provided canned boot sector data before - not as an exploit, but because the operating environment needed such in order to function. Of course, that was a ‘from the factory’ thing, not a field exploit.
Yeah, that's exactly what THEY wanted you to believe
Just kidding. Or maybe not... Was that "canned boot" somehow easily replaceable with a different one afterwards? Ie: the canned boot residing in another area of the HD which could be updated or using a custom tool? Or just reusing all the developed firmware, replacing the "canned boot" and generating the payloaded firmware?
