Critical 7-Zip Vulnerability Let Attackers Execute Arbitrary Code
OK, I haven't set out to post about potential security issues but when something comes across that looks like a potential risk to OpenWRT then I need to ask about it here. What caught my eye is the reference to SquashFS in the context of this CVE given that SquashFS is a common deployment format for OpenWRT releases.
Plz advise...
Many Thx
Integer underflow in zstd decompression code.
Debian tracker says their 7zip and p7zip packages affected. I don't think these are built for OpenWRT, or?
Linux kernel decompresses lzma squashfs. No 7-zip, no zstd.
Cool.
OpenWRT does include the libarchive package which supports 7z zstd:
https://git.openwrt.org/?p=feed/packages.git;a=tree;f=libs/libarchive
Not sure where their zstandard decompressor originates from though.
Also saw a few files, probably just patches and makefiles, in openwrt.git/tools:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=tools/7z
First of all, every security bug needs fixing, before even thinking about the question if it applies - or not.
That said, a 'normal' OpenWrt installation (image provided as-is) is not affected by this, neither libarchive nor 7-zip are part of the default installed package set, you'd need to install them explicitly (or explicitly install other packages depending on them). This means no new OpenWrt version update would be needed for this, 'just' an update to the affected packages.
When it comes to the actual effect on OpenWrt, that's going to be even smaller. As mentioned, for squashfs, the decompressor is inside the linux kernel - but even if that were affected similarly, nothing can mount a squashfs filesystem without root capabilities (at which point you don't need any vulnerabilities anymore, you already need to be king of the castle), nor are you likely to import/ mount 'untrusted' squashfs images on your router. You need to consider how likely it is that you might want to decompress untrusted archives on your router, for a normal package set this isn't very likely, but p2p applications, things like docker, plex or other rich media packages (parsing, decompressing, transcoding content from the web) might do this (generally packages with a rather high security surface to begin with, also quite demanding on storage, RAM and CPU). You can check using opkg or apk if the packages in question are installed on your router.
tl;dr: the default OpenWrt images are not affected. Depending on your installed add-on packages, you might need the update (opkg/ apk to the rescue).
How user uploaded content is OpenWRT's problem? Same way you can say that uhttpd serves EICAR file and is infected.
It only matters (in practice), if any of the packages on your router download and decompress untrusted content from the web on the router. As mentioned, neither of this is normally done on a router (and really shouldn't be, ever), but quite some users might want the convenience factor…
E.g. a p2p app might want to give you access to packed media contents (probably even while stuff is still downloading), docker might download/ uncompress tarballs from the web, things like plex might need decompression for extracting meta data, etc. None of these packages belong within a ten mile radius of your router, but in reality there are users of these packages.
Disclaimer: the packages above are only meant to illustrate the concept, I didn't investigate their usage of libarchive/ 7z or to which extent they may- or may not be affected.
I don't think either of us would even considering packages doing that on our border gateway, because it is a bad idea, but it happens.
libarchive does not use 7zip for extracting zstd. stop adding more eicar-s.
I'm not entirely sure what that sentence means...
Taking a quick look at their README:
7-Zip archives (including archives that use zstandard compression)
Looks like libarchive can decompress zstandard streams from 7z files.
And what this has to do with 7zip, the product with defective zstd routine?
Oh you mean in reference to this comment:
The two implementations might share some code, or might not.
Absolutely not. Own 7z demuxer and reference zstd decompressor