Download this article as a .PDF
Security breaches of all types seem to be reported almost daily, and they range in scope from ones that affect hundreds of platforms to those that afflict millions. Often these are software problems that developers incorporated in an application, albeit unintentionally (hopefully).
Of course, the hope is that the underlying hardware is secure, but what happens if it isn’t? Answer: Sometimes your hardware can come back to haunt you.
Such is the case for users of Intel’s Active Management Technology (AMT), found in the vPro versions of many of the company’s chips. The problem has been around since about 2008, and it affects the Standard Manageability (ISM) and Small Business Technology (SBT) firmware versions 6 to 11.6. This includes everything from a Nehalem Core i7 to the latest Kaby Lake vPro systems.
For those unfamiliar with AMT, it is a remote access system that allows remote management. These processor chips essentially have two distinct processors. The main application processor is the same as for chips without the vPro support. The other is the management chip, which has complete control over the application processor. This allows an operating system to be installed remotely or to track the operation of the system.
Though normally an Ethernet connection, the network can also be wireless. In many cases this is a second network connection, but often it shares the same connection as the application processor.
The management processor runs its own firmware and normally requires a secured remote management link. The problem is that these implementations of AMT have a flaw. Essentially, the system requires a password to gain access, but a blank or invalid password will work.
The name assigned to this problem is CVE-2017-5689. Intel has provided a discovery tool for the problem. Fixes are anticipated, but motherboard vendors will likely be the source of a fix, so stay tuned.
There are thousands of devices that have public internet addresses. There are many more that may be behind firewalls that would require additional malware to launch an attack. Either way, this is a serious issue.
As an actual problem, this is a significant one. The problem is that it is one of many and it highlights the need for truly secure hardware. Unfortunately, this example shows that even systems designed to be secure can be susceptible to problems. More systems are incorporating security processors, but these will only be useful if they are truly secure. Most require firmware and, unfortunately, it is likely to be written in C (but that’s another discussion).
I have a few systems that use AMT, but luckily they aren’t affected by this particular bug. Hopefully there are no more issues.
Developers will rarely be building the entire system from scratch. They will have to rely on everything from security processors to secure boot support. More complex systems have a larger attach surface and the potential for more bugs that can cause problems like this.
It is possible to develop and deploy secure systems, but the size of the company and the importance of the system is no guarantee that these problems will not occur. This doesn’t mean that we should give up on incorporating security into our applications, but we should be demanding that the hardware we rely on be as secure as possible.
