Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ThinkPwn: System Management Mode arbitrary code execution

github.com

Post reply on HN
Print view View original

101–110 of 154 posts

Re: ThinkPwn: System Management Mode arbitrary code execution

#101

Post by geofft »

yuhong wrote: post #78
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…

My personal favorite is the UEFI variable bugs that brick laptops. I think many of them are trivial to exploit even under Windows.

Don't you need root access for those? They're awful bugs, yes, but being able to semi-permanently brick a laptop from privileged userspace isn't super surprising. If you can reflash the firmware without the firmware checking signatures on updates, you're done.

Re: ThinkPwn: System Management Mode arbitrary code execution

#102

Post by yuhong »

geofft wrote: post #101
yuhong wrote: post #78

Earlier quoted context omitted.

My personal favorite is the UEFI variable bugs that brick laptops. I think many of them are trivial to exploit even under Windows.

Don't you need root access for those? They're awful bugs, yes, but being able to semi-permanently brick a laptop from privileged userspace isn't super surprising. If you can reflash the firmware without the firmware checking signatures on updates, you're done.

It is trivial for any malware to do though, without even needing a kernel driver. I can see ransomware trying for example.

Re: ThinkPwn: System Management Mode arbitrary code execution

#104

Post by mook »

m1el wrote: post #61
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…

do I understand correctly that v3 stores sort-of closure in C?

It's like a `this` pointer in C++, with a method table, yes. See the first link in the update from 30.06.2016. `v3` would be `RtServices`.

Re: ThinkPwn: System Management Mode arbitrary code execution

#105

Post by zxexz »

pierrec wrote: post #82
zxexz wrote: post #53

Earlier quoted context omitted.

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…

Huh, interesting. I managed to do it successfully on my X201, but only after supplying power through the RasPi I was using to flash it (no power to the board, battery and clock battery disconnected, though I doubt the latter was necessary).

Re: ThinkPwn: System Management Mode arbitrary code execution

#106

Post by CaptSpify »

devy wrote: post #65
CaptSpify wrote: post #60

Earlier quoted context omitted.

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.

It's only been a few days since disclosure. No PC manufacturers these days knows every single line of code they get from their vendors - if they did, there wouldn't need to outsource it in the first place.

You are correct, but that still doesn't make it right.

Re: ThinkPwn: System Management Mode arbitrary code execution

#107

Post by CaptSpify »

kuschku wrote: post #64
CaptSpify wrote: post #60

Earlier quoted context omitted.

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.

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…

Correct. Just because everyone does it, doesn't mean it's OK to do. "If everyone jumped off of a bridge..."

Re: ThinkPwn: System Management Mode arbitrary code execution

#108

Post by Asooka »

CaptSpify wrote: post #107
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…

Correct. Just because everyone does it, doesn't mean it's OK to do. "If everyone jumped off of a bridge..."

If everyone jumped off a bridge, the bridge is probably on fire, or the several decades of airtime has a higher ROI than the bridge and if by some miracle you actually start getting close to the water, you always have your golden parachute.

Re: ThinkPwn: System Management Mode arbitrary code execution

#109

Post by devy »

__jal wrote: post #87
devy wrote: post #62

Earlier quoted context omitted.

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

Give the vendor a timeframe to investigate and resolve. Even sometimes ignores reports like this, at least give them the courtesy instead of expose this as an 0day.

Re: ThinkPwn: System Management Mode arbitrary code execution

#110

Post by School-Cotton »

revelation wrote: post #92
bsilvereagle wrote: post #18

Earlier quoted context omitted.

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.

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.

OK, mind telling me how to get root on my iPhone, then?

BTW, I have physical access.

Post reply on HN