By Nathan Willis
March 27, 2013
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.
Comments (3 posted)
Brief items
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.
This is the "equal and opposite" reaction to blacklists: Total
Information Awareness applied to our customer's email.
--
Anonymous PRIVACY Forum reader (and ISP
employee)
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.
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.
--
Bruce
Schneier
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
Comments (1 posted)
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."
Comments (14 posted)
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."
Comments (83 posted)
New vulnerabilities
euca2ools: insecure snapshots
| Package(s): | euca2ools |
CVE #(s): | CVE-2012-4066
|
| Created: | March 25, 2013 |
Updated: | March 28, 2013 |
| 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: |
|
Comments (none posted)
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: |
|
Comments (none posted)
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: |
|
Comments (none posted)
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: | April 1, 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: |
|
Comments (none posted)
keystone: revocation check bypass
| Package(s): | keystone |
CVE #(s): | CVE-2013-1865
|
| Created: | March 21, 2013 |
Updated: | April 5, 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: |
|
Comments (none posted)
libxml2: denial of service
| Package(s): | libxml2 |
CVE #(s): | CVE-2013-0339
|
| Created: | March 26, 2013 |
Updated: | March 27, 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: |
|
Comments (none posted)
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: |
|
Comments (none posted)
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: |
|
Comments (none posted)
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: |
|
Comments (none posted)
Page editor: Jake Edge
Next page: Kernel development>>
