51–60 of 154 posts
Earlier quoted context omitted.
> What are we up to now? I am about to buy and advice to others the only freedom-respecting laptops [0]. [0] https://minifree.org/product/libreboot-t400/ and https://minifree.org/product/libreboot-x200/
AKA refurbished Lenovo hardware?
> Vulnerable code of SystemSmmRuntimeRt UEFI driver was copy-pasted by Lenovo from Intel reference code for 8-series chipsets. > Alex James found vulnerable code on motherboards from GIGABYTE (Z68-UD3H, Z77X-UD5H, Z87MX-D3H, Z97-D3H and many others): This is beyond the scope of just Lenovo machines.
Earlier quoted context omitted.
Most likely not; the flash protection is not done by the firmware, but by the Intel Management Engine and a public key burnt into silicon (Intel Boot Guard). The current exploit only runs far later, after the validation is performed. So unless you manage to mangle the code execution flow of the authentic firmware to the point that it skips the whitelists, you can't get rid of it.
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…
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 chip with the contents of the original so that they could fall back to the original in the event of failure.
[0] https://www.bios-mods.com/forum/Thread-TUTORIAL-Lenovo-X230-...
[1] https://www.digikey.com/product-detail/en/pomona-electronics...
Quite the hilarious "security advisory" [0] that Lenovo put out. They manage to take zero responsibility, shift blame to the researcher/IBV/Intel, and admit that they ship SMM code of both unknown author and purpose. [0] https://support.lenovo.com/us/en/solutions/LEN-8324
That's literally what every vendor does nowadays. Do you think LG can get the code for the firmware of the SoCs they use in their phones? Do you think the coreboot guys can get the source for the Intel Management Engine firmware? Do you think any of the firmware in your system comes from your OEM and is secure?
This is a failure in the entire industry, and it's getting worse every day.
The proper solution would be simple, too: Allow everything to be flashed with custom software, but allow the user to set a cryptographic key with which updates have to be signed. By default, the system could accept the OEM key, the user could lock it further down.
Provides additional security for corporations and nerds, provides additional flexibility, provides the ability to modify the firmware.
What are we up to now? Three preloaded spyware scandals, possible remote execution via the Intel stack and now this vulnerability. That's just what we know about, who knows what else exists. I don't think I can buy another one, which is sad as I think it was a timeless and great design.
I plan on using my quad core T520 for probably another 5+ years. All of their laptops after the T520 series have the full size keyboard with numberpad which off-sets the center of the keyboard, so now your typing is mostly happing on the left side of the keyboard and that causes wrist strain. Having a numberpad is really lame on a laptop. I won't buy one and I know of no one else that likes the numberpad either.. sad…
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.
Oh come on, how practical is this attack? I don't think Lenovo will default boot off a usb drive without user intervention. If you can get someone to run a USB that'll boot you open the user up to a bazillion exploits already and already own the machine.
I'm assuming that would probably need admin/root access to exploit, but it does mean that you can turn an OS-level privilege escalation bug into something substantially more persistent and difficult to recover from.
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.
Ehhh..... that used to be the case. As an owner of 2 thinkpads, I'm not convinced thats still true
Quite the hilarious "security advisory" [0] that Lenovo put out. They manage to take zero responsibility, shift blame to the researcher/IBV/Intel, and admit that they ship SMM code of both unknown author and purpose. [0] https://support.lenovo.com/us/en/solutions/LEN-8324
THERE IS NO SECURITY FOR THE HARDWARE OR SOFTWARE, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
SHOULD THE HARDWARE OR SOFTWARE BE COMPROMISED, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.I thought I have an intermediate level C knowledge, but I have no idea what is happening in the vulnerable line: *(v3 + 0x8)(*(VOID **)v3, &dword_AD002290, CommunicationBuffer + 0x18); As I understand it is (was) an example code from Intel. Example codes should be easy to understand and well documented.
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…
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…