Re: [PATCH 1/9] Known exploit detection

Ingo Molnar
2013-12-13T12:54:20Z

* vegard.nossum@oracle.com <vegard.nossum@oracle.com> wrote:

> From: Vegard Nossum <vegard.nossum@oracle.com>
>
> The idea is simple -- since different kernel versions are vulnerable
> to different root exploits, hackers most likely try multiple
> exploits before they actually succeed.
>
> Fixing an exploitable kernel bug usually means adding a check to see
> if what a userspace program tried to do is allowed and makes sense
> (for example, writing beyond the end of an array is a bug and can be
> fixed by checking that the index provided by userspace is indeed
> within the array bounds).
>
> Instead of just returning an error when these extra checks fail, we
> can also give the system administrator a heads up that somebody
> supplied this invalid input that would have lead to elevated
> privileges on earlier versions of the kernel.
>
> This serves as a practical, low-overhead early-detection of
> malicious users (and/or buggy userspace programs) to system
> administrators.
>
> I propose limiting the annotation of known exploits to the most
> serious type of exploit, namely where the attacker otherwise
> silently gains root/elevated capabilities. For sure, there is little
> point in calling exploit() where an older kernel would just panic or
> OOM.
>
> I also propose to keep each exploit() annotation around for only ~5
> years after the bug was discovered/fixed. This will allow us to
> catch most of the intrusion attempts while still not littering the
> kernel code forever.

So I really like the basic principle of injecting a little bit more
uncertainty into the life of attackers, with one caveat: I think this
feature should also come with a way to camoflague/fuzz the kernel
version from unprivileged user-space, in an opt-in fashion.

[ I also don't like some details about the implementation, see (2)
further below. ]

(1)

Regarding 'kernel version fuzzing to unprivileged user-space', distros
and people rebuilding their kernels already frequently patch their
kernel versions, so unprivileged user-space is already pretty robust
against it.

[ We also already change the kernel version for ABI-compatibility in
certain rare cases: see kernel/sys.c::override_release(). ]

This kernel version fuzzing feature could be implemented via a
/proc/sys/security/fuzz_kernel_version sysctl file (disabled by
default), which, if activated, would 'downgrade' the kernel's version
to a random version within the last 5 kernel versions.

So if the original version says:

$ uname -r
$ 3.11.9-200.fc19.x86_64

Then after doing:

# echo 1 > /proc/sys/security/fuzz_kernel_version

The /proc/sys/security/fuzz_kernel_version sysfs file disappears from
unprivileged view [the attacker shouldn't have it _that_ easy to
figure out that fuzzing is going on] and unprivileged user-space would
get a [per boot random] vanilla kernel version reported:

$ uname -r
$ 3.9.5

Where the major version would be randomized between
(curr_major-6..curr_major-1) and the minor version would be randomized
between 1 and 10, which minor versions exist in all past stable
kernels. This fuzzed version number is stable for as long as the
system stays up.

Root will still see the real kernel version of course:

# uname -a
# 3.11.9-200.fc19.x86_64

... so that bugreports and privileged bug reporting tools like 'abrt'
get the real kernel version, etc. (Obviously system logs should not be
visible to unprivileged user-space if this feature is activated.)

This fuzzing method won't be 'perfect', because often there are
secondary indicators of the version of the kernel which will leak the
information to unprivileged user-space:

- the availability of certain newer system calls and new system-call
features

- the presence of newer sysfs and procfs entries in /sys and /proc

- obviously the real kernel version might also be visible through
distro details, such as /boot entries [this directory is not
readable on many distros], or /lib (hosting kernel modules), or
simply the package list which includes the kernel versions.

... yet this adds enough uncertainty to the real version of the kernel
(to unprivileged user-space) to trap zero-day exploits, once the
underlying kernel bugs are fixed.

(2)

I'm not sure I like adding actual CVE numbers to the kernel source
code, but it's actually pretty useful in this case, so we might as
well use that, lacking alternatives.

I don't like some details about the exploit-detection implementation:

> include/linux/exploit.h | 23 +++++++++++++++++++++++
> security/Kconfig | 14 +++++++++++++-
> security/Makefile | 2 ++
> security/exploit.c | 28 ++++++++++++++++++++++++++++
> 4 files changed, 66 insertions(+), 1 deletion(-)
> create mode 100644 include/linux/exploit.h
> create mode 100644 security/exploit.c
>
> diff --git a/include/linux/exploit.h b/include/linux/exploit.h
> new file mode 100644
> index 0000000..a8df72a
> --- /dev/null
> +++ b/include/linux/exploit.h
> @@ -0,0 +1,23 @@
> +#ifndef _LINUX_EXPLOIT_H
> +#define _LINUX_EXPLOIT_H
> +
> +#ifdef CONFIG_EXPLOIT_DETECTION
> +extern void _exploit(const char *id);
> +
> +#define exploit_on(cond, id) \
> + do { \
> + if (unlikely(cond)) \
> + _exploit(id); \
> + } while (0)
> +
> +#else
> +
> +#define exploit_on(cond, id) \
> + do { \
> + } while (0)
> +
> +#endif
> +
> +#define exploit(id) exploit_on(true, id)

I think this should be named after what it does, the feature detects
exploit attempts:

detect_exploit(id);
detect_exploit_on(id);

It should _not_ be named 'exploit()', which awfully reads like code in
a real exploit attempting to exploit some vulnerability. I'd cringe
every time I came across such a line in the kernel :-)

Likewise, the header should IMHO be named detect_exploits.h, etc.

( It might even sense to add this facility to kernel.h, to make it
easily available everywhere and to make such patches true oneliners. )

Secondly, the actual code:

> +void _exploit(const char *id)
> +{
> + /*
> + * This function needs to be super defensive/conservative, since
> + * userspace can easily get to it from several different contexts.
> + * We don't want it to become an attack vector in itself!
> + *
> + * We can assume that we're in process context, but spinlocks may
> + * be held, etc.
> + */
> +
> + struct task_struct *task = current;
> + pid_t pid = task_pid_nr(task);
> + uid_t uid = from_kuid(&init_user_ns, current_uid());
> + char comm[sizeof(task->comm)];
> +
> + get_task_comm(comm, task);
> +

get_task_comm() is overkill here: task->comm is modified very rarely
in real apps (and almost never in a racy fashion), and if an attacker
wants to hide the name of the exploit he can already hide it by doing:

prctl(PR_SET_NAME, "bash")

So I'd suggest to just use task->comm - or if you _really_ want to
expose a reliable, informative fingerprint of the exploit attempt
itself, then dump the current syscall context (current ptregs, a dump
of syscall arguments, etc.).

[ That has to be done carefully though and if then it would probably
be more useful in other places where we don't necessarily know how
the exploit works: #GPF's, NULL pointer dereferences that got caught
safely, etc. ]

> + pr_warn_ratelimited("warning: possible %s exploit attempt by pid=%u uid=%u comm=%s\n",
> + id, pid, uid, comm);

Small nit, I'd suggest the following message pattern:

"WARNING: Possible exploit attempt (ID=%s, pid=%u, comm=%s)\n"

It's easier to grep for, 'WARNING' is the pattern we use for such
things and such.

> +}
> +EXPORT_SYMBOL(_exploit);

For new facilities we generally use EXPORT_SYMBOL_GPL().

Thanks,

Ingo