Security
What's new in OpenSSH 6.2
Version 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 lookups
The 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 all
The 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
This is the "equal and opposite" reaction to blacklists: Total Information Awareness applied to our customer's email.
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.
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 Boot
Matthew 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
| Package(s): | euca2ools | CVE #(s): | CVE-2012-4066 | ||||||||||||||||
| Created: | March 25, 2013 | Updated: | October 13, 2014 | ||||||||||||||||
| Description: | From the Red Hat bugzilla:
euca2ools 2.1.3 contains the node controller's end of the fix for bug 916709. We consequently need to roll that version out at least in every branch that contains eucalyptus. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
gnome-online-accounts: information disclosure
| Package(s): | gnome-online-accounts | CVE #(s): | CVE-2013-1799 | ||||
| Created: | March 25, 2013 | Updated: | March 27, 2013 | ||||
| Description: | From the Ubuntu advisory:
It was discovered that GNOME Online Accounts did not properly check SSL certificates when configuring online accounts. If a remote attacker were able to perform a man-in-the-middle attack, this flaw could be exploited to alter or compromise credentials and confidential information. | ||||||
| Alerts: |
| ||||||
kernel: denial of service
| Package(s): | kernel | CVE #(s): | CVE-2013-1819 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | March 22, 2013 | Updated: | March 27, 2013 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla: Linux kernel built with support for XFS file system is vulnerable to a NULL pointer dereference flaw. This occurs while accessing blocks beyond the end of the file system, possibly on a corrupted device. A user able to mount the file system could use this flaw to crash the kernel, resulting in DoS. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
kernel: multiple vulnerabilities
| Package(s): | kernel | CVE #(s): | CVE-2013-1873 CVE-2013-1796 CVE-2013-1797 CVE-2013-1798 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | March 25, 2013 | Updated: | July 12, 2013 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the CVE entries:
The kvm_set_msr_common function in arch/x86/kvm/x86.c in the Linux kernel through 3.8.4 does not ensure a required time_page alignment during an MSR_KVM_SYSTEM_TIME operation, which allows guest OS users to cause a denial of service (buffer overflow and host OS memory corruption) or possibly have unspecified other impact via a crafted application. (CVE-2013-1796) Use-after-free vulnerability in arch/x86/kvm/x86.c in the Linux kernel through 3.8.4 allows guest OS users to cause a denial of service (host OS memory corruption) or possibly have unspecified other impact via a crafted application that triggers use of a guest physical address (GPA) in (1) movable or (2) removable memory during an MSR_KVM_SYSTEM_TIME kvm_set_msr_common operation. (CVE-2013-1797) The ioapic_read_indirect function in virt/kvm/ioapic.c in the Linux kernel through 3.8.4 does not properly handle a certain combination of invalid IOAPIC_REG_SELECT and IOAPIC_REG_WINDOW operations, which allows guest OS users to obtain sensitive information from host OS memory or cause a denial of service (host OS OOPS) via a crafted application. (CVE-2013-1798) CVE-2013-1873 is a duplicate of CVE-2013-2634, CVE-2013-2635, and CVE-2013-2636. net/dcb/dcbnl.c in the Linux kernel before 3.8.4 does not initialize certain structures, which allows local users to obtain sensitive information from kernel stack memory via a crafted application. (CVE-2013-2634) The rtnl_fill_ifinfo function in net/core/rtnetlink.c in the Linux kernel before 3.8.4 does not initialize a certain structure member, which allows local users to obtain sensitive information from kernel stack memory via a crafted application. (CVE-2013-2635) net/bridge/br_mdb.c in the Linux kernel before 3.8.4 does not initialize certain structures, which allows local users to obtain sensitive information from kernel memory via a crafted application. (CVE-2013-2636) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
keystone: revocation check bypass
| Package(s): | keystone | CVE #(s): | CVE-2013-1865 | ||||||||||||||||
| Created: | March 21, 2013 | Updated: | April 9, 2013 | ||||||||||||||||
| Description: | From the Ubuntu advisory: Guang Yee discovered that Keystone would not always perform all verification checks when configured to use PKI. If the keystone server was configured to use PKI and services or users requested online verification, an attacker could potentially exploit this to bypass revocation checks. Keystone uses UUID tokens by default in Ubuntu. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
libxml2: denial of service
| Package(s): | libxml2 | CVE #(s): | CVE-2013-0339 | ||||||||||||||||||||||||||||
| Created: | March 26, 2013 | Updated: | July 15, 2013 | ||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
Brad Hill of iSEC Partners discovered that many XML implementations are vulnerable to external entity expansion issues, which can be used for various purposes such as firewall circumvention, disguising an IP address, and denial-of-service. libxml2 was susceptible to these problems when performing string substitution during entity expansion. | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
nova: two vulnerabilities
| Package(s): | nova | CVE #(s): | CVE-2013-0335 CVE-2013-1838 | ||||||||
| Created: | March 21, 2013 | Updated: | April 5, 2013 | ||||||||
| Description: | From the Ubuntu advisory: Loganathan Parthipan discovered that Nova did not properly validate VNC tokens after an instance was deleted. An authenticated attacker could exploit this to access other virtual machines under certain circumstances. This issue did not affect Ubuntu 11.10. (CVE-2013-0335) Vish Ishaya discovered that Nova did not always enforce quotas on fixed IPs. An authenticated attacker could exploit this to cause a denial of service via resource consumption. Nova will now enforce a quota limit of 10 fixed IPs per instance, which is configurable via 'quota_fixed_ips' in /etc/nova/nova.conf. (CVE-2013-1838) | ||||||||||
| Alerts: |
| ||||||||||
openstack-packstack: insecure file handling
| Package(s): | openstack-packstack | CVE #(s): | CVE-2013-1815 | ||||
| Created: | March 22, 2013 | Updated: | March 27, 2013 | ||||
| Description: | From the Red Hat advisory: PackStack is a command line utility that uses Puppet modules to support rapid deployment of OpenStack on existing servers over an SSH connection. PackStack is suitable for deploying both single node proof of concept installations and more complex multi-node installations. It was found that PackStack did not handle the answer file securely. In some environments, such as those using a non-default umask, a local attacker could possibly modify the answer file if PackStack was run in an attacker controlled directory, or attempted to create the answer file in "/tmp/", allowing the attacker to modify systems being deployed using OpenStack. Note: After applying this update, PackStack will create the answer file in the user's home directory by default. It will no longer create it in the current working directory or the "/tmp/" directory by default. (CVE-2013-1815) The CVE-2013-1815 issue was discovered by Derek Higgins of the Red Hat OpenStack team. | ||||||
| Alerts: |
| ||||||
privoxy: proxy spoofing
| Package(s): | privoxy | CVE #(s): | CVE-2013-2503 | ||||||||||||||||
| Created: | March 22, 2013 | Updated: | April 3, 2013 | ||||||||||||||||
| Description: | From the Fedora advisory: Privoxy before 3.0.21 does not properly handle Proxy-Authenticate and Proxy-Authorization headers in the client-server data stream, which makes it easier for remote HTTP servers to spoof the intended proxy service via a 407 (aka Proxy Authentication Required) HTTP status code. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>