For those who are interested in the Intel ME, the slides and white papers from the Black Hat Europe are public.
https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-T... https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-T... https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME-Flash-... https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME-Flash-...
In the conclusion they say "[...]. Such a vulnerability has the potential to jeopardize a number of technologies, including [...] Intel Boot Guard [...].
Maybe it's possible to deactivate Boot Guard permanently or inject custom keys to run own firmware.
On 08.12.2017 15:40, Alberto Bursi wrote:
On 12/08/2017 02:59 PM, Timothy Pearson wrote:
That's just the HAP bit. The ME is limited but NOT disabled, and the remaining stubs are still hackable [1].
Neither the ME or the PSP can ever be removed from their respective systems. They can both be limited to some extent, but to call either of them "disabled" is rather far from the truth.
Hacking them requires being able to write in the SPI flash, or to have buggy UEFI firmware. Which means most systems are still vulnerable.
But it is also true that if someone can hack UEFI he pwns you anyway, even without ME.
So imho ME with the HAP bit can be called "disabled", although the fight isn't over as ME isn't the only thing that was a threat anyway.
There is still need to secure the UEFI firmware (which is needed even if ME didn't exist), and doing a hardware mod to have a hardware switch to turn the SPI chip read-only at the hardware level (also needed regardless of ME).
I think many SPI chips only need some pin pulled high/low to go in read-only mode, and I frankly trust a dumb switch many orders of magnitude more than Boot Guard or anything software-based.
-Alberto
Fascinating!!
----- Mail d'origine ----- De: Thomas Heijligen src@posteo.de À: coreboot@coreboot.org Envoyé: Fri, 08 Dec 2017 16:16:30 +0100 (CET) Objet: Re: [coreboot] Disabling Intel ME 11 via undocumented mode
For those who are interested in the Intel ME, the slides and white papers from the Black Hat Europe are public.
https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-T... https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-T... https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME-Flash-... https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME-Flash-...
In the conclusion they say "[...]. Such a vulnerability has the potential to jeopardize a number of technologies, including [...] Intel Boot Guard [...].
Maybe it's possible to deactivate Boot Guard permanently or inject custom keys to run own firmware.
On 08.12.2017 15:40, Alberto Bursi wrote:
On 12/08/2017 02:59 PM, Timothy Pearson wrote:
That's just the HAP bit. The ME is limited but NOT disabled, and the remaining stubs are still hackable [1].
Neither the ME or the PSP can ever be removed from their respective systems. They can both be limited to some extent, but to call either of them "disabled" is rather far from the truth.
Hacking them requires being able to write in the SPI flash, or to have buggy UEFI firmware. Which means most systems are still vulnerable.
But it is also true that if someone can hack UEFI he pwns you anyway, even without ME.
So imho ME with the HAP bit can be called "disabled", although the fight isn't over as ME isn't the only thing that was a threat anyway.
There is still need to secure the UEFI firmware (which is needed even if ME didn't exist), and doing a hardware mod to have a hardware switch to turn the SPI chip read-only at the hardware level (also needed regardless of ME).
I think many SPI chips only need some pin pulled high/low to go in read-only mode, and I frankly trust a dumb switch many orders of magnitude more than Boot Guard or anything software-based.
-Alberto
On Fri, 8 Dec 2017 21:34:57 +0100 (CET) echelon@free.fr wrote:
For those who are interested in the Intel ME, the slides and white papers from the Black Hat Europe are public.
https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-T... https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-T... https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME-Flash-... https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME-Flash-...
I read the documents above and in:
https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-T...
we have:
The file /home/bup/ct was unsigned, enabling us to slip a modified version into the ME firmware with the help of Flash Image Tool. Now we were able to cause a buffer overflow inside the BUP process with the help of a large BUP initialization file.
[...]
By exploiting the vulnerability that we found in the bup module, we were able to turn on a mechanism, PCH red unlock, that opens full access to all PCH devices for their use via the DFx chain—in other words, using JTAG. One such device is the x86 ME processor itself, and so we obtained access to its internal JTAG interface. With such access, we could debug code executed on ME, read memory of all processes and the kernel, and manage all devices inside the PCH. We found a total of about 50 internal devices to which only ME has full access, while the main processor has access only to a very limited subset of them.
As I understand, this by itself isn't sufficient yet to boot a post-GM45 Intel with free software, however it gives a lot of insight on how things work and enables all researchers to understand better the Management Engine and recent Intel systems to, maybe one day, make free software booting possible on such platforms.
I hope that one day someone would find and publish a way to do that, like for instance by finding a bit in the flash descriptor that would enable "PCH red unlock".
As I understand enabling DCI is already possible trough some flash descriptor bits.
Thanks a lot for all the research that was done!
Denis.
On 12/12/2017 12:11 PM, Denis 'GNUtoo' Carikli wrote:
As I understand, this by itself isn't sufficient yet to boot a post-GM45 Intel with free software, however it gives a lot of insight on how things work and enables all researchers to understand better the Management Engine and recent Intel systems to, maybe one day, make free software booting possible on such platforms.
I hope that one day someone would find and publish a way to do that, like for instance by finding a bit in the flash descriptor that would enable "PCH red unlock".
As I understand enabling DCI is already possible trough some flash descriptor bits.
Thanks a lot for all the research that was done!
Denis.
As I have stated before it simply doesn't matter if some day an ME hack is discovered to be able to have a "libre" intel desktop, because the vendor (intel) is hostile to owner control it will be quickly fixed and thus one should support owner controller hardware such as POWER (where one can even change the microcode) instead of giving them more money to make better anti-features.
At least one shuld buy used hardware and not new hardware if they insist on x86-64.
Thanks.
They didn't seriously include a Java Runtime Environment into the IME?? I can't believe what's going on with this company.
Am Freitag, den 08.12.2017, 16:16 +0100 schrieb Thomas Heijligen:
For those who are interested in the Intel ME, the slides and white papers from the Black Hat Europe are public.
https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-H ack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel- Management-Engine.pdf https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-H ack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel- Management-Engine-wp.pdf https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME -Flash-File-System-Explained.pdf https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME -Flash-File-System-Explained-wp.pdf
In the conclusion they say "[...]. Such a vulnerability has the potential to jeopardize a number of technologies, including [...] Intel Boot Guard [...].
Maybe it's possible to deactivate Boot Guard permanently or inject custom keys to run own firmware.
On 08.12.2017 15:40, Alberto Bursi wrote:
On 12/08/2017 02:59 PM, Timothy Pearson wrote:
That's just the HAP bit. The ME is limited but NOT disabled, and the remaining stubs are still hackable [1].
Neither the ME or the PSP can ever be removed from their respective systems. They can both be limited to some extent, but to call either of them "disabled" is rather far from the truth.
Hacking them requires being able to write in the SPI flash, or to have buggy UEFI firmware. Which means most systems are still vulnerable.
But it is also true that if someone can hack UEFI he pwns you anyway, even without ME.
So imho ME with the HAP bit can be called "disabled", although the fight isn't over as ME isn't the only thing that was a threat anyway.
There is still need to secure the UEFI firmware (which is needed even if ME didn't exist), and doing a hardware mod to have a hardware switch to turn the SPI chip read-only at the hardware level (also needed regardless of ME).
I think many SPI chips only need some pin pulled high/low to go in read-only mode, and I frankly trust a dumb switch many orders of magnitude more than Boot Guard or anything software-based.
-Alberto
Hello! (I'm working from the office today on a library computer...) My regular laptop might be wearing one of those dratted things. But before we start confusing people further, perhaps one of the group needs to reiterate exactly what that contraption is, and why it was necessary. Oh and what the cleaner is supposed to do, and why machines who were cleaned of it, may not work correctly, or even may.
I've got an interesting idea that I do know what it does, and why, but there must be a few people there who're confused about what the IME is and isn't. ----- Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again."
On Fri, Dec 15, 2017 at 10:00 AM, Philipp Stanner stanner@posteo.de wrote:
Thanks.
They didn't seriously include a Java Runtime Environment into the IME?? I can't believe what's going on with this company.
Am Freitag, den 08.12.2017, 16:16 +0100 schrieb Thomas Heijligen:
For those who are interested in the Intel ME, the slides and white papers from the Black Hat Europe are public.
https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-H ack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel- Management-Engine.pdf https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-H ack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel- Management-Engine-wp.pdf https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME -Flash-File-System-Explained.pdf https://www.blackhat.com/docs/eu-17/materials/eu-17-Sklyarov-Intel-ME -Flash-File-System-Explained-wp.pdf
In the conclusion they say "[...]. Such a vulnerability has the potential to jeopardize a number of technologies, including [...] Intel Boot Guard [...].
Maybe it's possible to deactivate Boot Guard permanently or inject custom keys to run own firmware.
On 08.12.2017 15:40, Alberto Bursi wrote:
On 12/08/2017 02:59 PM, Timothy Pearson wrote:
That's just the HAP bit. The ME is limited but NOT disabled, and the remaining stubs are still hackable [1].
Neither the ME or the PSP can ever be removed from their respective systems. They can both be limited to some extent, but to call either of them "disabled" is rather far from the truth.
Hacking them requires being able to write in the SPI flash, or to have buggy UEFI firmware. Which means most systems are still vulnerable.
But it is also true that if someone can hack UEFI he pwns you anyway, even without ME.
So imho ME with the HAP bit can be called "disabled", although the fight isn't over as ME isn't the only thing that was a threat anyway.
There is still need to secure the UEFI firmware (which is needed even if ME didn't exist), and doing a hardware mod to have a hardware switch to turn the SPI chip read-only at the hardware level (also needed regardless of ME).
I think many SPI chips only need some pin pulled high/low to go in read-only mode, and I frankly trust a dumb switch many orders of magnitude more than Boot Guard or anything software-based.
-Alberto
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
-
Denis 'GNUtoo' Carikli -
echelon＠free.fr -
Gregg Levine -
Philipp Stanner -
Taiidan＠gmx.com -
Thomas Heijligen