Hard drive firmware attack possibilities? (network access possible?)

Went to buy a hard drive cash and at first they didn’t have it and would take two weeks to get. Then I was updated they it was suddenly available in less than 36 hours. There was some other signatures at the location that matched previous signatures before attacks were carried out.

Anyways instead of gaslighting myself, I am curious mainly if I did recieve a modified SSD with malicisious firmware customized for qubes, would it be possible for this to upload my data or allow access to my qubes by an advesary? If so how?

IMHO, not enough information to tell whether it was something nefarious or just a coincidence.

I’m not an expert in this area, but my understanding is that it’s possible for malicious drive firmware to infect dom0 (after which anything is possible). Note that this assumes the drive is an internal storage drive connected directly to dom0 and not some external (e.g., USB) drive. The proposed “storage domain” mitigates this risk, but it has not been implemented yet. You can read more here:

https://groups.google.com/g/qubes-users/c/9cso2wnw8Bg/m/BZU7pHrmKzwJ

1 Like

Thank you. This arch spec is beautiful. Is this the latest version? I’ll be pouring over this.

Also any idea when the ‘storage domain’ would be implemented? Is there timeline or somewhere I can see what’s implented and pending according to the envisioned architecture specifications?

Hoping there’s an pending area that aligns with my expertise where I could start to contribute sooner rather than later.

Concerning my search for a pending timeline I found this: Release 4.1 Milestone · GitHub

But still curious about ‘storage domain’ and other concepts covered in the arcspec. If there exists somewhere people are either working on them or talking about them, I’d like to read up!

Thanks.

Yes, I’m afraid it hasn’t been updated in a very long time (and probably won’t be).

No, sorry. I tried to find an open issue for this but couldn’t.

No, I’m afraid there’s no up-to-date public roadmap.

Searching this find “a first step towards untrusted storage domains” in Switch default pool from LVM to BTRFS-Reflink · Issue #6476 · QubesOS/qubes-issues · GitHub
Other development I miss?

IIUC from Architecture | Qubes OS image


what Jean-Philippe say in Aug 2018 (https://groups.google.com/g/qubes-users/c/qZuNgsPEqw0/m/5dhWAX8iAgAJ )
“currently disks are owned by dom0, and e.g. a malicious nvme device could do arbitrary DMA to compromise dom0 and therefore win. Just because your device has an IOMMU does not mean it is actually in use to protect you from all DMA-related attacks, and is this specific case it is not currently in use as such by Qubes.”
Is still true?

Partial firmware mitigation I find in same thread (https://groups.google.com/g/qubes-users/c/qZuNgsPEqw0/m/pXrhEtfeAAAJ ) from Brendan
"Flash firmware denial:

  1. The OPAL standard requires that securely-configured drives (having enabling OPAL or ATA Password and importantly, whether currently locked or unlocked) shall block firmware updates or, if they do not fully block, the unlocking credential used to unlock the drive at boot must also be sent to initiate firmware updates.
  2. IMPORTANTLY: when not securely-configured (as they come from the factory), firmware updates are not blocked at all. Enabling the locking of the drive at power on is also the way to block firmware changes."

But understand this to need start with “known good” state.

Curious after think about current day versions of
https://groups.google.com/g/qubes-users/c/9cso2wnw8Bg/m/BZU7pHrmKzwJ

Please say I confused or miss something. Thank you for any pointers or more info.

1 Like