LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityShadow hardeningThe shadow password mechanism was introduced to provide increased security over the early Unix practice of stored salted-and-hashed passwords in /etc/passwd — but that fact by no means makes it perfect. The Openwall security-hardened Linux distribution (better known as Owl) offers its own alternative called tcb, built around per-user directories and Blowfish encryption. Recently developer Paweł Hajdan unveiled a similar project of his own, which utilizes several of tcb's improvements, but supplies them in what Hajdan hopes is an easier-to-manage design. Originally, /etc/passwd contained a hashed version of each account's password. The file itself was readable by any user, which enabled features like looking up usernames by their UIDs, and other tricks unrelated to the passwords themselves. The trouble was that attackers could calculate hashes offline then compare their results against /etc/passwd looking for matches. Shadow shuts down that attack vector by separating the hashed password information into a separate file that is readable only by trusted processes. In a sense, both tcb and hardened-shadow take that same approach: separating unrelated information further to reduce the potency of attacks. Taking care of passwordsOpenwall's tcb mechanism stores salted-and-hashed passwords in a directory of its own, /etc/tcb/, beneath which there is a separate directory for each user. Each user's directory is owned by that user account, and contains their own private shadow file (e.g., /etc/tcb/linus/shadow) also owned by the user. Both the per-user directory and its contents are in the auth group with the SGID bit set for the directory, which provides for additional password policy enforcement. Namely, the system can grant a process read-only access to password hashes and the password-changing tools use each user's private directory as scratch space for the temporary and lock files required during the process. Openwall maintains that this set-up eliminates the need for SUID-root binaries altogether. Apart from the system password-changing utilities, most application programs access shadow password hashes through either Pluggable Authentication Modules (PAM) or the Name Service Switch (NSS) facility. Tcb provides a custom PAM module named pam_tcb and a corresponding NSS module named libnss_tcb that supersede their /etc/shadow-based alternatives, such as the pam_unix module. As a result, migrating from a shadow system to tcb should be completely transparent to other applications. Openwall provides its own patched suite of shadow utilities (including login, useradd, chpasswd, newgrp, and so on) patched to support /etc/shadow in addition to /etc/tcb/*/shadow (configurable via a switch in /etc/login.defs), as well as utilities to convert from shadow to tcb and vice-versa. But Owl's tcb scheme also involves a change to Glibc, so that the crypt(3) function uses the Blowfish cipher. The existing Glibc crypt() offers MD5, SHA-256, and SHA-512 encryption methods. The tcb version patches in Blowfish support that is "mostly compatible" with OpenBSD's bcrypt. The principle advantage is that Blowfish can be configured to use as many set-up rounds as desired when generating the hash; thus administrators can increase the number of rounds over time to make attacks more and more computationally expensive as processor power increases. Hardened-shadowHajdan calls his package hardened-shadow, which he says is inspired directly by tcb. In a March 14 post to the owl-dev list, Hajdan asks for feedback from people interested in the project as well as help performing a security audit of the code. Hardened-shadow is a reimplementation of the shadow utilities based on the original upstream sources, but supporting a somewhat tcb-like layout. The system uses /etc/hardened-shadow/, with a separate directory for each user account. But while tcb only stores a single shadow file for each account, hardened-shadow adds two more: a shell file and an aging file. The shell file allows chsh to modify the user account's default shell without having access to the shadow file, and aging holds the password expiration fields, which would eliminate the need for locking if administrators expired passwords before changing them, according to Hajdan. In addition, hardened-shadow does not require a patched version of Glibc crypt(), and it supports more PAM options than does pam_tcb. Fans of the Blowfish algorithm might balk at the omission of their favorite cipher, but Hajdan has added a PAM parameter to pam_hardened_shadow that allows one to pass the hash algorithm as an argument. In the standard crypt() scheme, the hash algorithm used is designated by a token surrounded by $ characters — MD5 uses $1$, SHA-256 uses $5$, and so on. Hajdan believes making the PAM module indifferent to the hash algorithm makes the code more useful, so that Owl users can take advantage of Blowfish, while others can use their own cipher — and future-proofs it against new exploits that target particular ciphers. On the down side, Hajdan admits that his code is currently incompatible with SELinux and with NIS. More importantly, of course, it is brand-new and virtually untested, so he advises against deploying it on any production systems. Openwall's Alexander Peslyak (aka Solar Designer) offered several reasonable suggestions as feedback to Hajdan's list message. Among them were switching to a common open source license in place of Hajdan's current, custom license text, and building hardened-shadow around pam_tcb rather than implementing yet another PAM module with virtually the same goals. Hajdan's reply was that he felt pam_tcb's reliance on a patched Glibc made for too many packages, and that pam_tcb duplicated too many functions already found elsewhere in the tcb library. Nevertheless, Peslyak said that Openwall would consider migrating to hardened-shadow's version of the shadow utilities (although not the PAM and NSS modules). The reason he gave was that Openwall currently maintains its patch set against a suite of tools that come from a blend of two different sources: the canonical shadow utilities, and a PAM-based implementation called SimplePAMApps. SimplePAMApps, however, is no longer being actively maintained. Owl and a few other distributions curate their own packages of it, but in the long run, synchronizing with an actively developed tool set is probably less work. The shadowy futureBack in 2010, Hajdan submitted patches to the shadow utilities to enable optional support for tcb, a change that appears to have landed in the 4.1.5 release from February 2012. Nevertheless, tcb is still an essentially Owl-only tool. There does not seem to be much interest in packaging it among the large, "mainstream" distributions; in 2006 the idea was floated on the fedora-devel list where it was met with skepticism. Some of the criticism from 2006 is questionable (for example, the concern that users could fill up the /etc filesystem by dumping files into their /tcb/ directories — the group permissions should prevent that), but others, such as requiring new methods for auditing password changes, may be more valid. Hardened-shadow does not alleviate all of those concerns, but by virtue of not requiring a patched Glibc, it at least stands a better chance of being packaged by other distributions. Any hope for widespread deployment, however, will probably still need to address the SELinux incompatibility in the PAM module — and it will certainly need to wait for a proper security audit and more sets of eyes scrutinizing the code. Shadowed passwords were introduced to split up user account information in a manner that made security exploits harder. As both of these projects show, further division holds the possibility of protection against other attacks. Neither tcb nor hardened-shadow is a perfect solution, of course, but the existing shadow system is far from flawless, too, which is part of what makes a fresh re-examination of it such an interesting exercise.
Brief items Security quotes of the week
“We wouldn’t share this with Google for even $1 million,” says [Vupen's Chaouki] Bekrar. “We don’t want to give them any knowledge that can help them in fixing this exploit or other similar exploits. We want to keep this for our customers.”
-- Forbes
on security research firms selling exploits to governments
Those customers, after all, don’t aim to fix Google’s security bugs or those of any other commercial software vendor. They’re government agencies who purchase such “zero-day” exploits, or hacking techniques that use undisclosed flaws in software, with the explicit intention of invading or disrupting the computers and phones of crime suspects and intelligence targets.
The more complicated answer is that many bad things can happen if your RNG breaks down, and some are harder to deal with than others.
-- Matthew
Green
In the rest of this post I'm going to talk about this, and give a few potential mitigations. I want to stress that this post is mostly a thought-exercise. Please do not re-engineer OpenSSL around any of the 'advice' I give herein (I'm looking at you, Dan Kaminsky), and if you do follow any of my advice, understand the following: When it all goes terribly wrong, I'll quietly take down this post and pretend I never wrote it.
[An] otherwise uninteresting article on Internet threats to public infrastructure contains this paragraph:
-- Bruce
Schneier
At a closed-door briefing, the senators were shown how a power company employee could derail the New York City electrical grid by clicking on an e-mail attachment sent by a hacker, and how an attack during a heat wave could have a cascading impact that would lead to deaths and cost the nation billions of dollars.Why isn't the obvious solution to this to take those critical electrical grid computers off the public Internet?
CyanogenMod to disable root by defaultThe CyanogenMod project has announced that access to the root account will be disabled by default on CM9 installs. "Shipping root enabled by default to 1,000,000+ devices was a gaping hole. With these changes we believe we have reached a compromise that allows enthusiasts to keep using root if they so desire but also provide a good level of security to the majority of users."
New vulnerabilities chromium, v8: multiple vulnerabilities
gif2png: code execution
gnash: heap-based buffer overflow
kernel: multiple vulnerabilities
libapache2-mod-fcgid: excessive resource consumption
libpng10: code execution
minitube: insecure tmp file handling
nginx: information disclosure
openswan: denial of service
pidgin: two denial of service vulnerabilities
pyfribidi: code execution
python-mwlib: denial of service
rubygem-actionpack: arbitrary HTML or webscript execution
systemd: removal of arbitrary system files
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||