Re: [qubes-users] Re: Intel ME exploitable
On Monday, May 8, 2017 at 1:16:26 AM UTC-4, Vít Šesták wrote: > While I sometimes use the arguments “in such case e, attacker gains nothing, > because it assumes you are already compromised”, one has to be careful with > this, because compromise doesn't imply a total compromise. > > A simple example (unrelated to ME) of this catch: One might think that giving > user full permissions for all the files does not decrease the security if the > user can simply sudo anything. While this is not mostly true when considering > RCE vulnerabilities (or running a trojan), it doesn't apply to > path-traversal-like vulnerability – attacker is not automatically in the > position where she can simply call sudo. > > I don't know ME well, but maybe this catch also applies to ME. Note that > whole ME includes not only some persistently running chip and its firmware, > it also includes some (optional) software for the OS, which is BTW actually > recommended to be removed by the Intel's security advisory. I don't know what > is it exactly capable of, it can probably give the admin access to OS shell, > and maybe something more. (And BTW, you can see it in dom0 by lsmod.) This > just illustrates that ME is actually a complex beast and it's hard to > properly reason about it. > > Regards, > Vít Šesták 'v6ak' as far as I've always understood one of main purposes of amt/vpro/ME, w/e you call it, was so you can recover a crashed os remotely. I doubt removing stuff even from kernel is a total solution. -- 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/7ee5fc02-78aa-4de3-a58b-24cf640dbfe6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Intel ME exploitable
> Get some code running in there, you're root. True, but at this moment, you are supposing attacker has already RCEd it. A logic flaw might allow one to do quite less than RCE. For example, it might mount a block device. In such case, it would be better to be mounted to some dummy VM rather than dom0. But maybe I am getting too theoretical there and it is not going to make a huge difference. Regards, Vít Šesták 'v6ak' -- 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/fa8b7759-2d54-401a-a3a3-107539361d7a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Intel ME exploitable
On 05/08/2017 05:16 AM, Vít Šesták wrote: > While I sometimes use the arguments “in such case e, attacker gains nothing, > because it assumes you are already compromised”, one has to be careful with > this, because compromise doesn't imply a total compromise. True, yet see below. > > A simple example (unrelated to ME) of this catch: One might think that giving > user full permissions for all the files does not decrease the security if the > user can simply sudo anything. While this is not mostly true when considering > RCE vulnerabilities (or running a trojan), it doesn't apply to > path-traversal-like vulnerability – attacker is not automatically in the > position where she can simply call sudo. True, yet nowhere near the gravity of access to ME. ME is running an OS that has effectively the security properties of MS-DOS. Get some code running in there, you're root. Except you're root on the entire machine. Even if you don't get code running there, commandeering it is enough to do remote screen and remote reprovision. > > I don't know ME well, but maybe this catch also applies to ME. Note that > whole ME includes not only some persistently running chip and its firmware, > it also includes some (optional) software for the OS, which is BTW actually > recommended to be removed by the Intel's security advisory. I don't know what > is it exactly capable of, it can probably give the admin access to OS shell, > and maybe something more. (And BTW, you can see it in dom0 by lsmod.) This > just illustrates that ME is actually a complex beast and it's hard to > properly reason about it. > The removal of the software just makes it harder for attackers (now they have to have system privileges to talk to the I/O ports or PCI, so exploit chaining would be needed). It is sound security advice to reduce the attack surface in this way, as it isn't a given that exploiting Microsoft Internet Exploder (or whatever they're calling it these days) will yield system access. -- Rudd-O http://rudd-o.com/ -- 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/59740614-3744-1ef3-bc1f-ee89f5d45c16%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Intel ME exploitable
While I sometimes use the arguments “in such case e, attacker gains nothing, because it assumes you are already compromised”, one has to be careful with this, because compromise doesn't imply a total compromise. A simple example (unrelated to ME) of this catch: One might think that giving user full permissions for all the files does not decrease the security if the user can simply sudo anything. While this is not mostly true when considering RCE vulnerabilities (or running a trojan), it doesn't apply to path-traversal-like vulnerability – attacker is not automatically in the position where she can simply call sudo. I don't know ME well, but maybe this catch also applies to ME. Note that whole ME includes not only some persistently running chip and its firmware, it also includes some (optional) software for the OS, which is BTW actually recommended to be removed by the Intel's security advisory. I don't know what is it exactly capable of, it can probably give the admin access to OS shell, and maybe something more. (And BTW, you can see it in dom0 by lsmod.) This just illustrates that ME is actually a complex beast and it's hard to properly reason about it. Regards, Vít Šesták 'v6ak' -- 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/781d1b38-ec21-40c8-9779-e09f83059462%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Intel ME exploitable
On 05/07/2017 03:21 PM, Manuel Amador (Rudd-O) wrote: Local exploit can talk to the ME via PCI and SMBus. Only from dom0. Remote exploit only good against machines with vPro (check your CPU SKU at the Intel database — I explicitly bought systems without that shit) because vPro is the prerequisite technology for AMT. If your machine does not have AMT / vPro, it cannot be exploited remotely because it is not listening over network cards. That isn't entirely true. The difference between vpro or not vpro is just a different ME image, thats it. the nics still have the ability to listen they just aren't openly doing 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/4b9f0b56-4278-b5e3-9b27-46d0ff3a3a7c%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Intel ME exploitable
On 05/02/2017 05:25 AM, Vít Šesták wrote: > * There seems to be some MEI PCI device (see lspci | grep -i mei) in dom0 and > /dev/mei0. I am not sure how all the parts (network stack, MEI PCI device, > MEI software for OS and management while offline) are connected together. I > am also unsure if having it in dom0 is good (i.e., it prevents passing > malicious inputs to it) or bad (i.e., it adds attack surface). The safest > approach seems to be attaching it to /dev/null with IOMMU (VT-d) isolation. > Just crerating an autostarted (and maybe also autoshutdown) > network-disconnected dummy VM with all ME-related PCI devices should do the > trick. The VM would be trusted not to pass any malicious input to MEI, but it > would not be trusted for anything else (so that it could absorb attack from > MEI). I am unsure if this adds some actual protection or if it is totally > hopeless. I remember a few days ago reading that you can talk to ME via SMBus, and that is in fact the way ME talks to other components when the system is off and therefore can't talk over PCI. PCI is obviously another way to talk to ME. Keeping them in dom0 won't hurt anything. The fact that ME cannot be exploited locally from a VM (assuming the Qubes OS security model holds) is enough to protect you from local exploits. In case of successful exploitation. the ME has full access to RAM in any case, so moving them to another VM won't give you any extra security. -- Rudd-O http://rudd-o.com/ -- 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/21446e90-3336-4d91-2249-9c60123a2b04%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Intel ME exploitable
On 05/02/2017 05:25 AM, Vít Šesták wrote: > Some notes: > > > * I wonder what is the technical distinction between home and SMB/Enterprise. > Is it vPro? I deduced this in the affirmative a few years ago by comparing the SKUs for various Intel products, and whether they had vPro. -- Rudd-O http://rudd-o.com/ -- 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/163291d6-af6e-50b4-6781-95c6c1e331b2%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Intel ME exploitable
On 05/01/2017 06:04 PM, cooloutac wrote: > On Monday, May 1, 2017 at 1:26:52 PM UTC-4, Vít Šesták wrote: >> AFAIU, if https://ark.intel.com/ shows “Intel® vPro™ Technology: no”, then >> the particular CPU is safe. But I am not 100% confident in vPro and related >> technologies, so I might be wrong. Can someone confirm/deny this claim? >> >> Regards, >> Vít Šesták 'v6ak' > I think its more about the management engine on the intel chipsets. They say > every board after 2008 is affected, even if you don't have amt it can be > exploited locally? does that mean from the host os or with physical access to > the board?Sounds scary regardless. Nono. The ME is available in all chipsets. But the antifeature exploited by the bug (remote and local commandeering of the machine via Ethernet, SMBus and PCI) is only present in systems with vPro / AMT, which is a *superset* of the ME. -- Rudd-O http://rudd-o.com/ -- 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/e7df8c24-f713-b78f-3179-3c5991eab3a8%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Intel ME exploitable
On 05/01/2017 05:26 PM, Vít Šesták wrote: > AFAIU, if https://ark.intel.com/ shows “Intel® vPro™ Technology: no”, then > the particular CPU is safe. But I am not 100% confident in vPro and related > technologies, so I might be wrong. Can someone confirm/deny this claim? That has been my experience as well. The typical test is to see if DHCP requests come out of your machine's network port after it has been "powered off" (it is well known that the CPU running the ME is separate and doesn't power off). -- Rudd-O http://rudd-o.com/ -- 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/2d52e0e2-2c62-c029-d56f-b30ba0bb9612%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Intel ME exploitable
On 05/01/2017 05:14 PM, Reg Tiangha wrote: > On 05/01/2017 10:38 AM, Jean-Philippe Ouellet wrote: >> *Sigh*... Yep. We were right to be concerned (of course). And now we >> have something other than our tin foil hats to point at too: >> >> https://semiaccurate.com/2017/05/01/remote-security-exploit-2008-intel-platforms/ >> >> I want my RISC-V laptop already! >> > I don't know if it helps things, but I recently disabled the > CONFIG_INTEL_MEI, CONFIG_INTEL_MEI_ME, and CONFIG_INTEL_MEI_TXE kernel > options in my kernel branches as soon as I was made aware of their > existence. My hope is that the ME hardware can't be exploited using > those methods if they don't exist in the kernel in the first place; that > someone would have to find another way. But again, I have no idea if > that's useful or not. For what it's worth, my systems still boot and run > properly, but the newest machine I have access to is of the Sandy Bridge > era; I have no idea if newer machines actually need those options baked > into the kernel in order to run. Can anyone advise? Local exploit can talk to the ME via PCI and SMBus. Only from dom0. Remote exploit only good against machines with vPro (check your CPU SKU at the Intel database — I explicitly bought systems without that shit) because vPro is the prerequisite technology for AMT. If your machine does not have AMT / vPro, it cannot be exploited remotely because it is not listening over network cards. A quick test: connect your machine physically to a router, start tcpdumping on the router, then power it off. Do you see DHCP requests being emitted on the port of the router where your machine is connected? If so, then you're screwed. > > https://github.com/rtiangha/qubes-linux-kernel > > Also, if anyone has any other ideas on kernel options to disable for > various security concerns (ME related or not), let me know. For the > moment, I've implemented almost all of the KSPP's recommended settings > that are applicable to a certain kernel branch, except for the ones > about loadable modules since I don't know how it affect u2mfn or any > other user-compiled kernel modules a Qubes user may want to install. I > haven't encountered any issues on my machines (or at least, any that > I've noticed), but those could use more testing as well: > > https://github.com/rtiangha/qubes-linux-kernel > KSPP is good, but it will not protect you from the attack, because the attack runs *on a different CPU within your machine, which is always on, even when the machine is off*. Yes, it's THAT bad. -- Rudd-O http://rudd-o.com/ -- 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/0361826c-468c-74a5-bd75-0701cd022ab1%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Intel ME exploitable
On Tuesday, May 2, 2017 at 2:15:42 PM UTC-4, Foppe de Haan wrote: > Maybe, but if that applies, what is there to do except to work around it (by > not using that NIC), and/or to hope that AMD will indeed release the code for > Ryzen's PSP? Ya we at mercy of vendors. not update for my board yet. -- 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/a7ac5b42-af4f-464d-8b3a-fd984b72%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Intel ME exploitable
Maybe, but if that applies, what is there to do except to work around it (by not using that NIC), and/or to hope that AMD will indeed release the code for Ryzen's PSP? -- 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/e5138301-a954-4e0e-ade7-2764f7795624%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Intel ME exploitable
On 05/02/2017 07:25 AM, Vít Šesták wrote: * I wonder what does “exploitable locally” mean. If physical access is required, I am not sure what would attacker gain (AEM bypass at most, I guess). If it allows unprivileged user to elevate privileges, this might be interesting for Qubes, depending on the attack vector: If it requires attack over network interface, then sys-net can perform it. @remotely: sys-net probably does not protect you here as Intel AMT (ME) runs even on top of the OS (Xen/Qubes). So it just captures all Intel management traffic directly in cooperation with your Intel chipset ethernet card and forwards it to the ME chipset - it never goes the regular way [3]; admittedly, it depends on Intel's implementation of VT-d. I guess they ignored Vt-d for ME though... ah yes, they likely did: "ME’s desire for accessing the host memory cannot be constrained in any way, on the other hand, not even by VT-d." [1] @locally: Not sure whether sys-net helps with AMT enabled. After all an attacker might be able to route packets to your sys-net VM (--> =remotely)? The local forwarding service from [2] is probably not enabled in your sys-net though, so that's a plus. Maybe we'll see a QSB sooner or later... Just my 5 cents. [1] https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf [2] https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075 [3] https://www.theregister.co.uk/2017/05/01/intel_amt_me_vulnerability/ -- 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/29b87e72-d8c4-6ad5-03d8-70eed3b32931%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] Re: Intel ME exploitable
On Mon, 1 May 2017, Vít Šesták wrote: > * I wonder what does “exploitable locally” mean. If physical access is > required, I am not sure what would attacker gain (AEM bypass at most, I > guess). If it allows unprivileged user to elevate privileges, this might > be interesting for Qubes, depending on the attack vector: If it requires > attack over network interface, then sys-net can perform it. If it > involves ME software for the OS (maybe for accessing the MEI PCI > device), we should be adequately isolated on Qubes. I hope that Qubes > adds some protection in any case and it is not exploitable from other > VMs than sys-net. The PDF from Intel linked earlier was pretty clear on this locally exploitable thing (when one connects the dots). It states "Disable LMS services" which according to description listens on some ports and forwards that traffic to ME/AMT (supposedly using the PCI interface). The reason for that is that ME/AMT has a fancy filter in NIC that automatically captures only incoming packets to enable remote administration (without host OS knowing anything about them) BUT a local machine/user cannot send incoming packets as it would require loopbacking eth cable. To make (some?) ME/AMT capabilities available locally, LMS seems to provide a cludge that forwards those local requests to ME/AMT using the local PCI device which allows an attacker to reach the vulnerable ME/AMT. The document also stated that one should prevent re-enabling LMS and that admin has necessary rights to exploit so it doesn't matter whether such user can reinstall LMS or not (LMS is a Windows service anyway but without much doubt, the attack would also work in Linux too if the attacker can access the MEI PCI device). However, it remains unclear how an ME/AMT exploit adds to what admin already can do (probably nothing that significant really). -- i. -- 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/alpine.DEB.2.20.1705021006180.2118%40melkinpaasi.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
