Intel ME exploitable

[Jean-Philippe Ouellet]

*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!

[Reg Tiangha]

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?

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

[Reg Tiangha]

Ugh, forgot to hit CTRL-SHIFT-V, ha!

https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project

[Vít Šesták]

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'

[cooloutac]

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.

And so we have to hope we get a bios patch or something? Is someone going to keep tabs on what boards are getting patched so we can go buy them? lol.

Its funny but after the recent dom0 update I told my family we have to buy new pc hardware and they think I'm completely nuts. And ironically, or maybe not, my bank card was just hacked over the weekend. I'm praying it was got from the only online vendor I ever used it once at a month or two ago, or the processing company and not my system. But it sure is a crazy coincidence...

I wonder are boards that check for bios updates themselves even safe, Can someone intercept with malicious update?

[Reg Tiangha]

It's up to you whether or not you trust this archive or not, but there
is an archive of various ME firmware being kept here:

http://www.win-raid.com/t596f39-Intel-Management-Engine-Drivers-Firmware-amp-System-Tools.html

and a more comprehensive archive here:

http://www.win-raid.com/t832f39-Intel-Engine-Firmware-Repositories.html

You might be able to update your Intel ME firmware using one of the
files found there. But you'd probably want to wait until a firmware with
at least an April 2017 release date or newer is available; not all of
them have one yet (certainly not for any of the machines that I run).

[Reg Tiangha]

Also, rather than doing a dump of your ME firmware and then running
Intel ME Cleaner on it, I think you can download one of the full
firmware images from the second link that's applicable for your machine,
run Intel ME Cleaner on it, and then flash that using an external
programmer. That said, I don't have the external hardware to do it, so I
haven't done it myself, nor do I know if that would actually work. All
Intel ME Cleaner tutorials that I've seen do it by dumping the ME
firmware from the chip first.

[Chris Laprise]

On 05/01/2017 12:38 PM, Jean-Philippe Ouellet wrote:
>
> I want my RISC-V laptop already!

I would agree, but these things are still quite slow... correct? I think
they are lacking in out-of-order execution and SIMD, for example.

A good benchmark for performance might be something like the last of the
PowerPC CPUs (G5) which is a different RISC-type architecture.

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Lolint]

Confirmation by Shintel:
https://downloadmirror.intel.com/26754/eng/INTEL-SA-00075%20Mitigation%20Guide%20-%20Rev%201.1.pdf

[Reg Tiangha]

On 05/01/2017 02:48 PM, 'Lolint' via qubes-users wrote:
> Confirmation by Shintel:

> <https://downloadmirror.intel.com/26754/eng/INTEL-SA-00075%20Mitigation%20Guide%20-%20Rev%201.1.pdf>https://downloadmirror.intel.com/26754/eng/INTEL-SA-00075%20Mitigation%20Guide%20-%20Rev%201.1.pdf
>
> --
> 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...@googlegroups.com
> <mailto:qubes-users...@googlegroups.com>.
> To post to this group, send email to
> qubes...@googlegroups.com
> <mailto:qubes...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/tSXLoJvyyEDdBtL6zdZ4leYPp6Ar5jEpbkx4pO2jFfQlzozE5zfWdPjQ6-aCESh9zDb0pq_C9lBV5LIf_gwds80eRVcRcs2Jvu_AfNjXnG0%3D%40protonmail.com
> <https://groups.google.com/d/msgid/qubes-users/tSXLoJvyyEDdBtL6zdZ4leYPp6Ar5jEpbkx4pO2jFfQlzozE5zfWdPjQ6-aCESh9zDb0pq_C9lBV5LIf_gwds80eRVcRcs2Jvu_AfNjXnG0%3D%40protonmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.


Well, they say that "this vulnerability does not exist on Intel-based
consumer PCs" and just in their small business versions, but who knows
if that's really the case?

That said, the firmware on most consumer platforms is about 1.5MB while
the small business stuff is 5MB so maybe this particular exploit only
exists somewhere in that extra 3.5MB worth of crap. But again, who knows?

The actual advisory lists which firmware versions are affected. For
those who want to attempt to flash their ME chip to patch against this,
any official "fixed" firmware's last four digits will start with a '3.'

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr

[Ilpo Järvinen]

On Mon, 1 May 2017, 'Lolint' via qubes-users wrote:

> Confirmation by Shintel:
> https://downloadmirror.intel.com/26754/eng/INTEL-SA-00075%20Mitigation%20Gu
> ide%20-%20Rev%201.1.pdf

So it requires either network connection to an ME aware NIC or,
unsuprisingly, access to some local HW interface of ME (that is used by
LMS that is a Windows thing). It's somewhat doubtful that such HW
interface would be available for other than dom0 under Qubes. Thus it
doesn't sound too bad, except for laptops with any kind of wireless
wired to ME (wired NICs need not to be connected - ever, use USB
device for providing ethernet instead if you want to avoid this
kind of issues).


--
i.

[Reg Tiangha]

A bit more analysis:

https://mjg59.dreamwidth.org/48429.html

[Vít Šesták]

Some notes:

* Applying the patch probably requires BIOS update (and MoBo vendor releasing the update), I guess.
* I wonder what is the technical distinction between home and SMB/Enterprise. Is it vPro?
* I am not sure how can I check the version. There are some ME/AMT-related Linux tools, but I have found rather tools for remote management than tools for accessing AMT on local machine.
* 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.
* 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.

Regards,
Vít Šesták 'v6ak'

[Reg Tiangha]

On 05/01/2017 11:25 PM, Vít Šesták wrote:
> Some notes:
>
> * Applying the patch probably requires BIOS update (and MoBo vendor releasing the update), I guess.
> * I wonder what is the technical distinction between home and SMB/Enterprise. Is it vPro?
> * I am not sure how can I check the version. There are some ME/AMT-related Linux tools, but I have found rather tools for remote management than tools for accessing AMT on local machine.
> * 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.

> * 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.
>
> Regards,
> Vít Šesták 'v6ak'
>

Not necessarily. Intel does provide flashing utilities along with the ME
firmware updates, but it's up to your OEM to release them to you. Or for
you to procure them from somewhere else.

As for checking versions, it's all tied to the firmware and not the
utilities. You can probably tell which one you have through your BIOS
menu; it should display it. Some other tips here:

http://www.win-raid.com/t596f39-Intel-Management-Engine-Drivers-Firmware-amp-System-Tools.html#msg10193

[Ilpo Järvinen]

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.

[David Hobach]

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/

[Foppe de Haan]

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?

[cooloutac]

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.

[Reg Tiangha]

Local access issues aside for a moment, it sounds like if you can
externally block the affected network ports, then you can also mitigate
this that way. That could be done on the router level, but may not stop
someone on the same subnet as you from getting at your machine that way
(nor if your router is compromised).

Someone here suggested an Ethernet condom, and I actually think there
might be some merit to it. Maybe this is where those pocket routers
(ideally with upgradable open-source firmware) with both wifi and
ethernet ports can come in. A private, external firewall that connects
to the network, rather than your machine doing so directly, with rules
to block those ME management ports and other high-risk ports just for
your machine. It's sad that we may be at that point, however, where we
need to seriously consider external hardware blockers for all sorts of
ports like USB, HDMI, etc, just to protect our devices.

[cooloutac]

What do you mean by pocket router? Is this like a cheap little router to dongle off your pc? it seems interesting because I definitely can't trust my home router at all...

[Reg Tiangha]

On 05/02/2017 01:36 PM, cooloutac wrote:
> What do you mean by pocket router? Is this like a cheap little router to dongle off your pc? it seems interesting because I definitely can't trust my home router at all...
>

I mean something like this:

https://www.asus.com/ca-en/Networking/WL330gE/

It's the model I have, but it's old and no longer supported by Asus.
There used to be OpenWRT support for it, but no longer because of the
low RAM size. There is a newer model:

https://www.asus.com/ca-en/Networking/WL330NUL/

but I don't know much about it or if it's supported by open-source
firmware. But maybe devices like these could help guard against similar
exploits to the one being discussed in this thread, assuming the router
firmware can be protected too. But then again, who knows what other
holes the ME stuff may have? Something like this could be as futile as
trying to plug one hole of many in a sponge.

[cooloutac]

I used to use opensource on wrt54g back in the day. I used tomato for the qos. I gave it away, and think nowdays, wow do I wish I still had that shit. crazy times we living in. I don't even think we can use opensource on any routers anymore?

[cooloutac]

I would be a beta tester but I don't think anyone writes the code or maintains the projects. They just wanna hack other people.

[cooloutac]

or the hardware companies got better at making it harder, but I really think it just boils down to interest, noones interested anymore.

[cooloutac]

https://www.amazon.com/Cisco-Linksys-WTR54GS-Wireless-Travel-Speedbooster/dp/B000A1AQOO I wonder if they got open source for this one? lol

[cooloutac]

https://www.amazon.com/Cisco-Linksys-WTR54GS-Wireless-Travel-Speedbooster/dp/B000A1AQOO/ref=sr_1_7?ie=UTF8&qid=1493758122&sr=8-7&keywords=pocket+router its 35 dollars but I bet none of them are new and they lying.

[cooloutac]

On Tuesday, May 2, 2017 at 4:46:33 PM UTC-4, cooloutac wrote:
> https://www.amazon.com/Cisco-Linksys-WTR54GS-Wireless-Travel-Speedbooster/dp/B000A1AQOO/ref=sr_1_7?ie=UTF8&qid=1493758122&sr=8-7&keywords=pocket+router its 35 dollars but I bet none of them are new and they lying.

all the complaints are about wireless but first thing I would do is shut the wireless off lol and just use it for my home desktop with ethernet.

[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/

[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/

[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/

[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/

[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/

[Tai...@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.

[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'

[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/

[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'

[cooloutac]

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.