Heads up: Serious vulnerability in latest NovaCustom/Dasharo UEFI firmwares

General Discussion
1

I think this might be of interest to some QubesOS users, as some NovaCustom laptops are QubesOS certificated, and thus QubesOS users are likely to own them.

Any user (eg remote attacker) that has enough privileges to communicate with the UEFI firmware can trivially flash an arbitrary malicious UEFI firmware, due to lack of effective signature verification in the Capsule Update code path. It is impossible to detect compromise or recover from it, unless you use a physical flash programmer.

Affected NovaCustom releases:
NovaCustom NV41 11th gen, starting with firmware release 1.6.0.
NovaCustom NV41 12th gen, starting with firmware release 1.8.0.
NovaCustom V54/V56, starting with firmware release 1.0.0.
NovaCustom NUC Box, starting with firmware release 0.9.0.

No patches are available as of date.

Recommended action: Do not upgrade the UEFI firmware on your device to an affected version. Wait for fixes to be released.

Mitigations: QubesOS prevent anyone but dom0 from talking to the UEFI firmware, largely mitigating the vulnerability, as long as you never boot any other operating system on the same device. Fusing Intel BootGuard also prevents malicious firmware from being installed.

Dasharo response:

They responded they don’t consider this an important issue, “since we [Dasharo] considered gaining root privileges a full compromise”.

NovaCustom response:

They responded that the next update “could possibly” have a fix resolving the security issue. During a meeting with Dasharo, they have responded they have a working fix.

This far, neither Dasharo nor NovaCustom has taken any public action in response to this vulnerability, other than responding to my public posts. Dasharo knew about the vulnerability before they released the new firmware updates, but decided to release anyway. NovaCustom has been aware of the vulnerability for a week.

5 Likes
2

On the Z690 and Z790, Dasharo uses vboot, and you are going to get a warning if the installed firmware isn’t signed with the installed certificate.

The certificate is installed in a read-only firmware region, there is no way to update without physical access to the system.

vboot-error
vboot-error1024Ă—499 66.7 KB

Here is a screenshot of the vboot warning.

You can use the Dasharo build scripts to build the firmware with you own personal keys, but I believe that the pre-built firmware is signed with 3mdeb keys.

5 Likes
3

The vulnerability is now mentioned in “Known issues” on the release download page, below many non-security related issues. But no other action has been taken or communicated. It looks like NovaCustom may not intend to withdraw the vulnerable release or inform its customer about the vulnerability on their blog. A bit disappointing they didn’t take this opportunity to show they take security seriously, and instead leave users uninformed and unprotected.

I asked for a time frame when a fix may be available, let’s see what they respond.

2 Likes
4

@novacustom posted this milestone URL:

1 Like
5

This vulnerability just looks like another example, why the qubes way of throwing away defense in depth, by allowing passwordless root seems like a pretty bad Security architecture. And that the documentatiom ignores this blatantly on both domU side and dom0 (Passwordless root access in qubes — Qubes OS Documentation)

2 Likes
6

I dont want to flog a dead horse, but is this true?
This vulnerability requires in Qubes that dom0 be compromised.
In that circumstance absence of passwordless root would provide almost
no defense, since the user account would be able to trivially import favorite
rootkit in to dom0.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

6 Likes
7

I’d like to add that if someone doesn’t like the default way, the options for changing things are described in the documentation:

3 Likes
8

This is incorrect. Not all things that break the linux Security model, such as worldreadable/writable files, race conditions, and xen privilege escalation options for vms (and/ or dom0) are documented and it would proabably not be reasonable, due too the high amount.

2 Likes
9

I am not sure if we are writing abot the same topic.The post you referenced was about the architectural weakness of qubesos that ot purely relies on virtualization. It was not about shifting the weakness from virtualization to another mechanism, but adding more layers.

2 Likes
10

I do not know to whom this is addressed.
The layer you would add by removing passwordless root is the finest
gossamer.
You cannot cover the sun with a sieve.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

4 Likes
11

Great analogy without any argument :). One reason why i love the qubesos (or most other) “security”-focused discussion venues that attract end-users.

Simply put, more (potentially) noisy exploits required → more logs → easier to find IoCs.
In the present case, this “gossamer” might prevent an adversary without access to a linux privilege escalation to establish persistence beyond the operating system (enjoy proving afterwards that the firmware is safe, and there is no backdoor)

1 Like
12

You think that an adversary who has a qubes->dom0 escalation will not
have a linux privilege escalation. I do not.
You think that an adversary who has established root access in dom0 will
leave breadcrumbs. I do not.

I find it hard to see scope for discussion here.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

6 Likes
13

Based on what I’ve seen Dasharo normally updates firmware once a year and microcode/security updates tend to be a bit behind with those updates. One of those annoying things where these laptops are sold as being more secure due to coreboot/heads/etc, but the reality is that they get updated less often and Dasharo doesn’t like to do hotfixes. If they deem it a big enough issue I assume it’d be fixed in a time frame measured in months.

1 Like