Hi, Over the last month I suggested two different approaches to improve the ImageBuilder security. The amount of feedback was fairly low, maybe partly because it's not trivial to understand the issue. I wrote a summary of the two approaches and the current problem, please spend the 5 minutes to read through it. It's a release goal for 20.x.
The current state of 19.07 ImageBuilders is insecure as the packages that are missing locally are downloaded via unencrypted HTTP and then directly installed, without any signature verification. As a consequence, images could contain malicious binaries if an attacker was able to intercept traffic. For now the SNAPSHOT ImageBuilder uses HTTPS for package downloads, which is suboptimal as HTTPS slows down the build process by about 50%, due to missing connection pooling in OPKG. A better implementation is to use OPKG signature checking (via `usign`), which is fast and the same mechanism as on running OpenWrt devices. However, the ImageBuilder offer a special folder called `packages/`, which contains `kernel-*.ipk`, `libc-*.ipk` and any other optional `ipk` files provided by the user. The folder is indexed after every change. The use case is that locally built packages can be included in images, instead of providing them via a remote repository. This folder adds the challenge for signature checking. OPKG can not *only* check remote feeds and trust local feeds. Below are two possible implementation to allow signature checking while allow a local `packages/` feed. ## Possible implementation Both implementation have their advantages and drawbacks, this document summarizes two different approaches to simplify the decision. ### Add trusted feeds to OPKG The approach adds a new feed type which is always trusted, as in *no signature checks are done, even if globally enabled*. This was done by adding a new feed prefix to OPKG, either `src/trusted` or `src/gz/trusted`. The local `packages/` feed is added as `src/trusted` and work independently of `option signature_check`. This implementation involves changes in OPKG [here][1] with a bit of glue code in the build system [here][2]. [1]: https://patchwork.ozlabs.org/project/openwrt/patch/20200916011041.1746959-1-m...@aparcar.org/ [2]: https://patchwork.ozlabs.org/project/openwrt/patch/20200916012457.1748220-1-m...@aparcar.org/ It is simple and the only possible attack is to modify the repositories file and set a feed from `src/gz` to `src/gz/trusted`. In that case it would also be possible to replace the entire feed address, therefore a minor *security issues*. ### Let ImageBuilder create signing keys The approach runs the same signing key generation steps as the build system. The keys are used to sign the local `packages/` feed and therefore don't require any additional changes in OPKG. Arguably this approach is a bit awkward because a feed is verified by a public key which was created on the very same machine. On the other hand, this approach brings the advantage that created images can contain a `usign`/`ucert` signature, so that created images are verifiable by the on device running `sysupgrade` process, if the ImageBuilders local key was previously included. This implementation exists [here][3] with the extra option to include the locally generated key in the build images. [3]: https://github.com/openwrt/openwrt/pull/3477 Best, Paul _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel