a BIOS BUG discovered..?!

[BillMorrow]

follow the link..
http://hothardware.com/news/lenovo-rock ... nerability

[Puppy]

It is this issue https://support.lenovo.com/us/us/solutions/LEN-8324

[ajkula66]

Heh...I guess that Kržanić now has an excuse to lay off more Intel employees, after those 12K sacked recently...not that heads shouldn't roll at Lenovo.

Will they? I highly doubt it.

[evening_hunger]

Who is Kržanić?

[RealBlackStuff]

Kržanić is the CEO of Intel.

[Kilkenny]

Not surprising given the cavalier attitude towards adding feature bloat to the BIOS. The BIOS is way, way too complex these days.

[erik]

The BIOS is way, way too complex these days.

That's because it's UEFI now, not BIOS. True BIOS is still simple... or basic, more accurately.

[dr_st]

A complete UEFI source tree is several hundred megs in size, and when you build it, it produces >1GB of intermediate stuff, before everything is somehow packed into a single 16MB binary. It's pretty mind boggling how it all works (and that it even works).

[Puppy]

A complete UEFI source tree is several hundred megs in size, and when you build it, it produces >1GB of intermediate stuff, before everything is somehow packed into a single 16MB binary. It's pretty mind boggling how it all works (and that it even works).

There is nothing wrong about that, especially if at least half of the source tree size are automatic tests Software just become complex because the hardware is complex. Remember what kind of various devices and features you had 15 years ago and now.

These bugs are different issue. Pushing for low-cost software developers and saving on them pays back.

[dr_st]

These bugs are different issue. Pushing for low-cost software developers and saving on them pays back.

As if bugs are only introduced by "low-cost software developers"...

[erik]

Speaking of UEFI complexity, the author of the exploit admits himself that one is more likely to be hit by lightening than affected by this issue.

http://blog.cr4.sh/2016/06/exploring-an ... enovo.html

Not mentioned in the public media is the fact that someone would have to have physical access to a machine to run the exploit, the system not have a boot password and USB would have to be enabled as a boot device. Anyone who keeps their system(s) secure with either a boot password or a BIOS password and USB excluded as a boot device have zero probability of being affected by this. And, it's not like there are a bunch of people running around with this exploit on USB keys in the first place.

[jaspen-meyer]

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.

That's a quote appearing in the article bill linked to - noteworthy no source is named.

Eric, I wonder about the need for a usb drive. My understanding is the 'Intel Management Engine' is designed to facilitate remote intrusion. I recently read the spec speet for the bios chip in an R30, circa 2003, and was surprised to learn it could be programed with 125kHz radio waves. Surely technology has improved since 2003.

[erik]

It's standard practice not to name sources when they don't come forth to the vendor first. It's a way to mitigate those seeking fame rather than doing this to truly help the industry.

It's certainly possible to write an executable that writes this exploit to memory, reboots a system and attempts to run the code at the EFI level just like a flash update. However, I'm not confident at this time that anything could be done with the data dump since there wouldn't be a place to retain it while a system boots. This would be needed to retrieve it later and potentially send over a network. That's where booting via USB becomes an important key in the process.

I'd also want to know if disabling the "Flash UEFI by end user" option would prevent this exploit from running. I've not inspected the exploit in detail to see what calls it makes.

IME/AMT might be usable in lieu of USB depending on the system. I'm not sure at this time if this exploit could run over AMT. Plus, AMT would have to be enabled. Many organizations disable it based on standard security practices.

The impact of this seems immeasurably low. The PR impact will certainly be higher than anything.

Lenovo released an affected systems list and is keeping it updated as research is completed on each system.

[Puppy]

Lenovo released an affected systems list and is keeping it updated as research is completed on each system.

One positive comment, Lenovo has tested even old .20 series models and very likely release BIOS updates for them. This is good support after all