A race condition vulnerability was reported in IMController, a software component of Lenovo System Interface Foundation, prior to version 1.1.20.3 that could allow a local attacker to connect and interact with the IMController child process' named pipe.

**About Lenovo**

*   Our Company
*   News
*   Investor Relations
*   Sustainability
*   Product Compliance
*   Product Security
*   Lenovo Open Source
*   Legal Information
*   Jobs at Lenovo

**Shop**

*   Laptops & Ultrabooks
*   Tablets
*   Desktops & All-in-Ones
*   Workstations
*   Accessories & Software
*   Servers
*   Storage
*   Networking
*   Laptop Deals
*   Outlet

**Support**

*   Drivers & Software
*   How To's
*   Warranty Lookup
*   Parts Lookup
*   Contact Us
*   Repair Status Check
*   Imaging & Security Resources

**Resources**

*   Where to Buy
*   Shopping Help
*   Sales Order Status
*   Product Specifications (PSREF)
*   Forums
*   Registration
*   Product Accessibility
*   Environmental Information
*   Gaming Community
*   LenovoEDU Community
*   LenovoPRO Community

© Lenovo.  
| | |

CVE-2021-3922: Lenovo Vantage Component Vulnerabilities - Lenovo Support DE

A buffer overflow vulnerability in Lenovo Smart Standby Driver prior to version 4.1.50.0 could allow a local attacker to cause denial of service.

CVE-2022-1110: Lenovo Smart Standby Driver Vulnerability - Lenovo Support DE

An information disclosure vulnerability was reported in some Lenovo Personal Cloud Storage devices that could allow an unauthenticated user to retrieve device and networking details.

 1548 |  198

感谢您的青睐，以下知识也很棒哦

联想网站提供的技术方案或与您产品的实际情况有所差异，您需在完整阅读方案并知晓其提示风险的情况下谨慎操作，避免造成任何损失。

CVE-2021-42848: 联想中国(Lenovo China)联想知识库

The supply chain for firmware development is vast, convoluted, and growing out of control: patching security vulnerabilities can take up to two years. For cybercriminals, it's a veritable playground.

BLACK HAT ASIA 2022 — When it comes to developing the firmware that powers computing devices, the ecosystem consists of complex supply chains that have multiple contributors. For any given device, firmware could be made up of a hodgepodge of components from different sources. And that means that when it's time to address security vulnerabilities, it's far from a straightforward process to get a patch out to the public.

During a panel-discussion session at Black Hat Asia on Thursday, entitled "The Firmware Supply-Chain Security Is Broken: Can We Fix It?", Kai Michaelis, co-founder and CTO at Immune GmbH, outlined what he called the overgrown supply-chain "tree," out of which grows onerous code reviews, and lengthy patching processes when a bug is found.

In fact, six to nine months for patches to roll out is the average, according to the panelists — with two years being not uncommon. And that means the supply chain represents a wide attack surface that's ripe for compromise, they warned. Given that vulnerable firmware threatens safety of the operating system and any applications, the potential for cyberattackers to find exploitable vulnerabilities is a serious concern.

**A Thorny Tree of Supply-Chain Complexity**

The final firmware that vendors incorporate into their hardware is a multisourced affair, explained Michaelis. Stakeholders can include various component vendors, a few open source repositories, reference implementations, original design manufacturers, independent BIOS vendors, and finally, the original equipment manufacturers (OEMs) that create and sell the final product to channel partners and end users.

Further complicating matters is the fact that subsystem vendors might be sitting in the middle of the code tree, itself combining elements from multiple component manufacturers into a single offering.

The unfortunate end result is that when a vulnerability is reported, OEMs often have multiple "branches" from which patches and updates flow — and they usually have no visibility to each other.

"It's a tree of suppliers and updates with little coordination between them, and the OEM has to ingest all of it," Michaelis said. "For vendors, packaging updates is a fairly manual process, and then consumers need to actually install those updates. In all, the patching process as it stands can be measured in months to years."

One of the main issues that Michaelis flagged is the fact that when bugs are found, they may be benign in and of themselves. However, when combined with additional vulns in other parts of the firmware, the flaws become weaponizable and could allow attacks on value-added reseller (VAR) partners — and from there, end users.

"Convincing a vendor to patch what it believes is a harmless flaw is not easy," he said. "And even if there is a patch, it takes so long for it to get downstream that an attacker could easily find another vulnerability to combine with it in the meantime. So this is the problem: Bugs exist in isolation because vendors don't talk to each other, and bugs have a long shelf life."

There are at least three other aspects that make matters even worse: One, end-of-life (EoL) devices often don't get updates; two, each vendor follows its own patch cycle; and three, sometimes vendors offer silent updates without issuing an advisory, which can discourage OEMs from incorporating patches.

**Repeating the Same Mistakes**

Alex Matrosov, founder and CEO at Binarly, explained during the panel that like in the software supply chain, firmware bugs can also be spread and re-imported even after they've been patched, resulting in what he called "repeatable failures."

For instance, a bug recently disclosed in one of the components in the Intel M15 laptop kit (CVE-2022-27493) is a classic out-of-bounds write flaw stemming from system-management mode (SMM) memory corruption — but not as what it seems.

"It's actually a 2019 bug found in the AMI codebase that we've now discovered in 2022 firmware," Matrosov explained. "This vulnerability was fixed, but the fixed version was not included by the device vendor. It's a very vulnerable component and has been known for years as a suitable attack vector, and it should be removed."

In another example, vulnerable code in an EDK open source library called SecurityPkg was removed in EDK II in 2018. However, somehow it found its way into 2022 firmware affecting several OEMs, via another library. "The risk was exponentially compiled," Matrosov said.

**Best Principles for Pruning Back the Patching Misery**

So, what's to be done? According to the panel, it will take a profound shift in strategy and thinking to reliably shore up firmware security. However, a good place to start is an aspirational list of first principles.

The panelists advocated, for instance, that OEMs and members of the security community as a whole make a concerted effort to educate component vendors and other supply-chain elements about security and convince them that updates are a necessity, even for EoL devices — and that further, if they don't issue a CVE, it becomes more difficult to communicate the urgency to patch and the bugs become difficult to track.

OEMs also should put in place efforts to increase risk transparency, according to the panel. This can be done by facilitating greater communication between vendors and creating a centralized repository of information about patches and bugs.

"Fixing the supply chain is a team sport," Matrosov said, noting that working with computer emergency response teams (CERTs) is a good goal.

"We really need an independent body to help coordinate patches when they affect multiple vendors, and to facilitate simultaneous patching. If one vendor patches and another doesn't, it creates a dangerous zero-day situation for a subset of the devices," he added.

Private security community collaboration will also be key, the panelists said. For instance, the Linux Foundation has launched a website called LVFS, which is a vendor firmware service that allows OEMs to upload firmware updates to be distributed to Linux users at zero cost. So far, about 150 vendors are participating, including Dell, HP, Intel, and Lenovo.

"There are about 1,000 different devices supported, and we've shipped more than 51 million updates since we started the project," said panelist Richard Hughes, principal engineer at Red Hat. "Also, we can take the firmware and decompress it into shards. A shard might be an EFI, binary, Intel microcodes, AMD PSP image, etc. So, all of those vendors uploading all those updates gives us a huge amount of data."

From there, the system can show users, say, the newest available Intel microcode for all of the different models in the system — and can push updates automatically.

There's plenty to be done, but Hughes struck an optimistic note.

"My personal conclusion is that by working together with CERTs and security companies, we can improve the immune system even further, speeding up the process of shipping fixes to end users and making sure that security issues patched by all vendors," Hughes said. "These are really hard problems that have plagued the entire industry for 20 years. Only now do we have all the infrastructure and the data to make things better."

Black Hat Asia: Firmware Supply-Chain Woes Plague Device Security

A potential vulnerability in the SMI callback function used in the NVME driver in some Lenovo Desktop, ThinkStation, and ThinkEdge models may allow an attacker with local access and elevated privileges to execute arbitrary code.

CVE-2021-4210: Multi-vendor BIOS Security Vulnerabilities (February 2022) - Lenovo Support DE

An authentication bypass vulnerability was discovered in an internal service of the Lenovo Fan Power Controller2 (FPC2) and Lenovo System Management Module (SMM) firmware during an that could allow an unauthenticated attacker to execute commands on the SMM and FPC2. SMM2 is not affected.

CVE-2021-3897: Authentication Bypass Vulnerabilities in FPC2 and SMM Firmware - Lenovo Support DE

Three flaws present in consumer laptops can give attackers a way to drop highly persistent malware capable of evading methods to remove it, security vendor says.

**_\[Editor's Note: This article was updated on 4/20/2022 at 12:28pmET with comments from Lenovo\]_**

More than 100 different Lenovo consumer laptop computers, used by millions of people worldwide, contain firmware-level vulnerabilities that give attackers a way to drop malware that can persist on a system even after a hard-drive replacement or operating system re-install.

Two of the vulnerabilities (CVE-2021-3971 and CVE-2021-3972) involve Unified Extensible Firmware Interface (UEFI) drivers that were meant for use only during the manufacturing process but inadvertently ended up being part of the BIOS image that shipped with the computers. The third (CVE-2021-3970) is a memory corruption bug in a function for detecting and logging system errors.

ESET discovered the vulnerabilities and reported them to Lenovo in October 2021. The hardware maker this week released BIOS updates addressing the flaws in all impacted models. However, users will have to install the updates manually unless they have Lenovo's automated tools to assist with the update.

UEFI firmware ensures system security and integrity when a computer is booting up. The firmware contains information that the computer implicitly trusts and uses while it boots up. So, any malicious code embedded in the firmware would execute before the computer even boots up and before security tools have had a chance to inspect the system for potential threats and vulnerabilities.

In recent years, a handful of malware tools have emerged that were designed to modify UEFI firmware to install malware during the supposedly secure boot-up process. One example is LoJax, a highly persistent firmware-level rootkit that ESET and others observed being deployed as part of a broader malware campaign by Russia's Sednit group. Another example is MoonBounce, a firmware level malware dropper that researchers from Kaspersky recently observed being used as part of a cyber espionage campaign.

Martin Smolár, malware analyst at ESET, says the two Lenovo drivers that were mistakenly included in the production BIOS without being properly deactivated give attackers a way to deploy similar malware on vulnerable Lenovo consumer devices.

"Exploitation of these vulnerabilities would allow attackers to directly disable crucial system security protections," Smolár says. Attackers with privileged access on a vulnerable system can simply activate the old firmware drivers and use them to turn off protections such as BIOS control register bits, protected range registers, and UEFI Secure Boot that prevent privileged users from making changes to system firmware. As a result, exploitation of these vulnerabilities would allow attackers to flash or modify firmware and execute malicious code, he says.

Meanwhile, CVE-2021-3970, the third vulnerability that ESET researchers discovered, allows arbitrary reads and writes from and into System Management RAM (SM RAM) — or memory that stores code with system management privileges. This gives attackers an opportunity to execute code with system management privileges on vulnerable systems, ESET said.

In an emailed statement, Lenovo thanked ESET for alerting the company about the vulnerabilities. "The drivers have been fixed, and customers who update as described in the Lenovo advisory are protected," the statement said. "Lenovo welcomes collaboration with BIOS researchers as we increase our investments in BIOS security to ensure our products continue to meet or exceed industry standards." 

The company's advisory described the flaws as being of medium severity and enabling privilege escalation for attackers that exploited them. The company said CVE-2021-3970 resulted from insufficient validation in some Lenovo models. Lenovo attributed the other two vulnerabilities to its failure to deactivate and remove drivers that were used in older manufacturing processes.

The advisory also includes instructions on where users with impacted devices can find the appropriate BIOS update and how they should install it.

Millions of Lenovo Laptops Contain Firmware-Level Vulnerabilities

A use-after-free flaw was found in the Linux kernel’s Bluetooth subsystem in the way user calls connect to the socket and disconnect simultaneously due to a race condition. This flaw allows a user to crash the system or escalate their privileges. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.

CVE-2021-3752: [PATCH 5.15 187/917] Bluetooth: fix use-after-free error in lock_sock_nested()

A password mismanagement situation exists in XoruX LPAR2RRD and STOR2RRD before 7.30 because cleartext information is present in HTML password input fields in the device properties. (Viewing the passwords requires configuring a web browser to display HTML password input fields.)

Announcements

**7.30****Support for new storage systems**

*   Dell EMC² PowerStore
*   IBM Spectrum Scale (GPFS)
*   Infinidat InfiniGuard
*   Microsoft Storage Spaces Direct

**Further enhancements**

*   HPE Primera, 3PAR: reimplemented using REST API instead of 3PAR CLI
*   HPE Primera, 3PAR: added detailed capacity for Tier, Pool, Volume and Disk
*   Hitachi VSP G/E/F HUS-VM: support for Hitachi Configuration Manager as a replacement for the Hitachi CCI and storage REST API
*   DataCore Server Group: automatic switch to active server in case of failure
*   SAN switch: added PCS error metric
*   Dell EMC Isilon: quota monitoring GUI ➡ STORAGE ➡ <storage alias> ➡ Configuration ➡ (tab Quota)
*   Security fixes
    *   CVE-2021-42372: Input field SNMP community string in "UI ➡ Alerting ➡ Options HW event" was not properly handled what could lead to remote command injection
    *   CVE-2021-42371: Docker does not contain hardcoded password for lpar2rrd user
    *   CVE-2021-42370: The UI does not contain plain password in HTML "password" input fields in the device properties

Announcement list

Use this form to sign up for new STOR2RRD announcements, upgrade and service emails.

CVE-2021-42370: Storage Monitoring EMC² IBM Hitachi HPE NetApp Lenovo

An issue was discovered in the Linux kernel before 5.0.19. The XFRM subsystem has a use-after-free, related to an xfrm_state_fini panic, aka CID-dbb2483b2a46.

Tag

#lenovo