On Sat, Mar 26, 2016 at 5:25 AM, ForgottenBeast <[email protected]> wrote:
> This might seem a little bit naive but a big part of tails use cases > need internet connectivity. Now if we start with the premise that there > IS malware in a blob (this is an hypothesis expressed for the sake of > the argument) this malware, to do anything useful, should satisfy some > properties: > > -to be able to identify itself and the machine on which it runs, mac, > and geographical location or at least provide a way to find out its > current ip address > -to be able to retrieve data > -to be able to communicate with its creators. > > Now barring a physical access scenario where opfor just walks in this is > going to take place over the wire. > I would think that with the amount of network debugging and packet > sniffing taking place around tails (to identify leaks and for > configuration purposes) a strange packet would be quickly detected. > Far from being naive, you are actually giving me a reasonable description of the risk evaluation, even if it's happening sporadically, and more as a side effect than a directed effort. And I agree that a body of /negative/ evidence thus accumulated (no suspicious packets anywhere for a long time) does increase the assurance in the software being benign, but the methodology is limited to detecting payloads which are actively and universally exploited today. The dormant backdoors, exploitable at will, are undetectable. You are also not taking into consideration how easy it is for a blob vendor to insert a malicious piece at any time: simply issue a driver update and wait for the updated kernel to make it into the various distributions. So even the blobs that are clean today carry a non-trivial probability of becoming dirty after every kernel bump, and even though looking at the raw traffic can make us relaxed about the current kernel, every blob update makes all the past data irrelevant. > > The juniper example you gave is, iirc, about a backdoored rng that would > allow easy cracking of vpn encryption. It's not quite the same thing, is > it? Now even if said malware were to completely compromise the operating > system it still would need to communicate about what it found. > The Juniper example was meant to demonstrate the complete lack of accountability on the part of "legitimate" sofwtare/hardware vendors, and the technical details are not at issue here. My point is that while individual crackers sometimes get jail time, big companies seem to be immune to prosecution, unless they protect user privacy and work _against_ cooperating with the law enforcement (see Lavabit). Another well-known example of this behavior is Apple's audacious erasure of 1984, which is clearly a break-in: an unauthorized (by user) access and the mishandling of users' files. If you did this, you'd be in jail, but Apple just shrugged it off. I am not very well versed on the legal issues surrounding computer-related crime, so I won't comment on why vendors never get punished, but for my money it's plenty enough to observe that they don't, for whatever reason. And this is a rather giant factor when it comes to them acting on the temptation to distribute invisible malware: there's virtually no downside, so I suspect most of them are doing it. And so suppose we finally discover a network card blob with a backdoor, which is activated by a secret knock, and which allows remote access to the card, and ultimately to the main CPU via DMA. My contention is that no one will get in trouble, not a single person or company. The backdoor will be declared a debugging feature accidentally left behind, a meaningless apology will go out along with a "fixed" blob, and then software vendors will go back to highfiving each other. Given this legal climate, why wouldn't they insert a backdoor or leave it behind, especially when the FBI and NSA keep telling them it's a good thing? Which is why I personally believe it's already there with very very high probability. _______________________________________________ tails-support mailing list [email protected] https://mailman.boum.org/listinfo/tails-support To unsubscribe from this list, send an empty email to [email protected].
