4 ms·

Sure... 1) Still no dnssec on archive.openwrt.org 2) Still no tls on archive.openwrt.org Those together mean you can poison the dns for it and it will downloa

Sure... 1) Still no dnssec on archive.openwrt.org 2) Still no tls on archive.openwrt.org Those together mean you can poison the dns for it and it will download packages from your fake site. And... 3) Problem was introduced Feb 2017, nobody checked tampered packages were still rejected until 2020. With 3) it means anyone can put whatever they want in the fake packages and the OS will install them. I don't need much from my router but I need it to be secure. So I got rid of openwrt the next week.

dastx 6y ago
If archive.openwrt.org is like any other *nix package management software, it's likely that it doesn't need dnssec or tls. The signature of the packages get verified based on predefined public keys. If the packages aren't signed by openwrt's private keys, the software will reject it. You'll notice many other package management software do the exact same thing. In any case, this is based on what other package management software does. I don't know if this is indeed the case.
- outsomnia 6y ago
  That is indeed the theory. But the point here is how openwrt broke that "last / only line of defence" package signature check and nobody noticed for three years and two major releases.
  - dastx 6y ago
    I am not aware of this. What happened?
    - outsomnia 6y ago
      As I linked above, introduced Feb 2017 found Jan 2020 https://openwrt.org/advisory/2020-01-31-1 https://openwrt.org/advisory/2020-01-31-1 A bug in the package list parse logic of OpenWrt's opkg fork caused the package manager to ignore SHA-256 checksums embedded in the signed repository index, effectively bypassing integrity checking of downloaded .ipk artifacts.