ThinkPwn: System Management Mode arbitrary code execution • Hacker News Board

Re: ThinkPwn: System Management Mode arbitrary code execution

#81

Post by loeg » Tue, Jul 05, 2016, 5:04 PM UTC

tinco wrote: post #59

loeg wrote: post #45

Earlier quoted context omitted.

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 { ui…

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

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

Re: ThinkPwn: System Management Mode arbitrary code execution

#82

Post by pierrec » Tue, Jul 05, 2016, 5:06 PM UTC

zxexz wrote: post #53

excelangue wrote: post #11

Earlier quoted context omitted.

On X220 and previous, the whitelist is removed by creating a modified version of the BIOS without the included whitelist, then flashing it to the BIOS chip. Technically, this can still be done on X230, but as it has the flash write disable unless a signed Lenovo image is to be flashed, the user must desolder the BIOS chip and flash it with the modified image using an SPI chip flasher. As this exploit can remove this…

Huh, here[0] is a a tutorial on removing the whitelist for the X230, via desoldering and an SPI flasher. Looking at the images, the chip looks like an SOIC-8. I wonder why they didn't just use a test clip like this one[1]... EDIT: The obvious answer would be that they didn't have one handy and were competent enough that de- and re-soldering the chip was not a big deal. EDIT (again): Also, they wanted to flash a NEW c…

>I wonder why they didn't just use a test clip like this one

Because they tried and it didn't work (third post). It seems to depend on the mobo as well as the programmer you're using, but sometimes SPI programming without removing the chip doesn't work, which has to do with the mobo consuming the power you're supplying to the chip. Some people work around that by supplying separate power but even then it's a crapshot.

Re: ThinkPwn: System Management Mode arbitrary code execution

#83

Post by [deleted] » Tue, Jul 05, 2016, 5:06 PM UTC

jimrandomh wrote: post #63

ssebastianj wrote: post #27

Earlier quoted context omitted.

The author (Dmytro Oleksiuk) tweeted [0]: 'Dear vendors, “give us your 0day vulnerability for free and don’t publish anything” — it’s not a cooperation request'. [0] https://twitter.com/d_olex/status/748806692754714625

His Twitter tagline is: "... aka Cr4sh, unethical hacker". He put "unethical" in his own damn profile, I don't think he deserves the benefit of doubt.

[deleted]

Re: ThinkPwn: System Management Mode arbitrary code execution

#84

Post by skykooler » Tue, Jul 05, 2016, 5:09 PM UTC

mdip wrote: post #25

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 s…

Sort of like all the iPhone vulnerabilities that allowed the devices to be jailbroken.

Re: ThinkPwn: System Management Mode arbitrary code execution

#85

Post by yuhong » Tue, Jul 05, 2016, 5:25 PM UTC

skykooler wrote: post #66

kuschku wrote: post #64

Earlier quoted context omitted.

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-hous…

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

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

Re: ThinkPwn: System Management Mode arbitrary code execution

#86

Post by wbkang » Tue, Jul 05, 2016, 5:33 PM UTC

bsilvereagle wrote: post #18

shimon wrote: post #6

Earlier quoted context omitted.

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.

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.

Any "physical" access is definitely way more privileged than just the local admin access.

Re: ThinkPwn: System Management Mode arbitrary code execution

#87

Post by __jal » Tue, Jul 05, 2016, 5:36 PM UTC

devy wrote: post #62

fencepost wrote: post #47

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 pr…

Perhaps financial compensation was indeed not Cr4sh's motivation for this zero day, but I felt it's a stretch to call this disclosure responsible. Also his name-calling (ThinkPwn) campaign was inappropriate and premature when the root cause was later discovered in Intel's reference code and propagated to IBVs's products.

Name calling? Come on. I'm not really a fan of the trend of "branding" vulnerabilities, but it is just harmless silliness, and substantially less inflammatory than security industry smack-talking norms from not too long ago.

Or put another way, I suggest adjusting your sensitivity before cracking open an issue of Phrack.

And a serious question: in your view what would be a "responsible" way to release a multivendor exploit? Please describe the preconditions which would need to be met before you'd use the adjective.

Re: ThinkPwn: System Management Mode arbitrary code execution

#88

Post by yuhong » Tue, Jul 05, 2016, 5:37 PM UTC

AdmiralAsshat wrote: post #74

snuxoll wrote: post #21

Earlier quoted context omitted.

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.

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

Though I doubt corporate buyers would be happy with for example LSE installed without permission.

Re: ThinkPwn: System Management Mode arbitrary code execution

#89

Post by yuhong » Tue, Jul 05, 2016, 5:40 PM UTC

quotemstr wrote: post #34

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.

I think you were there during the Win8 period when UEFI secure boot and ACPI BGRT was introduced for example, right?

Re: ThinkPwn: System Management Mode arbitrary code execution

#90

Post by Kadin » Tue, Jul 05, 2016, 5:41 PM UTC

gbrown_ wrote: post #17

jonwachob91 wrote: post #8

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

The example exploit is run from an UEFI shell which requires physical control of the device. It mentions exploitation from the OS as a possibility however one would expect that the OS shouldn't allow such operations as a non root user.

Sure, but there's not exactly a shortage of privilege-escalation exploits around. It doesn't seem like this is exactly a drive-by "oh please look at this resume.rtf.doc" type of attack, but it could become one with time if it goes on too long. Somebody would just need to stack things up in the right way, to get privileges in the OS and then from there inject the EFI code. That'd be a heck of a rootkit.