Betteridge’s Law of Headlines states, “Any headline that ends in a question mark can be answered by the word no.” This law remains unassailable. However, recent claims have called into question a black box hidden deep inside every Intel chipset produced in the last decade.
Yesterday, on the Semiaccurate blog, [Charlie Demerjian] announced a remote exploit for the Intel Management Engine (ME). This exploit covers every Intel platform with Active Management Technology (AMT) shipped since 2008. This is a small percentage of all systems running Intel chipsets, and even then the remote exploit will only work if AMT is enabled. [Demerjian] also announced the existence of a local exploit.
Intel’s ME and AMT Explained
Beginning in 2005, Intel began including Active Management Technology in Ethernet controllers. This system is effectively a firewall and a tool used for provisioning laptops and desktops in a corporate environment. In 2008, a new coprocessor — the Management Engine — was added. This management engine is a processor connected to every peripheral in a system. The ME has complete access to all of a computer’s memory, network connections, and every peripheral connected to a computer. The ME runs when the computer is hibernating and can intercept TCP/IP traffic. Management Engine can be used to boot a computer over a network, install a new OS, and can disable a PC if it fails to check into a server at some predetermined interval. From a security standpoint, if you own the Management Engine, you own the computer and all data contained within.
The Management Engine and Active Management Technolgy has become a focus of security researchers. The researcher who finds an exploit allowing an attacker access to the ME will become the greatest researcher of the decade. When this exploit is discovered, a billion dollars in Intel stock will evaporate. Fortunately, or unfortunately, depending on how you look at it, the Managment Engine is a closely guarded secret, it’s based on a strange architecture, and the on-chip ROM for the ME is a black box. Nothing short of corporate espionage or looking at the pattern of bits in the silicon will tell you anything. Intel’s Management Engine and Active Management Technolgy is secure through obscurity, yes, but so far it’s been secure for a decade while being a target for the best researchers on the planet.
Semiaccurate’s Claim
In yesterday’s blog post, [Demerjian] reported the existence of two exploits. The first is a remotely exploitable security hole in the ME firmware. This exploit affects every Intel chipset made in the last ten years with Active Management Technology on board and enabled. It is important to note this remote exploit only affects a small percentage of total systems.
The second exploit reported by the Semiaccurate blog is a local exploit that does not require AMT to be active but does require Intel’s Local Manageability Service (LMS) to be running. This is simply another way that physical access equals root access. From the few details [Demerjian] shared, the local exploit affects a decade’s worth of Intel chipsets, but not remotely. This is simply another evil maid scenario.
Should You Worry?
The biggest network security threat today is a remote code execution exploit for Intel’s Management Engine. Every computer with an Intel chipset produced in the last decade would be vulnerable to this exploit, and RCE would give an attacker full control over every aspect of a system. If you want a metaphor, we are dinosaurs and an Intel ME exploit is an asteroid hurtling towards the Yucatán peninsula.
However, [Demerjian] gives no details of the exploit (rightly so), and Intel has released an advisory stating, “This vulnerability does not exist on Intel-based consumer PCs.” According to Intel, this exploit will only affect Intel systems that ship with AMT, and have AMT enabled. The local exploit only works if a system is running Intel’s LMS.
This exploit — no matter what it may be, as there is no proof of concept yet — only works if you’re using Intel’s Management Engine and Active Management Technology as intended. That is, if an IT guru can reinstall Windows on your laptop remotely, this exploit applies to you. If you’ve never heard of this capability, you’re probably fine.
Still, with an exploit of such magnitude, it’s wise to check for patches for your system. If your system does not have Active Management Technology, you’re fine. If your system does have AMT, but you’ve never turned it on, you’re fine. If you’re not running LMT, you’re fine. Intel’s ME can be neutralized if you’re using a sufficiently old chipset. This isn’t the end of the world, but it does give security experts panning Intel’s technology for the last few years the opportunity to say, ‘told ‘ya so’.
Yes.
Why would a sane person trust a patch from a company that hid this for 8 years? Coreboot/libreboot start to look attractive here, and open archetectures even more so.
Since when does “In the published official documentation since 2006” equal hidden for 8 years?
It can’t be too hidden if I’ve been using it since 2006 for remote management, and our company isn’t even 200 people.
I think we are talking about two different things. I meant the bug the article refers to, and that the patch from intel addresses.
It was likely your mentioning of coreboot/libreboot that had me thinking otherwise.
In that case however, the answer to your question is: because Intel only knew about the exploit a couple days ago, which is not too long after it was discovered.
One person 8 years ago saying “ME/AMT is a bad idea” is not reporting an exploit.
It took Mr Demerjian finding an actual exploit in order to report an exploit.
Just wait until some kid finds a flaw in secure boot’s huge complex mess of surface.
@Joe I expect something like to to happen or a massive data leak to be attributed to ME/AMT.
I feel ME is about as trust worthy as Marcus Junius Brutus and we all know hwta he did.
https://rol.im/securegoldenkeyboot/
Even if you use Coreboot / Libreboot, you still need ME firmware from Intel on chipsets with an ME engine.
Putting it in common HaD terms, your Skylake processor is the ARM cores in a Raspberry Pi, and the ME engine in the chipset is the VC. Once the VC has started the CPU, then it’s not necessary, but until then it’s in control of everything.
????
So why is the entire ME firmware physically desoldered from my mainboard in my Lattitude E6400 (Albeit an old GM45 chipset with the IME pins on the ICH configured to disabled)
and why do even gen 5 Dells (U-series Core-i Dell laptops, high BGA failure BTW) still have two ROMs on some of their business class with one of the ROMs labeled “IME_ROM”?
I heard (aka hearsay) that disabling/enabling IME firmware requirement in modern systems is a config-bit ROM ordeal as opposed to the older electrical “leave the optional IME_VCC disconnected to disable optional IME” style configuration (GM45 + apparently 1st gen Core-i laptops/systems).
According to the GM45 datasheet, the ME is supposed to load its firmware from the ME partition on the boot flash. According to the same datasheet, using 2 flash chip is also possible to extend the size of the boot flash. You now have 2 flash chips acting as one bigger flash chip.
In order to verify if you have a management engine firmware, you can simply dump the boot flash with an SPI programmer, and then run ifdtool -d /path/to/image.rom
It will then tell you if it as an ME partition. Look at the ME partition size.
Here’s a non-zero size:
FLREG2: 0x05f50001
Flash Region 2 (Intel ME): 00001000 – 005f5fff
And here a zero-size ME partition:
FLREG2: 0x00001fff
Flash Region 2 (Intel ME): 00fff000 – 00000fff (unused)
Note that laptops aren’t ATX compliant, so unlike desktop computers, there is no guarantee that mistakes won’t fry it. Some usual advises:
– Do it when the computer is powered off with any power supply removed.
– Really respect the flash chip voltage. It’s usually 3.3v. Consult the datasheet if in doubt.
– Use short wires.
– Provide enough mA to power up the flash chip.
flashrom.org has documentation on how to do that.
Another explanation could be that it’s related to the mysterious ROM_BYPASS feature that allows, on early silicon revisions, to bypass the ME bootrom and instead load code from flash.
This would probably allow free software code to run on the management engine since I’d guess that it’s the bootrom which checks the signatures.
This would in turn might allow to run GNU/Linux on the ME and:
– Offloads IRC clients or always on software to it
– Offload tasks (email fetching) to it for better power management (when the x86 CPU is powered off or in S3 for instance)
– try to understand better the hardware to have more trustworthy computers
– Use it for testing coreboot more easily
– Use it as an BMC on servers
Denis.
Greatly insightful information you have provided.
Possibly it has the Flash 2 as an empty with the Flash 1 containing the required info to tell ME the partition is zero size (AKA no chip so nothing there if looked for), seems likely, though the datasheet labels the ROM as “for iAMT” where the PCB is labeled, “ME ROM”.
There are several revisions of the E6400, including a PCB with an Nvidia NVS 160M, the schematics are full of configuration tables that can aid in hardware modding.
However it maybe that I’ve confused GM45 with the GM945 chipset.
If it is possible to make a “super ROM” by using two large ROMs, then couldn’t I socket-ify the ROM, backup and try out COREBOOT/Libreboot as used on other GM45 laptops (Lenovo T440 AFAIR) and tweak it to a usable state and then have an entire initrd in BIOS-ROM as an idea?
For a “super ROM”, assuming nothing clever’s happened to ROM chips since I last looked (well, flash), instead of (say) a 1MB ROM, you have 2 512K ROMs. Then you use address bit 20 as the chip select for one ROM, and an inverted version of A20 as chip select for the other. So the upper address bit selects which ROM. It’s no magic trick.
What might be a trick, is getting the ROM off the motherboard, and putting a socket in, depends on what package the chips are.
Since I have seen mainboards where both have identical chipset, yet one has a 32Mbit (4MB) Rom and the other has a 64Mbit (8MB) Rom. Unless there is some trickery going on, I’m sure they could be replaced with a 128Mbit (16MB) Rom or higher and then accessed via commands.
I guess it is up to the first 64K/1MB? chunk of legacy code to set up reading the rest of the BIOS image from ROM where the ICH/PCH only reads a fixed size initial chunk from ROM (So the 1st MB/64K of ROM) and places the data aligned to the legacy start instruction address of FFFF0h on the internal execution bus where a JMP to the begining block starts the Flashrom extraction sequence? If that is so, then say a (Non existent) 1TB flash-rom can be used as long as the required code segments (Partitions) are in the correct places (Early on in the 1st MB boundary) since the thing is SPI and then memory mapped to the legacy execution area. A whole OS can be put on, say an eMMC over SPI hack-job in place of the original ROM….
Hint: use an Arduino or other uC for the middleman between SDCard and the SPI, try the original (Native to the device) flash image, if successful then experiment :) (;-D)
Heck, I’ve got a spare Latitude E6400 laptop… time to grab an arduino, find an SD card and see what can be bodged… with a catch: Time and space to do this (Hmmm? enough going on at the moment)
Libreboot is a coreboot distribution that focusses on 100% free software. As such it only supports a very small subset of the machines supported by coreboot.
The GM45 chipset has a management engine.
That management engine is supposed to load its code from the management engine partition on the boot flash.
A Libreboot image consist of an image that is the same size of your boot flash, and that you flash on it, and Libreboot images don’t have any management engine firmware, in fact the management engine partition size is zero. So when using Libreboot the management engine has no way to load a firmware.
Coreboot can also make such hardware function well without a management engine firmware.
The confusion you are making comes from the fact that all most/all more recent Intel architectures still require a management engine firmware.
Note that, as I understand, me_cleaner, on such hardware, strips down the management engine firmware but doesn’t remove all code from it. In fact it leaves only code partitions that are used to boot the management engine in order to have the computer boot when reflashing the management engine firmware.
Denis.
Libreboot sounds attractive until you lurk in their IRC channel. I’ve never seen such a hive of scum and villainy. One of their project maintainers swiftgeek flames newbies all the time. It’s no wonder their community is so fractured.
How they implemented ME is fundamentally flawed.
chango, that’s a misleading response. you only “need” it because they logic bomb their product to fail on the end user without it. i can’t call that a malfunction; because it isn’t one, by the definition of trusted computing they are adhering to, the end user is not trusted. using ARM as a reference doesn’t cut it here, ARM doesn’t have a silent snitch coprocessor, which is what ME is. an easier comparison would be a management chipset, ie the same one ME is actually based around, such as the iLo chip on a proliant. difference being on a server that sort of thing is a paid for feature. or maybe compare to the POWER architecture. a company called raptor engineering has a machine, the talos, based off of POWER8 as a pricey workstation, but i’d be willing to drop $14k to be able to zero out ME if that was the only option available. as it is now, in ukraine, cr4sh has had some success fixing ME by excising parts, and having purged it from hardware myself, it is doable, but not entirely, and entirely is what is needed. the hardware checks if certain files are present on a chip at boot and absent them passing a SHA ,i think SHA2 checksum fused in to the CPU it sets a timer on some boards to trun for up to about 30 minutes and then fail, or on some not boot at all. another thing worth mentioning since you mentioned ARM, get a SOIC clip from someone on ebay for $0.50, install flashrom on your raspberry pi, and use the built in SPI hardware to take out everything not on the manifest in that list from the SPI flash after backing up your original ME. it’s not in control of everything it interjects itself in to the path of control in order to prevent tampering with itself and it’s more insidious functions by the end user. it’s a trusted computing device and you aren’t trusted. to continue hammering it in in simple terms, it’s designed to make sure someone else who is not the purchaser and end user of computing hardware, can maintain remote control of it, despite unautorized access attempts by a purchaser who thinks they “own it” (that language is extremely close to a description in a white paper i read recently, i wish i could recall to link, as that particular bit really stuck. obviously it was not marketing marterial, i’m fairly sure it was an MIT work product. i’ll try and find a link.) another cool thing you can do with a raspberry pi is put it between anything on x86 hardware and the internet, while you won’t catch AMT’s protocol, yet, there’s a lot of security good to be done using that trusted system model, namely, establishing your own trusted system based on it and not trusting intel hardware. having multiple architectures in your path makes it harder on an adversary; not trusting intel doesn’t mean dumping them all immediately, but it’s certainly cheaper to throw some devices not known compromised at that low a level out at certain junctures than it is to reinvest in POWER machines, ARM has no such known compromises. while you can’t spot the protocol, yet, through wireshark programmatically, there is a lot to be said for network flow analysis, properly monitored, and secured itself, and well placed on a network. it’s ideal for spotting this sort of threat.
What no!
“If you’ve never heard of this capability, you’re probably fine.”
After reading that, paused for a short ROFL then resume.
:o)
Obligatory comic relief is obligatory.
sudo apt-get install libpci-dev
git clone https://github.com/hardenedlinux/intelmetool.git
cd intelmetool
sudo ./intelmetool
Firmware Version from 6.x to 11.6 should be patched
While opinions are welcome, the assertions in this article are somewhat baseless.
This would start the engine, wouldn’t it? How is this a patch?
The IME starts before the OS loads…
the utility will tell you about the firmware version, and what is enabled.
If you do not want Intel’s updates, than there is little you can do to permanently patch the IME itself given parts are chip level ROM.
Google CHIPSEC for a tutorial about what is available, as modules released by Intel are now available.
Thanks for the info. I wasn’t aware that the IME initialized before the OS.
That’s the scary part of this thing. It’s “god”. It can access anything, everywhere. Without you being able to do a damn thing about it.
One way to nerf it’s abilities might be to run a NIC that is not supported by the bios that way there is no networking until the OS is loaded.
re: nerfing its ability by using an unsupported nic. That might help, but essentially the ME is a separate processor with full access to your machine – CPU, RAM, Encryption modules. It is by definition a system wide back door. Even if you can remove the code, there is a watchdog timer and if its not running the computer reboots in 30 minutes. There are ways to kill it on some older processors but not all. It seems even if the remote ability is off, you can attack it on localhost. So, malware running with user privileges and knowledge of the exploit could attach to AMT on localhost and use it to gain admin/root and backdoor the machine.
The more I learn about Intel ME, The more I worry. Not so much for my own privacy but for the privacy of governments, commercial entities etc. You can almost guarantee certain countries have small teams constantly working on trying to exploit this disaster waiting to happen.
+1
+1
++
+1
True and not just small countries.
Some agencies with three character names with nearly unlimited funding in some large countries also are on the job of finding exploits as well so they can sabotage things other countries are doing.
Not trying to be critical about the timeliness of reporting, just making a quick point. This story was out yesterday, and over the weekend. Anyone worth their salt has already picked apart the mitigation doc, and has been working on an exploit.
https://downloadmirror.intel.com/26754/eng/INTEL-SA-00075%20Mitigation%20Guide-Rev%201.1.pdf
Pff… you vastly underestimate the amount of work required to identify such a weakness.
+1 for yet another Tron image as illustration. Bad Intel Bad.
i generally think outrage over IME is overblown, because it is only enabled when needed, and when needed it is very useful. but i sure am disappointed in the poorness of intel’s disclosure of this issue. semiaccurate is only slightly more clear. this HaD write up is actually the most to-the-point description i’ve seen yet. thanks.
You really think its not running every second the mobo has power flowing? Even the standby 3.3v is enough to keep it running. This is exactly how the NSA spy’s on us and is the whole reason this chipset was created, plenty of other ways for an admin to remotely manage pc’s without the need for a secret undocumented chipset that we know for a fact intercepts all network traffic, all data moving between storage devices and all peripherals including webcam and mic.
While I agree it’s troublesome, how much can it really be doing? How much computational power does it have?
Anyone worried about espionage can surely run Wireshark (on an AMD chip, or Android tablet, or Raspberry Pi, or roll their own FPGA sniffer) and see what’s going over the network. If the IME is spying, it’s almost certainly reporting back via the Internet (and/or receiving commands).
It has access to storage devices, also. It may compile data into bigger chunks, store them and then transmit them during high traffic time, or at shutdown…
Wireshark can be kept running to look out for such bulk transfers. You only need another PC running it to watch the network traffic, also a DDWRT as a Man in the middle (MITM) traffic capture in case the other PC misses things.
Basing your assumption on that wireshark can actually read what is being sent. the NIC cards in our computers are capable of transferring data at frequency’s outside of spec and simply are not seen by the likes of wireshark, it would take an oscilloscope to really see everything going on. Just like your Cox,comcast,centurylink,quest,aol.. modem is capable of transfering data on bands its not licensed for (in the usa). The internet infrastructure supports an extended range that is outside whats permitted for consumer and commercial so the government is able to pickyback a secure network on top. Big brother is watching and always has been. Nearly every US citizen now caries in there pockets the most advanced spying device ever dreamed up, Mic, Camera, A-GPS(reports back home for “assistance”) 4G always connected data that we can’t easily sniff, fingerprint reader(even not in use your bound to touch it by accident), access to virtually all online activity, proximity tracking using BT and WIFI Mac’s.
Can you post some sources on the hidden bands supposedly supported by the internet infrastructure?
I’d believe it can happen in some cases, but I’m skeptical data could pass through a wireless router without being detected. Even if there’s a binary blob in the wifi module playing along, that data still has to go through the OS to the ethernet switch. Someone must have captured&recorded it.
But honestly I definitely believe it’s a thing that could/has happened so I’m just curious where I can read about this.
“Is Intel’s Management Engine Broken?”
Yes, _by_design_
MJG’s writeup is the best summary I’ve seen so far: http://mjg59.dreamwidth.org/48429.html
In brief, probably don’t panic, but if you weren’t highly critical of Intel for the ME before (and you should have been), you *definitely* should be now.
Try this, take the line “A vulnerability has been found in AMT allowing an attacker to take some control of the ME” to “A vulnerability has been found in IPMI allowing an attacker to take some control of the BMC”.
Chances are the internet services you are using are running on a server which is based a reasonable recent Xeon which is probably using a Pilot 3 or Pilot 4 BMC. You are not likely to get source code for the BMC’s firmware either.
The two main things I see here are that end users are largely ignorant of system management and securing their own networks (though it is probably a bit easier with enterprise tools like switches that work at higher layers of the network stack). The second is that support comes direct from Intel but must filter through an OEM who may have already dropped support for a specific product.
As for getting access to ME firmware, it’s going to be on an SPI NOR flash part. There have been some projects here to access those flash parts here on HaD. There are professional tools that are pricey, but not so bad as to be completely out of reach of an individual.
http://www.dediprog.com/pd/spi-flash-solution/sf100
http://www.dediprog.com/pd/spi-flash-solution/sf600
The SF100 has worked on all platforms up until the Skylake family on boards with an ISP header. IIRC, there are potentially issues if you encounter a 32MB SPI flash part. The SF600 is the safer choice for current platforms.
The following 2 documents may be helpful for understanding ways to access your flash part in circuit.
http://www.dediprog.com/save/617.pdf/to/AN0103%20%20On-Board%20SPI%20programming%20DediProg%20tool%20(Designer%20version).pdf
http://www.dediprog.com/save/618.pdf/to/AN0106%20On-Board%20SPI%20programming%20with%20DediProg%20tools%20(End%20user%20version).pdf
That’s also an easy place to find sockets if you are handy with a soldering iron and want to convert your board under test to a socketed part.
With accessing the hardware to get a flash image out of the way, the next part is getting at the ME firmware.
You will need to understand descriptor mode.
This is the series 100 chipset datasheet and the descriptor mode info starts at 3.7.1.2
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/100-series-chipset-datasheet-vol-1.pdf
From here, you would decode the descriptor in the first block of your flash image, determine which blocks contain the flash descriptor, extract those blocks into an image, then start working on that.
Research on this isn’t new. This was one of the first few results when I googled “intel manageability engine processor architecture”
https://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub
Now, maybe you made it through that wall of text and maybe you even read some of the information I posted. If you did, I hope you understand a little more about the topic of firmware in PCs and an entry point to get into research.
Will read some documents, sometimes the firmware is in the same SPI-flash (32/64M-bit types, usually as far as I have seen yet) and in separated form (2x SPI flashrom) where the IME firmware can literately be desoldered off the mainboard.
I suspect more work is needed to truly disable IME, say, how Dell does it on their buisness lines with an empty IME_ROM pad and a small yellow sticker saying, “ME Disabled”
However, it seems people are frightened to try pulling a ROM, backing-up data and experimenting.
P.S. the Mini-PRO TL866 can be had for about $36 to some expensive $100+ for the CS (basic) model and around the same for the A model (contains ISP support, apparently)
> and in separated form (2x SPI flashrom) where the IME firmware can literately be desoldered off the mainboard.
No, it can’t. If you do this, the computer will not POST.
> I suspect more work is needed to truly disable IME, say, how Dell does it on their buisness lines with an empty IME_ROM pad and a small yellow sticker saying, “ME Disabled”
This doesn’t actually disable the ME. The ME firmware is still on chip, and the ME is still running. Dell simply sets a flag which disables the ME’s user facing functionality, because they have decided not to license the ME functionality for that particular model. Using Intel’s own utilities (FPT, FIT) you can change the flag yourself and enable the ME’s user interface.
The “ME Disabled” sticker is just because Dell has disabled the user’s ability to configure and use the ME’s remote management functionality. The ME is 100% still active and running the firmware from SPI flash.
> However, it seems people are frightened to try pulling a ROM, backing-up data and experimenting.
I don’t think people are “frightened” the issue is more: consumer x86 boards make debugging hideously difficult. Modifying the firmware is basically poking at a black box, and the only feedback you get is the computer booting, or not.
> P.S. the Mini-PRO TL866 can be had for about $36
Just buy a CH341A based programmer from China ($2) and a SOIC 8 clip (~$4) and you can read/flash the EEPROMs.
>> and in separated form (2x SPI flashrom) where the IME firmware can literately be desoldered off the mainboard.
>No, it can’t. If you do this, the computer will not POST.
When I get home from work, or if time next break, I’ll take pictures of my fully POST-ed DELL Latitude E6400 (Compal LA-3801P PCB in an aluminium+magnesium alloy case) With the keyboard lifted and Hackaday.com on the screen with this missing ROM labelled and pointed out via a POST-IT note…. Unless Intel have gotten more sneaky by inventing and selling invisible ROMs to hide the firmware in such a way that it looks like there is no physical 2nd ROM soldered at all there?
Oh, and the reading of the Mobile 4 series (aka GM45 etc) implies that IME is optional, Quote:
“For details on implementing Intel Management Engine
on the platform, please see the Platform Intel ME-EC Interaction Specification
document. Page 34 [LINK]
Oh, and so far, admittedly I am not fully familiar with this chipset’s ins and outs, thus will come across a lot of gotchas and self-debunking.
However a more constructive counter argument from you could be of more value, like the help and advice that GNUtoo gave above and what extremely valuable and research-sparking resources Matt gave to us.
And Quote on page 65:
“5.3.1.1 Single-Channel Population Rules for Systems with Intel Management Engine Enabled”
Blah, Blah,
“In case of Non-AMT AND non-iTPM systems, either Channel 0 or Channel 1 may be populated.”
Still reading (1st pass read)
That’s why IME is fundamentally broken by design there is no way to actually turn it off.
God forbid anyone has ME enabled machines running anything mission critical while connected to the Internet using the built in bios supported NIC.
OK, I can’t find “Platform Intel ME-EC Interaction Specification” yet for GM45, still fast-tracking the info to my mind…
The ME does more than present the specter of a back door as a remote management interface. It is a very much like a BMC for systems that are not servers. So it handles things like aspects of power management and thermal control. There will be more but they are going to be buried in specs and I only read things like the PCH specs when I need to for work. So disabling it isn’t a straightforward manner. you’d be better off blocking the ports it uses on your network in the same way they block access to IPMI traffic and BMC management ports in the datacenter (it would be even better if it had its own dedicated MAC you could put on a dedicated VLAN, but it looks a lot more like a shared LOM port in the server space).
I have no evidence, but I strongly suspect the ME group in Intel is based on the work of Intel’s BMC group that they dismantled I guess 10 years ago (I feel old now). The MP Xeon processor generation before the Nehalem Xeons was paired with the ESB2 southbridge which, IIRC was the last enterprise south bridge to contain a BMC.
One company I worked for ended up acquiring a few people who were affected by this change at Intel.
I would not be surprised if some manager managed to protect at least some people by pitching the concept of a lightweight BMC for the next generation of enterprise platforms. A little research on HECI might help understand the scope of what is going on.
You will still need the first ROM chip in a 2 chip config. That will have the descriptor, the PCH soft straps, and the GbE firmware as well as the ME firmware. The second flash part was really handy for people developing BIOS on mobile platforms to just flash their BIOS image without composing a full ROM image. But I haven’t worked in a place doing laptop firmware development in a while. All my work for the past few years has been with server firmware.
I recommended the Dediprog because that’s what we use at work and is the recommended solution from a large chip company I shall not name here :) But it’s not like you need a $50K hardware debugger and multiple NDAs to poke at a raw ROM image.
One thing I’m surprised no one is discussing yet is the upcoming Intel Innovation Engine. This thing also represents a security risk, but the fact that it’s an x86 ISA means reverse engineering firmware and software for it should be a lot like the same tasks on a PC.
Flashrom’s latest release supports CH341a based hardware programmers. They can be found for as low as $2.00, and if you need a way to interface, for another $2.00 you can just get a SOIC8 clip. With that you can read/write all these different flash chips: https://www.flashrom.org/Supported_hardware
Spam much?
Yay and Nay….
Whilst said hardware supports said ROMs.
The reason for TL866 is that we at work find bespoke micro-controllers whom a clone of its firmware helps get units out the door. It happens to support a lot, ranging from flashing generic flash-ROMs to testing RAM and the occasional 8bit microprocessor tests by the looks of things.
That way we can rely on it supporting most ICs we reprogram, Especially the programmable keyboards whom its’ ROMs have a bit-fade problem with most units (Tracked it down to not enough voltage across VCC when reading, only after the data has aged a decade or so, A writeback fixes things for another 10 years)
If it can already be used what amount to a privilege escalation past Kernelspace and into BIOS space then yes, this whole idea is exactly as stupid as everyone said it was.
It is quite funny that chinese ARMs are more private than Intel’s latest x86 CPUs. Next time I will use some OrangePi when joining Daish or browsing CP :-D
Are you sure?
@Phil, it is likely that while China is “evil” they are less “capable” than i(NSA)tel.
I would not underestimate China’s abilities though they probably have little interest in spying on individual people outside of China they have enough trouble keeping tabs on their own population.
But if you are a government or corporation with information of interest to them such as an aerospace company then you should fear the 3PLA.
For example CASC would love to get their hands on all of Spacex or ULA’s LV designs.
The question for me regarding this exploit is rather: “Can this bug be used to make this stinking rathole to get the fuck out of my computer????”
IME is suspected to do evil, evil, EVIL stuff. You don´t even need a tinfoil hat to recognize this.
Like the article says, if you have a sufficently old chipset, you can disable IME (Or do it like RMS and use a 15 year old laptop ;-) )
Maybe now it will be possible to turn it off on current hardware?
When the AMD and Intel management cores are owned, no one will hear about it until after it is replaced. That kind of information will sell for enough money to keep whoever discovers it fed for the rest of their life (or to be found dead having die from natural causes).
It is like waking up one day and realising that your nice secure house is really just a cardboard box in the middle of somebody else’s lounge room.
Nice analogy!
RE: IS INTEL’S MANAGEMENT ENGINE BROKEN? Maybe they were just under duress. The timing of the first ME chip-sets shipped in an election year after the winning candidate said that he would reform domestic spying programs and now Intel has a patch suddenly 8 years later after he exits. Probably all just coincidence I guess.
Good point!
Looking at historical port scans, it looks like ports 16992 and 16993 start to get scanned a lot more since the 6th of March (almost a month ago)
https://i.imgur.com/AmtM0sk.png
https://i.imgur.com/c5e9Cmk.png
So I wonder who had this information for a month and suppressed it.
Hi, could you reupload these images?
Create your own – go to the “Internet Storm Center”
DOH – almost 2 months ago not 1.
It surprises me not a bit that such a horrifically bad idea eventually backfires.
What does surprise me is that it took so long. (NSA may have been there before)
ME and AMT are nothing short of a backdoor. And we should have never allowed this shit on our systems.
Does this count as ‘Clipper chip’?
I’m sure it’s accessible by US spooks like the NSA.
And I would like to point out, or remind you, that AMD has similar technology baked in.
And it’s actually not a ‘very few’ that have this baked in either I’m told, it’s in the majority of modern systems.
A way around it if you are worried is to NOT use the on-board NIC for internet access but an external NIC. Since that won’t also work outside the OS like the IME crap does which works in its own world and works without the OS and even when the system is ‘turned off’.
True an external NIC should nerf it.
But if the NIC has a PXE boot rom it could in theory still still use it.
All this makes me miss the days of Unix work stations that had open firmware based boot roms.
I almost wonder if they were killed off on purpose to make government spying easier vs just by competition.
This just came out BTW: https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr
Subscribing to comments…
Yes it is broken but it’s mainly causing problems in Asus brand laptop in that window 10 constantly try to install but always there is error, you can stop this installation by regedit setting