OpenWRT remote code execution via MITM due to bug in package manager | Hacker News Reader

OpenWRT remote code execution via MITM due to bug in package manager

lists.infradead.org

89 pointsguidovranken29 comments

I never understood why domains used to NTP and Package mirrors depend on external, commercial, certificate authorities.

It could be a fallback, with a red big warning to manually check the certs are alright when you need it (e.g too long without synching your root certificates package). But for most cases there is no excuse not having it local at all times.

I mean MITM a domain essential for the "distro" should be at least just a little bit harder than regular MITM.

I've always wondered a similar thing... why is reputation-based TLD network security limited to a single verification entity (CA w/ revocation policy)? Seems obvious to me certs should be signed (and thus revokable) from multiple entities by default. I've implemented this before in clients ad-hoc, but why isn't it default?

Don't get me started on authoritative DNS security.

It's definitely an issue that the sha256 checksum check was broken.

But, can someone explain why a person who is MITM'ing ipk downloads would change the package and not the checksum?

Are there GPG signatures of the package checksums signed with a key that ships with the release?

Are package repos downloaded over HTTPS? Is there a CA bundle in the release with which repo x.509 certs are validated?

The SHA-2 checksums to verify packages against are delivered as part of the (signed) package index (as the article alludes to).

And those package repo sha256 checksums are signed and verified with ed25519 by usign and ucert (with a key built into the firmware)

usign: https://git.openwrt.org/project/usign.git

ucert: https://git.openwrt.org/project/ucert.git

Firmware releases are also signed with GPG: https://openwrt.org/docs/guide-user/security/release_signatu...

openwrt/openwrt: https://github.com/openwrt/openwrt

openwrt/packages: https://github.com/openwrt/packages

openwrt/openwrt/search?q="usign" https://github.com/openwrt/openwrt/search?q=usign

I installed newest version OpenWRT on a popular brand, recently manufactured wireless router last week.

The OpenWRT firmware couldn't access https sites without installing multiple packages first. Then they had me install all the root certs over an unencrypted connection. The opkg repos and install files are all downloaded over http.

With full seriousness, I really hope nobody expects operational security using these routers.

Oof. Well I hope that this episode has a positive outcome in that OpenWRT improve their install and packaging security.

>The opkg repos and install files are all downloaded over http.

This was a problem because of the bug. But now it isn't one anymore. 'opkg update' updates the package lists. The lists contain information about the packages: name, file size, architecture, description etc., and also the SHA256sum. When you install a package opkg will compare the SHA256sums.

For those who are using the Turris OS OpenWrt derivative: fixed in 5.0-rc0, for 4.0.x there is a bigger problem they are working on, for 3.x it might not have been introduced yet

Calling that remote code execution is a bit of a stretch. Maybe technically accurate. don't know.

Why, because it requires a MITM position?

Actually, using a DNS server serving the wrong IP for downloads.openwrt.org will have the same effect.

Why, because it requires a MITM position?

Yes, pretty much.

Tangentially related: I want to run OpenWRT but need at least 500Mbps WAN/LAN filtered routing capacity; my old tp-link 4300 barely manages 150mbps; can anyone recommend a modern home WiFi/router that can run OpenWRT and do line speed packet filtering between WAN and LAN?

For ac, 500+ Mbps is primarily feasible only at 5 GHz around 2 m / 5 ft away. WRT3200ACM

If you care about performance rather than open source purity tests, Asus RT-AX88U is the way to go.

Thanks. I should have made this more explicit, but I care less about the WLAN performance (as long as it's ok) - I care more about the wired one.

Most OpenWRT ports don't offload the LAN/WAN routing, and doing it on a lowly ARM CPU often effectively limits this to a few hundred megabits - e.g. 150mbps on my WDR4300 (which does manage 800Mbps for the same task with the original closed firmware which does do some hardware offloading)

Get a Xiaomi Router 3G. It is more difficult to do an initial flash, but is well worth it with an awesome $40 price tag on Aliexpress. Only downside is that it only has 3 GigE ports.

Please not, shitty wifi stability and much more: https://forum.openwrt.org/t/xiaomi-wifi-router-3g/5377/1187

I have three of them serving 802.11n on 2.4 and 802.11ac on 5 gigs and all work fine.

Know some people who use them for a bridged setup over ac standard. No issues there as well.

I'm running OpenWRT on a Netgear R7800 and see 940Mbps between lan and wan (that's wired lan, not wireless) with flow offloading enabled.

I use OpenWRT on a Linksys WRT3200ACM. It has a dual core ARMv7 cpu running at 1.8GHz, with 512MB of memory. It does very well, in my opinion.

My PC with an Intel Wireless-AC 9260 has the following network connection, reported by the OpenWRT interface: "400.0 Mbit/s, 40MHz, VHT-MCS 9, VHT-NSS 2, Short GI 400.0 Mbit/s, 40MHz, VHT-MCS 9, VHT-NSS 2, Short GI"

My work 2018 Macbook Pro gets the following: "540.0 Mbit/s, 40MHz, VHT-MCS 9, VHT-NSS 3 600.0 Mbit/s, 40MHz, VHT-MCS 9, VHT-NSS 3, Short GI"

Mine and my wife's LG V40 Android phones get this reported speed: "400.0 Mbit/s, 40MHz, VHT-MCS 9, VHT-NSS 2, Short GI 6.0 Mbit/s, 40MHz"

Not sure if there's any extra information I can provide. I'm not affiliated with Linksys.

I’ve considered getting the new Linksys. It’s been hard to justify its price tag though next to another router I would also highly recommend, the GL.iNet B1300. I have bought three of those so far and will buy one or two more when they go on sale again.

I forget which ARM chip it ships with, but it’s capable of pushing almost 200Mbps on WireGuard, and it’s a significant bargain over the Linksys. Its antennas probably won’t cover same distance as the Linksys though—that works in my small apartment or if you use a couple of them in a mesh network. For a bigger house and if you like to keep things simple, the Linksys or the Turris are probably the best options.

https://www.gl-inet.com/products/gl-b1300/

"The bug has been introduced with commit https://git.openwrt.org/54cc7e3 which failed to advance the proper string pointer when skipping the leading white- space portition of the checksum string, causing the subsequent hex decoding loop to return early with a zero length checksum."

I can't believe someone messed up something so simple! ( Sarcasm )

There HAS to be a better way lmao

If one is of the tinfoil hat persuasion, then

https://en.wikipedia.org/wiki/Underhanded_C_Contest

Yeah, yuck, this definitely could have been avoided if they did some proper lexing/parsing before dealing with the line, instead of manually separating things apart after matching on the beginning of the string...

That said, perhaps it's just too early in the morning but I don't think that commit introduced the error. The math/logic looks to be identical and I think the bug is `line + strlen("SHA256sum") + 1` which was already there before and doesn't increment past any spaces which might come after the (implied I guess?) colon. Though considering the colon isn't checked for in `SHA256sum`, you could put any character there and it'll work. Yay...

Nice catch I think. I’ll be damned if I can see a difference. Looks like the old code will also skip the checksum in the case of any non hexdigit padding.

Fixt in new builds of OpenWrt. If you are running the 18.xx or 19.xx branches then update to latest and all is good again.

Just updating isn't a very safe way to upgrade, use what they suggest in the mail instead:

To update the opkg package itself without upgrading the entire firmware, the following commands may be used once all repositories have been updated:

   cd /tmp
   opkg update
   opkg download opkg
   zcat ./opkg-lists/openwrt_base | grep -A10 "Package: opkg" | grep SHA256sum
   sha256sum ./opkg_2020-01-25-c09fe209-1_*.ipk

Compare both checksums and, if matching, proceed with installing the package:

   opkg install ./opkg_2020-01-25-c09fe209-1_*.ipk

I'm confused, they recommend using your vulnerable version of opkg to update opkg?

In that recommendation, they provide clear and easy to follow instructions for doing the checksum verification manually before applying the update.

> Compare both checksums and, if matching, proceed with installing the package

Reply on news.ycombinator.com