I’m not a expert, I saw Librem laptops and simply found them very
interesting machines. I’m thinking to buy one of them, but have a doubt.
I’m curious to know if Librem laptops have some particular protection
against those malware witch rewrite the EEPROM of the HDD or SDD to
change the disk drive firmware adding malicious code.
Is there some physical switch (or something like that) to ensure the disk
firmware can’t be modified without user permission?
I know the disk drive probably isn’t manufactured by Purism, but maybe Librem laptops have some feature to control the disk drive firmware…
Thank you in advance
Best regards,
Damiano
(Ferrara, Italy)
1 Like
I doubt it. I have never seen such a drive.
One thing to bear in mind is that in most cases the disk drive would be free to ignore or subvert the intent of such a physical switch. Hypothetically speaking, if you don’t trust the drive, you can’t trust that the firmware can’t be updated.
Such a switch may only serve a purpose in the event that malicious (root / kernel) code is running on the computer, in which case you do have a fairly major problem and protecting the drive firmware is only a small part of that.
I would suggest that the lack of trust in the drive is mitigated by using encrypted content, content that is encrypted on the host before sending to the drive. So the drive, hypothetically speaking, can only leak the encrypted content and any intentional modification of content by the drive would a) likely be detected and b) likely just corrupt the content and/or make it unreadable.
Hypothetically speaking, if you have lost custody of the laptop then a malicious party can physically remove the drive and attempt to update the firmware in another computer. Hence there is nothing that the computer itself can do to prevent firmware update. That leaves you with the drive attempting to protect itself. Obviously the malicious party can operate any physical switch. (So in some sense, you would be better off having a firmware protection password implemented in the drive’s firmware.)
In theory, if you trusted the original firmware of the drive, the firmware of the drive could be set to prevent updating the firmware ever via the conventional means but
- that is definitely a trade-off for the user i.e. what if some nasty bug is discovered and it needs fixing? what if the user wants to try replacement firmware?
- there is probably no way of reaching the situation of “trusting the original firmware of the drive” - since the firmware is (near) universally a blackbox (hence, for example, a firmware protection password could have a backdoor and you wouldn’t know about it).
Thank you for the answer.
Anyway, I understand, a conclusive solution would imply a disk with “open firmware” with password protection against firmware editing.
Maybe, it would be a good practice for any periferials’s firmware of a laptop, but manufacturers have no interest for it. It’s right?
Yes, that sums it up.
There is another partial solution to this problem, namely that the firmware has to be cryptographically signed. That prevents a random thief from changing the firmware, with or without a password, but it doesn’t prevent government thieves from changing the firmware and it does prevent you from changing the firmware arbitrarily (unless you control the signing key in some way).
Note that the disk is not the only component with firmware that raises the same issues. Many of the same issues come up in respect of the keyboard. Ditto WiFi.
Uh, they sell a Librem Key to verify /Firmware has not been tampered with.
I doubt that that verifies the disk firmware, only the BIOS.
There are so many places where potentially malicious firmware could hide peristently in a modern computer.
AFAIK, unfortunately, there isn’t a standard to do something like a recursive verification of all firmware of all peripherals against an expected state. Just a forest of proprietary commands and flash chip access methods.
So the drive, hypothetically speaking, can only leak the encrypted content and any intentional modification of content by the drive
I was also thinking about this. Hypothetically speaking this works, though, encrypted setups tend to have an unencrypted bootloader and kernel stored on the drive itself, so the drive could gain access over the host. Though both can be required to be signed, just have to be sure to enable that.
I have a last question…
I have various external usb mass storages infected since 2015 by a malware that I identify
in (probably) something derived from the stolen code of Hacking Team’s Galileo.
Now, if I would like to move the data from those storages to a Librem laptop with PureOS simply connecting the storages via usb to the Librem, how much can I trust an operation like this?
In other words, with this operation are the Librem’ security features (of pureboot, of pureOS, etc…) sufficient to avoid an infection on the Librem?
I don’t care about the storages, i care only about the data, but I fear to infect a just bought laptop. I don’t know how to solve the problem…
I imagine the answer (if exist) is not easy…
This is technically an independent question, so you should have created a different thread for that. The answer is that you probably should not trust PureOS here if the USB sticks are likely malicious. You should try Qubes OS instead to be on a safe side. Qubes OS isolates USB devices in a separate virtual machine, and they cannot attack the whole system.
Depends how much you care about the data.
Once something is subject to malware there is really no guarantee. The drive content itself could have been altered maliciously in any number of ways. The correct approach is to restore from backup. However I understand that that could be tricky if the infection occurred in 2015 and particularly if you only became aware of it some time afterwards.
I am not familiar with “Galileo” but a lot of malware is dependent on the operating system and so would be harmless if the content is used from Linux. (On the other hand, if it has specifically targeted Linux then something on the drive could have been maliciously altered with a view to triggering a Day 0 in some component that will access the file system on or a file from the infected drive.)
That is over and above malware that may have altered the drive firmware i.e. in addition to altering the drive’s contents or instead of doing so.
Ok, understood.
Thank you