[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20240817.shahka3Ee1iy@digikod.net>
Date: Sat, 17 Aug 2024 17:56:11 +0200
From: Mickaël Salaün <mic@...ikod.net>
To: landlock@...ts.linux.dev, oss-security@...ts.openwall.com
Cc: Jann Horn <jannh@...gle.com>,
Günther Noack <gnoack@...gle.com>, Paul Moore <paul@...l-moore.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, linux-security-module@...r.kernel.org
Subject: Landlock Houdini fix: CVE-2024-42318
Hi,
On July 24, Jann Horn reported [1] a security issue in Landlock [2]. He
provided a fix and a proof of concept. Many thanks for all this work!
He discovered a logical bug that makes it possible for a process to
escape its sandbox and bypass any Landlock restrictions. This is due to
a missing LSM hook implementation for the special case of keyctl(2)'s
KEYCTL_SESSION_TO_PARENT. This issue is now identified as
CVE-2024-42318 [2].
[1] https://bugs.chromium.org/p/project-zero/issues/detail?id=2566
[2] https://landlock.io/
[3] https://cve.org/CVERecord/?id=CVE-2024-42318
The issue was fixed a few hours later [4] and we developed a dedicated
test [5] to make sure the fix works as expected and that the issue never
happens again. This was merged in Linux 6.11-rc1 [6] published July 28.
[4] https://git.kernel.org/torvalds/c/39705a6c29f8a2b93cf5b99528a55366c50014d1
[5] https://git.kernel.org/torvalds/c/cc374782b6ca0fd634482391da977542443d3368
[6] https://git.kernel.org/torvalds/c/86b405ad8d0d2994a7ffbacb8fcf83be8afb952c
The fix has also been backported to:
- Linux 6.10.3 (released on August 3)
- Linux 6.6.44 (released on August 3)
- Linux 6.1.103 (released on August 3)
- Linux 5.15.165 (will be released in a few days, but in the meantime
you can cherry-pick
https://git.kernel.org/stable/c/0d74fd54db0bd0c0c224bef0da8fc95ea9c9f36c)
This vulnerability only impacts sandboxing put in place by Landlock, but
the kernel is not at risk, nor system services. The impact is limited
thanks to the stackable LSM infrastructure.
To fix this vulnerability, only the kernel needs to be updated, not the
sandboxed programs which will automatically be well-sandboxed with an
up-to-date kernel. Sandboxing with Landlock is really an investment to
leverage current and future Landlock features.
To exploit this vulnerability, an attacker needs to have full code
execution including the ability to perform arbitrary syscalls,
especially keyctl(2). Complementary security mechanisms can be put in
place to avoid arbitrary code execution or arbitrary syscalls (e.g.
with seccomp filters).
To test the fix, here are simple steps to run on an up-to-date kernel
source tree (Linux 6.6.44 to run these tests with an unprivileged user):
make alldefconfig
make TARGETS=landlock kselftest-install
./tools/testing/selftests/kselftest_install/landlock/base_test
# The global.cred_transfer test should pass.
Landlock is a defense-in-depth security mechanism. Even if it is
already useful to protect users and applications, it should not be the
only security layer for the system, mainly because it is not a full
feature access control system yet. As explained in the documentation
[7], some actions may not be restricted yet, which may also be the case
for other security modules. We are working to extend the access control
types [8], but it takes time and resources to build a new unprivileged
access control system properly handling Linux specificities.
[7] https://docs.kernel.org/userspace-api/landlock.html#filesystem-flags
[8] https://github.com/orgs/landlock-lsm/projects/1
Looking at the other side, it is interesting to note that Landlock can
also limit the impact of similar potential vulnerabilities affecting
other access control systems.
This issue also started a discussion to improve (or remove) the
KEYCTL_SESSION_TO_PARENT special case [9].
[9] https://lore.kernel.org/r/20240805-remove-cred-transfer-v2-0-a2aa1d45e6b8@google.com
We are two official reviewers for Landlock, but contributors and other
reviewers such as Jann (who previously reviewed the initial Landlock
code) also work on making changes as safe and secure as possible. The
Linux kernel needs more eyes, time, and experts to proactively find
these kind of issues. If you are interested, reward programs [10] may
help.
[10] https://alpha-omega.dev/
Regards,
Mickaël
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.
