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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to