[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <146c9b73-9c73-4f9e-a348-cd8fbb05cc7c@yahoo.fr>
Date: Sat, 16 May 2026 19:20:52 +0200
From: Lionel Debroux <lionel_debroux@...oo.fr>
To: oss-security@...ts.openwall.com
Subject: Re: Recent Kernel exploits, attack surface reduction,
example IPSEC
Hi,
> Multiple of the recent kernel exploits have affected the "esp" Linux
> Kernel module. ESP is, as far as I understand, part of IPSEC, and I
> think it's fair to say that IPSEC is not widely used these days. I
> think this raises some questions about attack surface. I want to note
> that I use IPSEC as an example here, but it likely applies in very
> similar ways to many features that are part of the Linux Kernel and
> are not used in most common setups.
>
> For everyone who builds custom kernels and doesn't use IPSEC, it's
> probably a good idea to disable all IPSEC-related config options, e.g.:
> CONFIG_INET_ESP
> CONFIG_INET6_ESP
> CONFIG_INET_AH
> CONFIG_INET6_AH
>
> I believe IPCOM is also rarely used separately from IPSEC, so consider
> also disabling these:
> CONFIG_INET_IPCOMP
> CONFIG_INET6_IPCOMP
>
> However, there's a broader point here: I think it's common these
> days that Linux distributions install most or all kernel modules by
> default, and loading them happens automatically. Which, in many cases,
> means people are potentially affected by security flaws in features
> they never use.
> "Attack surface reduction" is widely considered to be a good security
> principle, and I wonder if we can do better here.
>
> To pick the example of IPSEC, i wonder if it wouldn't be better to
> have, e.g., a separate "linux-modules-ipsec" package that isn't
> installed by default. People who use and need IPSEC will likely know
> that they need it, and can install it separately.
>
> I'm aware this doesn't come for free, and will add increased
> complexity to kernel packaging. But think about it like this: If we
> had that separation, three of the recent kernel local root exploits
> would've been much less impactful, and wouldn't have affected most
> systems.
Not building and installing by default infrequently used modules is
indeed one of the approaches for effective attack surface reduction.
Let's mention two other ones:
1) inserting dozens to hundreds of "install XYZ /bin/true" lines in
/etc/modprobe.d/*.conf files, plus lines in /etc/sysctl.d/*.conf files.
2) making it harder for unprivileged programs to just auto-load kernel
modules corresponding to uncommon socket / filesystem / etc. types, and
exploit whichever vulnerabilities they contain. I'm thinking about the
MODHARDEN grsecurity feature here.
I've been doing some of 1) for years against repeat security offenders
(tipc, dccp, sctp !, rds, can !, ppp*, ksmbd !, firewire*, n_hdlc,
n_gsm, several uncommon filesystems, unprivileged user namespaces !!,
BPF JIT !!, io_uring !!, etc.), to the extent that distro kernels allow
such hardening: nowadays, most distros force enable the BPF JIT...
This whack-a-mole process is individual, inefficient and incomplete: I
had missed algif_aead, esp4, esp6 and rxrpc, because I hadn't seen them
featured on security vulnerability feeds before.
As for 2): a '2010 grsec patch I have lying around already contains
occurrences of "MODHARDEN". The published
grsecurity-3.1-5.10.41-202105280954.patch contains 9 occurrences of
"MODHARDEN": preprocessor guards for 8 small blocks of code (< 100 LOC
total) and the following Kconfig text (reformatted to prevent wrapping):
config GRKERNSEC_MODHARDEN
bool "Harden module auto-loading"
default y if GRKERNSEC_CONFIG_AUTO
depends on MODULES
help
If you say Y here, module auto-loading in response to use of some
feature implemented by an unloaded module will be restricted to
root users. Enabling this option helps defend against attacks
by unprivileged users who abuse the auto-loading behavior to
cause a vulnerable module to load that is then exploited.
If this option prevents a legitimate use of auto-loading for a
non-root user, the administrator can execute modprobe manually
with the exact name of the module mentioned in the alert log.
Alternatively, the administrator can add the module to the list
of modules loaded at boot by modifying init scripts.
Modification of init scripts will most likely be needed on
Ubuntu servers with encrypted home directory support enabled,
as the first non-root user logging in will cause the ecb(aes),
ecb(aes)-all, cbc(aes), and cbc(aes)-all modules to be loaded.
IOW, MODHARDEN is an old idea for hardening Linux, and its
implementation is tiny.
(BTW, looking at the aforementioned patch: 3 of these blocks of code
prevent non-fs modules being loaded through mount... which would mean
that mainline Linux can be abused to do that)
I used to use grsec kernels for daily desktop usage. MODHARDEN was
enabled in my configs and the ones of Debian-packaged kernels (I
remembered about the log splats caused by grub-probe, and I've just
checked the Debian config-4.9.0-4-grsec-amd64 file from December 2017).
My experience was that MODHARDEN didn't prevent me from doing what I
wanted and needed with my computer.
Other mileages would vary... up to a point. Some desktop and server
users would definitely be unaffected like I was.
Lionel Debroux.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
