
ThinkPwn: System Management Mode arbitrary code execution - edmorley
https://github.com/Cr4sh/ThinkPwn
======
fencepost
Don't just plaster Lenovo with this - they're getting the splatter because
Cr4sh has been researching their firmware, but this is a multi-vendor issue.

A few important notes from the article and the releaser's blog post:

* This is not a Lenovo problem so much as a problem for multiple vendors who used BIOS based on Intel's reference information. The original problem was with source code provided by Intel. The same problem is confirmed to exist in at least one HP system.

* This was apparently fixed back in 2014, but there doesn't seem to be an indication that it was recognized as a security flaw then or at least it wasn't noted as a security fix. 2014 isn't that long ago in terms of propagating BIOS updates.

* Cr4sh apparently decided to just release, "I decided to do the full disclosure because the main goal of my UEFI series articles is to share the knowledge, not to make vendors and their users happy."

* His assessment is "It’s very unlikely that this vulnerability will be exploited in the wild, for regular customers there are much more chances to be killed with the lightning strike than meet any System Management Mode exploit or malware."

~~~
CaptSpify
Although you are correct, I don't feel it's bad to blame the vendor who was
running code that they didn't know the source of, nor the reasoning behind
it's existence.

~~~
kuschku
So, literally every vendor? Can you think of a single example of a vendor not
running UEFI code from others, not running either Qualcomm's kernels for ARM
chips, nor distributing Intel's ME firmaware, nor distributing AMD's TPM
firmware?

I don't think there's a single OEM that knows what they're actually running –
if there is, SAMSUNG would likely be it, because they have a chance at
actually doing everything in-house.

~~~
skykooler
Probably Apple, too - they prefer to implement things in-house wherever
possible.

~~~
yuhong
Apple now ships UEFI updates with every version of OS X.

~~~
weeks
Does Apple use UEFI now? Everything I've read suggests Apple forked at EFI
1.10 and never looked back.

~~~
yuhong
They would have to in order to boot later versions of Windows using UEFI.

------
jsjohns2
Quite the hilarious "security advisory" [0] that Lenovo put out. They manage
to take zero responsibility, shift blame to the researcher/IBV/Intel, and
admit that they ship SMM code of both unknown author and purpose.

[0]
[https://support.lenovo.com/us/en/solutions/LEN-8324](https://support.lenovo.com/us/en/solutions/LEN-8324)

~~~
kuschku
> and admit that they ship code of both unknown author and purpose.

That's literally what every vendor does nowadays. Do you think LG can get the
code for the firmware of the SoCs they use in their phones? Do you think the
coreboot guys can get the source for the Intel Management Engine firmware? Do
you think any of the firmware in your system comes from your OEM and is
secure?

This is a failure in the entire industry, and it's getting worse every day.

The proper solution would be simple, too: Allow everything to be flashed with
custom software, but allow the user to set a cryptographic key with which
updates have to be signed. By default, the system could accept the OEM key,
the user could lock it further down.

Provides additional security for corporations and nerds, provides additional
flexibility, provides the ability to modify the firmware.

~~~
jsjohns2
> Do you think any of the firmware in your system comes from your OEM and is
> secure?

No, of course not. But I'm surprised that Lenovo would tacitly admit this.

~~~
josteink
To be honest this has been going on ever since the first day random OEMs
started shipping X86-based machines. There's really nothing to admit.

Back then we had Amibios, Pheonix bios etc etc, but these days we call it
"UEFI" and "firmware" and everyone gets up in arms about it.

------
cdubzzz
Interesting bit form Lenovo's security advisory on the matter[0]:

> Shortly after the researcher stated over social media that he would disclose
> a BIOS-level vulnerability in Lenovo products, Lenovo PSIRT made several
> unsuccessful attempts to collaborate with the researcher in advance of his
> publication of this information.

[0]
[https://support.lenovo.com/us/en/solutions/LEN-8324](https://support.lenovo.com/us/en/solutions/LEN-8324)

~~~
geocar
Clear as mud.

Lenovo has previously sacrificed user security and privacy for money
(superfish), so it does not surprise me that they have done it again, and
these kinds of weasel words aren't going to get me to buy another Lenovo
product again.

Here's an idea: How about not putting backdoors in our products?

How about making it easier for consumers to replace software on systems they
own?

~~~
snuxoll
Lenovo has always maintained a higher standard for their Think products,
Superfish was only an issue on the Idea line. Doesn't excuse the debacle, but
ThinkPad's are their professional line of notebooks and they make every effort
to keep a positive image.

~~~
AdmiralAsshat
Lenovo only maintained the "standard" for their ThinkPads because it was an
explicit condition of IBM when they sold the ThinkPad line to Lenovo.

~~~
Daishiman
The sale happened ten years ago and it is extremely unlikely that there are
any contractual obligations for this anymore. Let's put this meme to rest;
Lenovo has been building solid Thinkpads.

~~~
mkoryak
what?! since when? I every single thinkpad I bought since my T43P has been a
total piece of shit in comparison.

Methinks you have never owned an IBM Thinkpad to make that statement.

~~~
Daishiman
I have used _exclusively_ Thinkpads since 1997.

The one I bought in 1999 broke through a cracked screen when a pencil got
wedged between the frame and the screen because the hinges were not as strong
as those today.

The T42, T43 and T60 series were absolutely incredible for their times but
were now without fault; even back then they screen bezel was huge and you had
to pay unreasonable money to get a screen with a higher resolution than
1024x800.

My Z60 was a fantastic machine that I ended up giving away. Its battery life,
however, will not be missed.

My last T420 has an assembly that flexed far more than I liked and buttons
whose pretty uniform black wore out with use, but I still keep it in the
closet because it's indestructible. It's ugly as sin though.

I have my minor disagreements with the keyboard design of the X250, but the
trackpad is _great_ , the screens have actually usable brightness now with
their default configuration, and battery life has gone way, way, _way_ up.

Let's not look at the past with rose-colored glasses. Every one of those
machines had a minor issue as far a Linux compatibility (always different),
but back then it was a pain in the ass to get the WiFi working, whereas now if
anything I might have a complaint about default keyboard bindings. Things
change, but at no point in all that time did I have to send any of those
machines for repairs (save for the Z60's fan getting clogged with dirt and
some random memory module that died).

People get enamored with their machines and their particular quirks, but I
much prefer the new, thinner machines. The tradeoffs are tradeoffs, and the
defects are just different. Hell I even prefer the new chiclet keys over the
old keys.

The _only_ thing I can say is different is that the frame of the newer
machines flexes more. That is not a defect; a frame that flexes is far more
resistant to falls and impact. All of my machines have fallen off chairs at
some point; all of them survived intact.

------
bsilvereagle
> Vulnerable code of SystemSmmRuntimeRt UEFI driver was copy-pasted by Lenovo
> from Intel reference code for 8-series chipsets.

> Alex James found vulnerable code on motherboards from GIGABYTE (Z68-UD3H,
> Z77X-UD5H, Z87MX-D3H, Z97-D3H and many others):

This is beyond the scope of just Lenovo machines.

~~~
pwnna
As confirmed by Lenovo as well:

> The package of code with the SMM vulnerability was developed on top of a
> common code base provided to the IBV by Intel. Importantly, because Lenovo
> did not develop the vulnerable SMM code and is still in the process of
> determining the identity of the original author, it does not know its
> originally intended purpose. But, as part of the ongoing investigation,
> Lenovo is engaging all of its IBVs as well as Intel to identify or rule out
> any additional instances of the vulnerability's presence in the BIOS
> provided to Lenovo by other IBVs, as well as the original purpose of the
> vulnerable code.

[https://support.lenovo.com/ca/en/solutions/LEN-8324](https://support.lenovo.com/ca/en/solutions/LEN-8324)

------
excelangue
Starting with the X230 series of ThinkPads, Lenovo has used flash write
protection to prevent "unauthorized" BIOS modifications. Owners of X220
laptops and below are able to reflash the BIOS to remove Lenovo's whitelist of
WLAN/WWAN cards; the X230 models are currently stuck with Wi-Fi N and Gobi
3000 3G-only cards due to Lenovo's whitelist. Would this exploit allow
ThinkPad owners to reflash their BIOS chip without desoldering and flashing
with external hardware?

~~~
big_youth
My coworker replaced his BIOS/UEFI with an open source version (thinkpads
enable this). It allowed him bypass Lenovo’s whitelisting of “approved”
hardware, so he could install his own 3g modem.

He repurposed an old Arduino into an SPI flasher and a chip clip to sit on the
bios flash chip.

[https://twitter.com/thomas_cannon/status/703633676102471680](https://twitter.com/thomas_cannon/status/703633676102471680)

~~~
zxexz
Is the open source version you speak of Libreboot? That's the only open source
BIOS replacement I know for any thinkpads. That Thinkpad looks a bit new for
full-fledged librebooting! Did he have to reflash the ME firmware back on?

------
quotemstr
I wish we could even purchase machines without SMM, Intel Management Engine,
and similar features. On any machine I own, I want the CPU and the software
running in ring zero to be the last word on what happens. I don't think it's
unreasonable to ask for a system that meets this requirement.

~~~
dandelion_lover
As I commented elsewhere, we can, see
[https://news.ycombinator.com/item?id=12037410](https://news.ycombinator.com/item?id=12037410)

~~~
driverdan
Old, outdated, expensive hardware with low specs? Nope. I have a lot of
respect for what they do but it's not the solution we need.

~~~
comex
An alternative is to use ARM-based devices: they typically lack microcode
updates, and while TrustZone hypervisors are often present and the situation
varies by device, at least some devices should allow the user to gain full
control of the CPU without having to exploit anything. (I don't know how
common that is, because every device manufacturer has their own boot process,
and from some quick Google searching it seems like most of the time nobody
bothers to figure out how the TrustZone stuff or the boot chain works, being
satisfied with custom Android images...)

ARM Chromebooks in particular I think are theoretically supposed to have fully
open source firmware, though the documentation is a little sparse... probably
mostly for the same reason, lack of interest.

~~~
makomk
As far as I know anything Allwinner-based lets you run whatever you like with
full control of the CPU, probably the same with other Chinese ARM SoCs but
there seems to be more of an open source community around Allwinner for some
reason. (The other main alternative is Rockchip.)

------
acd
Joanna Rutkowska has written about Intel based products that are possibly
vulnerable to the Intel management engine code. Even if you run an open source
operating system such as Linux or FreeBSD, there is still proprietary code in
the management engine that you cannot look or verify that its secure.

Here is the paper
[http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf](http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf)

UEFI is another gigantic hide point for malware.

I think one could possibly run more simple platforms such as Raspberry PI,
Odroid which may not have embedded management engines. That should be more
secure than x86 platforms.

~~~
0x0
Even the raspberry pi ARM cpu is slave to the VideoCore GPU, as the GPU (and
its corresponding binary blob) is what initializes first on powerup and only
later does it boot up the ARM CPU.

~~~
voltagex_
The situation is better than what it was - [https://github.com/christinaa/rpi-
open-firmware](https://github.com/christinaa/rpi-open-firmware)

------
flurpitude
Also found in an HP DV7 4087CL from 2010:
[https://twitter.com/al3xtjames/status/749063556486791168/pho...](https://twitter.com/al3xtjames/status/749063556486791168/photo/1)

------
gvb
This should be good news for people looking to getting rid of Computrace,
effectively a rootkit, from surplus Thinkpads.

[http://forum.thinkpads.com/viewtopic.php?t=114641](http://forum.thinkpads.com/viewtopic.php?t=114641)

Yes, I bought a surplus Thinkpad (T61) and found it had Computrace activated
on it. Grrrr.

Yes, I could call the Absolute(R) Software number and they should disable it
for me. I have not been willing to sit on hold and jump their hoops to date.
Since I run linux on the laptop, is fairly low risk for me, but Absolute(R)
Software could inadvertently or intentionally "brick" my laptop. Grrrr.

~~~
throwaway7767
AFAIK all the ThinkPads have a BIOS option to disable CompuTrace. Mine has
three options: "Enabled", "Disabled" (default option) and "Permanently
disabled".

The "permanently disabled" option erases the CompuTrace blob from the flash
chip, so it cannot be re-enabled afterwards.

This may not be the case for their non-business machines (i.e., not ThinkPad).

------
jkldotio
What are we up to now? Three preloaded spyware scandals, possible remote
execution via the Intel stack and now this vulnerability. That's just what we
know about, who knows what else exists. I don't think I can buy another one,
which is sad as I think it was a timeless and great design.

~~~
esaym
I plan on using my quad core T520 for probably another 5+ years. All of their
laptops after the T520 series have the full size keyboard with numberpad which
off-sets the center of the keyboard, so now your typing is mostly happing on
the left side of the keyboard and that causes wrist strain.

Having a numberpad is really lame on a laptop. I won't buy one and I know of
no one else that likes the numberpad either.. sadly many manufactures are
doing the same.

~~~
ovrdrv3
Wow this was actually going to be a major buying factor in my next Laptop, was
really considering a gaming laptop for the numpad but I guess it wouldn't be
too difficult to buy a bluetooth numpad for the right side of the keyboard/get
used to the numbers above the keyboard. Thanks for this angle. Never
considered wrist strain.

------
jonwachob91
T450S user here. What exactly does this mean for me? I get it's a security
issue, but that's about all I understood...

~~~
ihsw
The attack against you would be interdiction, where the NSA (or whomever)
would MITM shipping and receiving.

What shipping and receiving? Somewhere between where you will receive the
package -- be it your home, PO Box, postal office, etc -- and the originating
storage facility (ie: warehouse), there is a long list of hands exchanging
your product. One of these hands would be an NSA agent's hands.

[https://en.wikipedia.org/wiki/Interdiction](https://en.wikipedia.org/wiki/Interdiction)

Who is targeted? In all likelihood, businesses, but I'm sure individuals are
targeted as well.

The attack requires physical access to the hardware.

And just to be clear -- it's not just Lenovo products. The net seems to have
been cast much wider and other devices seem to be affected (HP laptops,
desktop motherboards).

~~~
mindslight
I'm sure the NSA has other ways of bypassing security of the proprietary
firmware (likely even through the front door), so this single exploit doesn't
really add to that threat.

What it hopefully does do is cast a little ray of light on this suite of user-
hostile firmware, helping us expunge this long present software muck that, for
example, allows such interdiction attacks to be so easy.

------
mdip
I've always liked the build quality of the ThinkPad series though it's been a
few years since I've put my hands on one. That said, it looks like they need
to spend similar attention on the software. On the flip side, though, I wonder
if this solves the issue with the Yoga laptops I read about recently where the
user could not disable SecureBoot in order to install the operating system of
their choice.

It's a little sad to be excited about a vulnerability because it might provide
an opportunity for a consumer open up the products they rightfully purchased.

~~~
happyslobro
I'm running Ubuntu on a Yoga 2 Pro, I hadn't heard about that issue. Either
the exploit is now a transparent part of the Ubuntu installer, or it doesn't
affect the Yoga 2.

~~~
mdip
I guess I could have provided context in that comment. :o)

Here's the story I was referring to:

[https://globalvoices.org/2016/06/16/in-defense-of-free-
softw...](https://globalvoices.org/2016/06/16/in-defense-of-free-software-my-
case-against-lenovo-in-mexico/)

And the HN thread:

[https://news.ycombinator.com/item?id=12027574](https://news.ycombinator.com/item?id=12027574)

------
shmel
Cool. Now Lenovo admits they have no idea whose this code is and what it is
supposed to do. It sounds like a shitty excuse of junior programmer: "Hey man,
not my fault! I have just copy-pasted that snippet from StackOverflow!"

------
kriro
So this is traceable to the Intel reference implementation. I am going to
assume incompetence but let's say I would assume malice instead (some
government agent wrote the reference spec full well knowing it's exploitable
with or without the knowledge of Intel) how would one go about soft-proving
that?

Compare machines that are vulnerable in the wild and same spec machines from
important people at Intel and/or suspected government agency (assuming they'd
simply use a non-vulnerable version instead of some completely different
hardware)?

------
OneTwoFree
I thought I have an intermediate level C knowledge, but I have no idea what is
happening in the vulnerable line:

    
    
        *(v3 + 0x8)(*(VOID **)v3, &dword_AD002290, CommunicationBuffer + 0x18);
    

As I understand it is (was) an example code from Intel. Example codes should
be easy to understand and well documented.

~~~
loeg
It's C generated by disassembling x86 assembler code. It is _not_ an example
code from Intel.

The function pointer at `v3 + 0x8` is invoked with arguments: (1) the pointer
at `v3 + 0x0`, (2) some fixed pointer, and (3) a pointer into the
CommunicationBuffer.

E.g. here's more idiomatic C code to represent the same idea:

    
    
        struct Thunk {
          void *argument;
          void (fp)(void *, DWORD *, void *);
        };
        struct CommunicationBuffer {
          uint64_t unknown[4];
          struct Thunk *thunk;
          ...;
        };
    
        EFI_STATUS __fastcall sub_AD3AFA54(
            EFI_HANDLE SmmImageHandle, VOID *CommunicationBuffer, UINTN *SourceSize)
        {
          struct CommunicationBuffer *cb = CommunicationBuffer;
          if (cb->thunk) {
            cb->thunk->fp(cb->thunk->argument, &dword, &cb->unknown[3]);
            cb->thunk = NULL;
          }
          return 0;
        }

~~~
tinco
What idiomatic C code uses thunks? Is this an interpreter/runtime for a
functional language or something? Or do some optimizers introduce thunks?

~~~
loeg
`qsort_r(3)` in libc, for example. It's not uncommon in idiomatic C code.

------
hoodoof
OK so what can be done to prevent this being an issue on my machine?

------
rikkus
Really hope Lenovo respond soon. Feel like I should leave my ThinkPads
hibernated for now.

~~~
shimon
I think this exploit requires local administrative access. If an attacker
already has this, you're pretty screwed to begin with.

In other words, while this could definitely make an attack more damaging and
harder to remove, it doesn't seem like a reason to stop using a computer that
has decent software and physical security.

~~~
bsilvereagle
This exploit just requires physical, not administrative, access to the
machine. You build an EFI "app", put it on a flash drive, and execute it from
the UEFI shell.

~~~
revelation
Well, physical access ranks higher than administrative. If an attacker has
physical access, no system is secure, if only because the _interface_ to the
system is no longer.

~~~
45h34jh53k4j
its not longer fair to call game over with physical access;

indeed countermeasure like full disk encryption, computrace and Mac firmware
passwords are all examples of things we do to raise the difficulty for a
physical attacker.

~~~
revelation
And the vast majority of them is trivially defeated by a bug inline with your
USB keyboard.

~~~
startling
You can reconstruct a lot of information with a keylogger but nowhere near all
of it.

