On 2020-05-14, Mogens Jensen <mogens-jen...@protonmail.com> wrote: > I was just trying out the fw_update program on OpenBSD 6.5, deleting/ > installing all the firmware and was wondering if fw_update will verify > the files before installing? > > There is a SHA256.sig in the remote firmware directory, but no > indication from fw_update, even with verbose output, if this is > actually used.
SHA256.sig is not used here. The firmware files are in the standard package format: a specially constructed tar.gz with an embedded signature in the gzip comment. See pkg_sign(8) for more information. > Normally I would just assume that fetched files are verified, but maybe > in the case with fw_update, the rationale is that firmware files are > binary blobs so we can't know if they are malicious anyway, therefore > no reason to bother with verification. As with any other package that can install files and execute commands on your system, malicious firmware packagss would be a big problem. The signature checking is important. > As firmware is fetched over plain HTTP, I guess that in case of no > verification it would in theory make the system vulnerable to a MITM > attack, but I'm no expert. It's vulnerable to a "serve stale content" attack, i.e. sticking to an older version with vulnerabilities when a fixed version is available. But someone who can do that can also just block access to the update servers having the same end result. These can probably be mitigated by adding firmware packages to the table of vulnerable package versions in the "quirks" package in the main package set (though if that is also held back, it relies on the user to notice via the displayed timestamp, I don't hold out much hope for this really being noticed. We could make this more visible by having the quirks packages "expire" but this has problems too, especially for architectures which take a long time to build packages, or which don't have binary packages for -stable). As the firmware servers are independent and run by different people under one domain name they can't really share a private key, making it awkward to obtain certificates. Not impossible, we know how to do it using DNS-01 and copying CSRs amd certificates around, but I'm not really seeing enough benefits from running https on them to make it worthwhile.