What is he talking about?
He is referring to the Intel Manageability/Management Engine, or ME. It is a processor embedded in the chipset's PCH, and is typically composed of an ARC, ARCCompact, or i486/i586 hybrid microprocessor. It is designed to, among other things, make remote administration easier. On servers and certain business laptops that support AMT (Intel Active Management Technology), certain network cards can be used to control the system remotely. This requires enabling it in the BIOS/UEFI and setting a password. If you have a 3G card installed, then it in theory could use that card for remote management, but in all likelihood, you don't.
The danger of exploits
There is a risk of vulnerabilities in the network protocol, as with everything that implements a network stack, and there have been bugs involving them in the past. They typically require you to actually enable remote management to be vulnerable. Overall, the whole ME scare is a bit overdone. All the scary capabilities listed are opt-in or not even present.
The danger of rootkits
There is also the fear that the ME could be used to hide a low-level rootkit. This is not an issue in most cases because it requires either very privileged access to the computer, or the ability to physically modify the motherboard (replace the BIOS chip, for example). Even without the ME, very stealthy rootkits can still be installed with that level of access.
The benefits of newer processors
I would not recommend using an older CPU model. Newer models have had significant improvements in security. A current modern processor may support many of the following:
- NX - One of the oldest security features, it allows marking pages as non-executable, so a buffer overflow that overwrites NX data cannot then execute it.
- SMEP - Prevents low-privilege userspace code from being executed in a high-privilege, kernelspace environment. This forces attackers to inject their shellcode directly into the kernel, which is far more difficult and prone to crashes.
- SMAP - Same as SMEP, but prevents all accesses, not just execution.
- UMIP - Hides certain potentially sensitive information which otherwise could be accessed at low privileges.
- VT-x (virtualization) - Not usually used for security, but can be used for sandboxing, in a pinch.
- VT-d (IOMMU) - Allows isolating devices from each other and from the rest of the memory, preventing DMA attacks.
- IR and x2apic - While their functions are unrelated to security, they are both needed for VT-d to function against malicious actors.
- MPX - While designed for debugging, it can be used to prevent buffer overflows on programs which use these instructions.
- SGX - Creates a secure, encrypted "enclave" that even high-privilege code cannot access.
- RDRAND/RDSEED - Adds high-quality random data to the system, which is useful when doing things like generating passwords. While there are reasons to be skeptical about using it as your sole randomness source, it is harmless when used to augment your system's other sources.
- AES-NI - Accelerates AES encryption with dedicated hardware instructions, but is also useful for security by preventing side-channel attacks, since the processor's cache is not used.
- CET - An upcoming feature that is designed to help mitigate ROP attacks (attacks that allow running arbitrary code on memory which is executable but cannot be written to by executing instructions out of order).
- MPK - An upcoming feature that, among other things, allows code to be executable but not readable by providing more fine-grained control over memory permissions.
- BootGuard - Prevents any unauthorized modification of the BIOS, by signing it and verifying the signature at each boot.
- TPM - While limited in capabilities, it's still useful for secure attestation, key storage, and detecting evil-maid attacks (see Joanna Rutkowska's "anti-evil maid" program).
- fTPM - Similar to a hardware TPM, but integrated into the ME itself. While it has its own downsides, it is also invulnerable to the classical MITM attacks against regular TPMs.
- TRR/pTRR - Strongly resists rowhammer attacks on supported memory modules by detecting when a row is being accessed too often, and refreshing it by force.
Of all of these security features, only NX is typically supported on older processors, and even then, it can be buggy.
The issues with older processors
Additionally, older processors often have severe bugs which are not going to be fixed due to no longer getting microcode updates. Many 32-bit Core2duo processors have a bug which causes NX to be active on only one of the two cores. Newer systems also often have more secure BIOS, largely due to the work done by Legbacore. These newer systems lock the BIOS so it cannot be modified. Old systems do not have this and are very easy to infect with BIOS rootkits, as they offer no write protection for the BIOS.
Older processors are probably going to be 32 bit, which reduces the quality of ASLR, a technique to randomize the locations of loaded libraries. On Linux for example, the strength of ASLR is limited to 16 bits (8 by default) on these processors, compared with 32 (16 by default) when running on a 64 bit system. Certain side-channel attacks can break ASLR much more easily on 32 bit systems because of this.
But what is the actual risk?
If your system's ME supports remote management and if you have a supported network card and if you enable it in the BIOS and if there is a remotely exploitable bug in the network stack and if you allow incoming connections, then you can potentially get your computer infected with the equivalent of a BIOS rootkit (the ME code exists in the BIOS, after all). If you use an older system to avoid the ME, you will be forgoing a large number of important security features and will need to live with known, often severe bugs.
If you are still worried about the ME, or your threat model makes it a bigger risk than it would be for most people (e.g. you need to use a 3G card), there are currently two ways to limit the powers of the ME, aside from simply turning off AMT. The first method works on Sandybridge and Ivybridge processors. Overwriting the first page of the ME can cripple it, so only the core functionality is enabled. The second method allows completely disabling it during runtime. An undocumented switch was found which causes the ME to lock itself up after running the necessary hardware initialization routines.
To end with an analogy, imagine a web browser. Sure, older browsers were simpler and do not have potentially exploitable features like WebGL or WebRTC, but would you really trust someone if they recommended you use an outdated web browser with known bugs, just because newer models which fixed them may potentially have their own set of problems?