The display and the business end of the equipment are critical and should not be network-connected (or even have USB ports, for that matter). The part that uploads to whatever big server should have updates all the time. The critical bit should either be connected to the non-critical bit by a genuinely one-way link (e.g. unidirectional fiber) or should use a very small, very carefully audited stack for communication.…
Yep. That worked fine for the Iranian uranium centrifuge guys...
Pretty sure you can build an X-Ray/MRI control software in Rust on top of seL4, and do lightweight verification (or, even better: hardware breakers of some sort) around issues like "will output lethal doses of radiation". That is a general purpose enough kernel and a general purpose enough programming language, without having to drag in tens of millions of lines of code intended for personal GUI systems... Then for m…
Rust has a lot of nice safety features, but the compiler hasn't been formally verified at all.
Yeah, I am aware. The problem is that using, say, CompCert might result in less security in practice, since although the compiler transformations are verified, code written in C is usually more prone to security issues. It also puts the burden of proving memory safety on the developer, which is a requirement for proving nearly anything else. I don't know Rust well enough to know if this applies for sure, but I think it is a lot less to ask from the manufacturer that they produce a proof of the form "assuming this language's memory model holds, we have properties X, Y and Z" and then just hope the compiler is sane, versus requiring a more heavy-weight end to end proof. Also, eventually there might be a mode for certified compilation in Rust/Go, at which point you get the best of both worlds.
In offense of these medical devices, they should never have been running Windows or any general purpose OS in the first place! A lot easier to guarantee security if the entire thing is a well tested 10-50KLOC Rust daemon on top of seL4. I am not even asking them to do formal verification themselves, just a small trusted base and reasonable secure coding practices. I mean, come on, a critical medical device running th…
Of course, such devices can put their code in ROM, and so any malware would not survive a reboot.
Sure, but then, you also need strict W^X memory protections, without exceptions (kernel included), since malware in memory of a device that doesn't often reboot is dangerous enough. For example, the very best malware for network devices never writes itself to disk even if possible, in order to avoid showing up in forensics. This already precludes most general purpose OSes and is still technically vulnerable to some convoluted return-to-X attacks that just swap data structure pointers around and use existing code to construct the malicious behavior, so I'd still feel better with a minimal trusted base even then.
I would be curious as to the agenda of these "Shadow Brokers" it all sounds very Gibsonesque. Recent events have made Neuromancer seem more and more prophetic to me.
They were hackers who acquired a trove of state secrets and were looking to make a quick buck. I've linked an archive of their initial statement below. I think it speaks volumes about how far the NSA can be trusted that these people were the ones to leak the tools instead of a state actor or someone previously known. https://web.archive.org/web/20160815124425/https://github.co...
that's pretty heavy. life imitating art for sure. thanks
My first thought would be to clear the routing table on Windows (maybe using a batch script on startup?) and using bridged networking in the VM. That would totally disable internet access on Windows though, including updates (but you also wouldn't have that attack surface!)
Thanks. Had a brief look, seems useful. Does the VM using the "nat" mode of networking also use Windows routing table? I don't know much about the networking between guest and host, except that the guest uses NetworkManager through its ethernet device. Even though this is a virtual device, I didn't think it would go through Windows' own net stack. Would the bridged networking be any different than passing through the…
As far as I understand it, with bridged networking you're basically sharing the network device -- your VM has it's own stack down to the MAC address. So as long as your network device is still online (in the sense of being enabled in Windows and having a cable attached), packets for a particular MAC will travel to the right network stack.
This is probably useful from the VirtualBox manual:
> With bridged networking, VirtualBox uses a device driver on your host system that filters data from your physical network adapter. This driver is therefore called a "net filter" driver. This allows VirtualBox to intercept data from the physical network and inject data into it, effectively creating a new network interface in software...