From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Can/should we prospectively drop various kernel capabilities related to firmware access? Date: Sun, 05 Jun 2022 15:58:46 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0251757033240997088==" List-Id: --===============0251757033240997088== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello *, a while ago, we tried to enforce an "integrity" lockdown of the kernel by ena= bling LSM, and enforcing this mode through the kernel configuration. Ultimately, th= e latter was reverted due to firmware flashing rendered unusable, since direct PCI acc= ess, /dev/mem and various other sensitive functionalities were crippled by LSM. The other day, I stumbled across https://eclypsium.com/2022/06/02/conti-targe= ts-critical-firmware/, and would like to take this article as an opportunity to discuss the kernel c= apabilities we prospectively want to support in IPFire again. (A news comprehension of th= at article is, for example, available through https://www.bleepingcomputer.com/news/secu= rity/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 fea= tures 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 f= or 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 capa= bilities 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, an= d even sensitive environments often remain vastly unpatched. Providing IPFire users = with an easy possibility of updating their firmware therefore is a good thing, presum= ed 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 l= ess 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 b= e significantly hampered. From an academic standpoint, the little we support, the better. Though, again, regarding post-compromisation activity, we have always preache= d that IPFire is not intended to have any 3rd party code run on it. If an attacker m= anages to do this somehow, it's curtains either way. More skilled threat actors are lik= ely to bring their own toolkit. In my opinion, making decisions for IPFire 3.x is a bit too early, with the P= akfire Build System being somewhat-ish working, and something like an 1.0 version of IPFir= e 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, t= o 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=C3=BCller --===============0251757033240997088==--