Hacker News new | past | comments | ask | show | jobs | submit login

Are these blob type of attacks accessible after boot? Essentially, are these only accessible if you have physical access? And at that point, isn't it game over anyways?



Intel ME allows intentional remote access through the ME in some enterprise scenarios (vPro). The driver support matrix is quite small and this is a massively overblown concern IMO, but it’s the root of a lot of the hand wringing.

However, onboard firmware based attacks are absolutely accessible remotely and after boot in many scenarios. It’s certainly plausible in theory that an exploit in ME firmware could, for example, allow an attacker to escape a VM or bypass various types of memory protection. Unfortunately the actual role of the ME is rather opaque (it’s known, for example, to manage peripherals in s0ix sleep).

Ditto for any other blob. Maybe a specially crafted packet can exploit a WiFi firmware. Maybe a video frame can compromise the GPU.

These are also good persistence vectors - gain access remotely to the NOR flash containing EFI, and you have a huge attack surface area to install an early boot implant. (or if secure boot isn’t enabled, it’s just game over anyway). On Linux, it’s often just hanging out in /dev as a block device; otherwise, once an attacker has access to the full address space, it’s not too hard to bitbang.

These are all fairly esoteric attacks compared to the more likely ways to get owned (supply chain, browser bugs, misconfiguration), but they’re definitely real things.

The closed-sourceness is only a tiny part of the problem, too - a lot of the worst attacks so far are actually in open source based EFI firmware, which is riddled with bugs.

Which takes me back to my original response to “isn’t everyone backdoored by ME” - sure, maybe, but if you’re looking for practical holes and back doors, ME is hardly your largest problem.


> The closed-sourceness is only a tiny part of the problem, too - a lot of the worst attacks so far are actually in open source based EFI firmware, which is riddled with bugs.

Can you elaborate and/or provide context/links?



Makes sense given the context. When you said bugs in open source EFI implementations, I thought you meant bugs in things like rEFI/rEFInd/rEFIt.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: