Some computer manufacturers have started releasing patches for eight serious vulnerabilities in Intel processors or they have outlined firmware update plans for vulnerable models.
Acer, Dell, Fujitsu, Hewlett Packard Enterprise (HPE), Lenovo, Panasonic and Intel have identified hundreds of their products, including laptops, desktops and servers, that are affected by the recently announced flaws.
Intel published a security advisory detailing the vulnerabilities earlier this week. They affect subsystems that are present in many Intel processors: the Intel Management Engine (ME), the Intel Trusted Execution Engine (TXE) and the Intel Server Platform Services (SPS).
The flaws can be used to compromise third party secrets, including so-called platform keys that are used for secure boot and other secure attestation features, or to execute arbitrary code inside the Intel ME environment.
The ME subsystem has its own dedicated microprocessor and operating system (based on MINIX) and provides out-of-band remote computer management. The subsystem is present in most Intel CPUs manufactured after 2008 and runs even when the computer’s main OS is shut down.
Lenovo has published a support page with an inventory of affected products, including ThinkCentre and IdeaCentre desktops and all-in-ones; IdeaPad and ThinkPad laptops; ThinkStation tower workstations; ThinkServer and ThinkSystem servers and Server x racks. Patches are already available for some of the affected models and updates are expected to be released today for the majority of remaining devices.
Dell has separate support articles for its server products and client platforms. BIOS updates that include the patches are already available for servers, but affected laptops, desktops and other types of devices are scheduled to receive patches at different times over the next few months, depending on model. The flaws’ impact on many Dell hardware products is still being investigated.
Acer has identified a number of affected laptops and desktops but has not yet indicated when patches will be released. The company is still in the process of determining if the flaws affect many of its other computers models.
“Due to potential platform key exposure and third-party services dependency on those keys, existing platform keys will be revoked,” Acer said in its advisory. “As a result, some third parties may require that those platform keys be re-issued to avoid interruptions in their service.”
The same warning was put out by Fujitsu, which notes in a support article that the revocation of existing platform keys is being targeted for the first half of 2018 in a coordinated effort. New keys should be provisioned until then to avoid interruptions for third-party content and service providers, the company said.
Fujitsu has listed affected motherboards, desktops, laptops, workstations and servers in a PDF document, along with expected patch release dates for each of them. Updates are already available for some models.
HPE has released firmware patches for its ProLiant Gen10, ProLiant DL20 Gen9 and the ProLiant ML30 Gen9 server products.
“For Gen10 systems, in addition to the ROM, IE, and SPS firmware updates, a System Recovery Set update is required after updating to these firmware versions, in order to maintain proper Secure Start protection,” the company said in a support document.
Panasonic has also identified some affected rugged business laptops and is working on determining if other devices are affected. The company plans to release patches in late January.
Intel expects to release firmware updates in December for its NUC small-factor PCs, boards and kits, as well as for its Compute Stick and Compute Board platforms.
Searching for and deploying updates for these vulnerabilities will require a lot of effort from both businesses and consumers so many systems are likely to never be patched, especially since installing BIOS/UEFI patches on PCs is not exactly straight-forward. On top of that, many of the affected systems have probably reached end-of-support and will never receive firmware updates from manufacturers.
The flaws and their wide-ranging impact are likely to reopen the debate in the technical community about the security risks associated with Intel ME. While the technology makes the administration of laptops, workstations and servers easier in enterprise environments, vulnerabilities in its code could be exploited to install virtually undetectable rootkits. Because the ME subsystem cannot be disabled by users, some security experts have compared it to a backdoor.
Newly Patched Samba Flaw Is a Reminder to Stop Using SMB1
The Samba Project fixed two vulnerabilities this week, including one that could allow attackers to compromise servers that accept SMB version 1 connections. The flaw should serve as a reminder that this old and outdated version of the protocol should really disappear from corporate networks.
Samba is an implementation of the Server Message Block (SMB) network file-sharing protocol that’s widely used on Linux systems. Microsoft has its own SMB implementation in Windows, which it sometimes calls the Common Internet File System (CIFS).
The SMB protocol is decades old, being created in 1983 at IBM, and is currently at version 3. However, recent scans have shown that SMBv1 is still widely used on corporate networks, which poses serious security risks.
Leaving aside the fact that SMBv1 doesn’t support encryption or other modern security features, the code that implements it is very old, both in Samba and Windows. This means it hasn’t been written following modern secure programming guidelines and is likely full of serious security vulnerabilities.
The WannaCry and NotPetya ransomware worms that caused hundreds of millions of dollars to multinational companies and infrastructure providers this year spread using two SMBv1 exploits that affected Windows: EternalBlue and EternalRomance. And these were not the only critical SMBv1 discovered over the years.
Microsoft has been actively trying to get companies to stop using SMBv1 on their networks and the Samba Project recommends the same. Its workaround for dealing with this flaw is to turn off SMBv1 access to the server by adding “server min protocol = SMB2” to the [global] section of the smb.conf and restarting smbd.