Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG48ez2sZ58VQ4+LJu39H1M0Y98LhRYR19G_fDAPJPBf7imxuw@mail.gmail.com>
Date: Mon, 30 Mar 2020 17:12:58 +0200
From: Jann Horn <jannh@...gle.com>
To: bpf@...r.kernel.org, 
	Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: CONFIG_DEBUG_INFO_BTF and CONFIG_GCC_PLUGIN_RANDSTRUCT

I noticed that CONFIG_DEBUG_INFO_BTF seems to partly defeat the point
of CONFIG_GCC_PLUGIN_RANDSTRUCT.

CONFIG_GCC_PLUGIN_RANDSTRUCT randomizes the layout of (some)
kernel-internal structs, which AFAIK is intended to make exploitation
harder in two ways:
1) by ensuring that an attacker can't use a single exploit relying on
specific structure offsets against every target
2) by keeping structure offsets secret from the attacker, so that the
attacker can't rely on knowledge of structure offsets even when trying
to exploit a specific target - only relevant for the few people who
build their kernel themselves (since nobody was crazy enough to
implement generating relocations for structure offsets so far).

When CONFIG_DEBUG_INFO_BTF is on, the kernel exposes the layouts of
kernel structures via the mode-0444 file /sys/kernel/btf/vmlinux, so a
local attacker can easily see structure offsets, defeating part 2.

I wonder whether these kconfig knobs should be mutually exclusive, or
whether /sys/kernel/btf/vmlinux should have a different mode, or
something like that.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.