For almost two years now, I have avoided all Intel systems with the 965 chipset and newer, instead opting to stay with the 945 chipset and older in order to bypass the security issues surrounding the Intel Management Engine within the unclear 2006 to 2008 general period of initiation. However, in the time since I have acquired a Dell XPS 410, I have been forced to fully sort out the mess, misinformation, and confusion that is the 965+ chipset, the Intel Management Engine, and Intel Active Management technology, just to feel comfortable operating it.
As with a prior Wiki I have compiled, I initially wrote the following information with the intention that it be used as a personal reference. But, seeing as how there have been past examples where this particular group of people have expressed interest and concern in the subject matter (https://forums.macrumors.com/thread...y-privacy-issues-on-intel-based-macs.2193645/, and on a semi-related note, https://forums.macrumors.com/thread...n-the-new-announcements.2267073/post-29238209), along with the fact that, as far as I am aware, there does not presently exist any centralized information resource on the Internet detailing which chipsets are truly affected, which chipsets can be remotely compromised, and what exactly can be done to mitigate a vulnerable chipset should the user come into possession of one, I have decided to publish it here for future public reference.
Preventing Security Vulnerabilities from Intel Active Management Technology within Pre-Nehalem Systems (Core 2 Solo / Duo / Quad)
The Intel Management Engine was introduced with the Intel Q965 chipset, and is present in the subsequent Q35 and P/G/GM/Q/X4x (henceforth known as "i4x") chipsets, each introduced in 2006, 2007, and 2008, respectively. It has full access to the processor interface, DRAM controller, internal graphics controller, graphics interfaces, and the I/O Controller Hub, but can only send and receive data over the network if the motherboard supports Intel vPro, or more specifically Intel Active Management Technology (itself a subset of vPro). In order to function, Intel vPro / AMT requires "the platform to have an Intel AMT-enabled chipset, network hardware and software, connection with a power source and an active LAN port." (i965 datasheet)
The Intel ME should not be confused with Intel AMT, as only AMT is capable of interfacing with the Intel-manufactured onboard Network Interface Controller and thus presenting a security risk. The ME and its vPro / AMT subset was later carried over to mobile platforms via Centrino Pro, and the subsequent Centrino 2 vPro in 2007 and 2008, respectively.
AMT should also not be confused with the open Alert Standard Format, as ASF is OS-dependent via software, cannot transmit the same breadth of data, is not exclusive to Q965+, and cannot run when the system is powered off.
On mobile systems, AMT is only supported if the system is branded as compatible with Centrino Pro or Centrino 2 vPro. On desktop systems, vPro, and therefore AMT, is only supported if the motherboard contains the Q965, Q35, or Q45 business-class chipsets, which can be identified by the printed model number of the ICH, otherwise commonly known as the southbridge (refer to the large Intel-branded chip on the system motherboard):
82801HO (Q965, Digital Office, contains both ME and AMT)
82801IO (Q35, Digital Office, contains both ME and AMT)
82801JO (Q45, Digital Office, contains only AMT)
All Core 2 Solo, Core 2 Duo, Core 2 Quad, and Core 2 Extreme-based desktop boards lacking the above ICH chips do not have AMT, as vPro / AMT (as well as the ME on Q965 and Q35 chipsets) are not built into any desktop chipsets free of the 'Q' designation prefix (except for Q963, Q33, and Q43, which also lack vPro / AMT, but do support ASF), rendering the ME on P/G/GM/X4x chipsets as presumptively benign.
Alternatively, mei-amt-check (https://github.com/mjg59/mei-amt-check) can be used on Linux systems to determine the presence of the ME and AMT. If the 'mei_me' module is not automatically loaded upon boot, then the system lacks the ME, and by extension AMT, and thus does not require manual circumvention.
Further, the user can also run ls /dev | grep mei to check for the presence of the ME in an even faster fashion. In the event the command returns mei and thus confirms the presence of the ME, this method unfortunately still cannot check for the presence of AMT, whereas usage of the aforementioned mei-amt-check tool will be necessary to draw a final conclusion.
Although the ME was introduced with the Q965 chipset, AMT made its debut slightly beforehand on i945-based systems with the Intel 82573E Gigabit Ethernet Controller, which can be confirmed with lspci | grep Ethernet, whereas the following mitigation steps would apply.
As a preventative measure on affected, usually Q-based chipsets, disable the integrated NIC via the system BIOS and replace it with an alternative network interface that does not contain a central NIC chip designed by Intel, which will prevent AMT (and potentially the ME itself on i5x systems and up) from communicating with the Internet because it only contains drivers for the onboard NIC (as of i5x). Examples include non-Intel USB Wi-Fi adapters, USB Ethernet adapters, and internal PCI or PCIe network cards. This action can also effectively render the ME and AMT on applicable systems as presumptively benign.
As with Core 2-based systems, vPro / AMT appears to only be present on Core i3/5/7-based systems with Q-prefixed chipsets. However, it is currently unknown what exact relationship the ME has with the NIC of all Core i3/5/7-based chipsets, and how it differs from its relationship with those of Core 2-based chipsets in preceding versions. Therefore, NICs on Nehalem-based systems and up are potentially unsafe by default without manual circumvention through alternative hardware.
Addendum on the ME / AMT within Post-Nehalem Systems (Core i3 / i5 / i7+)
Starting with ME version 6.0 in the first Nehalem systems (Core i7, X58 chipset, Nov 2008), the ME is not only more tightly integrated into the rest of the system due to the memory controller having been moved from the southbridge directly into the central processor, but coupled with the complete lack of any documentation that Intel has provided, it is not fully known what the ME itself can do without AMT. Therefore, using alternative network adapters to lock the system down as a failsafe is recommended.
According to research and verification (not official documentation, courtesy of Intel), the ME was only included in certain Core 2-based chipsets that supported vPro. This is a prime example of where the ME wasn't as tightly integrated; if vPro / AMT wasn't present on the system, then there was no need to include the ME either on i965 and i3x chipsets (2006 / 2007).
As of the i4x chipsets and up (2008+), the ME seemingly began being built into the system regardless of the presence of AMT. However, the ME on i4x chipsets weren't vulnerable to SA-00112 without the presence of AMT, suggesting that the ME lacked any network capabilities at all and required AMT for that ability (or to be a threat) on i4x chipsets. On the other hand, although not all ME 6.0+ (Nehalem) systems include AMT, they are still vulnerable to the aforementioned SA-00112, regardless of whether or not AMT is present or enabled.
Therefore, it may also be logically argued yet that the ME 6.0+ itself in Nehalem systems and newer is theoretically no more capable than the prior versions in Core 2 systems. After all, if the premise of AMT is to enable network interfacing and remote configuration of the ME, then one might reasonably ask what the objective would be of building network capabilities directly into the ME?
The only issue with this theory however is the aforementioned vulnerability difference to SA-00112, suggesting that the ME itself in Nehalem and up did indeed gain certain independent networking capabilities of its own, irregardless of the presence of AMT. Unfortunately, there also does not seem to be any evidence presently available to disprove this estimation either.
AMD Platform Security Processor Notes
o The PSP has full access to all hardware components, as with the ME.
o The PSP is located exclusively on the CPU die, whereas the ME is located on the motherboard southbridge.
o Last safe CPUs are anything in the FX (Bulldozer) family using the AM3+ CPU socket.
o Fastest FX CPU is FX-9590 / overclocked FX-8370. Motherboard should have the FX990 chipset for best performance.
Resources
en.wikipedia.org
en.wikipedia.org
en.wikipedia.org
Running tests on various systems with differing chipsets
As with a prior Wiki I have compiled, I initially wrote the following information with the intention that it be used as a personal reference. But, seeing as how there have been past examples where this particular group of people have expressed interest and concern in the subject matter (https://forums.macrumors.com/thread...y-privacy-issues-on-intel-based-macs.2193645/, and on a semi-related note, https://forums.macrumors.com/thread...n-the-new-announcements.2267073/post-29238209), along with the fact that, as far as I am aware, there does not presently exist any centralized information resource on the Internet detailing which chipsets are truly affected, which chipsets can be remotely compromised, and what exactly can be done to mitigate a vulnerable chipset should the user come into possession of one, I have decided to publish it here for future public reference.
Preventing Security Vulnerabilities from Intel Active Management Technology within Pre-Nehalem Systems (Core 2 Solo / Duo / Quad)
The Intel Management Engine was introduced with the Intel Q965 chipset, and is present in the subsequent Q35 and P/G/GM/Q/X4x (henceforth known as "i4x") chipsets, each introduced in 2006, 2007, and 2008, respectively. It has full access to the processor interface, DRAM controller, internal graphics controller, graphics interfaces, and the I/O Controller Hub, but can only send and receive data over the network if the motherboard supports Intel vPro, or more specifically Intel Active Management Technology (itself a subset of vPro). In order to function, Intel vPro / AMT requires "the platform to have an Intel AMT-enabled chipset, network hardware and software, connection with a power source and an active LAN port." (i965 datasheet)
The Intel ME should not be confused with Intel AMT, as only AMT is capable of interfacing with the Intel-manufactured onboard Network Interface Controller and thus presenting a security risk. The ME and its vPro / AMT subset was later carried over to mobile platforms via Centrino Pro, and the subsequent Centrino 2 vPro in 2007 and 2008, respectively.
AMT should also not be confused with the open Alert Standard Format, as ASF is OS-dependent via software, cannot transmit the same breadth of data, is not exclusive to Q965+, and cannot run when the system is powered off.
On mobile systems, AMT is only supported if the system is branded as compatible with Centrino Pro or Centrino 2 vPro. On desktop systems, vPro, and therefore AMT, is only supported if the motherboard contains the Q965, Q35, or Q45 business-class chipsets, which can be identified by the printed model number of the ICH, otherwise commonly known as the southbridge (refer to the large Intel-branded chip on the system motherboard):
82801HO (Q965, Digital Office, contains both ME and AMT)
82801IO (Q35, Digital Office, contains both ME and AMT)
82801JO (Q45, Digital Office, contains only AMT)
All Core 2 Solo, Core 2 Duo, Core 2 Quad, and Core 2 Extreme-based desktop boards lacking the above ICH chips do not have AMT, as vPro / AMT (as well as the ME on Q965 and Q35 chipsets) are not built into any desktop chipsets free of the 'Q' designation prefix (except for Q963, Q33, and Q43, which also lack vPro / AMT, but do support ASF), rendering the ME on P/G/GM/X4x chipsets as presumptively benign.
Alternatively, mei-amt-check (https://github.com/mjg59/mei-amt-check) can be used on Linux systems to determine the presence of the ME and AMT. If the 'mei_me' module is not automatically loaded upon boot, then the system lacks the ME, and by extension AMT, and thus does not require manual circumvention.
Further, the user can also run ls /dev | grep mei to check for the presence of the ME in an even faster fashion. In the event the command returns mei and thus confirms the presence of the ME, this method unfortunately still cannot check for the presence of AMT, whereas usage of the aforementioned mei-amt-check tool will be necessary to draw a final conclusion.
Although the ME was introduced with the Q965 chipset, AMT made its debut slightly beforehand on i945-based systems with the Intel 82573E Gigabit Ethernet Controller, which can be confirmed with lspci | grep Ethernet, whereas the following mitigation steps would apply.
As a preventative measure on affected, usually Q-based chipsets, disable the integrated NIC via the system BIOS and replace it with an alternative network interface that does not contain a central NIC chip designed by Intel, which will prevent AMT (and potentially the ME itself on i5x systems and up) from communicating with the Internet because it only contains drivers for the onboard NIC (as of i5x). Examples include non-Intel USB Wi-Fi adapters, USB Ethernet adapters, and internal PCI or PCIe network cards. This action can also effectively render the ME and AMT on applicable systems as presumptively benign.
As with Core 2-based systems, vPro / AMT appears to only be present on Core i3/5/7-based systems with Q-prefixed chipsets. However, it is currently unknown what exact relationship the ME has with the NIC of all Core i3/5/7-based chipsets, and how it differs from its relationship with those of Core 2-based chipsets in preceding versions. Therefore, NICs on Nehalem-based systems and up are potentially unsafe by default without manual circumvention through alternative hardware.
Addendum on the ME / AMT within Post-Nehalem Systems (Core i3 / i5 / i7+)
Starting with ME version 6.0 in the first Nehalem systems (Core i7, X58 chipset, Nov 2008), the ME is not only more tightly integrated into the rest of the system due to the memory controller having been moved from the southbridge directly into the central processor, but coupled with the complete lack of any documentation that Intel has provided, it is not fully known what the ME itself can do without AMT. Therefore, using alternative network adapters to lock the system down as a failsafe is recommended.
According to research and verification (not official documentation, courtesy of Intel), the ME was only included in certain Core 2-based chipsets that supported vPro. This is a prime example of where the ME wasn't as tightly integrated; if vPro / AMT wasn't present on the system, then there was no need to include the ME either on i965 and i3x chipsets (2006 / 2007).
As of the i4x chipsets and up (2008+), the ME seemingly began being built into the system regardless of the presence of AMT. However, the ME on i4x chipsets weren't vulnerable to SA-00112 without the presence of AMT, suggesting that the ME lacked any network capabilities at all and required AMT for that ability (or to be a threat) on i4x chipsets. On the other hand, although not all ME 6.0+ (Nehalem) systems include AMT, they are still vulnerable to the aforementioned SA-00112, regardless of whether or not AMT is present or enabled.
Therefore, it may also be logically argued yet that the ME 6.0+ itself in Nehalem systems and newer is theoretically no more capable than the prior versions in Core 2 systems. After all, if the premise of AMT is to enable network interfacing and remote configuration of the ME, then one might reasonably ask what the objective would be of building network capabilities directly into the ME?
The only issue with this theory however is the aforementioned vulnerability difference to SA-00112, suggesting that the ME itself in Nehalem and up did indeed gain certain independent networking capabilities of its own, irregardless of the presence of AMT. Unfortunately, there also does not seem to be any evidence presently available to disprove this estimation either.
AMD Platform Security Processor Notes
o The PSP has full access to all hardware components, as with the ME.
o The PSP is located exclusively on the CPU die, whereas the ME is located on the motherboard southbridge.
o Last safe CPUs are anything in the FX (Bulldozer) family using the AM3+ CPU socket.
o Fastest FX CPU is FX-9590 / overclocked FX-8370. Motherboard should have the FX990 chipset for best performance.
Resources
Intel Management Engine - Wikipedia
Intel Active Management Technology - Wikipedia
Intel AMT versions - Wikipedia
Intel VPro and fiber networks
Solution: Hi there! I checked with a couple of our Intel engineers and here is what I found out:vPro utilizes the integrated network adapter. Currently
community.spiceworks.com
Last edited:
