LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityWhat's new in OpenSSH 6.2Version 6.2 of the OpenSSH package was released on March 22, bringing with it the usual palette of new encryption and authentication schemes, administrative options, and bug fixes. The notable changes include improved granularity for existing options, but there are also brand new features—such as the ability to fetch authorized keys via an external command, and the ability to require multiple authentication methods when users log in through sshd. Because OpenSSH includes a flexible mechanism to invoke operating system authentication methods, this means sshd can require genuine multi-factor authentication, with hardware tokens or biometrics. Answer first these questions three (or two)The sshd daemon in OpenSSH is configured (by default) through the /etc/ssh/sshd_config file. 6.2 adds a new keyword, AuthenticationMethods, which takes one or more comma-separated lists of authentication methods as its argument (with the lists themselves separated by spaces). If only one list is supplied, users must successfully complete all of the methods—in the order listed—to be granted access. If several lists are provided, users need complete only one of the lists. For example, the line
AuthenticationMethods ``publickey,password hostbased,publickey''
would require the user to either perform public-key authentication
then enter a password, or to connect from a trusted host (i.e., using
host-based authentication) and perform public-key authentication. The
listed authentication methods are invoked in order, which matters most
visibly when several interactive methods are specified. It is also
important to note that the AuthenticationMethods feature
applies only to the SSH 2
protocol, and that each authentication method listed must also be
explicitly enabled in the sshd_config file.
There are just four allowable methods: publickey, password, hostbased, and keyboard-interactive. That might sound a tad inflexible, but keyboard-interactive is a generic method that can trigger other mechanisms, such as BSD Auth, S/KEY, or Pluggable Authentication Modules (PAM). By appending the desired submechanism after a colon, such as keyboard-interactive:pam, one can add any PAM module to the mix—including modules that build on an entirely different authentication model, such as Kerberos, hardware security tokens, or perhaps face recognition. Naturally, PAM needs to be configured to specify the module of interest as well, via /etc/pam.conf or /etc/pam.d/sshd. The salient point, of course, is that modules are available which rely on "something you have" or "something you are" authentication. Otherwise, requiring users to provide a public key and a password is not genuinely multi-factor authentication, since both factors are squarely in the "something you know" column. Granted, there is a gray area where public keys are concerned, since users do not memorize them, but the fact that exact digital copies can be made separates them from hardware tokens. Whether widespread ease-of-deployment through OpenSSH will reinvigorate the development and maintenance of hardware and biometric PAM modules remains an open question. Key lookupsThe second addition to sshd's authentication toolkit is the AuthorizedKeysCommand keyword. The command supplied as the argument to this keyword is invoked to fetch the key of the user attempting to authenticate. In previous releases, this key-fetching step was limited to looking up the user's key on the filesystem (in the file specified by the AuthorizedKeysFile keyword). By accepting a command instead, administrators can look up the incoming user's key in a database, or over (for example) LDAP. OpenSSH imposes some restrictions on the program specified for AuthorizedKeysCommand; it will be passed one argument (the username of the user attempting to connect) and it must return output on stdout consisting of zero or more lines of public keys, formatted in the same manner used by the AuthorizedKeysFile. In addition, the command is run as the user specified in the AuthorizedKeysCommandUser directive, which the OpenSSH project advises be a dedicated account with no other role on the machine. If AuthorizedKeysCommand fails to return a key that authenticates the user, then it falls back onto the old-fashioned local key lookup method, which allows for a safety net in the event that the command fails or the remote host queried is unavailable. In a related feature, OpenSSH 6.2 also adds support for Key Revocation Lists (KRLs). KRLs are compact, binary files that can be generated by OpenSSH's ssh-keygen utility. The KRL specification allows for several formats, depending on the type of credential revoked. The file can list a plain-text public key, a key's SHA1 hash, a certificate's key ID string, or a 64-bit certificate serial number (in decimal, hexadecimal, or octal). When revoking certificates via serial number, the KRL can specify a range, which is what leads to a claim in the OpenSSH 6.2 release notes that KRL can be so compact that it takes "as little a one bit per certificate." The multiple acceptable formats specified in the KRL format can simplify the task of revoking keys. Among other things, the ability to revoke a credential by its serial number or key ID alone—without the original in hand—makes it possible for an administrator to revoke a compromised key or certificate rapidly when fetching a copy of the complete credential might cost valuable time. In addition, it allows administrators to revoke keys or certificates that have been (or are feared) lost. Encryption for allThe new sshd authentication features are not the only changes in OpenSSH 6.2, of course. There are several new ciphers, modes, and message authentication codes (MACs) supported, such as Galois/Counter Mode (GCM) for AES, the 128-bit flavor of Message Authentication Code using Universal Hashing (UMAC-128), and encrypt-then-MAC (EtM) mode for SSH 2. The latter alters the packet format, computing the MAC over the packet length and the entire encrypted packet, rather than over the plaintext data payload. There is also a new option available for specifying TCP forwarding behavior in sshd. In previous releases, the only possible options were "yes" and "no"; 6.2 adds two more: "local" and "remote", which allow administrators to limit TCP forwarding to just local or just remote hosts. In addition, there are several new command-line switches for logging and interactive help, which should make OpenSSH easier to work with, even though they do not add new features. The prospect of multi-factor authentication with ssh may have the most far-reaching implications, but OpenSSH 6.2 includes plenty of practical updates as well.
Brief items Security quotes of the week
We log every message. We log who sent it, from what IP address, and to
whom. We scan headers and payloads for potentially "spammy" topics. We
even retain binary attachments and other payload data. Whereas before,
the Email system only logged trivial, non-identifiable information, it
now warehouses every message and tags it internally with a customer
account number.
-- Anonymous PRIVACY Forum reader (and ISP
employee)
This is the "equal and opposite" reaction to blacklists: Total Information Awareness applied to our customer's email.
Paula
Broadwell, who had an affair with CIA director David Petraeus,
similarly took extensive precautions to hide her identity. She never logged
in to her anonymous e-mail service from her home network. Instead, she used
hotel and other public networks when she e-mailed him. The FBI correlated hotel registration data from several different hotels -- and hers was the common name.
-- Bruce
Schneier
The Internet is a surveillance state. Whether we admit it to ourselves or not, and whether we like it or not, we're being tracked all the time. Google tracks us, both on its pages and on other pages it has access to. Facebook does the same; it even tracks non-Facebook users. Apple tracks us on our iPhones and iPads. One reporter used a tool called Collusion to track who was tracking him; 105 companies tracked his Internet use during one 36-hour period.
So, you know all that talk about things like Aaron's
Law and how [the US] Congress needs to fix
the CFAA [Computer Fraud and Abuse Act]? Apparently, the House Judiciary Committee has decided to raise a giant middle finger to folks who are concerned about abuses of the CFAA. Over the weekend, they began circulating a "draft" of a "cyber-security" bill that is so bad that it almost feels like the Judiciary Committee is doing it on purpose as a dig at online activists who have fought back against things like SOPA, CISPA and the CFAA. Rather than fix the CFAA, it expands it. Rather than rein in the worst parts of the bill, it makes them worse. And, from what we've heard, the goal is to try to push this through quickly, with a big effort underway for a "cyberweek" in the middle of April that will force through a bunch of related bills.
-- Mike
Masnick analyzes proposed US legislation
KASLR: An Exercise in Cargo Cult Security (grsecurity blog)Over at the grsecurity blog, Brad Spengler and the PaX Team have co-written a lengthy look at kernel address space layout randomization (KASLR) and its failures. "KASLR is an easy to understand metaphor. Even non-technical users can make sense of the concept of a moving target being harder to attack. But in this obsession with an acronym outside of any context and consideration of its limitations, we lose sight of the fact that this moving target only moves once and is pretty easy to spot. We forget that the appeal of ASLR was in its cost/benefit ratio, not because of its high benefit, but because of its low cost."
Garrett: Secure Boot and Restricted BootMatthew Garrett asserts that people attacking UEFI secure boot are aiming at the wrong target. "Those who argue against Secure Boot risk depriving us of the freedom to make a personal decision as to who we trust. Those who argue against Secure Boot while ignoring Restricted Boot risk depriving us of even more. The traditional PC market is decreasing in importance. Unless we do anything about it, free software will be limited to a niche group of enthusiasts who've carefully chosen from a small set of devices that respect user freedom. We should have been campaigning against Restricted Boot 10 years ago. Don't delay it even further by fighting against implementations that already respect user freedom."
New vulnerabilities euca2ools: insecure snapshots
gnome-online-accounts: information disclosure
kernel: denial of service
kernel: multiple vulnerabilities
keystone: revocation check bypass
libxml2: denial of service
nova: two vulnerabilities
openstack-packstack: insecure file handling
privoxy: proxy spoofing
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||