Comment by fencepost | Hacker News Reader

Comment by fencepost | Hacker News Reader

Parent Full thread

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."

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-house.

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

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

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

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

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

https://xkcd.com/1170/

I wonder what command and control systems that ship with Russian and Chinese military equipment use.

I thought that Chromebooks, at least, run coreboot rather than UEFI, and so should be immune from this.

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.

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.

I'm much more upset with the vendors that thought UEFI was a good idea and pushed it, than security researches who discover vulnerabilities in UEFI, no matter how they choose to disclose it.

UEFI vs BIOS itself isn't the issue. UEFI, the specificaiton, is really a nice interface to the hardware. The issue is with specific implementations of UEFI, and the fact that UEFI firmware vendors (much like traditional BIOS firmware vendors) can churn out hacky code and nobody is the wiser.

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.

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.

My mistake - I had developed the impression that Lenovo was informed ahead of time. I had only skimmed at first.

I had thought the complaint was about not waiting until what sounds like most of the PC OEMs stopped sitting on their thumbs. Please disregard that part of my response.

Why?

Lenovo put users at risk and public shaming is a tool to correct their behaviour.

Lenovo could allow users to replace software on their machine, but presently choose not to because they might make less money.

However if Lenovo are shamed, people might buy less of Lenovo's products, which will also make Lenovo less money.

> I'm not really a fan of the trend of "branding" vulnerabilities, but it is just harmless silliness

It's probably harmless but I'm not so sure it's silly. It's much more distinguishing than monikers like "CVE-2016-0093". It can sometimes convey the seriousness of the relevant exploit (not sure if that's the case this time though). These branded-vulnerabilities are also probably much more valuable on a CV as such.

Sure. "Silly" is in the eye of the beholder, of course, and I do think successfully executing the "launch" of an exploit is probably a great career move.

I still think it is silly.

I'm less convinced the trend has any use for communicating seriousness. I don't expect product names (basically what this is) to meaningfully convey actionable information in any trustworthy way. But I'll reconsider next time I see a car named "Cheap, mostly-OK vehicle with probable future maintenance headaches" or an exploit named "Smasher of stacks of a little-known utility optionally installed alongside Enterprise Product X, so long as these 7 unlikely preconditions are met".

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.

Reply on news.ycombinator.com