LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityReactive vs. pro-active kernel securitySecurity patches are almost always a question of tradeoffs. Sometimes the protection offered outweighs the negative effects that a security-oriented fix brings—and sometimes it doesn't. In addition, pro-active security fixes often face an uphill battle to get into the kernel, especially if they cause performance or other problems, because many kernel developers are skeptical of "solutions" for theoretical problems. In many cases, these changes come under the heading of "kernel hardening", and don't correspond to a particular known security hole; instead they address a class of potential problems, which can be much harder to sell. A good example of this can be found in Vasiliy Kulikov's recent RFC patch to implement some checks in the functions that copy data to and from user space. Copying the wrong amount of data to or from user space can lead to security problems, like code execution or disclosing the contents of kernel memory, so checking to ensure that copies are not larger than the expected data structure is certainly beneficial. But the copy_to/from_user() functions are performance-critical. In typical fashion, Linus Torvalds doesn't mince words in his reply to Kulikov:
That patch is entirely insane. No way in hell will that ever get merged.
copy_to/from_user() is some of the most performance-critical code, and runs a *lot*, often for fairly small structures (ie 'fstat()' etc). Adding random ad-hoc tests to it is entirely inappropriate. Doing so unconditionally is insane. He does go on to suggest that a cleaned up version which is configurable so that only those distributions or users who want the extra checking will pay the price for it might be acceptable. To Torvalds, the patch is more evidence of the "craziness" of the security community: "It's exactly the kind of 'crazy security people who don't care about anything BUT security' crap that I refuse to see." That, of course, is something of a recurring theme in terms of Torvalds and other kernel hackers' reactions to pro-active security fixes. Ingo Molnar had a similar concern in the discussion of another of Kulikov's patches: an effort to remove control characters from log file output. Molnar is skeptical of the patch, partly because there are no specific threats that it addresses:
Yes, but there's a world of a difference between alleged harm and
actual demonstrated harm.
That is a not so fine distinction that is often missed in security circles! :-) When an actual flaw is found in the kernel, especially if there are exploits for it in the wild, fixes are made quickly—no surprise. But theoretical flaws, or fixes that protect badly written user-space programs often have a tougher path into the kernel. Over the years, we have seen numerous examples of these kinds of patches, often coming from hardened kernel projects like grsecurity/PaX and Openwall. But, to some extent anyway, those projects are more concerned with security than they are with things like performance, and are willing to sacrifice performance to reduce or eliminate entire classes of security threats. There is clearly a kernel (so to speak) of truth to Torvalds's complaint about "security crap", but there is also room for different kinds of kernels. It is reminiscent of the situation with SELinux in some ways. SELinux offers protections that can sometimes mitigate security problems before they come to light—exactly what pro-active security measures are meant to do—but SELinux is disabled by numerous administrators and by most distributions other than Red Hat's. For some, the extra protection that SELinux provides is not worth the overhead and problems that it can cause. Others may be more concerned about zero-day exploits and enable SELinux or run hardened kernels. Another example of a fix that didn't make it into the kernel, though it would have eliminated a common security problem, is Kees Cook's attempt to disallow symbolic links in "sticky" directories—to stop /tmp symlink bugs (like this one from July 12). That particular fix was controversial, as some kernel hackers didn't think it appropriate to change core VFS code to fix buggy user-space programs. But moving the fix into a Linux Security Module (LSM)—along with a handful of other unrelated security fixes—didn't pass muster either. There have also been various efforts to remove sources of information in /proc and elsewhere that can make it easier for exploits to function. Things like hiding kernel addresses from unprivileged processes, restricting page access to read-only and no-execute, protecting /proc/slabinfo, and lots of others have been proposed—sometimes adopted—over the last year or two. These kinds of fixes are often greeted with a level of skepticism (which is not so different from other kinds of patches really), and sometimes find their path into the mainline to be fairly difficult—sometimes impossible. That's not to say that any of those that were rejected should be in the kernel, but in most cases they do add some level of protection that very security-conscious users might be very happy to have. The risk of keeping many of these pro-active hardening features out of the mainline is probably small, but it certainly isn't non-existent. There is a balance to be found; performance, maintainability, and less intrusiveness of patches are often more important to Torvalds and the kernel community than fixes that could, but might not, catch security exploits that aren't yet known. Essentially, making most users pay a performance penalty over and over again, potentially untold trillions of times, is too high a price. Fixing the problems that are found, when they are found, is the course that the mainline has (largely) chosen. It is probably somewhat disheartening for Kulikov, Cook, and others to continually have their patches rejected for the mainline, but they do tend to be used elsewhere. Many of Cook's patches have been picked up in Ubuntu, where he is a member of the security team, and Kulikov is a student in the Google Summer of Code for Openwall specifically tasked with hardening both the Openwall kernel and upstream (to the extent he can anyway). Their efforts are certainly not being wasted, and security-conscious administrators may want to choose their distribution or kernel carefully to find the one that best matches their needs.
Brief items Security quotes of the week
So, with this increasing proliferation of eavesdrop-thwarting encryption
built in to our infrastructure, we might expect law enforcement wiretap
rooms to have become quiet, lonely places.
-- Matt Blaze
But maybe not: the latest wiretap report identifies a total of just six (out of 3194) cases in which encryption was encountered, and that prevented recovery of evidence a grand total of ... (drumroll) ... zero times. Not once. Previous wiretap reports have indicated similarly minuscule numbers.
The FBI got a search warrant for Ardolf's house and computer, and found
reams of evidence, including copies of data swiped from the Kostolniks'
computer, and hacking manuals with titles such as "Cracking WEP Using
Backtrack: A Beginner's Guide;" "Tutorial: Simple WEP Crack Aircrack-ng"
and "Cracking WEP with BackTrack 3 - Step by Step instructions." They also
found handwritten notes laying out Ardolf's revenge plans, and a cache of
snail mail that Ardolf had apparently stolen from the Kostolniks' mail box
and stashed under his bed.
-- Wired
on the "WiFi-Hacking Neighbor From Hell"
Israeli intelligence unfortunately doesn't send us any reports. There was a
lot of talk -- on the Internet and in the media -- that Stuxnet was a joint
US-Israeli project. I think that's probably the most likely scenario. It
was highly professional work, by the way, and one that commands a lot of
respect from me. It cost several million dollars and had to be orchestrated
by a team of highly trained engineers over several months. These were no
amateurs; these were total professionals who have to be taken very
seriously. You don't get in a fight with them; they don't mess around.
-- Evgeny
Kaspersky in an interview in Der Spiegel
The whole post was about whether or not anyone had a legitimate copyright
claim on the photos, noting that the photographer, David Slater, almost
certainly did not have a claim, seeing as he did not take the photos, and
even admits that the images were an accident from monkeys who found the
camera (i.e., he has stated publicly that he did not "set up" the shot and
let the monkeys take it). And yet, Caters News Agency has a copyright
notice on two of the images, claiming to hold the rights to them. We
doubted that the monkeys -- who might have the best "claim" to copyright on
these photos, if there is one, had licensed the images.
-- Mike
Masnick on a
New vulnerabilities apt: incorrect signature validation
asterisk: multiple vulnerabilities
blender: embedded code execution
dbus: denial of service
fabric: symlink attack
kernel: multiple vulnerabilities
libpng: denial of service
libvirt: denial of service
openoffice.org: code execution
oprofile: privilege escalation/file overwrite
vte: memory exhaustion
xml-security-c: arbitrary code execution
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||