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

Reply via email to