ThinkPwn: System Management Mode arbitrary code execution

Post by happyslobro » Tue, Jul 05, 2016, 11:05 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…

Post by lallysingh » Tue, Jul 05, 2016, 11:47 PM UTC

viraptor wrote: post #123

geocar wrote: post #14

Earlier quoted context omitted.

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?

Lenovo is not one team. People who write and test superfish are not the same who deal with firmware. They may not even know each other.

Post by mdip » Wed, Jul 06, 2016, 12:01 AM UTC

happyslobro wrote: post #131

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…

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.

Post by lmz » Wed, Jul 06, 2016, 1:00 AM UTC

sprkyco wrote: post #120

gbrown_ wrote: post #17

Earlier quoted context omitted.

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.

Typically physical control is deemed as the game ender. If this is proven to be OS executable it will be a major issue. Many of the Adobe, IE, and other high volume exploit vendors codebase zero-day root exploits would allow one to not only gain access at a root level on a machine, but now also at a much lower level. This level would negate the typical benefits of recovering from a root-level "hack" via HDD erasing o…

Post by voltagex_ » Wed, Jul 06, 2016, 1:50 AM UTC

0x0 wrote: post #132

acd wrote: post #126

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 UEFI is another gigantic hide point for m…

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.