LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecuritySeunshare, /tmp directories, and the "sticky" bitThe /tmp directory has been an unceasing source of security problems going back decades; there are still regular reports of vulnerabilities from insecure usage of temporary files. Part of the problem is that /tmp (and /var/tmp) are shared resources that can be written to by any process, which allows attackers to use various race conditions (typically time-of-check-to-time-of-use (TOCTTOU) races) in insecurely written programs to elevate their privileges. It is a bit ironic, then, that a utility specifically geared toward running a program with a private /tmp directory (for application sandboxing) would run afoul of a somewhat different kind of temporary file vulnerability—one that was long-ago excised by the advent of "sticky" directories. But that is just what Tavis Ormandy found. The basic problem is that insecure programs often open files in /tmp after checking to see whether the file exists. In the window between the time that the test is done and the time that the file is opened, a malicious program can swap in a file of its choosing (or, more likely, a symbolic or hard link to a file of its choosing). When that happens, the buggy program is operating on a file that it does not expect and that can cause all manner of mayhem. For normally privileged programs, that mayhem is largely restricted, but for setuid programs, it can lead to full system compromise. Long ago, attackers could use the world-writable attribute of /tmp to delete files that were created by setuid programs. The attacker could then replace the file with a link, and when a privileged program re-opened the file—something that is, in general, a bad practice with temporary files—it would be opening a file of the attacker's choice. But, the advent of the "sticky" bit as applied to directory permissions closed that loophole by only allowing the file owner (or root) to delete a file in a sticky directory. Since that time, lots of code has been written with a sticky /tmp directory in mind. As part of its efforts to use SELinux to provide application sandboxes, Red Hat created the seunshare utility. That utility will run a command with alternate /tmp and home directories, along with a given SELinux context. seunshare will "unshare" the default mount namespace (so that the command has its own view of the filesystem hierarchy), mount the specified directories over top of /tmp and the home directory, and instruct the kernel to execute the command in the (optionally) given SELinux context. Since the temporary directory specified is under the control of the user, it doesn't necessarily have the sticky bit set, which leads to the vulnerability. In Ormandy's example, he uses ksu to show how the /etc/passwd file could be overwritten by running ksu under seunshare. There are likely other setuid programs that make the assumption that their temporary files are in sticky directories, and quite possibly some where the consequences could be more severe than just trashing the password file. So a mechanism that was meant to provide more security actually left a hole behind. Unfortunately, this is not an uncommon occurrence in the security realm. This particular case also shows the value of disclosing security vulnerabilities. Ormandy reported the bug back in September and, though there was a flurry of discussion about it, that discussion died off in late November (at least in the bug report). Things didn't pick up again until Ormandy posted a request for an update, along with notice that he was ready to publish an advisory, on February 18. Hearing no complaint, he did so on February 23. After that, the discussion picked up again, with solutions being proposed, though no fix is yet available for Fedora or RHEL. One has to wonder how long this potential local privilege escalation might have languished had Ormandy not released his advisory. As a temporary mitigation, Ormandy suggests removing the setuid bit from seunshare or restricting access to it. The solution that Dan Walsh has proposed removes the -t tmpdir argument to seunshare and instead mounts a tmpfs on /tmp (with the sticky bit set). Presumably that will be released in the near future. There has been an attempt to harden the behavior of sticky directories to try to avoid some of the longstanding /tmp directory problems—though that would not have thwarted this particular vulnerability because it relies on the directory being sticky. There has been resistance to that effort because it is seen as something of an ugly hack to work around badly written code, so it has not made it into the mainline (though Ubuntu and other kernels do have that hardening). But temporary file vulnerabilities of various sorts still rear their head with depressing frequency. We will undoubtedly see others crop up in the future.
Brief items Security quotes of the week
Sometimes, when I'm in a fanciful mood, I enjoy devices like brain-scanning
lie detectors, and hi-tech sniffer dogs, because their appeal speaks to our
desire for simple mechanical explanations in a complex world, and for
machines to aggrandise intuition, or make it more sciencey. But I enjoy
them mostly because - like the ridiculous new porno-scanners in US
airports, that give staff a view of your breasts and penis - they show how
much of security is about theatre rather than reality.
-- Ben
Goldacre (Thanks to Felipe Sateler.)
The constitutionality of state and federal information privacy laws have
historically and consistently been called into question, and things would
be no different if—and it's a big if—Congress grants the FTC
[Federal Trade Commission] authority
over online tracking. When considering technical standards and what
"tracking" means, it's worth keeping in mind the possible constitutional
challenges insofar as state action may be involved, as some desirable
options to curb online tracking may only be possible within a voluntary or
self-regulatory framework.
-- Harlan
Yu in the Freedom to Tinker blog
While "scare 'em and snare 'em" may be business as usual in the IT security
industry, other HBGary Federal skunk works projects clearly crossed a line:
a proposal for a major U.S. bank, allegedly Bank of America, to launch
offensive cyber attacks on the servers that host the whistle blower site
Wikileaks. HBGary was part of a triumvirate of firms that also included
Palantir Inc and Berico Technologies, that was working with the law firm of
the U.S. Chamber of Commerce to develop plans to target progressive groups,
labor unions and other left-leaning non profits who the Chamber opposed
with a campaign of false information and entrapment.
-- Paul
Roberts at threatpost.com
Wallach: Things overheard on the WiFi from my Android smartphoneOver at the Freedom to Tinker blog, Dan Wallach reports on an experiment he did with his undergraduate security class: using Wireshark and Mallory to listen in on what his Android phone was sending. He describes what was found for a number of different applications including Gmail, Google Voice and Calendar, Facebook, Twitter, Angry Birds, and more. "What options do Android users have, today, to protect themselves against eavesdroppers? Android does support several VPN configurations which you could configure before you hit the road. That won't stop the unnecessary transmission of your fine GPS coordinates, which, to my mind, neither SoundHound nor ShopSaavy have any business knowing. If that's an issue for you, you could turn off your GPS altogether, but you'd have to turn it on again later when you want to use maps or whatever else. Ideally, I'd like the Market installer to give me the opportunity to revoke GPS privileges for apps like these."
Firefox and Thunderbird security updatesMozilla has released Firefox 3.6.14 and 3.5.17 and Thunderbird 3.1.8, each of which fix some security vulnerabilities, including some that are marked "critical". Mozilla strongly recommends that all users upgrade to the new releases. Each Firefox release fixes eight critical, one high, and one moderate vulnerability (3.6.14, 3.5.17), while the Thunderbird release fixes two critical, and one moderate flaw (3.1.8).
New vulnerabilities abcm2ps: multiple vulnerabilities
acroread: multiple vulnerabilities
avahi: denial of service
clamav: arbitrary code execution
firefox: multiple vulnerabilities
fuse: denial of service
gimp: multiple vulnerabilities
kernel: denial of service
logwatch: privilege escalation/arbitrary code execution
openjdk: privilege escalation
pam-pgsql: buffer overflow
pango: arbitrary code execution
php: casting vulnerability
ruby: multiple vulnerabilities
samba: denial of service
wireshark: code execution
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||