Security
Fedora accepting YubiKey one-time passwords
Some Fedora hosts and services have recently added a new authentication mechanism which uses a USB device that generates one-time passwords (OTPs). The YubiKey doesn't require any client-side software because it acts like a USB keyboard. In addition, the server-side authentication software, as well as a client-side utility to update the YubiKey, are open source. Like most security measures, hardware-based OTPs have advantages and disadvantages. But, when an OTP is combined with another authentication method—a regular password for example—it can provide a two-factor authentication that is much more secure.
YubiKeys came into Fedora to provide two-factor authentication for access to sensitive servers, like those that contain the keys for signing Fedora packages. Now that the infrastructure team has gotten that working, it decided to allow other Fedora users to use their own YubiKeys for single-factor authentication to things like ssh access to fedorapeople.org or signing in to the Fedora Community site.
The YubiKey uses symmetric encryption, which means that both the YubiKey and the server must share an AES secret key. The YubiKey comes from the factory with a pre-installed key that is shared with Yubico's server. For Fedora's purposes, users will run fedora-burn-yubikey when they first get the device. That script will generate a key on the server that also gets burned into the YubiKey.
To use the device, users plug it into the USB port on the machine they are using, put the cursor in the password prompt field, and press a button on the YubiKey. That will generate an OTP and a carriage return into the field. The OTP contains a serial number that gets incremented each time the YubiKey is used. Invalidating an exposed (but unused) OTP is done by properly authenticating with the server, thus incrementing the serial number past the exposed password.
The server ensures that each password can only be used once by tracking the serial number for each AES key it knows about. Even if an attacker were able to capture the AES key somehow—the YubiKey device has no means to read it out directly—he must also use a serial number that is greater than the last one used by the owner. If that happened, the next legitimate attempt to authenticate using the YubiKey would fail (because its serial number is now too low), which would be a clear indication of key compromise.
Obviously, physical security of the YubiKey is paramount. An attacker that gets access to it for even a short time can easily—largely undetectably—authenticate as the owner. Since OTPs that have been used are no longer valid, sniffing password entry on the wire or "keystroke" logging won't be of any assistance to an attacker—by the time the password is known, it's no longer useful.
After Mike McGrath announced YubiKey support on the fedora-devel mailing list, there was some discussion of the device and possible attacks against it. One of the concerns raised was with the potential sharing of AES keys between servers. If a user wanted to use the same device with multiple YubiKey-enabled sites, they would need to share their AES key with all of the servers. If any one of those servers was compromised, it would allow an attacker to authenticate to any of the others.
For a number of reasons, this attack scenario was considered to be unlikely. It would take explicit action by the user—or a compromised client machine—when writing the AES key to the YubiKey to record the key before it gets written. Presumably users who are purchasing YubiKeys will be security-conscious enough to recognize that it is a bad idea to record the AES key. McGrath also made the window of exposure quite small:
In addition, newer YubiKeys allow for two different keys to be stored in them and will generate OTPs from one or the other based on how long the button is pressed. Toshio Kuratomi puzzled out the magic incantation required to write the second key and observed that holding the button for longer than 2.5 seconds would send an OTP based on the second key. Using that feature would allow sharing the device with two separate services, but if YubiKey OTPs become more popular, some other scheme for handling multiple sites will probably be required.
In some ways, this is all just a prelude to more widespread use of multi-factor authentication. In the next few years, OTPs are likely to become much more widely used for accessing sensitive sites and applications. The YubiKey idea is interesting, particularly because it doesn't require client-side support and doesn't lock users into some proprietary OS. A similar device that used public key, rather than symmetric, encryption would be worth trying as well.
Brief items
Security quotes of the week
Schneier on Stuxnet
Here's a fairly comprehensive look at what's known about the Stuxnet worm by Bruce Schneier. "Stuxnet was expensive to create. Estimates are that it took 8 to 10 people six months to write. There's also the lab setup--surely any organization that goes to all this trouble would test the thing before releasing it--and the intelligence gathering to know exactly how to target it. Additionally, zero-day exploits are valuable. They're hard to find, and they can only be used once. Whoever wrote Stuxnet was willing to spend a lot of money to ensure that whatever job it was intended to do would be done."
Flaw in libc implementation threatens FTP servers (The H)
Anybody running an anonymous FTP server may want to have a look at this article in The H about a newly-disclosed denial of service problem. "The problem exists because GLOB_LIMIT, a feature added in 2001 to limit the amount of memory used by the glob() function is ineffective. Globbing, as it is called, calls on the glob() function to match wildcard patterns when generating a list of matching file names. Because GLOB_LIMIT is not effective, it potentially allows a system's main memory to be flooded when processing certain patterns and this may, depending on the hardware used, cause the system to become very slow, cease to respond or even crash as a result."
Gilmore on the "computer health certificate" plan
Worth a read: this response by John Gilmore to the computer health certificate idea being pushed by a Microsoft researcher. "I'd recommend merely ignoring his ideas til they sink like a stone. But it looks like Intel and Microsoft are actively sneaking up on the free Internet and the free 10% of the computer market by building in these techniques and seeking partnerships with governments, ISPs, telcos, oligopolists, etc to force their use. So some sort of active opposition seems appropriate."
IcedTea6 1.7.5, 1.8.2, 1.9.1 Released
A number of vulnerabilities have been fixed in IcedTea6 1.7.5, IcedTea6 1.8.2 and IcedTea6 1.9.1. Click below for a list of the security issues fixed in these releases, which include man-in-the-middle attacks, code execution, and more.
New vulnerabilities
acroread: multiple vulnerabilities
| Package(s): | acroread | CVE #(s): | CVE-2010-2883 CVE-2010-2887 CVE-2010-2889 CVE-2010-2890 CVE-2010-3619 CVE-2010-3620 CVE-2010-3621 CVE-2010-3622 CVE-2010-3623 CVE-2010-3624 CVE-2010-3625 CVE-2010-3626 CVE-2010-3627 CVE-2010-3628 CVE-2010-3629 CVE-2010-3630 CVE-2010-3631 CVE-2010-3632 CVE-2010-3656 CVE-2010-3657 CVE-2010-3658 | ||||||||||||||||
| Created: | October 11, 2010 | Updated: | January 21, 2011 | ||||||||||||||||
| Description: | From the Adobe security advisory:
Critical vulnerabilities have been identified in Adobe Reader 9.3.4 (and earlier versions) for Windows, Macintosh and UNIX, Adobe Acrobat 9.3.4 (and earlier versions) for Windows and Macintosh, and Adobe Reader 8.2.4 (and earlier versions) and Adobe Acrobat 8.2.4 (and earlier versions) for Windows and Macintosh. These vulnerabilities, including CVE-2010-2883, referenced in Security Advisory APSA10-02, and CVE-2010-2884 referenced in the Adobe Flash Player Security Bulletin APSB10-22, could cause the application to crash and could potentially allow an attacker to take control of the affected system. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
kernel: denial of service
| Package(s): | kernel-rt | CVE #(s): | CVE-2010-3067 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | October 8, 2010 | Updated: | March 28, 2011 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the CVE entry:
Integer overflow in the do_io_submit function in fs/aio.c in the Linux kernel before 2.6.36-rc4-next-20100915 allows local users to cause a denial of service or possibly have unspecified other impact via crafted use of the io_submit system call. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
kernel: multiple vulnerabilities
| Package(s): | kernel | CVE #(s): | CVE-2010-2960 CVE-2010-2962 CVE-2010-3079 CVE-2010-3310 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | October 13, 2010 | Updated: | May 10, 2011 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the SUSE advisory:
CVE-2010-2960: local users could crash the system by causing a NULL deref in the keyctl_session_to_parent() function CVE-2010-2962: local users could write to any kernel memory location via the i915 GEM ioctl interface CVE-2010-3079: local users could crash the system by causing a NULL deref in ftrace CVE-2010-3310: local users could corrupt kernel heap memory via ROSE sockets | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
MRG Messaging: denial of service
| Package(s): | MRG Messaging | CVE #(s): | CVE-2010-3083 CVE-2010-3701 | ||||||||
| Created: | October 8, 2010 | Updated: | October 14, 2010 | ||||||||
| Description: | From the Red Hat advisory:
A flaw was found in the way SSL connections to the MRG Messaging broker were handled. A connection (from a user or client application) to the broker's SSL port would prevent the broker from responding to any other connections on that port, until the first connection's SSL handshake completed or failed. A remote user could use this flaw to block connections from legitimate clients. Note that this issue only affected connections to the SSL port. The broker does not listen for SSL connections by default. (CVE-2010-3083) A flaw was found in the way the MRG Messaging broker handled the receipt of large persistent messages. If a remote, authenticated user sent a very large persistent message, the broker could exhaust stack memory, causing the broker to crash. (CVE-2010-3701) | ||||||||||
| Alerts: |
| ||||||||||
openswan: code execution
| Package(s): | openswan | CVE #(s): | CVE-2010-3308 CVE-2010-3302 | ||||||||||||||||
| Created: | October 11, 2010 | Updated: | November 17, 2010 | ||||||||||||||||
| Description: | From the CVE entries:
Buffer overflow in programs/pluto/xauth.c in the client in Openswan 2.6.26 through 2.6.28 might allow remote authenticated gateways to execute arbitrary code or cause a denial of service via a long cisco_banner (aka server_banner) field. (CVE-2010-3308) Buffer overflow in programs/pluto/xauth.c in the client in Openswan 2.6.25 through 2.6.28 might allow remote authenticated gateways to execute arbitrary code or cause a denial of service via long (1) cisco_dns_info or (2) cisco_domain_info data in a packet. (CVE-2010-3302) | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
subversion: restriction bypass
| Package(s): | subversion | CVE #(s): | CVE-2010-3315 | ||||||||||||||||||||||||||||||||||||
| Created: | October 11, 2010 | Updated: | February 16, 2011 | ||||||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
Kamesh Jayachandran and C. Michael Pilat discovered that the mod_dav_svn module of subversion, a version control system, is not properly enforcing access rules which are scope-limited to named repositories. If the SVNPathAuthz option is set to "short_circuit" set this may enable an unprivileged attacker to bypass intended access restrictions and disclose or modify repository content. | ||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||
wireshark: stack overflow
| Package(s): | wireshark | CVE #(s): | CVE-2010-3445 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | October 13, 2010 | Updated: | April 19, 2011 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Mandriva advisory:
It was discovered that the ASN.1 BER dissector in wireshark was susceptible to a stack overflow. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
xpdf: code execution
| Package(s): | xpdf | CVE #(s): | CVE-2010-3702 CVE-2010-3704 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | October 8, 2010 | Updated: | April 19, 2011 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory:
An uninitialized pointer use flaw was discovered in Xpdf. An attacker could create a malicious PDF file that, when opened, would cause Xpdf to crash or, potentially, execute arbitrary code. (CVE-2010-3702) An array index error was found in the way Xpdf parsed PostScript Type 1 fonts embedded in PDF documents. An attacker could create a malicious PDF file that, when opened, would cause Xpdf to crash or, potentially, execute arbitrary code. (CVE-2010-3704) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>