ptsecurity's research

[persmule]

May it be useful to you. Disabling Intel ME 11 via undocumented mode

[archfan]

Can we update me cleaner to enable the HAP bit by default?

[corna]

I've just received an email pointing me to that post, I've just finished reading it. Thanks for the link, very interesting, it also confirms my empirical observations about ME11.

Modifying the "Reserved" field in FIT changes the bit 16 in the PCHSTRP0, as confirmed by the corresponding XML. I'll do some tests on my PC the next days and, if everything works correctly, I'll add it to me_cleaner.

Yes, I'll add it by default when a full image is passed (as this operation is far safer than the rest of _mecleaner, there is no point of making it optional).

[corna]

Here it is, not tested yet (but it's just a flipped bit in the PCHSTRP0, it'll probably work).

If you want to test it note that the HAP bit it in the descriptor region, not in the me region, so you have to provide (and flash back) a full dump, not just the ME image.

[skochinsky]

setting PCHSTRP10[7] to 1 may activate "Alt ME Disable" mode in ME <11.0.

[yoonsikp]

Would it be possible to add a flag to the tool so that the only change is flipping the bit? If I'm running modified firmware I would want as few changes as possible.

[archfan]

Alright. Who wants to go first and test this commit? :P

[corna]

@skochinsky On the "Intel 7 series - SPI programming guide" it is indeed a reserved bit, to be set at 0. How did you find this information?

@yoonsikp Sure, as soon as I check if everything works as expected I'll add also that option

@archfan I'll test it in a few days if you're not in a hurry ;)

[ghost]

I'll try it out :)

edit Nothing seems to have caught fire, system seems to have booted fine. I'm not sure how I should verify that ME isn't running.

edit 2 Output from intelmetool

Bad news, you have a `QM67 Express Chipset Family LPC Controller` so you have ME hardware on board and it is very difficult to remove, continuing...
RCBA at 0xfed1c000
MEI was hidden on PCI, now unlocked
MEI found: [8086:1c3a] 6 Series/C200 Series Chipset Family MEI Controller #1

ME Status   : 0x1e003052
ME Status 2 : 0x16320002

ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : NO
ME: Manufacturing Mode      : YES
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: Current Working State   : Recovery
ME: Current Operation State : M0 with UMA
ME: Current Operation Mode  : Normal
ME: Error Code              : Image Failure
ME: Progress Phase          : BUP Phase
ME: Power Management Event  : Pseudo-global reset
ME: Progress Phase State    : M0 kernel load

PCI READ [bc] : 0x000000bc
ME: Extend SHA-256: 08aded87d51a833126a953a171d1f437a0f252e601f12d90378b95b5cd2c8ba0

ME has a broken implementation on your board with this BIOS
WRITE    [00] : CB: 0x80040007
WRITE    [00] : CB: 0x000002ff
READ     [08] : CB: 0x12cc678c
ME: response is not complete
ME: GET FW VERSION message failed
WRITE    [00] : CB: 0x80080007
WRITE    [00] : CB: 0x00000203
WRITE    [00] : CB: 0x00000000
READ     [08] : CB: 0x12cc678c
ME: response is not complete
ME: GET FWCAPS message failed
Re-hiding MEI device...done, exiting

[skochinsky]

@corna

@skochinsky On the "Intel 7 series - SPI programming guide" it is indeed a reserved bit, to be set at 0. How did you find this information?

It was mentioned in the XML of one version of the Flash Image Tool as "AltMeDisable". Even though it's actually hidden in the UI, the code supports it and the corresponding help text says:

When set true, ME is disabled in BringUp.

Besides, the BUP code indeed checks this bit (in some cases) and sets OperationMode field in FWSTS1 register to ME_OPERATION_MODE_ALT_DISABLED (2).

[corna]

@matts3h This new discover is only for ME >= 11 (Skylake and following), I've not added yet to _mecleaner the suggestion from Skochinsky for ME < 11. Moreover I think intelmetool doesn't support this "AltDisabled" operation mode yet, I'm afraid we'll have to use MEInfo (the Windows tool from Intel) for now.

@skochinsky thanks!

[ghost]

Whoops, sorry. I don't know how I missed that.

[grudnevkv]

Tried new commit on i5 6500 (Q170 chipset) ./me_cleaner.py today.rom

Gave me error

Traceback (most recent call last): File "./me_cleaner.py", line 657, in fdf.seek(fpsba) NameError: name 'fdf' is not defined

Tried with option -d ./me_cleaner.py -d today.rom

Full image detected The ME/TXE region goes from 0x3000 to 0xa00000 Found FPT header at 0x3010 Found 1 partition(s) Found FTPR header: FTPR partition spans from 0x3400 to 0x132400 Found FTPR manifest at 0x3848 ME/TXE firmware version 11.6.27.3264 ...... ...... Setting the HAP bit to disable Intel ME... Removing ME/TXE R/W access to the other flash regions... Checking the FTPR RSA signature... VALID Done! Good luck!

flashed back to chip and it doesn't start. HDMI output is not turned on, CPU fan is working. Need to check if it CPU fan works more, than 30 minutes.

[ghost]

Could someone with an SPI flash programmer or other way to recover test if setting this bit causes Verified Boot (in FVE or FVME mode) to shut down/"brick" the computer (on a PC with it enabled - like the XPS 15 9550 or 9560), like modifying the ME normally would?

[persmule]

I have managed to set HAP on ME8 (within my x230) by the modification below:

@@ -652,7 +652,7 @@ if name == "main": print("Truncating file at {:#x}...".format(end_addr)) f.truncate(end_addr)

• if me_start > 0 and me11: # Intel ME > 11 only, ignored on TXE/SPS
• if me_start > 0:# and me11: # Intel ME > 11 only, ignored on TXE/SPS print("Setting the HAP bit to disable Intel ME...") fdf.seek(fpsba) pchstrp0 = unpack("<I", fdf.read(4))[0]

But I did not see any different yet. x230-log-1.txt

[skochinsky]

@persmule HAP bit only works in ME11, it won't have any effect in ME8.

[skochinsky]

@Hikari-chin

Could someone with an SPI flash programmer or other way to recover test if setting this bit causes Verified Boot (in FVE or FVME mode) to shut down/"brick" the computer (on a PC with it enabled - like the XPS 15 9550 or 9560), like modifying the ME normally would?Could someone with an SPI flash programmer or other way to recover test if setting this bit causes Verified Boot (in FVE or FVME mode) to shut down/"brick" the computer (on a PC with it enabled - like the XPS 15 9550 or 9560), like modifying the ME normally would?

I don't have one, but if BIOS is using ME's self-reported hash as part of the measurement as suspected, the hash won't be set if ME is disabled, likely causing measurement to fail.

[persmule]

@skochinsky What I want to do is actually to "setting PCHSTRP10[7] to 1 may activate "Alt ME Disable" mode in ME <11.0.". How could I hack this script to do this?

[skochinsky]

@persmule something like this might work:

  print("Setting AltMeDisable bit in PCHSTRP10...") 
  fdf.seek(fpsba+0x28) 
  pchstrp10 = unpack("<I", fdf.read(4))[0] 
  pchstrp10 |= (1 << 7) 
  fdf.write_to(fpsba+0x28, pack("<I", pchstrp10)) 

[corna]

Here it is 3d060ebb9b831b65162a1fce2d21e1254ce1bd58 I wrote it yesterday but I forgot to commit and push it

Not tested yet

[h0t]

Hi, I saw that in you commits https://github.com/corna/me_cleaner/commit/173c7433770fe808e18cfac216aae050a29e68fb ignored on TXE/SPS, but we checked it also for SPS and TXE.

[persmule]

@corna @skochinsky Already applied 3d060eb , but still seems to have no different: x230-log-1.txt

[skochinsky]

3d060ebb9b831b65162a1fce2d21e1254ce1bd58 is buggy, it writes back to wrong offset (0 instead of 0x28).

[corna]

Fixed

[platomav]

Works at ME8

[corna]

@platomav Great! Do you also have the output of MEInfo with the "plain" _mecleaner (master branch)?

I've tested the dev branch on my H110: the machine boots fine and the BIOS still takes 3-4 seconds more for the boot and then complains about a corrupted ME FW. Unfortunately both intelmetool and MEInfo fail to retrieve the ME status, so my tests won't be very useful.

If anyone can test it on a ME 11 platform (Skylake and later), please post here the output of MEInfo.

[corna]

@h0t Hi! From the blog post I got that the HAP bit is ignored on TXE and SPS, am I wrong? Moreover _mecleaner can't currently distinguish between ME, TXE or SPS firmware, so the HAP bit is set also on those images.

[platomav]

Great! Do you also have the output of MEInfo with the "plain" me_cleaner (master branch)?

I didn't check today but it should be the same as seen at my previous report.

Unfortunately both intelmetool and MEInfo fail to retrieve the ME status, so my tests won't be very useful.

Make sure you use -verbose parameter at MEInfo. It should at least show the FWSTS. If not, try MEManuf -verbose.

[h0t]

Hi! From the blog post I got that the HAP bit is ignored on TXE and SPS, am I wrong? Moreover me_cleaner can't currently distinguish between ME, TXE or SPS firmware, so the HAP bit is set also on those images.

Hi, thank you for your work! We saw HAP mode also on SPS and TXE firmware.

Unfortunately both intelmetool and MEInfo fail to retrieve the ME status, so my tests won't be very useful.

try "meinfo -FWSTS"

[corna]

@platomav Great, thanks, I'll try it

@h0t Thank you!

It seems you were right @skochinsky, on my Ivy Bridge platform (ME 8.0.3.1427) this is the output of intelmetool after setting PCHSTRP10[7] to 1 (while this was the output with that bit set to 0).

[platomav]

@corna Ok, here is a full ME8 report from today:

ME8 Healthy (no me_cleaner):

ME8 FTPR-only (me_cleaner master 2e8761e):

ME8 FD-only (me_cleaner dev e29a50e):

ME8 FTPR + FD (me_cleaner dev e29a50e):

As expected, Alt ME Disable takes precedence over anything else that me_cleaner can do to the ME at the SPI firmware level.

[archfan]

Amazing progress here. I'd like to thank everyone for their contributions!

Wouldn't it make sense now to secure the firmware against malicious rewrites? Anyone looking into that?

[grudnevkv]

@archfan You can make flash WP (WriteProtected via SPI-flasher)

[h0t]

Skylake (gigabyte brix gb-bsi5ha-6300):

@corna you can also delete module's metadata (we checked it). Thanks!

[grudnevkv]

HAP worked on (e29a50ea137430e6776839e8f1aad83df92f7e84) ME/TXE firmware version 11.6.27.3264, Jetway NF592-Q170 (i5 - 6500 - Skylake, Intel Q170 chipset) In BIOS: ME status says "ME Failed", but I booted some Linux LiveUSB and it worked over 2 hours before I turned it off

With me_cleaner (master branch) ME mode was: "ME temporary disabled" Don't have Windows, so no MEInfo

[corna]

@platomav Thanks for the report, it confirms our expectations.

@archfan Yes, as @grudnevkv said you can write protect the flash with the protection settings in the flash descriptor (you can do it with ifdtool -l, which locks both the ME and the BIOS regions). If in the future you want to update one of those region you'll need an external programmer.

@h0t Thank you for the report. I suspected the modules metadata can be removed (and they're also easy to be removed, just an extra f.fill_range here), but I don't think it has any advantage as they don't contain code and the space they use is not much. I prefer leaving them where they are.

@grudnevkv It's enough, thank you.

[dryoma]

Hey there,

Just to clarify: with this new feature one will be able to turn the IME off as a whole entity, including its code in its blackbox rom won't fire; without the need to strip the firmware, as was being done previousely? Meaning, it will be as if that shit doesn't exist, and a backdor switch will not be able to reanimate it?

you can write protect the flash with the protection settings in the flash descriptor (you can do it with ifdtool -l, which locks both the ME and the BIOS regions). If in the future you want to update one of those region you'll need an external programmer.

Sorry for the offtopic, a noob question: so using an spi flasher a user can effectively prevent their bios from being tampered with? Does this make the bios totally immutable, and immune to all kinds of stuff like such attacks, restoring backups via dual boot? Also, is it reversible (I assume, with the flasher too)?

[grudnevkv]

Just to clarify: with this new feature one will be able to turn the IME off as a whole entity, including its the code in its blackbox rom won't fire; without the need to strip the firmware, as was being done previousely? Meaning, it will be as if this shit doesn't exist, and a backdor switch will not be able to reanimate it?

Nope ME is still there with essential core modules (SYSLIB, KERNEL e.t.c), but with this mode (Alt Disable Mode) it just do something with BootGuard and then idles as far as I understood article.

Sorry for the offtopic, a noob question: so using an spi flasher a user can effectively prevent their bios from being tampered with? Does this make the bios totally immutable, and immune to all kinds of stuff like such attacks, restoring backups via dual boot? Also, is it reversible (I assume, with the flasher too)?

Yes, it can prevent, unless someone has physical access to your motherboard and SPI flash chip on it. Cause to disable WriteProtect you need physical access to SPI chip. Actually WriteProtect can be enabled by software or external SPI programmer, but to enable writing you need external SPI flasher

[skochinsky]

For ME<11, the AltMeDisable bit is checked in the BUP module, so you still need to have the BUP module present, otherwise boot ROM will enter the 30-minute reboot cycle, same as with missing firmware. And boot ROM and BUP still run the very basic initialization, so you can't get rid of them, but in theory it should let us remove everything but BUP (e.g. even KERNEL and maybe ROMP too).

[skochinsky]

@grudnevkv

Don't have Windows, so no MEInfo

You can try the DOS or UEFI version.

[corna]

Nope ME is still there with essential core modules (SYSLIB, KERNEL e.t.c), but with this mode (Alt Disable Mode) it just do something with BootGuard and then idles as far as I understood article.

Correct. The problem is that recent (ME > 6, ~2008) x86 platforms require Intel ME, period. For ME 6-10 it is required as it is the only entity capable to turn off the 30 minutes watchdog, for ME > 11 the integration is tighter and ME also initializes part of the system (I think). Unless the crypto has some flaws and we're able to write our code and reimplement the initialization done by the basic modules, we will never be able to remove completely the Intel ME firmware.

The HAP/AltMeDisable bit is useful because it tells Intel ME to stop gracefully (instead of our previous method, which was to corrupt the non fundamental modules to force ME to hang), which might be better for Boot Guard, but for the current users of _mecleaner nothing should change.

Yes, it can prevent, unless someone has physical access to your motherboard and SPI flash chip on it. Cause to disable WriteProtect you need physical access to SPI chip.

Mainly yes, however there are also some other methods, see this. For example, on my Sapphire Pure Platinum H61 with coreboot the security override pin is enabled, which causes a total unrestricted access to the flash. It is currently unknown to me what drives that pin.

@skochinsky KERNEL is already removed by _mecleaner, I'll check if we can remove also ROMP.

[corna]

You can try the DOS or UEFI version.

Is there a UEFI version?

[skochinsky]

yes, there is MeInfo.efi.

[persmule]

coreboot log on my x230 with Alt ME Disable applied:

x230-log-1.txt

[grudnevkv]

@skochinsky Where to download DOS MEInfo version ?

@corna

Mainly yes, however there are also some other methods, see this. For example, on my Sapphire Pure Platinum H61 with coreboot the security override pin is enabled, which causes a total unrestricted access to the flash. It is currently unknown to me what drives that pin.

Well, yes, I read somewhere WP pin can be connected to chipset, so if you are paranoid about it you need accurately cut trace on PCB to WP pin.

@corna In what me_cleaner version KERNEL module is removed ? I get this output:

rbe (Huffman , 0x007cc0 - 0x00a380): NOT removed, essential kernel (Huffman , 0x00a380 - 0x019fc0): NOT removed, essential syslib (Huffman , 0x019fc0 - 0x02cfc0): NOT removed, essential bup (Huffman , 0x02cfc0 - 0x055c40): NOT removed, essential

[corna]

Where to download DOS MEInfo version ?

MEInfo is not redistributable, don't ask where it can be downloaded

Well, yes, I read somewhere WP pin can be connected to chipset, so if you are paranoid about it you need accurately cut trace to WP pin.

My bad, I misunderstood you. There are two types of flash write protections: 1) Hardware WP pin (active low), which is usually connected to VDD (or, like in the Chromebooks, to GND with a jumper to disable the write protection). This is set by the manufacturer and, unless you want to do hardware modifications on your board, you can't change this. Moreover this protection covers only a small part of the flash chip (usually the bootblock, to have the read-only root of trust of the firmware). 2) Descriptor security settings, which are a set of bitmasks read by the flash controller that allow/disallow the read/write access on the various regions (BIOS, descriptor, ME, GbE, EC, ...) for ME or the system. These are our "security access bits", as once we have set the descriptor and the ME region as read only for everyone, no one can change them without an external programmer (except for the cases I linked before).

We only care about 2), the WP pin is useless for us.

In what me_cleaner version KERNEL module is removed ?

It is removed only for ME < 11, for ME >= 11 those four modules are required and unremovable (as confirmed by the RE of ptsecurity).

[nroach44]

X220:

Full image detected
The ME/TXE region goes from 0x3000 to 0x500000
Found FPT header at 0x3010
Found 1 partition(s)
Found FTPR header: FTPR partition spans from 0x3400 to 0x79400
ME/TXE firmware version 7.1.20.1119
Removing extra partitions...
Removing extra partition entries in FPT...
Removing EFFS presence flag...
Correcting checksum (0xed)...
Reading FTPR modules list...
 UPDATE           (LZMA   , 0x0475c5 - 0x047657): removed
 BUP              (Huffman, fragmented data    ): NOT removed, essential
 KERNEL           (Huffman, fragmented data    ): removed
 POLICY           (Huffman, fragmented data    ): removed
 HOSTCOMM         (LZMA   , 0x047657 - 0x04cc0c): removed
 RSA              (LZMA   , 0x04cc0c - 0x0516bd): removed
 CLS              (LZMA   , 0x0516bd - 0x0560cf): removed
 TDT              (LZMA   , 0x0560cf - 0x05c27a): removed
 FTCS             (Huffman, fragmented data    ): removed
The ME minimum size should be 86016 bytes (0x15000 bytes)
The ME region can be reduced up to:
 00003000:00017fff me
Setting the AltMeDisable bit in PCHSTRP10 to disable Intel ME...
Checking the FTPR RSA signature... VALID
Done! Good luck!

Intel ME early init
Intel ME firmware is ready
CBFS: 'Master Header Locator' located CBFS at [700100:7fffc0)
CBFS: Locating 'mrc.cache'
CBFS: Found @ offset 1fec0 size 10000
find_current_mrc_cache_local: No valid MRC cache found.
  Row    addr bits  : 15
  Column addr bits  : 10
  Number of ranks   : 2
  DIMM Capacity     : 4096 MB
  CAS latencies     : 5 6 7 8 9
  tCKmin            :   1.500 ns
  tAAmin            :  13.125 ns
  tWRmin            :  15.000 ns
  tRCDmin           :  13.125 ns
  tRRDmin           :   6.000 ns
  tRPmin            :  13.125 ns
  tRASmin           :  36.000 ns
  tRCmin            :  49.125 ns
  tRFCmin           : 160.000 ns
  tWTRmin           :   7.500 ns
  tRTPmin           :   7.500 ns
  tFAWmin           :  30.000 ns
  Row    addr bits  : 15
  Column addr bits  : 10
  Number of ranks   : 2
  DIMM Capacity     : 4096 MB
  CAS latencies     : 5 6 7 8 9
  tCKmin            :   1.500 ns
  tAAmin            :  13.125 ns
  tWRmin            :  15.000 ns
  tRCDmin           :  13.125 ns
  tRRDmin           :   6.000 ns
  tRPmin            :  13.125 ns
  tRASmin           :  36.000 ns
  tRCmin            :  49.125 ns
  tRFCmin           : 160.000 ns
  tWTRmin           :   7.500 ns
  tRTPmin           :   7.500 ns
  tFAWmin           :  30.000 ns
ME: Wrong mode : 2
ME: FWS2: 0x120a0000
ME:  Bist in progress: 0x0
ME:  ICC Status      : 0x0
ME:  Invoke MEBx     : 0x0
ME:  CPU replaced    : 0x0
ME:  MBP ready       : 0x0
ME:  MFS failure     : 0x0
ME:  Warm reset req  : 0x0
ME:  CPU repl valid  : 0x0
ME:  (Reserved)      : 0x0
ME:  FW update req   : 0x0
ME:  (Reserved)      : 0x0
ME:  Current state   : 0xa
ME:  Current PM event: 0x2
ME:  Progress code   : 0x1
Waited long enough, or CPU was not replaced, continue...
PASSED! Tell ME that DRAM is ready
ME: FWS2: 0x120a0000
ME:  Bist in progress: 0x0
ME:  ICC Status      : 0x0
ME:  Invoke MEBx     : 0x0
ME:  CPU replaced    : 0x0
ME:  MBP ready       : 0x0
ME:  MFS failure     : 0x0
ME:  Warm reset req  : 0x0
ME:  CPU repl valid  : 0x0
ME:  (Reserved)      : 0x0
ME:  FW update req   : 0x0
ME:  (Reserved)      : 0x0
ME:  Current state   : 0xa
ME:  Current PM event: 0x2
ME:  Progress code   : 0x1
ME: Requested BIOS Action: No DID Ack received

Booted and stayed up.

[skochinsky]

ME: Wrong mode : 2

mode 2 is "Alt Disable". I guess coreboot needs to be updated to handle this situation.

[archfan]

Just tested ced3b46 on my workstation. No problems so far. In fact setting the HAP bit has decreased my boot time. Before I had to power cycle a couple of times before I could see anything on my screen - or sometimes it would take ~ 5 minutes. Those bugs are gone now.

[grudnevkv]

@corna MeInfo MEv11.6 DOS output for (i5-6500 Q170-chipset)

[corna]

Great, it seems that everything is working as expected, I'll merge soon the dev branch into master. Thank you all for the tests.

@skochinsky I'll fix it, however it's just a warning message, nothing more.

@archfan Great! This could mean that some BIOS handle this "Alt Disable Mode" better than the previous disable (and maybe some BIOS that previously didn't work with _mecleaner now work correctly).