Welcome Guest | Sign In
ECTNews.com
E-Commerce Times TechNewsWorld CRM Buyer LinuxInsider
Discussions

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 oiaohm on 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.

https://www.darkreading.com/vulnerabilities---threats/how-the-major-intel-me-firmware-flaw-lets-attackers-get-god-mode-on-a-machine/d/d-id/1330565

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.




 * Topic  Author  Date
Re: Unsigned Firmware Puts Windows, Linux Peripherals at Risk  Jack M. Germain  2020-02-19 17:16:06
Re: Unsigned Firmware Puts Windows, Linux Peripherals at Risk  oiaohm  2020-02-19 18:28:53
Re: Unsigned Firmware Puts Windows, Linux Peripherals at Risk  GerryP  2020-02-20 13:52:58
Re: Unsigned Firmware Puts Windows, Linux Peripherals at Risk  oiaohm  2020-02-21 12:38:15
Re: Unsigned Firmware Puts Windows, Linux Peripherals at Risk  GerryP  2020-02-22 20:22:00
Jump to:
Your Name: [modify]
* Subject: [edit]
Choose Icon:

Submissions containing gratuitous promotions or advertisements
will not be posted. [Message Board and Community Rules]


* Comments:

Notify me by e-mail when someone responds to my post.

When considering an online-only dealer to purchase an automobile, which is most important to you?
30-day low price guarantee
Comprehensive and verifiable vehicle inspection policy
Extended warranty protection plan provided by the dealer
Full money back return policy with no questions asked for at least a week after delivery
The dealer has many outstanding reviews, and few or no complaints.
I would not consider buying a vehicle from an online-only dealer.