Known-exploit detection for the kernel

An attacker might try a number of different kernel exploits before actually getting one that works with a specific running kernel. If the kernel were instrumented to detect the failed attempts, it could alert system administrators about an in-progress attack in addition to returning an error code to the attacker. That's the idea behind a patch set proposed by Vegard Nossum: complain loudly when someone attempts to exploit a closed security hole.

Any given kernel will have both patched and unpatched vulnerabilities; hopefully the latter are far fewer than the former. When targeting a system, attackers can either figure out which kernel version is running and what vulnerabilities it is likely to have, or they can just try to exploit a bunch of recent vulnerabilities. Many attacks seem to be of this untargeted, mass-attack style, so recognizing and flagging failed attempts may help administrators put a stop to the attacks.

Nossum suggested adding an exploit() annotation to the fixes for specific kinds of now-closed security holes. For example, in sock_alloc_send_pskb() from net/core/sock.c:

    if (npages > MAX_SKB_FRAGS) {
        exploit("CVE-2012-2136");
        goto failure;
    }

In suitably configured kernels, that would put out a rate-limited message to the system logs noting a "possible exploit attempt". But, he said, the annotations should not be for all bugs, nor should they have an unlimited lifespan:

The reaction has largely been positive, though there were some concerns and quibbles. Ted Ts'o wondered if malware writers would just start checking kernel versions more carefully to avoid setting off the alarms. But Kees Cook is not convinced that testing for kernel versions will be all that effective:

Ts'o disagreed, as he believes the landscape mostly consists of distribution kernels: "testing for various distribution kernel versions, as well as specific ChromeOS and Android kernel versions, wouldn't be that difficult for an attacker, and would probably allow them to avoid detection for 99% of the Linux systems found in the wild". Cook noted that careful attackers aren't really the focus of this work. He believes that there are a lot more custom kernels installed than Ts'o does, but recognizes there is no real way to know. There are "sloppy attackers", though, who will probe all kinds of kernels without doing any checks first—Nossum's patches would potentially catch some of those.

Furthermore, Ts'o is skeptical that the enterprise distributions will even build with the CONFIG_EXPLOIT_DETECTION flag turned on. The support burden for explaining false positives (and actual attacks for that matter) might be rather high. While not speaking in any official capacity, Jiri Kosina said that he suspected SUSE would indeed turn off exploit detection to try to "maintain sanity of our support engineers".

Ryan Mallon is worried that attackers will just clean out the logs as soon as they hit upon a successful attack. But Ingo Molnar pointed out that many sites do not rely on log files on the local disk, but instead use the network or append-only media to protect their logs.

The logistics of adding the annotations as well as maintaining them going forward was another area of concern. Cook volunteered to help add annotations, but wanted to make sure that he wasn't the only one doing so. Dave Jones wondered about tests to ensure the triggers are still firing correctly when code around them changes. James Morris is also concerned about the long-term maintenance of the triggers. He is not at all sure that the feature belongs in the mainline "without at least first being proven in the field".

Adding tests could also help ensure that a vulnerability doesn't get reintroduced, which is something that has happened several times in the past, as Molnar pointed out. In addition, he said, annotating earlier bugs will help alert kernel developers to "'hotspot' areas in the kernel that tend to attract more bugs than others". The annotations will also help point out dangerous patterns in the code.

Nossum has been maintaining the patch set for around six months at this point. It consists of two base patches, one that adds the exploit() call and another to hook it into the audit subsystem, and then seven patches to add annotations for CVEs from the past two years. The latter patches are largely "one-liners in the error path of a specific input validation check". He doesn't believe there is much of a maintenance burden for the triggers and plans to maintain a public git repository with the patches going forward.

Linus Torvalds was generally in favor of the idea: "I think that it's a good idea to at least have the option to complain about certain errors, and leave markers in the logs about things that look suspicious." But he doesn't want to see annotations added for random CVEs, just those that are actually being used by rootkits or other malware. Cook and Nossum both seem to be on the same page with Torvalds; that only "serious privilege escalation issues" (in Cook's words) get annotated.

While it may not catch that many attackers, catching even one is clearly better than none. Given that the patch is lightweight, and has a low maintenance burden, it wouldn't be a surprise to see it get added to the mainline before too long. As Molnar suggested, for more security-sensitive installations, exploit() could be turned into a more active deterrent that freezes all tasks being run by the suspected UID. It could certainly be a useful tool in the ever-escalating battle between administrators and attackers.