KernelTrap - security

Linux: First Release Of nftables

Jeremy — Wed, 01 Apr 2009 21:05:48 +0000

Netfilter maintainer Patrick McHardy recently announced a first alpha-release of nftables, slated to eventually replace iptables as the standard Linux packet filtering engine. Nftables aims to simplify the kernel ABI, reduce code duplication, improve error reporting, and provide more efficient execution, storage and updates of filtering rules. Patrick began with a high level overview of the three pieces that comprise the firewall, "the kernel provides a netlink configuration interface, as well as runtime ruleset evaluation using a small classification language interpreter. libnl contains the low-level functions for communicating with the kernel, the nftables frontend is what the user interacts with." An insightful overview can be found on lwn.net.

Patrick explained that data is represented internally in a generic fashion, "meaning it's possible to use any matching feature (ranges, masks, set lookups etc.) with any kind of data." He went on to add, "the kernel doesn't have a distinction between matches and targets anymore, operations can be arbitrarily chained, fixing a common complaint that multiple rules are required to f.i. log and drop a packet. Terminal operations will stop evaluation of a rule, even if further operations are specified." Speaking about the the userspace frontend, he noted, "the classification language is based on a real grammar that is parsed by a bison-generated parser (currently, it might have to be replaced) and converted to a syntax tree." Patrick continued, "the frontend supports both dealing with only a single rule at a time for incremental operations, as well as parsing entire files. In the later case verification is performed on all rules and changes are only made after full validation. Currently not implemented, but planned, is transactional semantic where changes are rolled back when the kernel reports an error."

Quote: Linux Will Have Similar Problems

Jeremy — Mon, 18 Aug 2008 17:28:00 +0000

"If web browsers, office suites and mail clients on Windows have certain kinds of vulnerabilities, it is safe to assume that the same programs on Linux will have similar problems."

Quote: Security Is Not An Absolute

Jeremy — Tue, 12 Aug 2008 15:27:51 +0000

"Security is not an absolute. Just as the terrorists win if it can induce the White House to shred the constitution and force us all to live in a constant state of fear, it is also pointless to induce people to install software that horrifically slows down their server so badly that you can't get anything done."

Security Bugs and Full Disclosure

Jeremy — Wed, 16 Jul 2008 12:57:33 +0000

In an announcement for the 2.6.25.10 stable kernel, Greg KH noted, "it contains a number of assorted bugfixes all over the tree. And once again, any users of the 2.6.25 kernel series are STRONGLY encouraged to upgrade to this release." The emphasis on the word strongly led to a lengthy discussion about how security fixes are handled in the Linux Kernel. Linus Torvalds replied, "I personally consider security bugs to be just 'normal bugs'. I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special." Later in the thread he went on to explain, "one reason I refuse to bother with the whole security circus is that I think it glorifies - and thus encourages - the wrong behavior. It makes 'heroes' out of security people, as if the people who don't just fix normal bugs aren't as important. In fact, all the boring normal bugs are _way_ more important, just because there's a lot more of them. I don't think some spectacular security hole should be glorified or cared about as being any more 'special' than a random spectacular crash due to bad locking."

Theodore T'so pointed out that other developers had different beliefs about disclosure than Linus and referred to mailing lists such as the private security@ list described in the SecurityBugs documentation, originally created in early 2005. He then described Linus' stance, "if Linus finds out about a security bug, he will fix it and check it into the public git repository right away. But he's very honest in telling you that is what he will do --- so you can choose whether or not to include him in any disclosures that you might choose to make." Regarding whether Full Disclosure is the best policy, Ted highlighted the fact that the debate has been going on for several decades, "it is clear that we're not going settle this debate now, and certainly not on the Linux Kernel Mailing List." Later in the discussion, Linus offered a succinct summary of his viewpoint, "my responsibility is to do a good job. And not pander to the people who want to turn security into a media circus."

Quote: Not A Huge Fan Of Security Lists

Jeremy — Wed, 16 Jul 2008 12:16:52 +0000

"Excuse me for not exactly being a huge fan of 'security lists' and best practices. They seem to be _entirely_ based on PR and how much you can talk up a specific bug. No thank you."

Ksplice, Rebootless Linux Kernel Security Updates

Jeremy — Fri, 25 Apr 2008 20:20:55 +0000

"I've put together an automatic system for applying kernel security patches to the Linux kernel without rebooting it, and I wanted to share this system with the community in case others find it useful or interesting," said Jeff Arnold, announcing ksplice. He explained, "the system takes as input a kernel security patch (which can be a unified diff taken directly from Linus' GIT tree) and the source code corresponding to the running kernel, and it automatically creates a set of kernel modules to perform the update. The running kernel does not need to have been customized in advance in any way." The project's website notes, "ksplice cannot handle semantic changes to data structures—that is, changes that would require existing instances of kernel data structures to be transformed." With this limitation, Jeff suggested ksplice is still able to automatically apply 84% of the kernel security patches released between May 2005 and December 2007. He continued:

"I've been pursuing this project because I don't like dealing with reboots whenever a new local kernel security vulnerability is discovered. The rebootless update practices/systems that are already out there require manually constructing an update (through a process that can be tricky and error-prone), and they tend to have other disadvantages as well (such as requiring a custom kernel, not handling inline functions properly, etc). This new system works on existing kernels, and it simply takes a unified diff as input and does the rest on its own."

Patching CVE-2008-0600, Local Root Exploit

Jeremy — Tue, 12 Feb 2008 02:23:04 +0000

Patches for a much publicized Linux kernel local root exploit were released today as 2.6.24.2, 2.6.23.16, and 2.6.22.18. The latest bug, labeled as CVE-2008-0600, was introduced by the vmsplice() system call and added into the 2.6 kernel in 2.6.17. It is the third in a series of root exploits surrounding the same system call, the two earlier bugs being CVE-2008-0009 and CVE-2008-0010. Easily obtained exploits exist for both the older CVE-2008-0010 which affected the 2.6.23 and 2.6.24 kernels, and the latest CVE-2008-0600, allowing a local non-root user to gain root permissions.

Quote: A Fix For This Problem

Jeremy — Mon, 11 Feb 2008 13:42:37 +0000

"All currently active Linux kernel versions are now released with a fix for this problem. We have released them through our normal channels, with the needed information as to what the problem is, a pointer to the CVE number, and the patch itself."