subject:"\[qubes\-users\] Re\: Intel ME exploitable"

Re: [qubes-users] Re: Intel ME exploitable

2017-05-08 Thread cooloutac

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

2017-05-08 Thread Vít Šesták

> 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

2017-05-08 Thread Manuel Amador (Rudd-O)

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

2017-05-07 Thread Vít Šesták

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

2017-05-07 Thread taii...@gmx.com


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

2017-05-07 Thread Manuel Amador (Rudd-O)

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

2017-05-07 Thread Manuel Amador (Rudd-O)

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

2017-05-07 Thread Manuel Amador (Rudd-O)

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

2017-05-07 Thread Manuel Amador (Rudd-O)

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

2017-05-07 Thread Manuel Amador (Rudd-O)

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.

33 matches

Mail list logo