IPFire 2.27 - Core Update 171 released [SECURITY ADVISORY]

[siosios]

Today, we release IPFire 2.27 - Core Update 171. It updates major parts of the distribution, such as the kernel and the IPS engine, and features bug fixes as well as stability and security improvements - most notably, upstream fixes against a strain of vulnerabilities in the kernel's WiFi components. Particularly IPFire users running WiFi networking hardware are advised to install this update as soon as possible, and reboot their systems afterwards.
Also, this Core Update initiates the deprecation of IPFire support for 32-bit ARM hardware, ultimately taking effect on February 28, 2023.
Modernizing system components

Several core parts of IPFire have been updated and modernized:

• Suricata has been updated to the 6.x versioning branch, after a show-stopping issue (#12548) has been resolved upstream. IPFire users will benefit from more stable, secure, and versatile IPS functionality.
• The Linux kernel has been updated to 5.15.71, providing IPFire users with hardware support improvements and security fixes.
  
  • Most notably, it resolves issues affecting ASIX USB3-to-LAN adapters using the ax88179-178a driver.
  • Upstream patches for fixing CVE-2022-41674 and CVE-2022-42719 to CVE-2022-42722 have been incorporated, plugging several security vulnerabilities in the kernel's WiFi components that could have lead to RCE and DoS attacks, simply by emitting crafted WiFi beacons.
  • To cut attack surface, some debugging functionalities have been removed, for which there is no legitimate use-case on an IPFire machine.
  • ARM installations will experience a security benefit thanks to seccomp support enabled. Doing so previously caused issues on some boards, hence it was enabled on x86 only.
  • Mathew McBride submitted patches to add support for the 64-bit ARM Traverse Ten64 board family.

Sunsetting 32-bit ARM support

Back in the glory days, the IPFire development team was optimistic about ARM becoming an affordable yet powerful alternative to the x86 architecture. Support was added in IPFire 2.11, 13 years ago. Soon, we finally would see some diversification among the hardware landscape, forcing competition and ultimately better products - or so we hoped.
Disappointment kicked in just two years later, when we realized hardware vendors were just dumping new SoCs on the marked without caring about proper operating system support at all. Existing boards disappeared quicker than the kernel developers could reverse engineer them and implement drivers. Very few of these boards actually met IPFire's demands, such as having at least two properly connected NICs.
Things did not improve afterwards, as we had to assess that there was no innovation on the market, and given the hardware specifications of the vast majority of 32-bit ARM boards, the architecture quickly became very much a legacy burden to us. Maintaining our own ARM kernel patchset started to eat into the spare time of IPFire's developers, while the amount of IPFire installations actually running on ARM never exceeded 10%. At some point, we decided not to support any additional SoCs without proper mainline kernel drivers, to prevent the situation from escalating to a DDoS against the people behind IPFire.
Today, despite significant efforts on our part, we are left with a patchy list of ARM boards supported, scanty upstream support (much like 32-bit x86), and a general disinterest in this architecture. Unsurprisingly, at the time of writing, only 0.86% of all IPFire installations out there run on 32-bit ARM.
Due to all these reasons, we decided to discontinue IPFire support for 32-bit ARM on February 28, 2023. Users are recommended to replace their hardware; after that date, IPFire won't provide updates for this architecture anymore.
64-bit ARM board support will continue, and while it is not a mainstream architecture to us (backing only 1.25% of all IPFire installations), supporting it is much less of a hassle, thanks to better upstream development and big server vendors and cloud providers rapidly shifting to 64-bit ARM. As to be expected, the boards available are much more powerful and suitable for firewalling purposes as well. We hope our decision will gain us resources to focus on more important work, such as the development of IPFire 3.
Miscellaneous

• Perl, all its modules and related packages were updated to 5.36.0, resolving functional and security issues.
• The toolchain, comprising of glibc, binutils and more, was modernized as well.
• linux-firmware, the conglomerate of proprietary 3rd-party firmware files, has been updated as well. By removing some firmware files related to unsupported hardware, especially Bluetooth devices, we save a couple of megabytes.
• Creating full-ISO backups is now possible again, resolving #12932.
• libsodium is now shipped with the core system, required as a dependency to some add-ons (#12929).
• Faulty links to IP blocklist source websites have been fixed (#12938).
• Orphaned RRD graphs are now cleaned automatically on a weekly basis, saving disk space.
• NUT logs can now be viewed in the web interface (#12921).
• Connections to literal IPv6 addresses no longer crash IPFires' proxy (#12826).
• IPFire's default domain is now used for DHCP leases where no domain can be determined, rather than defaulting to localdomain.
• Updated packages: bind 9.16.33, binutils 2.39, curl 7.84.0, dhcp 4.4.3-P1, efibootmgr 18, efivar 38, expat 2.4.9, glibc 2.36, iproute2 5.19.0, kbd 2.5.1, libarchive 3.6.1, libhtp 0.5.41, linux-firmware 20220913, nettle 3.8.1, OpenVPN 2.5.7, Perl 5.36.0, sqlite 3390200, Squid 5.7, strongSwan 5.9.7, Suricata 6.0.8, udev 3.2.11, Unbound 1.16.3, util-linux 2.38.1, wireless-regdb 2022-08-12
• Updated add-ons: elfutils 0.187, fetchmail 6.4.32, hplip 3.22.6, lcdproc 0e2ce9b, ncat 7.92, rsync 2.3.6, Tor 0.4.7.10

As always, we thank all people contributing to this release in whatever shape and form. Please note IPFire is backed by volunteers, maintaining and improving this distribution in their spare time - should you like what we are doing, please donate to keep the lights on, an consider becoming engaged in development to distribute the load over more shoulders.


More...