Intel Warns of Critical Vulnerability in Processor Firmware (SecurityWeek)

Nine-Year-Old Critical Vulnerability Affects Intel Active Management Technology

Intel issued a critical alert  Monday concerning an escalation of privilege vulnerability affecting Intel Active Management Technology (AMT), Intel Small Business Technology (SBT), and Intel Standard Manageability. Firmware updates are available in all cases — but that’s not the end of the story.

While the Intel alert states, “This vulnerability does not exist on Intel-based consumer PCs,” security commentators such as Charlie Demerjian suggest “there is literally no Intel box made in the last 9+ years that isn’t at risk. This is somewhere between nightmarish and apocalyptic.” The vulnerability affects every Intel system from Nehalem in 2008 to Kaby Lake in 2017.

According to Intel, the vulnerability (CVE-2017-5689) can be accessed in two ways. Where AMT and ISM have been provisioned, an unprivileged network attacker could gain system privileges. Where not provisioned, a local attacker could provision them and gain local system privileges on AMT, ISM and SBT. Intel gives no details on the vulnerability itself.

The three main issues for business are the extent of the damage that could be done through this vulnerability; the difficulty in knowing what systems are vulnerable; and the lack of control over the availability of Intel’s firmware updates.

AMT is intended to give IT departments a means to manage client systems. When enabled, packets sent to ports 16992 or 16993 are redirected through Intel’s Management Engine (a small, separate processor independent of the main CPU) and passed to AMT. The operating system never sees these packets. AMT can be used to install media, reboot the machine and more, remotely. It requires a password for access; but this vulnerability suggests that the password can be bypassed.

Understanding the extent of the risk could also be difficult. “What about embedded devices that are increasingly PC based?” asks Demerjian. “Digital signage perhaps? Industrial controls. HVAC. Security systems. Flight controls. Air traffic controls. Medical devices. I could go on but all of these are likely PC based and anything infrastructure related is likely networked.”

SANS’ Richard Porter suggests, “Get a good, complete hardware inventory together, and get a good software inventory — know what’s in your organization and on your network, and know what’s running on that gear. This includes elevator controls, industrial presses, MRI machines, point of sale stuff, TVs, DVRs and photocopiers — all of it!  Without knowing what’s on your network, the best you’ll do is to get a reasonable percentage of affected systems — you’ll never patch the machines you don’t know about.”

The third issue is patching. While it is Intel’s responsibility to develop the patches (which it has done), it is not Intel’s responsibility to deliver them. That’s down to the device manufacturers and OEMs; and it is generally thought that not all will do so.

Demerjian warns, “If you have a white-box PC or one from a sketchy vendor, chances are they won’t bother with a firmware update. Security is a cost center and most OEMs run on margins too thin to bother with security patches even if they cared. Most simply don’t care.” Put bluntly, many systems will likely never be patched.

This raises two further issues: what should be done when you have little or no control over whether or even if you will receive patches; and secondly, how urgent is this issue? The latter takes us into conjecture. The Intel alert makes no statement over whether the company is aware of any current exploitation of the vulnerability — the alert neither confirms nor denies it.

Researchers have been warning Intel for years. In 2012, Demerjian wrote, “Intel doesn’t understand security, but they are not shy about shouting it from the rooftops. They took a good idea, vPro [which includes AMT], and turned it into a remote exploit and security risk that prevents a compromised machine from being repaired.” 

Demerjian in particular wonders, ‘why now?’; adding “SemiAccurate strongly suspects this vulnerability is being exploited in the wild as we speak.” It is conjecture, but it could be true (and all the while we don’t know whether Shadow Brokers has any further exploits to announce).

The implication is clear: business cannot wait for a solution to be handed to it; it needs to be proactive and mitigate the vulnerability as soon as possible. Luckily, Intel has published separate documents that should help. 

How To Find Intel® vPro™ Technology Based PCs will help to determine whether a system is AMT, SBA or ISM capable. If it is not, then no mitigation is required.

INTEL-SA-00075 Detection Guide steps through the process of using Intel’s System Discovery utility to determine the firmware version and whether it is vulnerable.

INTEL-SA-00075 Mitigation Guide provides “instructions on how to implement mitigations on Intel’s manageability SKU systems that are vulnerable to a known privilege escalation issue.”

All three documents are useful; but business is advised to employ mitigations where necessary as soon as possible. The mitigation document provides details on removing the supporting code in Windows. “What it boils down to,” says SANS’ Porter, “is you want to stop and disable the LMS Service (Local Management Service), then delete LMS.exe.”

Kevin Townsend is a Senior Contributor at SecurityWeek. He has been writing about high tech issues since before the birth of Microsoft. For the last 15 years he has specialized in information security; and has had many thousands of articles published in dozens of different magazines – from The Times and the Financial Times to current and long-gone computer magazines.

Previous Columns by Kevin Townsend:

Tags:

Source: SANS ISC SecNewsFeed @ May 2, 2017 at 08:39AM

0
Share