LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityCalibre and setuidPrograms that regular users can run with root privileges (i.e. setuid programs) are tricky to write correctly, which is why they are best avoided whenever possible. But there are, of course, things that users need to be able to do that require privileges (changing passwords is a canonical example), which is why the setuid/setgid facility exists in Unix. When the need arises, however, a great deal of care should be taken before writing and releasing a program that is meant to be installed as setuid (aka SUID). A recent bug report for the Calibre e-book reader shows the kinds of problems that can come about if proper care is not exercised. Jason Donenfeld reported several bugs in the setuid calibre-mount-helper program to the project's Launchpad bug tracker on November 1. Essentially, the program is meant to allow Calibre users to mount various removable devices (like e-book readers connected via USB) to update the content on readers. Unfortunately, it suffered from five separate problems that Donenfeld reported, some of which could be easily used as a local privilege escalation—to root. The problems themselves read like a laundry list of things not to do in a setuid program including not sanitizing user input, not setting the PATH environment variable before calling exec(), and not sanity checking arguments. It's not completely surprising that Calibre got these things wrong, as they are fairly common programming mistakes. For programs running with a user's privileges, those kinds of errors typically just lead to bugs of various sorts (some of which could have fairly catastrophic consequences for the user, but not the system as a whole). For setuid programs, though, errors like those can lead to very serious security holes—as they did here. Something that was a bit surprising was the combative tone that Calibre's lead developer Kovid Goyal took in the comments on the bug. Rather than working with Donenfeld to see what the problems were, he dismissed most of the bugs as invalid. Even after Donenfeld tried to further point out the problems, Goyal was rather sarcastic in response:
You mean that a program designed to let an unprivileged user
mount/unmount/eject anything he wants has a security flaw because it allows
him to mount/unmount/eject anything he wants? I'm shocked.
The proof-of-concept that Donenfeld posted with the bug—fairly snarky in tone, which may not have helped—clearly showed how to exploit the lack of PATH sanitization to get root privileges, but didn't demonstrate a different reported problem with argument injection to the mount program. That particular problem results from not sanitizing the user input and passing it on to mount. The other three problems (arbitrary root-owned directory creation, arbitrary empty directory removal, and creating .created_by_calibre_mount_helper files anywhere in the filesystem) are going to be harder to exploit, but they certainly aren't capabilities that regular users should have. Goyal fixed the PATH issue immediately, but didn't see the argument injection problem, and therefore didn't fix it. Dan Rosenberg pointed out that there was still a bug:
Unfortunately, sarcasm does not make you right. Yes, this is a critical security flaw, because anyone with calibre
installed on their system now allows any user to gain root privileges by
mounting on top of important directories. Just because your application
allows this by design rather than by mistake doesn't make this less of a
problem.
In addition, Rosenberg suggested that there were safer ways to allow users to mount removable media, rather than writing a setuid application specific to Calibre. Once again, though, Goyal takes the combative approach. He committed a fix (though it doesn't really solve the problem) for the problem of "mounting on top of important directories", but seems affronted by the bug comments:
Sarcasm doesn't make me right, being right makes me right. The sarcasm was
just a bonus earned by the [sanctimoniousness] of the post I was responding
to.
Part of the problem is that Goyal is looking for a single solution to the mounting problem that works "on *every single linux distro that the current technique works on* not just version >= x of distro y". While that complaint has some merit, it is hardly an excuse to introduce security holes into the system. Though Goyal claims to be aware of the "dangers" of setuid programs, the code in calibre-mount-helper does not really bear that out. In fact, Donenfeld quickly came back with an example exploit that routed around Goyal's fix. The fix just disallows mounting in /usr, /bin, or /sbin, but Donenfeld's example mounts a /etc filesystem (with a chosen root password in passwd), thus allowing the user to log in as root. Obviously, /etc can be added to the disallowed list, but that becomes something of an arms race. A whitelisting approach might be more reasonable, but a better solution would be to use the distribution-supplied mechanisms for mounting the e-book readers. Those solutions should have had most of the obvious (and some non-obvious) problems shaken out, though there is no universal cross-distribution mechanism as Goyal would like to see. As Donenfeld points out, Debian does not install the mount helper, and instead uses a wrapper script around udisks. Fedora also avoids the mount helper. Judging from this bug report, Ubuntu has picked up the Debian fix as well. It is unclear whether any of those distributions made an effort to get the word out about the problem or get a fix upstream. openSUSE seems to install calibre-mount-helper, however, and various other distributions may as well. In any case, anyone who picks up the source package and installs it will get the program installed as a setuid binary in /opt/calibre/bin. Writing secure code is hard. Programmers tend to focus on what they are trying to accomplish, rather than all of the different ways the program can be abused. That's not an excuse, but it is an explanation of sorts. Distributions and users should be especially vigilant about setuid programs that come in from packages that, arguably anyway, shouldn't need them. Projects should probably also try to engage with folks that report security problems, rather than attacking them. As of this writing, the Calibre trunk is still vulnerable to the example exploit that Donenfeld posted. One would expect to see a fix for it soon, and that any distributions that install calibre-mount-helper to issue updates. Users that have it installed from source may want to investigate using a wrapper script or other means to disarm the bug until the fix is made, at least on shared machines.
Brief items Security quotes of the week
Key signing events are boring.
-- Alan
Cox forgets "mind-numbingly"
People often say to me "well, don't you know why this is happening to you?" and I reply that while we may all speculate, I have been refused official answers. The little official correspondence I received said it was probably a mistake. It took months and they assure me that things will be better someday, probably. I've been detained multiple times since that letter, both in the U.S. and abroad. The DHS won't share a copy of my files with me or my lawyers. It says that I have no right to know what is in them.
-- Tor developer (and Wikileaks supporter) Jacob
Appelbaum gets another "random" airport security screening
The redress letter suggests that even though nothing is wrong, I'll still be selected for "random" screenings. Consider what they tell us of safety and justice, and ask yourself: is it possible that a system full of such obvious and casual dishonesty will provide it?
Security experts have said that RSA wasn't the only corporation victimized
in the attack, and that dozens of other multinational companies were
infiltrated using many of the same tools and Internet infrastructure. But
so far, no one has been willing to talk publicly about which other
companies may have been hit. Today's post features a
never-before-published list of those victim organizations. The information
suggests that more than 760 other organizations had networks that were
compromised with some of the same resources used to hit RSA. Almost 20
percent of the current Fortune 100 companies are on this list.
-- Brian
Krebs
Blaze: Key escrow from a safe distanceMat Blaze has published a look back at the clipper chip controversy [PDF] for an upcoming conference. It is a good retrospective of a crucial moment in the crypto wars. "And so even before the Web became synonymous with the Internet, before a single bit of encrypted SSL traffic was generated, lines were being drawn for what would become an epic battle that would preoccupy a generation of cryptographers. (And it was a bad time for that community to be preoccupied; this was the same time that the basic foundations of the of web and other critical communications technologies were designed and put into place. We've been living with the security, or lack of security, built in to that infrastructure ever since)."
New vulnerabilities backuppc: cross-site scripting
chromium: multiple vulnerabilities
empathy: cross-site scripting
kernel: file corruption
phpldapadmin: multiple vulnerabilities
python-django: multiple vulnerabilities
radvd: multiple vulnerabilities
simplesamlphp: xml encryption weakness
squid: denial of service
tor: information disclosure
wireshark: multiple vulnerabilities
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||