What do a Lenovo touch pad, an HP camera and Dell Wi-Fi have in common? They'll swallow any old firmware, legit or saddled with malware Some of the biggest names in the technology world still ship hardware that can be possibly hijacked by well-placed miscreants, thanks to poor or non-existent checks for firmware updates. Eclypsium said on Monday that, despite years of warnings from experts – and examples of rare in-the-wild attacks, such as the NSA's hard …
"They [Qualcomm] stated that there was no plan to add signature verification for these chips. However, Microsoft responded that it was up to the device vendor to verify firmware that is loaded into the device."
Fortunately for M$, it's really on the device manufacturer. Firmware updates really have to be signature-checked, or in the least disallowed, unless (for instance) a "dev mode" pin is connected ... and even that should burn an eFuse to void warranty (Samsung KNOX Warranty Void style).
There's really no semantic working-around this incompetence.
If you don't trust the hardware vendor, what are you doing using their hardware? Hardware can do bad stuff, even without installing new firmware.
If their signing key gets compromised, that is bad. However compromising a signing key would be a significant extra barrier for a targetted attacker (and they would still have to do all the other stuff).
Meanwhile, manufacturers complain doing signature verification of firmware code is tricky in embedded systems and other low-end or resource-constrained gadgets. While PCs and servers have plenty of room to check updates, fitting that cryptographic tech onto normal gear is not so simple, it is claimed.
If it's possible to embed a CPU in a CPU (Intel ME), then this could be done, too.
At worst, just disallow write access to the chip. I know that sometimes customers might need to update the firmware, but tough cookies, it's a security risk to these very customers.
At best, implement a small chip that does only one thing: read firmware chip, check the digital certificate, dis/allow write access accordingly. Even that is imperfect, but it's better than leaving it open for world + dog.
It is a question of cost and size against security. Are you willing to pay more for your laptop, which is thicker, because the Synaptics trackpad is thicker and includes a beefier processor capable of checking the keys on the firmware?
And that multiplied around wireless chipset, camera, USB hub etc.
Most people want a "cheap" device (cheap being relative to what it would cost to provide a secure device), not necessarily a secure one - they don't understand the problem, for a start. That means that the security conscious are left with having to take the insecure stuff and doing what they can to minimise risk.
At worst, just disallow write access to the chip. I know that sometimes customers might need to update the firmware, but tough cookies, it's a security risk to these very customers.
I assume you mean read access... But even so, they should throw out that $2,000 laptop, because the wireless/trackpad/camera has a critical security issue and can't be updated?
It is a question of cost and size against security. Are you willing to pay more for your laptop, which is thicker, because the Synaptics trackpad is thicker and includes a beefier processor capable of checking the keys on the firmware?
This exactly, thank you for posting. A trackpad is a rather 'dumb' device; in order to verify its own software updates, the trackpad subsystem will need to be designed to be a 'smart' device with built-in self-compare and analytic functions. Will buyers be willing to foot the additional costs when the main motherboard (CPU) / OS firmware update procedures *should* be doing the verification work for any dedicated subsystems directly attached?
And of course, once the trackpad is smart enough to verify its firmware updates, the manufacturer will need to add in some telemetry so that the customer experience can be optimised. As will the keyboard supplier. And the display supplier. And the camera supplier. And the microphone supplier. And especially the wireless controller supplier (to deal with all of this extra data). Just think of all the lovely high-value data which can be obtained, before beginning to consider what the operating system and browser will be gathering.
What a marvellous future we can all look forward to!
The idea of Zero trust is to do your OWN security checking and not let someone else (the perimeter) do your checking for you. Perimeter checking has gotten us into a state where 90% or more of IoT devices don't even have a password for authentication. Each component must verify its inputs and outputs. That is just good engineering.
If I want to build a reliable hardware product, I want check all my inputs (length, types, buffers, commands, etc.) rather than have MS Windows verify it for me. Firmware upgrade verification is just another type of verification. Just an ECC or an RSA check against a public key burnt into OTP/ROM/etc.
Having done tons of these devices, I have realized that the manufacturers do not want to do any software as they only make money off the sale of parts, not software. Hence the reluctance.
I completely disagree. I have lead teams of security engineers where we did secure firmware updates on extremely low powered devices. These devices run for 20 years on a pair of batteries, communicate using encrypted communication (nowadays it is AES),
We have probably 50 million of these devices out there.
It is possible to do these things with careful design and implementation. Many processors don't permit these things directly so you have to use good design principles.
Furthermore, our devices were evaluated for security vulnerabilities by well reputed research labs, security testing companies, and certain government agencies,
I own the device, I should be able to flash my own firmware onto it. At the very least, the manufacturer should be required to provide the signing certificate upon request, but this needs a change in the law. Prohibiting consumers to flash new software encourages planned obsolescence and waste, which is bad for the environment.
Being able to get the signing certificate on request is exactly the same as having unsigned firmware updates. The hacker just needs to contact the manufacturer, requests the certificate, makes his contaminated firmware patch, signs it with the manufacturers certificate and hey presto, he can infect any machine with the manufacturers hardware installed!
Signed firmware updates certainly remove the freedom for you to flash your own firmware onto it, and that is not desirable. On the other hand, *most* people don't want to flash their own firmware (in fact, they will only flash a new copy of the manufacturer's firmware if they really, really, have to), but they do want to be reasonably confident that any new firmware won't introduce a security vulnerability. We have to balance those two requirements (it is hard to have both), and in general, your freedom to flash firmware updates will usually lose.
One possible solution is for an unsigned firmware update to be allowed if a normally unconnected contact is driven to a particular value. However this only works if an additional contact is essentially free (as in, there is a spare one), because most people don't want to pay for the ability to flash their own firmware.
There are solutions ... Some processors have the OTP (One Time Programmable) option to boot even when the signature check fails if a particular line is held high (or low). There are other variations to the theme.
Nothing prevents a manufacturer putting a jumper on the board to help bypass the signature verification. That way, people like us can use the system for white-hat analysis.
Having the "signing certificate" wouldn't do you any good. Certificates contain public keys. You need the corresponding private key.
Giving that out to customers would be idiotic; a private key isn't any good if it's not private.
In order to make it possible for users to install their own firmware, vendors would need to provide some secure mechanism for authorized users (i.e. equipment owners) to disable firmware signature checks; or to add additional public keys to the collection of verification keys; or, if the device implements a full hierarchical PKI, to add root certificates.
At that point, we're likely back to putting the responsibility on the OS.
Agreed. Of course, it would help if OEMs would provide useful information about what their firmware updates actually do. I routinely reject firmware updates offered by OS and equipment vendors because the change notes are useless. ("Install this update to correct certain problems and improve performance.")
I hate to ask this, but what would a signing system which relied upon Microsoft mean for linux users? Would it mean that linux-compatible hardware would become harder (or impossible) to find? Some of the points raised in the article seem reminiscent of the situation around UEFI-based motherboards from a few years back. Going around that loop again would be undesirable, to say the least.
Signed firmware is a nice feature to have.
It also has a significant cost impact if you need to select an embedded controller that supports the required features to make it work, and there's usually an impact on boot time and also on how long it takes to program the kit - not so much a problem for the customer doing updates but a big issue for manufacturing.
A lot of specialist effort has been expended looking at this and it isn't trivial to sort it out even for things that cost a lot more than a webcam.
It's also worth mentioning that while signed firmware is nice to have it's not going to protect you against a truly capable opponent, it just removes the lowest hanging fruit.
Signed firmware is just ONE of the fundamental tools we use to protect against hackers. Without signed firmware, it is hard to prove (impossible?) that what the processor is running is legit. That doesn't mean that signed firmware will protect you from buffer overruns and other memory issues, MITM, etc.
You only need to check a signature when activating an update, in which case a few seconds more or less hardly matter. After that, a CRC is fine to check for memory errors. Yes, I know you can change the FW to fit the CRC, but if you can change the memory you can also completely disable the check.
"Meanwhile, manufacturers complain doing signature verification of firmware code is tricky in embedded systems and other low-end or resource-constrained gadgets."
If you can do 10GB ethernet, you have the horsepower to do signature VERIFICATION. Having built systems with secure boot that go out into the field and run for 20 years on a pair of batteries, I bet them $1m they can too. That was 8 years ago and the processors I worked with cost $1.50.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
