Can/should we prospectively drop various kernel capabilities related to firmware access?

["Peter Müller" <peter.mueller@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 3629 bytes --]

Hello *,

a while ago, we tried to enforce an "integrity" lockdown of the kernel by enabling
LSM, and enforcing this mode through the kernel configuration. Ultimately, the latter
was reverted due to firmware flashing rendered unusable, since direct PCI access,
/dev/mem and various other sensitive functionalities were crippled by LSM.

The other day, I stumbled across https://eclypsium.com/2022/06/02/conti-targets-critical-firmware/,
and would like to take this article as an opportunity to discuss the kernel capabilities
we prospectively want to support in IPFire again. (A news comprehension of that article
is, for example, available through https://www.bleepingcomputer.com/news/security/conti-ransomware-targeted-intel-firmware-for-stealthy-attacks/.)

It is not news that ordinary threat actors are capable of deploying UEFI/BIOS rootkits.
The first UEFI rootkit used in the wild was spotted in 2018, and TrickBot features such
capabilities since 2020 at the latest. To the best of my knowledge, non-state backed
miscreants targeting things like Intel ME in "production", however, is a new development,
and certainly a worrying one.

When asked, we regularly state IPFire is not a general-purpose distribution, and
anything being too far from the duties of a firewall should be run elsewhere. (In my
perception, we do not state this bold enough, but let's leave that as it is for the
time being.) Following this principle, I would like to see things such as the multimedia
stack we currently support in IPFire 2.x go in IPFire 3.x. As for kernel capabilities and
attack surface, dropping virtualisation support would cause a more noticeable improvement,
but I am not sure if this is feasible even for IPFire 3.x.

However, with regards to firmware flashing capabilities, I am quite torn: On the one
hand, as stated in the aforementioned report, the threat of firmware implants being deployed
by cybercrooks en masse particularly _stems_ from firmware being outdated, and even
sensitive environments often remain vastly unpatched. Providing IPFire users with an
easy possibility of updating their firmware therefore is a good thing, presumed they
actually do so. (Which I doubt, given that even after five weeks, merely 40% of all IPFire
installations run on an up-to-date Core Update, according to Fireinfo. With less than
half of our userbase installing updates in a somewhat timely manner, I doubt the majority
of them will even consider firmware updating.)

On the other hand, if IPFire's kernel would lack abilities required to flash firmware,
deployment of UEFI/BIOS rootkits and eventually Intel ME/SMM implants would be significantly
hampered. From an academic standpoint, the little we support, the better.

Though, again, regarding post-compromisation activity, we have always preached that
IPFire is not intended to have any 3rd party code run on it. If an attacker manages to
do this somehow, it's curtains either way. More skilled threat actors are likely to bring
their own toolkit.

In my opinion, making decisions for IPFire 3.x is a bit too early, with the Pakfire Build
System being somewhat-ish working, and something like an 1.0 version of IPFire 3.x anticipated
by the end of the year (unforeseen incidents not taken into account). However, I think it
is good to have such debates on principles solved sooner rather than later, to avoid breaking
changes to security concepts being introduced in production. :-)

If anybody has some thoughts and opinions to share on this front, I am happy to hear them.

Thanks, and best regards,
Peter Müller