Security

LSS: The kernel hardening roundtable

Hardening the kernel to make attackers' jobs harder was the topic of a wide-ranging discussion at the Linux Security Summit (LSS) held on September 8, 2011. Reducing the attack surface of the kernel, protecting it from user-space attacks, and finding ways to mitigate entire classes of exploitable bugs were all on the table. As might be expected, the biggest barrier to getting these hardening patches accepted into the mainline is often performance concerns. While no firm conclusions were drawn, many ideas were discussed, some of which may eventually find their way into the mainline.

Attack surface

The discussion began with an effort to quantify the "exposed surface" of the kernel as roundtable leader Will Drewry of Google's Chrome OS team put it. He and the other roundtable leader, Kees Cook of the Ubuntu security team, put together their own list, but also asked those present to add to it. Obvious attack surfaces like the system call interface, /proc and sysfs files, the networking stack, and device drivers were mentioned, but also less obvious things like filesystem parsing, auto-loaded kernel modules, device scanning, CPU or other hardware bugs, side-channel timing attacks, and so on.

Enumerating the attack surface "helps define what to pay attention to", Cook said. The intent of many of the kernel hardening patches is to try "to kill off a whole class of problems, rather than shooting individual bugs", he said. The latter is where most of the current kernel security effort goes, he said. Drewry added that the intent is to figure out what can be done now to reduce those attack surfaces. Many of the attack surfaces are still present even in a system that runs a mandatory access control (MAC) system like SELinux, Cook said, because the system call interface is still available to be used (and abused). That is one of the problems with looking to the LSM interface to provide confinement, he added.

Casey Schaufler also pointed out that there is often special-purpose hardware in Linux systems—in years past it was graphics hardware, but these days tends to be video hardware—that is allowed to be directly accessed from user space. That opens up a number of potential security problems, he said, but that won't stop it from happening. The capabilities provided by allowing direct access to these devices are "so compelling that security concerns are secondary".

But there are kernel installations that are more security-sensitive, Cook said, that could benefit from restricting some features even at the cost of performance. If a particular hardening feature has no real cost, it could be put into the kernel without providing a configuration option to disable it. Others, that do have a cost, could be optional and distributions or users could enable them based on their needs.

API/ABI restrictions

The "biggest single exposure" in Linux systems is applications that run as root, Schaufler said, like the X server. Because the kernel is one "gigantic privileged application" it can't be protected against other privileged applications like X, Cook said. But, applications could have the ABI available to them reduced, Drewry said, which would reduce the damage they could do if they are compromised.

The only existing "API management" tool in the kernel (besides the LSM interface) is seccomp, but it is too restrictive to be useful for many applications, Drewry said. Since seccomp only allows four system calls (read(), write(), exit(), and sigreturn()), it is too limited for many possible reduced-ABI applications. The Chrome/Chromium browser team would like to be able to reduce the system calls that its rendering processes can make. Seccomp is too limited for Chromium's needs, so they have implemented a more complicated solution, with a "trusted" assembly language thread that mediates system calls. System call restrictions could also be enforced using ptrace(), Drewry said, but there is an "intense amount of overhead".

What Drewry is looking for is some kind of expanded seccomp where a subset of system calls would be allowed. So far, his patches to implement that have been shot down from various directions, but there is hope that there may be some kind of resolution at the upcoming Kernel Summit.

Some of the attendees were skeptical of an expanded seccomp approach. Schaufler pointed out that there is already a mechanism in the kernel (capabilities) for reducing the impact of vulnerabilities, but "no one uses it". Cook was not convinced that the granularity of capabilities was really all that useful because the number of capability bits that are equivalent to root is so large.

As Drewry cast about for a way to limit system calls, there was discussion of possibly augmenting the LSM interface. As Cook pointed out, the current interface does not mediate all system calls, so it can't be used for Drewry's use case as it stands. James Morris noted that LSM is intended to be an access control framework and not anything more than that. In the end, Drewry doesn't particularly care how to get there, he is just looking for a way for "reducing what I expose to untrusted applications", he said.

Schaufler also pointed out that reducing the ABI available to an application doesn't help "if the ABI is completely well-defined and if it is consistent with the security policy" of the system. "That's a lot of 'if's", Drewry responded, to general agreement, that neither of the two conditions are met on Linux systems. Because the system call interface is not well-defined, nor necessarily consistent with the system security policy, reducing the exposure of parts of that interface can help. Schaufler cautioned that the ad hoc documentation makes it hard to decide where the bugs actually are: "If the code is the documentation, it is impossible to have a bug".

There were questions about whether seccomp filtering (in whatever form) would actually be used by applications. Cook noted that, in addition to Chromium, several other projects popped up on linux-kernel to express interest in the feature, including QEMU, vsftpd, and others. One attendee also hypothesized a DNS server that was limited to recvmsg(), sendmsg(), and write() (to a log file) as another possible use-case.

There were also concerns that seccomp filters would spread security policy throughout the system, but others saw that as a feature. Unlike MAC policy, which tends to be imposed from the outside, seccomp filter policy would embody "the programmer's idea of what it should be able to do", as Cook put it. While the system call granularity may not be exactly right, it is the place where user space enters the kernel, so mediating at that point makes some sense.

Attendees theorized that if a flexible seccomp filter facility was available, multiple applications would take advantage of it. Smalley was a bit skeptical that it would be straightforward for most applications to use the facility because it might require a major rework of the program. He pointed to the privilege separation efforts that went on in OpenSSH as an example. That required "significant refactoring", he said.

Drewry said that the Chromium team's plan is to move the browser to whatever solution becomes available to better contain the renderers. Right now, that is the "trusted thread" sandbox, but if there are other facilities available, Chromium will use them. That could be some kind of SELinux containment, seccomp filtering, or something else entirely. In the future, the team would also like to confine renderers based on where the data comes from, he said, so that all renderers running for a given site were protected from each other as well.

PaX and grsecurity

The roundtable wrapped up with some discussion of bringing more of the grsecurity and PaX hardening patches into the mainline. Those patches tend to be fairly intrusive and have performance implications that make them undesirable to many kernel hackers, but they do provide protections that some would find valuable. According to Cook, there are many pieces of grsecurity and PaX that could make their way into the mainline.

Simple things, like constifying function pointers, are essentially free and should be mainlined immediately: "It's a shame that hasn't been done long ago", one attendee said. Others that have more impact are trickier. Making them optional is one possibility, but even that has a cost that maintainers are likely to push back against. Adding another path through core kernel code can be a maintenance headache, and those may be difficult to get into the mainline.

Andre Hedrick mentioned that he has been pulling apart the grsecurity/PaX patches to try to make them more palatable. For one thing, grsecurity depends on a role-based access control (RBAC) mechanism that isn't present in the mainline (and isn't implemented as an LSM, so it isn't likely to ever be, at least in that form). Hedrick is trying to remove that dependency from the grsecurity features of interest, like better address-space layout randomization (ASLR) and a fully relocatable kernel, both of which can thwart various kinds of attacks.

One goal would be to find the grsecurity/PaX changes that have minimal impact and to get those into the mainline as non-optional protections. Turning RBAC into an LSM might be another useful exercise. grsecurity developer Brad Spengler provided a "long list" of features that could make their way into the kernel at last year's LSS, Cook said. That list would make a good starting point.

Cook also noted several other efforts aimed at hardening the kernel. Those include the work that Openwall hacker Vasiliy Kulikov has been doing, much of which is being discussed on the kernel-hardening mailing list. Also, the Ubuntu security team has been working on a kernel hardening project of its own. There is no lack of ideas out there, and a clear need to make the kernel more resistant to attacks. Based on the discussion, and the various ongoing efforts, we are likely to see more and more hardening patches aimed at the mainline over the next few years.

[ I'd like to thank LWN subscribers for supporting my travel to LSS. ]

Comments (12 posted)

Quotes of the week

-- Microsoft makes .txt files dangerous

-- FEDORA-2011-12302 (Thanks to Rahul Sundaram; see also FEDORA-2011-10266 and FEDORA-2011-2890)

Comments (13 posted)

An alleged SSL/TLS protocol vulnerability

Here are articles in the Register and Threat Post on a new attack that, it is said, can extract cookies from SSL streams. Details are scarce, but it seems to be a man-in-the-middle attack that injects a bit of JavaScript into the victim's browser. That JavaScript can then take advantage of the fact that SSL connections are reused across page fetches to carry out a known-plaintext attack against that connection. TLS versions 1.1 and 1.2 are apparently not vulnerable, but, alas, nobody uses those versions. Those wanting to do some digging can learn a bit more from conversations on the TLS list and Hacker News.

Comments (26 posted)

Garrett: UEFI secure booting

Matthew Garrett has posted an article about the UEFI "secure boot" feature and its potential impact on Linux.

As he notes, it is not time to panic yet, but it is worth being concerned about. Those who are interested in learning more about Microsoft's plans may want to watch this video which describes them in detail.

Comments (85 posted)

django: multiple vulnerabilities

Package(s):	django	CVE #(s):
Created:	September 19, 2011	Updated:	September 21, 2011
Description:	Django 1.2.6 and Django 1.3.1 fix several security issues, including session manipulation, a denial of service attack via URLField, URLField redirection, and host header cache poisoning. See the Django advisory for details.
Alerts:	Fedora FEDORA-2011-12493 Django 2011-09-10

Comments (none posted)

ffmpeg: denial of service/code execution

Package(s):	ffmpeg	CVE #(s):	CVE-2011-1196 CVE-2011-2161 CVE-2011-3362
Created:	September 20, 2011	Updated:	August 30, 2012
Description:	From the Ubuntu advisory: It was discovered that FFmpeg incorrectly handled certain malformed ogg files. If a user were tricked into opening a crafted ogg file, an attacker could cause a denial of service via application crash, or possibly execute arbitrary code with the privileges of the user invoking the program. This issue only affected Ubuntu 10.10. (CVE-2011-1196) It was discovered that FFmpeg incorrectly handled certain malformed APE files. If a user were tricked into opening a crafted APE file, an attacker could cause a denial of service via application crash. (CVE-2011-2161) Emmanouel Kellinis discovered that FFmpeg incorrectly handled certain malformed CAVS files. If a user were tricked into opening a crafted CAVS file, an attacker could cause a denial of service via application crash, or possibly execute arbitrary code with the privileges of the user invoking the program. (CVE-2011-3362)
Alerts:	Gentoo 201310-12 ffmpeg 2013-10-25 Mandriva MDVSA-2012:148 ffmpeg 2012-08-30 Mandriva MDVSA-2012:074-1 ffmpeg 2012-08-30 Mandriva MDVSA-2012:076 ffmpeg 2012-05-15 Mandriva MDVSA-2012:075 ffmpeg 2012-05-15 Mandriva MDVSA-2012:074 ffmpeg 2012-05-14 Debian DSA-2336-1 ffmpeg 2011-11-07 Ubuntu USN-1209-2 libav 2011-09-19 Ubuntu USN-1209-1 ffmpeg 2011-09-19

Comments (none posted)

kernel: denial of service

Package(s):	linux-ti-omap4 linux kernel	CVE #(s):	CVE-2011-1771
Created:	September 21, 2011	Updated:	September 21, 2011
Description:	The CIFS filesystem implementation does not properly handle direct I/O, allowing a local attacker with access to a CIFS filesystem to cause a kernel oops.
Alerts:	Oracle ELSA-2013-1645 kernel 2013-11-26 Ubuntu USN-1256-1 linux-lts-backport-natty 2011-11-09 Ubuntu USN-1212-1 linux-ti-omap4 2011-09-21

Comments (none posted)

httpd: denial of service

Package(s):	httpd	CVE #(s):	CVE-2011-3348
Created:	September 16, 2011	Updated:	October 20, 2011
Description:	From the Fedora advisory: mod_proxy_ajp when combined with mod_proxy_balancer: Prevents unrecognized HTTP methods from marking ajp: balancer members in an error state, avoiding denial of service.
Alerts:	Gentoo 201206-25 apache 2012-06-24 Ubuntu USN-1259-1 apache2, apache2-mpm-itk 2011-11-11 openSUSE openSUSE-SU-2011:1217-1 apache2 2011-11-04 SUSE SUSE-SU-2011:1215-1 Apache2 2011-11-04 Mandriva MDVSA-2011:168 apache 2011-11-09 Scientific Linux SL-http-20111020 httpd 2011-10-20 Red Hat RHSA-2011:1391-01 httpd 2011-10-20 Slackware SSA:2011-284-01 httpd 2011-10-17 Fedora FEDORA-2011-12715 httpd 2011-09-14

Comments (none posted)

mantis: multiple vulnerabilities

Package(s):	mantis	CVE #(s):	CVE-2011-2938 CVE-2011-3356
Created:	September 19, 2011	Updated:	November 9, 2012
Description:	Mantis 1.2.7 fixes cross site scripting and remote SQL injection vulnerabilities. See the Mantis bug report for details.
Alerts:	Gentoo 201211-01 mantisbt 2012-11-08 Fedora FEDORA-2011-12369 mantis 2011-09-09

Comments (none posted)

openttd: multiple vulnerabilities

Package(s):	openttd	CVE #(s):	CVE-2011-3341 CVE-2011-3342 CVE-2011-3343
Created:	September 20, 2011	Updated:	January 12, 2012
Description:	From the CVE entries: Multiple off-by-one errors in order_cmd.cpp in OpenTTD before 1.1.3 allow remote attackers to cause a denial of service (daemon crash) or possibly execute arbitrary code via a crafted CMD_INSERT_ORDER command. (CVE-2011-3341) Multiple buffer overflows in OpenTTD before 1.1.3 allow remote attackers to cause a denial of service (daemon crash) or possibly execute arbitrary code via vectors related to (1) NAME, (2) PLYR, (3) CHTS, or (4) AIPL (aka AI config) chunk loading from a savegame. (CVE-2011-3342) Multiple buffer overflows in OpenTTD before 1.1.3 allow local users to cause a denial of service (daemon crash) or possibly gain privileges via (1) a crafted BMP file with RLE compression or (2) crafted dimensions in a BMP file. (CVE-2011-3343)
Alerts:	Debian DSA-2386-1 openttd 2012-01-11 Gentoo 201111-03 openttd 2011-11-11 Fedora FEDORA-2011-12975 openttd 2011-09-19

Comments (none posted)

php: denial of service

Package(s):	php	CVE #(s):	CVE-2011-3182
Created:	September 19, 2011	Updated:	April 13, 2012
Description:	From the CVE entry: PHP before 5.3.7 does not properly check the return values of the malloc, calloc, and realloc library functions, which allows context-dependent attackers to cause a denial of service (NULL pointer dereference and application crash) or trigger a buffer overflow by leveraging the ability to provide an arbitrary value for a function argument, related to (1) ext/curl/interface.c, (2) ext/date/lib/parse_date.c, (3) ext/date/lib/parse_iso_intervals.c, (4) ext/date/lib/parse_tz.c, (5) ext/date/lib/timelib.c, (6) ext/pdo_odbc/pdo_odbc.c, (7) ext/reflection/php_reflection.c, (8) ext/soap/php_sdl.c, (9) ext/xmlrpc/libxmlrpc/base64.c, (10) TSRM/tsrm_win32.c, and (11) the strtotime function.
Alerts:	SUSE SUSE-SU-2013:1351-1 PHP5 2013-08-16 Mandriva MDVSA-2012:071 php 2012-05-10 SUSE SUSE-SU-2012:0496-1 PHP5 2012-04-12 Debian DSA-2408-1 php5 2012-02-13 Mandriva MDVSA-2011:165 php 2011-11-03 Ubuntu USN-1231-1 php5 2011-10-18 Gentoo 201110-06 php 2011-10-10 Fedora FEDORA-2011-11537 maniadrive 2011-08-26 Fedora FEDORA-2011-11528 maniadrive 2011-08-26 Fedora FEDORA-2011-11537 php-eaccelerator 2011-08-26 Fedora FEDORA-2011-11528 php-eaccelerator 2011-08-26 Fedora FEDORA-2011-11537 php 2011-08-26 Fedora FEDORA-2011-11528 php 2011-08-26

Comments (none posted)

roundcube: cross-site scripting

Package(s):	roundcubemail roundcube	CVE #(s):
Created:	September 15, 2011	Updated:	September 15, 2011
Description:	The Roundcube web mail system suffers from cross-site scripting vulnerabilities in its user interface messages.
Alerts:	Fedora FEDORA-2011-12131 roundcubemail 2011-09-06

Comments (none posted)

wireshark: denial of service

Package(s):	wireshark	CVE #(s):	CVE-2011-3266
Created:	September 19, 2011	Updated:	September 21, 2011
Description:	From the CVE entry: The proto_tree_add_item function in Wireshark 1.6.1, when the IKEv1 protocol dissector is used, allows user-assisted remote attackers to cause a denial of service (infinite loop) via vectors involving a malformed IKE packet and many items in a tree.
Alerts:	openSUSE openSUSE-SU-2011:1263-1 wireshark 2011-11-21 SUSE SUSE-SU-2011:1262-1 wireshark 2011-11-21 openSUSE openSUSE-SU-2011:1142-1 wireshark 2011-10-18 Gentoo 201110-02 wireshark 2011-10-09 Fedora FEDORA-2011-12423 wireshark 2011-09-09 Fedora FEDORA-2011-12403 wireshark 2011-09-09

Comments (none posted)

vsftpd: denial of service

Package(s):	vsftpd	CVE #(s):	CVE-2011-2189
Created:	September 19, 2011	Updated:	December 7, 2011
Description:	From the Debian advisory: Maksymilian Arciemowicz discovered that vsftpd is incorrectly handling certain glob expressions in STAT commands. This allows a remote authenticated attacker to conduct denial of service attacks (excessive CPU and process slot exhaustion) via crafted STAT commands.
Alerts:	Ubuntu USN-1288-1 vsftpd 2011-12-07 Debian DSA-2305-1 vsftpd 2011-09-19

Comments (none posted)

zabbix: remote information disclosure

Package(s):	zabbix	CVE #(s):	CVE-2011-3265
Created:	September 19, 2011	Updated:	September 21, 2011
Description:	From the CVE entry: popup.php in Zabbix before 1.8.7 allows remote attackers to read the contents of arbitrary database tables via a modified srctbl parameter.
Alerts:	Fedora FEDORA-2011-12489 zabbix 2011-09-10 Fedora FEDORA-2011-12485 zabbix 2011-09-10

Comments (none posted)