I was just listening to Security Now (episode 993 @ 56m30s) . It briefly discussed a new RCE being disclosed within 2 weeks and its bad. Alleged to not need authentication, targets all Linux/BSD distributions and has been there for over 10 years.
If true, this could prove to be an opportunity to gain access to professional/commercial routers that were formerly closed off to the possibility of running OpenWRT. You might want to hold off any updates that come along if this is in your interest.
News of what appears to be a potentially serious (as in 9.9) Linux unauthenticated remote code execution vulnerability just broke. It was sent to me this morning by a listener of ours, Alessandro Riccardi. Here is what he just posted, and why it might matter, yesterday. He leads with six bullet points:
● Unauthenticated RCE vs all GNU/Linux systems (plus others) disclosed 3 weeks ago. ● Full disclosure happening in less than 2 weeks (as agreed with devs). ● Still no CVE assigned (there should be at least 3, possibly 4, ideally 6). ● Still no working fix. ● Canonical, RedHat and others have confirmed the severity, a 9.9, check screenshot. ● Devs are still arguing about whether or not some of the issues have a security impact.
It might make more sense to wait until there actually is something to report, other than clickbaity pre-announcements of certain doom to come.
By its very nature, OpenWrt evades quite a few security issues by having a minimal kernel- and userspace configuration, 'different' (smaller) packages (no, I won't list musl and mbedtls as superior, just a different set of bugs) - and not providing quite a few packages at all. Case in point, CUPS isn't available/ packaged in OpenWrt at all, so any bugs found in CUPS do not apply to OpenWrt by definition.
Let's just dissect a statement (independent of the specific case at hand) such as this:
it claims to apply to Linux and BSD operating systems, this means
it can't be a kernel bug, as Linux and BSD kernels don't share code
it can't be a libc bug, as the typical linux distributions are glibc based, while the BSDs have their own (materially different) libc implementations; OpenWrt uses musl instead
it can't be a bug in systemd, as the BSDs don't use it - nor does OpenWrt
it could be an ssl/ tls bug, affecting most systems - but most systems build upon OpenSSL, while OpenWrt defaults to using mbedtls (meaning OpenWrt wouldn't be affected by such a bug)
it could be a bug in OpenSSH, however OpenWrt doesn't use OpenSSH by default (dropbear is used instead)
it could be a bug in X.org/ wayland or one of the common desktop environments (including gtk/ qt), neither of which are available on OpenWrt
it could be a bug in chrome/ firefox, neither of which is available in OpenWrt
it could be a bug a common libraries, like libpng, libjpeg, ffmpeg and similar things, which aren't commonly used on OpenWrt (non-default) and less likely with untrusted input (given the prevalent non-interactive usage scenarios of OpenWrt)
it could be a bug in one of the common network related dæmons (samba, CUPS, etc.), neither of which are installed by default on OpenWrt (nor even available on OpenWrt, in case of CUPS)
it could be a bug in hostapd (wpad, wpa_supplicant), this is one of the more likely things to affect OpenWrt
With OpenWrt having to deal with pretty special devices, which all have a serious lack of performance, flash and RAM in common, you won't see a lot of these bugs affect OpenWrt, be it because of the packages not being available at all, not preinstalled by default or configured/ stripped down enough that a potential bug won't end up in the binary packages, because the features it is contained in are disabled for space saving reasons.
Keep in mind that a large aspect of potential security issues, stemming from interactive usage and having to accept and parse untrusted input doesn't really apply to OpenWrt in the first place, nor are privilege escalations overly critical (there are no unprivileged users with remote access).
Neither of this means that there aren't- or can't be just as serious security issues in OpenWrt, those just tend to be more targeted to OpenWrt-only and less likely to be shared with general purpose linux/ BSD.
It seems its "just" CUPS/IPP related. So it will hit the big distributions including CUPS by default only.
What you need to know for now, according to Margaritelli, is:
Disable and/or remove the cups-browsed service.
Update your CUPS installation to bring in security updates if or when available.
Block access to UDP port 631 and consider blocking off DNS-SD, too.
It affects "most" Linux distros, "some" BSDs, possibly Google ChromeOS, Oracle's Solaris, and potentially others, as CUPS is bundled with various distributions to provide printing functionality.
To exploit this across the internet or LAN, a miscreant needs to reach your CUPS service on UDP port 631. Hopefully none of you have that facing the public internet. The miscreant also has to wait for you to start a print job.
If port 631 isn't directly reachable, an attacker may be able to spoof zeroconf, mDNS, or DNS-SD advertisements to achieve exploitation. Details of that path will be disclosed later, we're promised.
It's a quite "interesting" vulnerability for various reason. Nowdays almost all printers are reachable via wifi/lan/internet. And I bet there are portions of cups/libs used to provide IPP service on this devices. And I bet again that a lot of these printers will never see any patch if affected. So a permanent threat within a network. \o/
Sorry for being the party pooper. As I saw this topic I tried to figure out how serious this is because a 9.9 is very rare and would have prop. needed actions from my side on my servers facing the www. So someone pointed me to this more detailed article which I shared here. But personally I would not classify it as a 9.9. Because most ppl. do not share their printers to the internet. So it is more a internal network threat. Which is more severe for companies.
That's true. But as far as I know its all going through their clouds. So your printer is connected to their cloud and the app is connecting through the cloud to your printer. So it is "protected" as far as you can trust what HP or any other printer manufacturer is providing in this regard within their cloud. If they use CUPS in any way I can imagine it could be devasting if other users manage it to break out from their accounts reaching other printers. But this risk is not higher now then before.
Going back to OP's point regarding force flashing some locked-down routers: it does appear some router's factory firmwre supports connecting to printer via USB and provide network printing (presumably via CUPS?), but all such routers I can think of also just allows you to flash your favorite customer firmware without asking.
It might be more useful for hacking into your locked-down, carrier-provided modems or ONT boxes -- instead of the usual way of grabbing its super admin password (like nE7jA%5m) via forum or befriending the telecom contractor. But those boxes usually has no printing functionality.
OpenWRT can provide print services as well, via p910nd (not CUPS).
Unless the locked down router has TONs of storage space it will be using something similar as p910d is much lighter than CUPS (which is 1.1mb installed v ~300k for p910nd).
As I saw this topic I tried to figure out how serious this is because a 9.9 is very rare and would have prop. needed actions from my side on my servers facing the www. So someone pointed me to this more detailed article which I shared here. But personally I would not classify it as a 9.9. Because most ppl. do not share their printers to the internet. So it is more a internal network threat. Which is more severe for companies.