"Carrying forward" a DMA attack..?

[neilh...@gmail.com]

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..?

Thanks

[Chris Laprise]

The former is true: A Qubes netvm (e.g. sys-net) is like having a
separate router device. If its compromised it could launch (non-DMA)
attacks against other devices on the net... AND against your appvms.

But proxyvms can help protect your other vms in various ways: A
sys-firewall can filter packets with hardly any risk of being attacked
itself. A VPN gateway can reject anything that doesn't belong to the
encrypted packet stream. Etc...

Of course, non-networked VMs are the safest of all.

Chris

[johny...@sigaint.org]

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.

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.

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.

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

[johny...@sigaint.org]

> 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.)

That's also assuming the DMA attack isn't confined to a
non-net/non-firewall/non-dom0 VM.

A single compromised AppVM that isn't involved in the shared network
connection shouldn't affect the laptop (but could scrape info and tamper
with anything you do in that VM, which might have cascading effects with
any credentials used elsewhere).

But if dom0 or sys-net/sys-firewall (or whonix-gw or any other
netvm/proxyvm) is affected by the DMA attack, the rest of what I said
should apply.

JJ

[Chris Laprise]

On 09/25/2016 07:08 AM, johny...@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

[johny...@sigaint.org]

Chris wrote:
> 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.

I'm curious as to why you would say this.

Any additional firewall between a Laptop and the network is a plus for
security, and with Qubes isolating the NIC in a virtual machine, its safer
from compromise than a typical firewall.

Now, some firewalls, such as shorewall running on a Linux box, might have
slicker and more advanced/flexible firewall configuration than Qubes, the
network card isolation is a huge boost to security in my eyes.

And there's nothing stopping you from running shorewall or another
firewall in your sys-firewall, to get the combined benefits of both
approaches.

While I like the simplicity of Qubes' firewall config, I'd actually like
to see more powerful firewall/iptables configuration, as well as having it
locked down to a greater degree by default (such as with Tails' iptables
configuration).

Similarly, I'd like to see apparmor installed and configured tightly with
Qubes by default. (Again, Tails is a good example of including apparmor
support by default, although they inexplicably exclude the "extra"
profiles, which include chromium and some other useful/critical profiles,
IMO. Maybe its for performance reasons, but it still seems crazy [almost
suspicious, lol] not to include them.)

Qubes NIC isolation + iptables + apparmor can make a system incredibly
secure against breaches. While Qubes' isn't designed as a firewall for
other computers/devices, it strikes me as having the potential to be a
safer firewall base than the alternatives.

JJ

[johny...@sigaint.org]

Chris wrote:
> 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.

This is one of my favorite implicit features of Qubes:

Setting up multiple layers of network protection is sooooo much easier
than on a non VM'd system.

When I used to use Tails, I set things up to use VPN-over-Tor, so any
dodgy Tor exit node only sees encrypted VPN traffic, and my nosy ISP
doesn't know if I'm use a VPN, or which provider. I've also done
Tor-Over-VPN, and VPN->Tor->VPN setups. :)

It was a nightmare to set up. And that can lead to mistakes.

On Qubes, it's a simple matter of layering another ProxyVM above
sys-firewall. Add the NetworkManager service in the VM Manager settings,
and you can configure OpenVPN, and you're good to go. Any additional
layers are just as easy.

(Qubes-whonix is a good example of such a configuration.)

Memory can be a problem for limited systems (such as mine) and multiple
ProxyVM layers, but (at a slightly greater risk of the effects of a
compromise) could do your VPN configuration right in sys-firewall/sys-net
if you wished, to avoid additional VM's.

For example, with sys-net -> sys-firewall -> sys-whonix -> sys-vpn ->
AppVM (and hey, throw a Tor Browser on top of that if you want to go nuts)
any attacker has quite a few challenges ahead of them. :)

I generally go with sys-net->sys-firewall->sys-vpn, and Torbrowser when I
need to get to a .onion site.

It's rewarding to fire up iptraf-ng in sys-net, and see nothing but
encrypted packets to your VPN provider, while your AppVM's think they're
just on the regular net. :)

(Standard disclaimer, of course, that your VPN provider will see any
unencrypted traffic you send through it. As Chris mentioned,
https-anywhere can with that risk.)

JJ

[Chris Laprise]

On 09/25/2016 08:12 AM, johny...@sigaint.org wrote:
> Chris wrote:
>> 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.
> I'm curious as to why you would say this.
>
> Any additional firewall between a Laptop and the network is a plus for
> security, and with Qubes isolating the NIC in a virtual machine, its safer
> from compromise than a typical firewall.

I guess I was thinking in terms of using a single NIC/netvm. Having a
second NIC/netvm only for the other laptop does offer hope that one DMA
exploit can't carry over to the other netvm (and thus the other
laptop).... but that protection is probably due not only to vt-d but to
some filtering done by an intermediate proxyvm or such.

Its quite true about Qubes' network "layering" offering both greater
simplicity and security. I think this is because potential leaks around
a tunnel are more easily dealt with in a vm that's devoted to the tunnel.

Chris

[raah...@gmail.com]

or just only allow https in the vm firewall settings.

[johny...@sigaint.org]

>> 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.

That's a wonderfully simple solution that never crossed my mind.

(My VPN ProxyVM is only allowed to send packets to specific VPN servers on
the given port, using the firewall, which is a bit of a parallel to that.
Great peace of mind for stopping leaks of unencrypted data.)

JJ

[Jeremy Rand]

raah...@gmail.com:

> or just only allow https in the vm firewall settings.

I assume you mean whitelisting TCP port 443? If so, be aware that while
this will stop most non-HTTPS traffic, there is nothing that prevents
other protocols from using port 443. It's a fairly well-known attack on
Tor's "stream isolation by port" feature for websites to use nonstandard
ports in order to get isolated in the wrong Tor circuit (e.g. in order
to deanonymize SSH traffic), which is why Tor doesn't stream-isolate by
port by default.

Whitelisting TCP port 443 is still better than nothing, though, assuming
that you don't expect any legitimate traffic to go over other ports.
Just be aware that it's trivially easy to bypass for an attacker.

Assuming that you're using a Firefox-based browser (including Tor
Browser), you can get some defense in depth by also enabling the feature
of HTTPS-Everywhere that blocks all non-TLS requests. Nothing wrong
with combining this with the firewall whitelist that you suggested.

Cheers,
-Jeremy

[raah...@gmail.com]

I do https only on most of my vms. Of course nothing is 100% but i'm not sure if you are saying that would make me more vulnerable? I believe this is common qubes practice among even the devs.

what extra benefits would https everywhere plugin have over the firewall? I do use this plugin on the vms that aren't restricted to only https, I also use ublock origin. I also always use noscript or scriptsafe on all vms. But is there extra settings to use in https everywhere, because all I thought it does was verify certs with the fsf. I use it on all my machines and maybe i'm missing the setting to stop http connections, but I think the firewall is all you need and separate from the browser itself.

But by blocking everything but https is helpful not just against mitm, but say for example in your email vm where you dont' want to accidentally click a bad link. So if some sketchy non http link you would be forced to copy it to a less privileged vm to open it.

[raah...@gmail.com]

On Tuesday, September 27, 2016 at 5:11:27 PM UTC-4, Jeremy Rand wrote:

oh I see now there is the feature in the plugin ive never used lol. I still think its unescessary if you already blocking that traffic with the firewall, especially if that plugin or browser is compromised, especially with latest news about firefox plugins. For example noscript itself is considered a vulnerability on firefox now.

[Jeremy Rand]

raah...@gmail.com:

As I said, it gets you defense in depth because the two mechanisms
prevent different (though overlapping) attacks.

HTTPS Everywhere's feature for blocking non-TLS requests will block
non-TLS requests from Firefox that use port 443, while the FirewallVM
won't be able to stop this. For example, a request to
http://www.nsa.gov:443/ will be stopped by HTTPS Everywhere, since it
knows the protocol being used as opposed to just the TCP port.

The FirewallVM, on the other hand, will block TCP connections on ports
other than 443 even if Firefox in the AppVM is compromised. E.g. you
visit https://www.nsa.gov/ , they deploy a Firefox zero-day, and are
thus able to bypass HTTPS Everywhere.

Both of these attacks have a lot of overlap (e.g. a simple request to
http://www.nsa.gov/ will be blocked by both). But each defense does
prevent some types of attack that the other doesn't, so it makes sense
IMO to use both. Definitely won't hurt you, and it might help depending
on what attacks get aimed at you.

(Of course, either of those defenses alone is likely to prevent the vast
majority of real-world attacks, but I'd still suggest doing both.
Justified paranoia is why we're all here, right? :) )

Cheers,
-Jeremy

[raah...@gmail.com]

good points. Yes seems like a good idea to do both.