Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What kind of security vulnerabilities do you think an incompetent PC OEM is going to accidentally introduce to a barebones PC that's basically shipping an Intel reference platform and no SSD? Or that GL.iNet might be able to introduce to a system where OpenWRT is assembling the firmware image that gets flashed to the board, and if there are any closed-source components they'd be coming from Mediatek and not developed by GL.iNet?

Shipping telco hardware with a massive bespoke software stack implementing an impossibly-complex pile of standards is very different from what we're talking about here.



> What kind of security vulnerabilities do you think an incompetent PC OEM is going to accidentally introduce to a barebones PC that's basically shipping an Intel reference platform and no SSD?

Historically remote code execution in the IME.

> an incompetent PC OEM

And then it never gets patched.


> Historically remote code execution in the IME.

That's only a problem if the Active Management Technology feature is correctly supported by the OEM including wiring it up to a supported NIC, and the feature is enabled and provisioned by default, and the NIC in question is connected to a network that is a potential attack vector.

From what I can tell, the current NIC of choice for Chinese router PCs is the Intel i226-V, and such PCs come with 4-8 of those. In order to work with the Active Management Technology feature, those would have to be the more expensive i226-LM or i226-IT parts. So AMT is impossible to enable on those PCs and there's no part of the boot firmware that continues interacting with any NIC after the OS has taken over managing PCIe peripherals.


> there's no part of the boot firmware that continues interacting with any NIC after the OS has taken over managing PCIe peripherals

Are you sure about that? Because I remember something called ACPI that gets executed by the OS every time some configuration changes, such as power levels.


> that gets executed by the OS

Do you see the problem here?

Which ACPI table do you expect to be used for delivering malicious executable code?


I'm not that knowledgeable, but I rememember Computrace auto-install on a system that didn't even have UEFI.


STH has reviewed Chinese PCs that come preloaded with malware. My MSI motherboard force installs Nahimic by default. Not technically malware but the same mechanism exists for malware.


Do you think any of that is relevant to the case of buying a barebones PC that doesn't include SSD or RAM, then adding those components yourself and installing a non-Windows OS?

If your MSI motherboard is installing Nahimic without an internet connection, it is doing so through a mechanism where the installer is made available to the OS in an ACPI table that Windows checks. That check can be disabled with a registry key to prevent such software from being re-installed, and the motherboard may have a BIOS option to disable the anti-feature (though the registry key method is generally more effective, since BIOS settings often get reset to defaults).


I think if a company is willing to ship windows malware they're also willing to ship UEFI malware.


Please don't ignore the points I've already made about how a firmware-based attack against a non-Windows OS is a lot hardware to pull off. I'm not asking if you think a company would be willing to ship such malware, I'm asking what kind of malware you think is realistically possible. What do you expect a UEFI-based malware to be capable of doing in this context, given the constraints of the hardware we're talking about?


I’ve reluctantly come to the view that Apple is the best bet for a consumer to get a somewhat reasonable (price notwithstanding) compromise between hardware vertical integration and software that offers substantial bug bounties and large market incentives to not allow bad vulnerabilities to sit for too long. With deep enough pockets to hang tough if needed in various situations.


Apple also ships bloated buggy software with a massive TCB that makes it almost trivially easy for state actors to break in.


I completely agree about the buggy bloated software but all I’m saying is that it’s the best bet compared to actual consumer alternatives which are generally a frankenmix of the lowest cost components sourced from the lowest cost vendor with minimum effort spent to ensure and maintain any semblance of security.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

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

Search: