Question on DMA attacks

[neilh...@gmail.com]

From the user FAQ:

https://www.qubes-os.org/doc/user-faq/#can-i-install-qubes-on-a-system-without-vt-d

"an attacker could always use a simple DMA attack to go from the NetVM to Dom0"

So what does this mean though..?

Can they launch this DMA attack from a compromised App VM..?

Could they simply do a browser exploit in an App VM, and then do a DMA attack from there to go to dom0..?

Or is it a lot harder than that..?

I'm just trying to work out whether it's really worth buying a new laptop just to get VT-D.... I currently have VT-X, but not VT-D.

[raah...@gmail.com]

I guess its up to your budget man. Maybe this will help you decide. http://theinvisiblethings.blogspot.com/2010/04/remotely-attacking-network-cards-or-why.html

[raah...@gmail.com]

On Thursday, July 14, 2016 at 10:22:28 PM UTC-4, neilh...@gmail.com wrote:

I'm no expert but I'll try to answer your questions.

DMA generally means malware put in the network card or graphics card to get direct memory access. In other words malware going straight from the piece hardware bypassing the operating system software to use, or retrieve, or manipulate the running memory directly.

Its not a browser exploit unless somehow the browser exploits and infects the graphics card which is highly unlikely in qubes since most of the gpu functions is limited to dom0 and not in the appvm where you would be running your browser.

The main benefit would be to try and prevent dma attacks from the network card and the netvm, which receives all the packets from the internet, and which qubes considers always unsafe. How hard is it? Probably not as hard as infecting the gpu card, and well i'm only a noob but I doubt its very easy. Its probably something that would happen from a more personal or targeted attack, not something random. But then again this is 2016 so who knows lol.

[neilh...@gmail.com]

But it's still not clear how these malicious packets can be sent to the network card.... can these be sent after compromising an App VM (via something like a browser exploit)...??

Or can they be sent just purely over the internet itself to any device connected to the web...? Directly send packets just over the web?

Or does it require attacking the Net VM, and not just the App VM... however that would be done...?

I'm just trying to figure out FROM WHERE the network card could be attacked.

[raah...@gmail.com]

all network packets go to your network card. I'm not sure what you mean? It can be attacked from anywhere in the world wide web.

[neilh...@gmail.com]

Oh OK. I see you have now updated with a new answer.

[raah...@gmail.com]

I guess you are asking me specifically how? I dunno man i'm a noob. I guess there is many ways, for example reverse shell from buggy dhclient or icmp packet. or who the heck knows. Probably too many possibilities to list. Joannas blog mentioned poc from buffer overflow.

Anothing thing to consider is you have to trust the intel firmware sometimes.

[raah...@gmail.com]

I guess I would also assume wireless network card to be more vulnerable, but maybe someone more expert can reply.

[neilh...@gmail.com]

So essentially, this is isolating the network card/Wifi from dom0..

Just like you create a USB qube, to isolate USB from dom0

But still.. no one has ever shown a proof of concept for this... You see plenty of videos of people exploiting browsers with Metasploit... but no videos of anyone doing DMA attacks

Still, I take Joanna's word for it that it's a real thing.

[raah...@gmail.com]

On Friday, July 15, 2016 at 12:00:57 AM UTC-4, neilh...@gmail.com wrote:
> Oh OK. I see you have now updated with a new answer.
>
> "The main benefit would be to try and prevent dma attacks from the network card and the netvm, which receives all the packets from the internet"

maybe just a MITM, maybe your infected router infecting your netcard. I mean I really don't know there is many possibilities on where the malicious packet is coming from.

I don't really think attack would be coming from an infected appvm, which should be noted is also not easy to make persistent. But it is possible for an infected appvm to then infect netvm and then change your netcard firmware I guess. again not as easy as just that magic packet coming from god knows where to your very vulnerable network card.

You know what, get the iommu machine, its also not 100% (nothing is) but it would make it alot harder.

[raah...@gmail.com]

there is many poc's, do some google searching. How likely to happen to yourself? I woudln't know. Most likely a very persistent person personally targeting you, but in 2016 I consider us all targets, and no I don't mean by the government... I'm super paranoid though thats why I'm using qubes lol.

But yes you are correct just like when creating a usb qube.

I think qubes is also working on being able to have like an onboard gpu isolated only to dom0, and other gpu for domu appvms. But most people just want that for gpu passthrough which doesn't nescessarily = security for me but I'm very nooby user.

[raah...@gmail.com]

I can't find any poc for sound card. I imagine it would be possible though, maybe it depends on the card like probably a plugged in one. But i'm talking out my ass and have no idea what I'm talking about. Maybe in future qubes will be isolating the sound controller as well lol.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

DMA is mechanism for PCI devices to access system memory (read/write).
Without VT-d any PCI device can access all the memory, regardless to
which VM is assigned (or left in dom0). Most PCI devices allow driver to
request arbitrary DMA operation (like "put received network packets at
this address in memory", or "get this memory area and sent to the
network"). So, without VT-d, it gives unlimited access to the whole
system. Now, it is only a matter of knowing where to read/write to take
over the system, instead of just crashing. But since you can read the
whole memory, it isn't that hard.

Now, how it applies to Qubes OS? The above attack requires access to PCI
device. Which means that can be performed only from NetVM / UsbVM, so
someone must first break into one of those VMs. But it isn't that hard,
because there is a lot of complex code handling network traffic. Recent
bugs includes DHCP client, DNS client etc. Most of attacks on NetVM /
UsbVM (but not all!) requires being somehow close to the target system -
for example connected to the same WiFi network, or in case of UsbVM,
having physical acccess to some USB port.

But, just exploiting a browser in an AppVM isn't enough, as normal AppVM
do not have any PCI device assigned (unless you do that manually).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXiKLfAAoJENuP0xzK19cs21wH/A1AOVEKZLAr/p1/rY3gOCzJ
r8qVwL8bl9sEq/WmkDAbml/wxyLBCd46bqvUD645V0FtqHIkluikIGaPUH+tNwxu
PnE/3xw5tAqIvl73GJ8Eon0V12Bt9e0CJa2GhbQ67ahdj12CR3Gg4IrbSoswNYpT
qK4WiIBA6UhuERx02dVvA1Hd1kEcOHvTmYTn0W1gDmiFughXM8okf44bU3PHatU/
PFGqEMc/HkWgAPb+0VAUtRoem0NdJVKUa3XGgV5KrkbxeAhSj7VMy+lD/MxSdEQE
Mep+XT6I16ItBVBEq1eOEMAJxJe0YnR5/TLfKHt7rBAZmziArAUb9LKw00pV1Pc=
=aQzl
-----END PGP SIGNATURE-----

[Alexis Wattel]

.

[7v5w7go9ub0o]

Thank you for this overview!

I'm still on R2.1, as VT-d on 3.x seems to fail on my Lenovo box. (BTW,
Lenovo has indicated that BIOS updates are forthcoming).

I'm presuming that VT-d is important enough (I occasionally use open
hotspots) that I'm best off keeping it and 2.1, foregoing any Qubes/XEN
updates to 3.x (I'm keeping application software up to date outside of YUM).

So the question becomes, is my reasoning valid?

Are there any 2.1 issues that indicate I should upgrade to 3.x without VT-d?

Thanks in Advance

[neilh...@gmail.com]

Wow.. Thanks Marek... That was a very clear explanation of DMA attacks... The best that I've ever seen.

Perhaps this should even be posted somewhere on the QUBES website.

I think that's convinced me that I definitely need to get VT-D.

[raah...@gmail.com]

lol https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=what+is+a+dma+attack

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Clear and lucid answer, as always. Thanks, Marek! Added to the FAQ:

https://github.com/QubesOS/qubes-doc/commit/45cffd68543447c81d9922572d52e408b7ff
5e65

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXiS7OAAoJENtN07w5UDAwBTIQAK3BACGM/8ishjh08vqn6kwC
IRV4/kTuLwqQAcsVDVdtTSf8TXPLjtoU6IDPfJOstDDoF3PkKZwvlV6YbFKx5e6e
Ixb9ka928uVk0qHQbJvu8bIZJgBO4p/abM2cGCv9rX1ii/3rV0DiKfAs4MA+oNKK
i3QumQMQs3wqU4uIIfk2DkEqpaPmPV+IkY2eD5JdxZowWKf8OoXmwhn1EowRXL62
XL78iT8OgmKM+Errc1bQqBl9OJ7b0l7pAiAZL3jIWpLMOU2qIcr5lCoqG9CwD9z+
YPd8s44ybJvoKpt+y0N/VajPFm/sFZPAIoz17pLJ6+oVJVVyiEuvu5qZNRK+OI7Z
iXrHbv0paPSKvbmSkHQ2PJ+/vQKNw3/l474nj2Op6VhNfT+mO93glmP51au2yGMv
5vVJ/zKIn/+4Vl4OWaeMrkVfkpG4bzqYJyrwVusl392ZjeA9j5yairLSvqcKPVyU
FO+RyG9v94U0o1ib479Buk7ga9VPst+J14BQeFCWRdnZID5SrmcH3oBPmaekTfas
856IFKAuGgosGuzwJcn1s2oJLkD2OFA1R3C6VwcQVYB6K+BpvAaYSrjhxRWeeeZH
bI0nzOZL/6RKf++uYAkolHWC5r1862NBQEB3bOtYR1zHssL2DiDijmLDa0KE7brX
oxk7rg2YM7ejVQEIOi4q
=zG0v
-----END PGP SIGNATURE-----

[Chris Laprise]

IIRC, this point may be covered by Joanna's blog post re: 'What makes
Qubes different from ...?'

The main website does sort of lack a concise rundown of Qubes' main
advantages, such as:

* Simple and strong isolation mechanism, instead of complex permissions
in monolithic kernels
* Safe virtualization of software components that normally expose
regular hypervisors to exploits (i.e. graphics, copy+paste)
* Window manager that reliably reflects the security context of running apps
* Hardware virtualization of risky interfaces such as NICs and USB
* Overall philosophy of 'protect the core system and non-networked VMs';
remotely exploited VMs stay contained ('game over' situation unlikely)

Plus secondary advantages:
* Template system
* Disposable VMs
* AEM
* Trusted document 'sanitizing'
* Flexible use of anon networks (Tor, etc.)

Chris

[raah...@gmail.com]

I think the op's real question was how would one go about compromising the network card in the first place to attempt a dma attack. IMO, that is too general question and he would have to google the many different methods. Noone is going to give him step by step instructions with there preferred method against qubes users. I gave example of reverse shell from exploiting fedora's dhclient, which was biggest issue of shell shock. Using ICMP packet to reverse shell, Marek gave example of packet to exploit DNS client. Only to name a few. The link in Joannas blog gave example of many diff methods of using dma attack after taking over the netcard with malicious packet. So many methods to take over the netcard and many methods on how to attempt dma attack afterwards to take over the whole system. Too many to list.

To even say that he has to take Joannas word for it that dma attacks actually exist, and that he has never seen any poc's of these things actually being done I find suspicious. Because its a matter of a simple google search.

[raah...@gmail.com]

And sure most common methods are from lan, but imo we should assume all our routers are compromised anyways, and all our iot devices and phones. And Marek said it doesn't always have to be local attack!!! We should stress that point.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-07-15 16:22, Chris Laprise wrote:
> IIRC, this point may be covered by Joanna's blog post re: 'What makes Qubes
> different from ...?'
>
> The main website does sort of lack a concise rundown of Qubes' main
> advantages, such as:
>
> * Simple and strong isolation mechanism, instead of complex permissions in
> monolithic kernels * Safe virtualization of software components that
> normally expose regular hypervisors to exploits (i.e. graphics, copy+paste)
> * Window manager that reliably reflects the security context of running
> apps * Hardware virtualization of risky interfaces such as NICs and USB *
> Overall philosophy of 'protect the core system and non-networked VMs';
> remotely exploited VMs stay contained ('game over' situation unlikely)
>
> Plus secondary advantages: * Template system * Disposable VMs * AEM *
> Trusted document 'sanitizing' * Flexible use of anon networks (Tor, etc.)
>
> Chris
>

Thanks for the feedback. Many of these things were already mentioned on the
Tour page, but many other important features were not, so I've revised that
page accordingly:

https://github.com/QubesOS/qubesos.github.io/commit/c696eaff4edd9d72a30bb5107
49e9bed2f849a54

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXor5JAAoJENtN07w5UDAwWxkP/jZNi02vVHSiSQNaqR8M89fT
O6hr68OQI+ylto9rVkjZAsbqGpaIko4jMs8fzYng4kfzjm23UW8baZH8ryxBsbcF
B9JB3k+glovBKZs1/U7tn/b59K88y7yteyGE5jwHiYFU2fbUNK7Q/z5uKGIZRu0p
mdnTGyycIps8X4EPAiEY9itRRcy4kdQX3F2zHAxFBNqneWtDxHxXYzQjEQzxvYpy
dyMWNfhq3zCL3oQy0204CwuE91QT/GJj903tdjKlQtSkiEHSUb5QUhTZMLgVfdiZ
uwxj/Dg1d4+ocYr6IaRkVTznpSTX9IXci+Y0DnHEYyFpHI5axauO2GQTwOKLkd+G
bcIzBD5k3KXBND8TM5VT6diidtnIYtqnDoXqmC/YuT0O/8qX2ewPRhfQsmG/jQrI
oOGEMJbEfw1UC52vInpB/Vce3kwEGK689nsSdkp17NsimKbcUTBxbCQbiBwq1Sag
30joPQ9vhzCtPwqxn33aw1aqmJ+wwIXw/CYw2Ff4hIigYbnmbyxLw5MKy06w6BnL
Lk4fq+7+1GU72MQ02G3mObblrjR9+KHu1cD8ToxwhEtkQra0vM+RpTh3tqO02fIw
9/SJh0V/lKfuQLci+GHCCEKTXtuHS/QhyyVqcfcdGSNkotvGzccrxYP2O6RhV/en
LeNVhxlX4OlE2eo1sg+9
=Z7vh
-----END PGP SIGNATURE-----