LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityFedora accepting YubiKey one-time passwordsSome 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:
I had this [attack] in mind when I designed the burn script. The key never
touches the drive during the burning process [so the] attack window here,
while real, is very tiny. Certainly safer then typing your username and
password everywhere all the time :)
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
There is one type of surveillance that genuinely would be rendered
impractical by widespread use of secure communications, however. Known
individual suspects can be targeted by other means, but if the government
wanted to do wholesale surveillance, in which the whole communications
stream is automatically analyzed and filtered by artificial intelligence
software hunting for suspicious communications by unknown parties -- as
several accounts have suggested the National Security Agency did under the
warrantless wiretapping program authorized by President George W. Bush --
they really would need a back door at the system level. But while
governments may consider it a bug when network architecture renders such
sweeping surveillance infeasible, citizens should probably regard it as a
feature.
-- Julian
Sanchez
Except that we don't forget about it. Over time, these enigmatic warnings
do al-Qaida's work for them, scaring people without cause. Without so much
as lifting a finger, Osama Bin Laden disrupts our sense of security and
well-being. At the same time, they put the U.S. government in the position
of the boy who cried wolf. The more often general warnings are issued, the
less likely we are to heed them. We are perhaps unsettled or unnerved, but
we don't know what to do. So we do nothing-and wish that we'd been told
nothing, as well.
-- Anne Applebaum in
Slate on vague security warnings
Schneier on StuxnetHere'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" planWorth 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 ReleasedA 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
kernel: denial of service
kernel: multiple vulnerabilities
MRG Messaging: denial of service
openswan: code execution
subversion: restriction bypass
wireshark: stack overflow
xpdf: code execution
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||