On Sunday, September 25, 2016 at 7:32:34 AM UTC-4, Chris Laprise wrote: > On 09/25/2016 07:08 AM, johnyju...@sigaint.org wrote: > >> Let's say I have a Qubes machine connected to a 2nd laptop by Ethernet. > >> > >> The Qubes machine is sharing its Internet connection. > >> > >> Let's say the Qubes machine gets hit with a DMA attack. > >> > >> The 2nd laptop is not a Qubes machine, and therefore doesn't have VT-D for > >> DMA protection. > >> > >> Can the DMA attack be "carried forward" to the 2nd laptop... or is it > >> killed for good by the Qubes machine..? > > My take on it: > > > > If the Qubes machine is hit by a DMA attack, it is compromised and could > > thus tamper with the forwarded Internet connection however the attacker > > desires. (As well as scraping any credentials you might use in common on > > the Qubes box, and carrying out aggressive attacks on anything on your > > network.) > > > > So a compromised machine couldn't specifically "forward" a DMA attack per > > se, but it has full control of the Internet connection and traffic to and > > from the laptop. > > I think this should be clarified... > > Qubes users' typical idea of a DMA attack is one that's initiated as a > network-bourne attack against the NIC. Then, once malware has control of > the NIC, the actual DMA attack can take place against whatever processes > are running in the machine. > > Inside Qubes, that's not a huge deal because the NIC's DMA is contained > in sys-net and the other (downstream vms) don't have hardware NICs that > can also be attacked. The netvm can try to mess with the traffic of your > connected vms, but you might be using a proxyvm gateway (running openvpn > or whonix/tor) in which case the netvm malware is pretty helpless... it > could try to do sidechannel attacks but the topic here is DMA attacks. > > > Any unencrypted net connections could be spied upon, tampered with, > > MITM'd, injecting spyware (which may in turn use a DMA attack itself, or > > 0day exploits, or whatever) into an unencrypted mail/http connection, for > > example. > > That's why applications should use SSL/TLS just as a routine matter. In > some vms, you might even want to set 'Https Everywhere' to only allow Https. > > > I'd say it's no more risky than what a crooked ISP, a hacked Cable Modem, > > or anything else upstream in the net connection could achieve. > > > > Any strongly encrypted connection (Tor, OpenVPN, HTTPS without state-actor > > CA certificate tampering/spoofing, etc.) should be safe, other than > > potential denial-of-service which would be pretty noticeable. > > > > I would say having the Qubes box between the laptop and the Internet > > generally increases the safety of the laptop. > > Especially if you did the sharing via a separate vpn or ssh tunnel. But > in general, I don't think Qubes security should be considered much if > any benefit to adjacent non-Qubes systems. > > Chris > > > The benefits far outweigh the risks, as long as you don't do most of your > > critical browsing/email through unencrypted connections; in which case > > your probably screwed anyway :). > > > > JJ > >
or just only allow https in the vm firewall settings. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/43280b8f-0548-40df-8d5d-8e46cd584d3e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
