Lenovo XClarity

Apparently Lenovo’s XClarity Administrator software uses the Redfish API:

“Lenovo XClarity is a fast, flexible, and scalable hardware systems management application that enables administrators to deploy infrastructure faster and with less effort. This video provides a brief overview of XClarity Administrator, VMware Integration, the XClarity Mobile App, and new features supporting extended management of storage and network switches.”

Here’s a Lenovo video showing the tech:

Lenovo BIOS to UEFI


“Lenovo BIOS to UEFI TS Converter with CG/DG Prep: Allows you to configure SecureBoot/UEFI settings, as well as Virtualization Technology and TPM for Credential Guard and Device Guard. This script is designed to work on both ThinkPad and ThinkCentre machines. This script connects to the WMI instances for Lenovo machines, and then configures the requested settings. This script is designed to be used as part of a task sequence where you want to convert from legacy BIOS to UEFI and at the same time prepare the machine for Credential Guard and Device Guard.”

New UEFI RNG tool

Finnbarr P. Murphy has a new UEFI tool that checks your firmware for RNGs, and it sounds like he’s found some Lenovo Thinkpad errors with it:

[…] Here is a small UEFI shell utility that checks your firmware for available RNGs: […] I built the utility on a 64-bit Fedora 24 platform using GCC and UDK2015. I have not tried building a 32-bit utility nor have I build it using Visual Studio or other development frameworks – so do not be surprised if you have modify either the code or the build recipe in these cases. I tested the utility on a Lenovo T450 using firmware version JBET60WW (1.24) and was surprised to find that the firmware did not appear to support any RNGs as evidenced by the zero RNG algorithm count returned. However, by explicitly, testing for the default RNG if the count was zero, it was possible to determine that the T450 did in fact at least support the default RNG. Perhaps, I am not parsing the UEFI specification correctly but I would expect the RNG count returned by GetInfo to include the default RNG. Interestingly, when I build and load the UDK2015 test RNG DXE driver which contains a reference counter mode DRBG (Deterministic Random Bit Generator) conforming to NIST SP 800-90a, the algorithm count returned by GetInfo jumps to 2. This leads me to suspect that their is a bug in the firmware w.r.t. to the RNG protocol implementation. Please let me know if I am incorrect in my assumptions or observations.


ThinkPwn updated


exploiting Lenovo firmware, part 2D

A bit more on this:

Lenovo has updated their support document. The initial version had no technical details. The update now has a huge list of models which are affected or not. The researcher also mentions that an update from the vendor is expected next month. I’m still waiting to see the IBV’s and other OEMs responses to this.



exploiting Lenovo firmware, part 2C

A bit more on this:

exploiting Lenovo firmware, part 2B

more on this:

Lenovo has a response:

System Management Mode (SMM) BIOS Vulnerability
Lenovo Security Advisory:  LEN-8324
Potential Impact:  Execution of code in SMM by an attacker with local administrative access
Severity:  High
Scope of Impact: Industry-wide


The researcher also has a few responses:


exploiting Lenovo firmware, part 2A

A few bits of news to add to this:


These days, it is nice to know that a firmware bug is probably an accidental defect, rather than some backdoor.  🙂

In 2015, UEFI Forum used to do Security Advisories, with 2 PDFs each containing more than a dozen potential exploits. I wonder how many of those are in today’s vendors codebases? No more advisories from UEFI Forum since 2015, so who knows what other cut-and-paste OEM/IBV bugs are being propogated? I wish UEFI Forum would issue more Security Advisories, multiple bugfixes on the EDK2-devel project appear to merit this kind of attention.

exploiting Lenovo firmware, part 2

Cr4sh has written the second article in his series on Lenovo firmware security research:

Exploring and exploiting Lenovo firmware secrets
Hi, everyone! In this article I will continue to publish my research of Lenovo ThinkPad’s firmware. Previously I shown how to discover and exploit SMM callout vulnerabilities on example of SystemSmmAhciAspiLegacyRt UEFI driver 1day vulnerability. Also, I introduced a small toolkit called fwexpl that provides API for comfortable development of firmware exploits for Windows platform. My previous Lenovo exploit was able to execute custom code in SMM, such conditions allow relatively easy bypass of BIOS_CNTL security mechanism which protect firmware code stored inside SPI flash chip on motherboard from unauthorized modifications by operating system (BIOS_CNTL bypass also was discussed in my another article “Breaking UEFI security with software DMA attacks”). In addition to BIOS_CNTL, modern Lenovo computers also use SPI Protected Ranges (aka PRx) flash write protection, so, in this article I will present my generic exploitation technique that allows to bypass PRx and turn arbitrary SMM code execution vulnerability into the flash write protection bypass exploit. This technique also can be applied to UEFI compatible computers of other manufacturers — they all use similar design of specific firmware features that responsible for platform security. In second part of the article I will present a new 0day vulnerability in Lenovo firmware that allows arbitrary SMM code execution on a wide range of Lenovo models and firmware versions including the most recent ones. Exploitation of this vulnerability may lead to the flash write protection bypass, disabling of UEFI Secure Boot, Virtual Secure Mode and Credential Guard bypass in Windows 10 Enterprise and other evil things. […]


Sogeti ESEC: SMM unchecked pointer vulnerability

[Update: SMM driver dev advice for this from issue is here:



Bruno of Sogeti ESEC Lab has published an interesting paper with an SMM exploit, well-written with lots of background on UEFI and SMM exploits, lots of images/figures and links, definately worth reading:

SMM unchecked pointer vulnerability
Mon 30 May 2016 by Bruno

This article explains the exploitation of an SMM unchecked pointer vulnerability present in several firmwares. As this vulnerability is a memory corruption, it only applies to firmwares including the unpatched vulnerable DXE driver. It first explains the SMM mode and some of its mechanisms, then the reversing of the UEFI driver in which the vulnerability is present, then the exploitation of the vulnerability in it-self and finally a little conclusion about the impact of the vulnerability. […]

This vulnerability was initially found on two different firmwares of different OEM, both of them seem to have a lot in common. Their firmware were based on one version of the EDK implementation by Intel with several new features added. After some research it appears that both were using code provided by American Megatrends Inc. (AMI) . We contacted AMI and the OEM and got quick responses from them. We would like to thank them for working with us, especially Lenovo for coordinating with us. […]

This vulnerability allows to gain code execution in SMM. In the case of both studied firmwares the flash was not protected by the Protected Range (PR) registers, code execution in SMM allows rewriting the flash and potentially the setup of a persistent bootkit.

On January 2016 VirusTotal (VT) began to provide information on firmware images as described in their blog post . We used this for finding firmware which includes the SMIFlash driver. In total we found approximately 900 different firmwares (type:rom) which contains it, 468 of those had different versions, however it is likely that a lot of these firmwares are just different versions of one another. We have gathered the Vendor identification provided by VT for each of those firmware and got approximately 10 different constructors however 84% of the firmwares have AMI as vendor. […]


fwexpl – PC Firmware Exploitation Tool and Library

Dmytro Oleksiuk (aka Cr4sh) has a VERY INTERESTING new firmware tool for Windows

PC firmware exploitation tool and library

Project includes the following components:
 * libfwexpl — Hardware abstraction library for Windows (see include/libfwexpl.h).
 * libdsebypass — Windows x64 DSE bypass exploit based on Secret Net 7.4 0day privileges escalation vulnerability (see include/libdsebypass.h).
 * driver — Kernel mode part of libfwexpl.
 * application — Application that implements System Management Mode code execution exploit for 1day vulnerability in SystemSmmAhciAspiLegacyRt UEFI SMM driver of Lenovo firmware.

  –target <N> — Select known target where <N> is a target number. If –target and –target-addr options are not specified — exploit will use heuristics to find EFI_BOOT_SERVICES structure address that neccessary for SystemSmmAhciAspiLegacyRt driver vulnerability exploitation.
  –target-list — Print all known targets information.
  –target-addr – Use manual address of EFI_BOOT_SERVICES.LocateProtocol field for SystemSmmAhciAspiLegacyRt exploit. This option will be ignored if –target was specified.
  –target-smi – Use manual SMI handler number for SystemSmmAhciAspiLegacyRt exploit. This option will be ignored if –target was specified. If –target-addr was specified without –target-smi — SystemSmmAhciAspiLegacyRt exploit will check all of the possible SMI handlers from 0 to 255.
  –smram-dump — Determinate current SMRAM address and dump it’s contents to file specified by –file option.
  –phys-mem-dump — Full raw physical memory dump into the file specified by –file option.
  –phys-mem-read <addr> — Read physical memory starting from specified address.
  –phys-mem-write <addr> — Write physical memory starting from specified address.
  –length <bytes> — Number of bytes to read or write for –phys-mem-read and –phys-mem-write.  
  –file <path> — Memory dump path to read or write, in case of –phys-mem-read this parameter is optional and when it’s not specified — application will print a hex dump of physical memory to stdout. In case of –smram-dump this parameter is mandatory.
  –exec <addr> — Execute SMM code at specified physical memory address.
  –dse-bypass — Install and exploit Secret Net 7.4 driver to bypass Windows x64 DSE.  
  –test — Run some basic libfwexpl tests.

To learn more about this project please read his blog post, “Exploiting SMM callout vulnerabilities in Lenovo firmware”:


List of UEFI vendors who care about security

Which UEFI vendors care — or at least may care — about security? The list (alphabetically) is shorter than you might expect:

Hewlett Packard Enterprises
HP Inc.
Insyde Software
Intel Corp.
Phoenix Technologies

Nobody else. If your vendor is not listed above, ask them why you should purchase a UEFI-based system from them.

The above list is from the list of vendors who have feedback mechanisms listed on the UEFI Forum’s security contact page.


Thinkpad password bypass hardware

Some friends of mine are gathering up some old IBM Thinkpads from a recycling center, to refurbish them with Libreboot. It reminds me how much fixing end-user problems are like attacking a system. One of the Thinkpads had multiple passwords that had to be bypassed, so it could be used.

There’s a password bypass solution for Thinkpads that involves custom hardware:

“Joe in Australia offers the only Affordable Fully Assembled, Programmed and Tested unlimited use USB based ThinkPad Supervisor Password [SVP] Recovery or Clear Tools in the world.  Joe’s KeyMaker X1 [KMX1] and X2 [KMX2] can Recover or Clear Supervisor Password from all current IBM and Lenovo ThinkPad models with the exception of the SL300 SL400 SL500 G550 T*40 X*40 X1 Carbon (Gen 2) it can do this even if TPM/TCPA/PC8394T/8356908 security has been enabled. SL300 SL400 SL500 G550 T*40 X*40 X1 Carbon (Gen 2) do NOT store Supervisor Password [SVP] in an EEPROM, that is the reason the SVP cannot be recovered in those models from an EEPROM by KMX1 or KMX2.”



Cr4sh on SMM exploits in Lenovo firmware!

Dmytro Oleksiuk aka Cr4sh has a new blog post on SMM exploits on Lenovo firmware! Very well written and detailed, with source code!

Exploiting SMM callout vulnerabilities in Lenovo firmware
Hi, everyone. In this article I’ll continue to publish my research in PC firmware security field. In previous article, “Breaking UEFI security with software DMA attacks”, I’ve shown how to exploit UEFI boot script table vulnerability and get access to the SMRAM using software DMA attack under Linux. This time we will talk about discovering and exploitation of SMI dispatch vulnerabilities in UEFI System Management Mode drivers. For anyone who’s not familiar with architecture of SMM phase firmware code on UEFI based platforms I’ll strongly recommend to read my other article “Building reliable SMM backdoor for UEFI based platforms”, especially the part about communicating with SMM code using software SMI.

SMM vulnerabilities that I will talk about in this article aren’t new. Around one year ago LegbaCore and Intel Security published two works: “How Many Million BIOSes Would you Like to Infect?” and “A New Class of Vulnerabilities in SMI Handlers” correspondingly, they rediscovered some security issues in SMI handlers code that was actually a known problem among PC firmware developers (for example, same attacks was described in Loïc Duflot work “System Management Mode Design and Security Issues” presented six years ago). Nevertheless, researchers were able to find and report a lot of firmware vulnerabilities of this class in products like Lenovo, Dell, HP laptops and many others (CERT VU#631788). To play with these vulnerabilities I got ThinkPad T450s laptop. According to original security advisory by Lenovo (apparently, it has a lack of technical details) — some unspecified SMM callout vulnerabilities were patched in the latest version of it’s firmware and everything that we need to do is just find out and exploit one of these vulns. […]



Matthew Chapman on Lenovo laptop internals

Matthew Chapman has a nice set of blog posts that go into detail about Lenovo internals, including some firmware and ACPI details, all because of a new battery:

Unlocking my Lenovo laptop, parts 1-3

Two months ago, I bought a new battery for my Lenovo laptop (a ThinkPad X230T). I was about to go away on holidays and wanted a battery that could last me through a plane flight; the original battery was by then barely lasting ten minutes. Little did I know that I was about to […]

In part 1, we looked at the communication between a Lenovo Thinkpad X230T laptop and battery, and discovered that there a challenge-response protocol used to authenticate ‘genuine’ Lenovo batteries. On the laptop side, this – and battery communication in general – is implemented in a component known as the embedded controller (EC). […]

In part 2, we discovered that a embedded controller update is performed by uploading a small ‘flasher’ program to the EC. This flasher program is then responsible for programming a new firmware image to the EC’s internal flash memory. However, both the flasher program and part of the firmware image are encrypted: the old (currently running) EC firmware decrypts the flasher program, and the flasher program then decrypts the new firmware update. This creates a bit of a chicken-and-egg problem that prevents discovering the encryption algorithm from firmware update files alone. […]

Blog series:

Linux ACPI to IBM and Lenovo: help!

If you know someone at IBM or Lenovo, the Linux-ACPI community needs more involvement from you, please help.


——– Forwarded Message ——–
Subject:     ibm-acpi developers not responding despite serious bugs and debuggers
Date:     Sat, 30 Jan 2016 13:22:27 +0000
From:     jono <lejono@gmail.com>
To:     Rafael J. Wysocki <rafael@kernel.org>
CC:     ACPI Devel Maling List <linux-acpi@vger.kernel.org>, ibm-acpi-devel@lists.sourceforge.net

Dear Rafael,
Sorry to trouble you, but a number of us are having lots of grief
getting a response from ibm/lenovo regarding acpi bugs in newer models
like the Helix 2. The bugs make these machines difficult to use, and
there are various reports of this on the internet, along with people
willing to debug patches. But it’s impossible to contact anyone on the
ibm-acpi team to help with this. Do you know who we can contact to
help sort these bugs out? Myself and others are polite, fairly tech
savy, and willing to help, so I’m a bit puzzled by the silence from
this team.

The example is the Helix 2, see:

and various repetitions of this…

For more information, see the Linux-ACPI mailing list archives on kernel.org


Using UEFI_boot_script_expl on Lenovos

Dmytro “Cr4sh” Oleksiuk has a conversation on Twitter about using using his CHIPSEC-based exploit module against Lenovo models, noting some firmware vulnerabilities in Lenovo x220/x230 laptops.

Here are 5 tweets, let’s see how the non-deterministic WordPress.com rendering software will show them:

It is nice to hear “The most recent ones looks not vulnerable.” Maybe the Lenovo QA team is improving? 🙂 Looking forward to more research on this, more than just a few Tweets, his research is usually very verbose! Also, he has updated the readme on his update script today:


Microsoft getting tough on Superfish OEMs

Since the days of MS-DOS, OEMs have bundled lots of crap along with their Microsoft OS, and users would always blame Microsoft, not the OEM or IHV or ISV, for the user experience. Since NT was created, there have been tests for OEMs/IHVs, initially to get listed on the Hardware Compatibility List, these days to get certs and more. Now that modern versions of Windows include installer-related binaries in ACPI tables, that can be misused by attackers if OEMs don’t clean up their systems properly (Lenovo, Dell, etc.), Microsoft is increasing their testing of OEM systems bloatware.


I’ve heard one interesting potential feature of the new Microsoft laptop is that it might be the one Windows box doesn’t have OEM bloatware on it. Granted, it’ll have other Microsoft bloatware on it…