4 ms·
I don't think it was a WebRTC issue, I think they crafted a video such that the decoder would end up executing code. Similar to what happen to Jeff Bezos.
by alex_duf 6y ago
I don't think it was a WebRTC issue, I think they crafted a video such that the decoder would end up executing code.
Similar to what happen to Jeff Bezos.
- mikece 6y agoEven so, wouldn't running Tails on a VPN have only exposed the IP address of the VPN connection?
- stefan_ 6y agoThe point is that you can't have the Tails machine decide what connections are proxied through Tor and which are not. If you have an external device like a router or a Raspberry that transparently tunnels the data, a compromise of the Tails machine can't trivially expose your real network connection.
- schoen 6y agoOne thing that I've thought about this is that whether you do the firewalling on the end-user device or on another device, the firewall will normally permit connections to every Tor guard. That means that if an attacker can make the device make a "special" TCP connection of any kind (e.g. just an HTTP request) to an arbitrary IP address and port number, it could make that connection to an actual Tor guard node run by an affiliate of the attacker. Then the attacker can distinguish that connection from other Tor activity because it isn't Tor traffic. The point of that is to say that "only allowing the machine to talk to Tor nodes" wouldn't stop an exploit from effectively bypassing Tor—by talking in a slightly unusual way to an adversary-controlled Tor node! If they're not already doing it, it might be safer for Tails to learn the specific guard that its copy of Tor is using at a particular time, and only allow outbound traffic to that guard rather than to any Tor node. (Another precaution which they might already be taking: only the Tor daemon process should be able to open remote sockets at all.)