I received a Error " Boot Hash Mismatch" when I booted my Librem 14 this morning October 23, 2024. How can I verify this is because of an update not tampering?
Grub, System, VML, Config, initrd indicate
5.10.0-30-amd64
Thanks All
2 Likes
Did you recently update the operating system kernel?
I’m not sure. I know that seems weird but I did an up date on several applications and the system update may have taken longer to load. I’m away from home and the cellular and hotel networks may have been slow enough to cause the delay. That is why I’m looking for a way to verify that the up date is legitimate. I don’t normally do updates or upgrades away from my home network. Thanks for any and all help!
1 Like
That question can’t be answered by a boot hash. A hash mismatch will occur regardless of whether the update was legitimate i.e. any boot update, whether legitimate or not, will change the hash value and will create a need to re-sign.
Generally speaking only legitimate updates should happen because the authenticity can be verified automatically by e.g. apt before the update is applied. However that depends on a range of settings.
The real purpose of the boot hash is against that evil maid who is working at the hotel where you are staying i.e. have you left your laptop unattended at any time?
(I personally think that updates that will create a need to re-sign should be more intrusive and give you a ‘louder’ warning - so that you can decide to defer the update or so that you can re-sign immediately. However that would require upstream work.)
Likewise. On any computer. For exactly this kind of reason.
Do you have a LiveBoot USB with you?
1 Like
I suggest holding off any network activities on the Librem 14 for now. Assuming you are using PureOS, you can look through /var/apt/dpkg.log for a history of apt actions.
True but if you genuinely suspect that the evil maid has been at work then at a bare minimum you need to do that from a LiveBoot. Hence my question.
1 Like
No live boot. I have my librem key. My key gave me the Boot Hash Mismatch error and red screen . I don’t suspect physical tampering. My worry is; could this result from a network attack? If so how do I verify? Could this mismatch be the result of my update of application packages which resulted in / triggered a OS system upgrade / update?
Thanks
1 Like
Then your next best option is to boot normally and follow the advice in Frankly’s post. That will show what packages were updated and hence whether it is plausible that one of the packages that was updated changed a file that is covered by the boot hash.
That said, I am not sure whether that path is correct. On my system I see /var/log/apt/history.log for things installed recently via apt and /var/log/dpkg.log for anything installed via dpkg whether directly via dpkg or indirectly via apt (and with the latter log file having rather more detail, probably too much).
However we should be honest. A maid whose IT skills are much greater than her cleaning skills could disguise her intrusion from such checking - and the same would apply to a sophisticated network attacker.
One thing that I am not sure that you have covered is whether the root file system is encrypted. If so, then that at least raises the sophistication bar since /var/xyz is most likely on the root file system.
I’m not aware of any high-profile serious, outstanding security fails at the moment, never mind about ones that can be used by a remote attacker, but new 0-days pop up from time to time.
If you are concerned about network attack then that obviously asks questions about what your network attack surface looks like. What services running? Configured to allow remote access? Firewalled? Strengthened? etc.
1 Like
Thanks, Boot, Drives are all encrypted.
I’ll move forward on the assumption that the files were downloaded during the update of the application files and are correct. I can then verify as suggested.
Hopefully all is good and the extended downloads were do to a slow network.
Thanks to all for your help.
1 Like