Get the ECT News Network Editor's Pick Newsletter » View Sample | Subscribe
Welcome Guest | Sign In
E-Commerce Times TechNewsWorld CRM Buyer LinuxInsider

LinuxInsider Talkback

ECT News Community   »   LinuxInsider Talkback   »   Re: Unsigned Firmware Puts Windows, Linux Peripherals at Risk

Re: Unsigned Firmware Puts Windows, Linux Peripherals at Risk
Posted by: Jack M. Germain 2020-02-19 17:16:06
See Full Story

Eclypsium has released new research that identifies and confirms unsigned firmware in WiFi adapters, USB hubs, trackpads and cameras used in Windows and Linux computer and server products from Lenovo, Dell, HP and other major manufacturers. Eclypsium also demonstrated a successful attack on a server via a network interface card with unsigned firmware used by each of the big three server manufacturers. The demonstration shows the exposed attack vector once firmware on any of these components is infected using the issues the report describes.

Re: Unsigned Firmware Puts Windows, Linux Peripherals at Risk
Posted by: oiaohm 2020-02-19 18:28:53 In reply to: Jack M. Germain
This is the biggest bit of garbage I have ever read because they totally don't understand the problem space.

The problem is not unsigned firmware. Its non-verified firmware.

Yes signing firmware can be a method to assist in verification.

We have to remember threats like above turn up yes this is signed firmware and systems still get exploited. So if all hardware mandated signed firmware nothings says that attack will not use old flawed version of firmware that was signed.

Really have another side to this problem.

In their attack example they are using a open source implemented version of the firmware that would not exist if the device required signed. This is a security upside to this as well not covered. The security upside is if there is a fault in that firmware that a third party can make a new version with the fix. Yes this is doubled sided without a verification system third party could make a hostile version as well. Signed firmware by a vendor that is not more with know security faults is also a hostile firmware.

Signed firmware is a doubled sided problem.

Now what would I class as correct fix to this long term.

Its not signing firmware. Because the ability to repair firmware is important.

1) We need standard for how to extract firmware from devices. Part of that standard is that the code to extract the firmware is rom code. The extract firmware to be checksumed and compared against list of known good. This counters old signed firmwares and the unsigned firmware problem to extend.

2)We need a standard to be able lock firmware. As in you send X command to device after it receives that command it will no longer allow firmware to be changed unless the system is fully powered down.

Please look at there example again. Lets forgot for one min that what they did was unsigned. Lets pretend it was signed.

BMC(Baseboard Management Controller) is for some reason expecting a particular version of network card firmware. Its signed and the OS now uploads incompatible with BMC version.

Lets say my point 2 was implemented when the system powers on the BMC puts the firmware into the network card and locks it. Yes 2 could have a string value so the party locking it can leave a name of who did it. Of course the operating system will need the point 1 for it drivers to find out what firmware it is in fact dealing with.

Now really think how often to you update firmware. If when you system booted some chip like the BMC set all the firmware would you notice.

Having my feature 2 would allow implementing signed firmware on hardware that does not have any signed firmware processing. Why the controller that send the signed firmware to the hardware without any signed firmware check checks the firmware and locks the device that receives it.

Other thing to consider is Dell, HP.... the OEM and ODMs basically could require own custom version of firmware for some reason. Do we really want every chip in our computer wasting silicon space for signature processing of firmware with fuse-able links burn out making those parts unique. Or would we be better off with the ability for one master chip to validate firmware then send to the controllers as lock them from being altered after that point.

Really its not cost sane to-do signed firmware on every controller. Now all controllers having a lock from firmware change and ability to extract firmware that is cost sane and can block all the attacks people point to lets sign the firmware for.

Signed firmware only part of the solution. Problem is signed is only validating where it come from not that is the right version for everything else in the system. My idea first item that need a particular version of firmware locks the door on everyone less.

Controller taking unsigned firmware end user could allow when attempting to develop a fixed firmware against some particular issue so the right to repair. Signed firmware processed inside the controller as the solution is anti the right to pay a third party to fix a security fault in firmware.

The problem space is complex not helped by people thinking signed firmware is a magical bullet that fix everything when it not.

Re: Unsigned Firmware Puts Windows, Linux Peripherals at Risk
Posted by: GerryP 2020-02-20 13:52:58 In reply to: oiaohm
Please edit the comment above for typos and omissions. The last few paragraphs are confusing and the topic critical.

Re: Unsigned Firmware Puts Windows, Linux Peripherals at Risk
Posted by: oiaohm 2020-02-21 12:38:15 In reply to: GerryP
To me its not really confusing but at the end due to growing length I did attempt to cut it down.

Reading over there is a clear omission that most people would not know.

"Really its not cost sane to-do signed firmware on every controller."

This paragraph. Exactly what about the controllers make cost insane.

Large number of controllers core instruction set is still based about the 8051 8 bit instruction set with extended parts to the instruction set to process that. You could argue that this is old. Even if we move to a modern risc-v the controller version can be RV32I with no extensions. So a risc-v with only maths there is add and subtraction

The simple reality in controller silicon the ability to process x502 certificate or equal to check that firmware is signed by the correct party in time effective way does not exist in the controller silicon in lot of cases. Adding this ability you are talking about increasing size of controller a lot and giving those who compromise that controller more cpu it work with as well.

Now it still a silicon cost to add to the MMU or equal of the controller the means to have a flag set that locks the memory where the firmware is stored read only to the controllers CPU. Think about this no point checking if the firmware was signed if it sitting in read/write memory. So this is a cost that has to be paid but its the bare min cost.

Same with the storing the in rom section of cpu the code to dump the firmware back to host when requested. Doing both means to lock memory that the firmware is stored in and return contents of firmware to host is a lot smaller in silicon than implementing everything you need to process signing in the controller.

"Controller taking unsigned firmware end user could allow when attempting to develop a fixed firmware against some particular issue so the right to repair."
The controller having the ability to take unsigned firmware does not mean in general operation end user will be able to use unsigned firmware. That the core concept to what I have written.

Individual controllers being able to take unsigned firmware is not the threat. The ability to modify the firmware at any time is the threat in fact. Think about this a controller that takes unsigned firmware but you can lock it as long as the firmware is locked from change of firmware before attacker can change it the attacker can do nothing with the fact it unsigned firmware. Remember it does not make any sense to waste time sending to a controller that cannot process signature the signature that you are just going to lock. I am not saying not to send checksum.

Something with signed firmware arguement as well is how with signed firmware are you going to handle a key compromised problem. Lets say you have put your x502 certificate or equal into your controller that you have spent the extra silicon to process this. Now you need to somehow get revoked to a controller of course if you have used fuse-able links to write it into the controller the controller is now scrap and most likely made the board on it security scrap.

More you look at it signing firmware is not the solution at the individual controller level.

This is most likely the confusing part as well.

The concept that controllers that will accept unsigned firmware does not mean the firmware is not signed and enforced.

Concept of validating controller is not being suggested in this write up saying unsigned firmware is putting Linux and Windows at rish. Validating controller could be like the BMC or the main CPU these items have more processing power. What a validating controller needs is the means to send to the controllers under it the firmware that are validated and lock against change except in cases attacker will not be able to perform. Simplest form of this is firmware can only be changed with device is power cycled with power cycling triggering the system that will relock it. Attacker does not have a open window.

Validating controller can be a bigger bit of silicon with more processing. Remember this is a pay once item compared to pay for every single controller. Validating controller could have the means to reach out to internet and check for revoked 502x certificates and be storing checksums of acceptable firmware on particular devices. Remember acceptable firmware checksums allow locking to particular version. Also this is 1 device in system to update if signature/checksum method is found to have a exploitable flaw.

Remember validating controller could kick in when you plug in a USB device or any other device before the OS in the machine is informed that the device is even present yet.

One of our biggest problem is also not that is unsigned. Lot of these controllers are using the failed concept of security by obscurity. This is done like in the SD standards here that we will give a stack of commands to manufacture to do what they like instead of defining command to read firmware, write firmware and lock firmware.

Here is a good question why can your general SD card reader pass though write firmware commands? Normal usage you don't need to change the firmware on a SD card so a general SD reader should not need this feature. Next question how do you work out that the SD card you put in is hostile or not the instructions to read what firmware is in it is not standard. Signed firmware does not equal not hostile firmware.

When you start thinking carefully you will notice that most of the x86 PC device firmware is basically writable 24/7 that is not a feature we in fact need this feature gives attackers too large of window to cause trouble. Also we lack standard ways to validate what firmware is in fact being used need to detect old/out of date/flawed in usage as we as modified.

The problem space is not simple. Signed firmware is a tool that can help with the problem if it used correctly to validate supply chain. Having every controller in the system validate signed firmware is not the way forwards because a signed firmware does not mean it the correct and current version. You have to look a xbox hacking on this one where people to play not approved games are using Microsoft signed code just old version with known flaws.

Validation of what firmware you are using is more important than any of them being signed. Validation that you are using the most current with the min flaws can be done by simply checking the firmwares against a checksum list attacker cannot mess with.

Signing firmware does not equal a full blown Validation system. Validation system can using signing as extra feature to check supply line but it does not require signing of firmware to be solid wall attacker cannot get past.

See why I give thumbs down. Signing is only icing on the cake of security. Proper validation of what being used is the cake. The cake is just fine with a defined shape without the icing but the icing is undefined shape. This is true for the signing icing and validation cake. The undefined shape of signing is what allowed attackers to use old versions of signed firmware.

Of course someone will say lets just make signed firmware that you cannot use old versions then you end up with users screwed over because new version of firmware has security fault and user cannot switch back to old version.

Firmware signing no matter how you look at it cannot ever fix the attacker problem completely and when it get close it starts harming the owner of the hardware.

Validation systems with lock firmware provided by controllers can 100 percent block the attacker without physical access exploiting included hardware in a device/computer without firmware signing as long as the firmware has no other flaws.

Yes validation systems can be design that the owner of a bit of hardware can physically access the hardware and disable them if there is some valid reason to-do so like repair/diagnostics.

Security is a very simple to get tunnel visioned and start going after so called silver bullets. Problem is as soon as you do that you are hurting self.

Validation is not without is flaws when it comes to functional security but for this problem space its the core question. Does the chosen method make sure you are using the Valid and Correct Firmware? Signed firmware fails to answer that question so is not complete solution instead is only a part that can help correct solution. Correct solution is a validation system that may or may not depend on signed firmware.

Remember signed does not equal valid. This is where lets sign the firmware falls in heap. Basics people faking checks and using valid signatures before computers really showed the fault of signed firmware as well. We have not learnt from history and we are lining up to repeat it.

Something critical here. Some of the hardware that is in usage using unsigned firmware has to be power cycled to change firmware by PCIe/USB... These bits of hardware already have the lock.

You could modify the PCI-e controller/usb controller that when powering up or power cycling a bit of hardware up that it validates the firmware attacker would not be able to exploit these devices even that they accept unsigned firmware. Yes this could well and truly frustrate an attacker they changed the firmware only to have the validation system on power cycle switch it back and log a issue.

Issue for the validation system is the standards of PCIe, USB... don't include standard systems to write and read firmware. Yes the security by obscurity thing.

Re: Unsigned Firmware Puts Windows, Linux Peripherals at Risk
Posted by: GerryP 2020-02-22 20:22:00 In reply to: oiaohm
Thanks for the clarification. Very much appreciated.
Jump to:
Given the spread of the Covid-19 Delta variant, if my employer requires me to return to the company's location in 2021, I will...
Agree because I'm fully vaccinated.
Agree if the company institutes a mandatory mask requirement and other safety protocols.
Comply reluctantly, because I can't afford to lose my job, but start looking for different employment.
Resign immediately so I can dedicate all of my time to find a job I feel is safer.
Resign because I'm not vaccinated and don't want to risk infection to myself or others.