Re: [qubes-users] "Carrying forward" a DMA attack..?
On Tuesday, September 27, 2016 at 9:14:51 PM UTC-4, Jeremy Rand wrote: > raahe...@gmail.com: > > On Tuesday, September 27, 2016 at 5:11:27 PM UTC-4, Jeremy Rand wrote: > >> raahe...@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 > > > > 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. > > > 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 good points. Yes seems like a good idea to do both. -- 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/95ea1c42-5f2f-477a-9314-e4460d374fb1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
raahe...@gmail.com: > On Tuesday, September 27, 2016 at 5:11:27 PM UTC-4, Jeremy Rand wrote: >> raahe...@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 > > 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. 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 -- 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/6560bf5f-8710-40e8-0a14-be32c57adae3%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] "Carrying forward" a DMA attack..?
On Tuesday, September 27, 2016 at 5:11:27 PM UTC-4, Jeremy Rand wrote: > raahe...@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 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. -- 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/5a29f491-7cf3-4311-b532-edf7441643a7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
On Tuesday, September 27, 2016 at 5:11:27 PM UTC-4, Jeremy Rand wrote: > raahe...@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 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. -- 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/18285799-3c78-4349-b368-22b1329c4329%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
raahe...@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 -- 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/8d47d4b9-7ed4-84f4-e697-13db24877024%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] "Carrying forward" a DMA attack..?
>> 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 -- 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/5068e719853d90f9b3551cca68a41026.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
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.
Re: [qubes-users] "Carrying forward" a DMA attack..?
On 09/25/2016 08:12 AM, johnyju...@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 -- 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/605b6a87-b40e-132f-803b-a7260a520846%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
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 so 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 -- 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/57abd72601b36ae3f1206f134fa5b74c.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
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 -- 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/598dca948a53984b3391d5b33cb580b8.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
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 -- 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/c65148ba-d1d8-2955-3284-19a09e3faa41%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
> 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 -- 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/6978265996a4e9a7ec09b8eac062a91a.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
> 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. 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 -- 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/bfbc4f1250a9ae5f80d3cc221b6d6ba8.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Carrying forward" a DMA attack..?
On 09/25/2016 02:34 AM, neilhard...@gmail.com 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..? Thanks 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 -- 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/96df4645-8bc9-cbbf-ee29-a9951591b3c0%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
