LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityEnforcing password strengthThere have been a lot of high-profile site compromises of late (kernel.org, Linux.com, MySQL, WineHQ, ...), most or all of which have led to password disclosure. Hopefully all of the disclosed passwords were stored as hash values, but, even so, sufficiently motivated attackers may well be able to crack some of the passwords via brute force or other means. Because passwords are often reused between sites, these compromises have made projects and others concerned about the security of the passwords granting access to their sites. That concern led Kevin Fenzi of the Fedora infrastructure team to put out a message noting that all Fedora Account System (FAS) users are required to change their password (and SSH public keys, more about that below). As Fenzi said, the password change is not because of any known compromise of the Fedora infrastructure, but is, instead, a reaction to the recent compromises: "due to the large number of high profile sites with security breaches in recent months, that this is a great time for all Fedora contributors and users to review their security settings and move to 'best practices' on their machines." Part of those "best practices" is to have a strong password, so Fedora is enforcing some rules on the new passwords:
New Password Rules:
I asked Fenzi in an email where the rules came from, and he pointed me to a Fedora infrastructure bug ticket and the report [PDF] from the University of Amsterdam that it references. That report looks at various password cracking methods and estimates that using those guidelines (actually just the first three) will result in passwords that will take ten years or more to crack at 2 billion guesses per second. That rate was an average of what the researchers found that a modern GPU-equipped system could guess for several different hash algorithms. As Przemek Klosowski points out, the number of possibilities for each kind of password differ widely. There is a math error in the length-12 case (should be (24+10)^12), and evidently Klosowski is only considering 24 letters, rather than the 26 in English, but his conclusion still stands: the number of possibilities are ten orders of magnitude apart from the first to the last rule. In the end, that doesn't really matter, as long as the weakest choice is sufficient. Most who commented on the requirement were not particularly annoyed by the password change mandate, but the same cannot be said about the SSH key requirement. SSH users may tend to be more security savvy and are thus less likely to have lost control of their private SSH key than they are to have an easily cracked password—though of course that's no guarantee. But if the private SSH key that corresponds to the public key installed on the FAS servers has been compromised, it's likely that's because the owner's system has been breached. If that's the case, generating a new SSH key on a compromised system will likely only result in another compromised key. In addition, a massive SSH key flag day has its own dangers as Simo Sorce points out:
OTOH with a massive key change you have no reasonable way to monitor
suspicious key replacement activity. Remember that ssh keys can be
uploaded by simply knowing the FAS account password which is arguably
much simpler to snatch as we have many systems that require such
passwords in various different ways.
There is a strong belief that the kernel.org compromise was done via a compromised SSH key, however, so the infrastructure team is requiring folks to change their keys. Many are not happy about it, including Sorce who goes on to say:
The problem is that blindly changing keys if a contributor is being
careless accomplishes exactly nothing, and just burdens all careful
ones.
If you have evidence of contributors being careless with SSH keys the only recourse is to identify and educate the offenders requiring them to change those keys and not have a 'hit 100 to educate 1' policy that serves little or no purpose. Sorce's complaint is a reasonable one. Unfortunately, it's hard to know whose keys may have been compromised (or, indeed, if any have been compromised at all) as several folks mentioned. By bringing it up and requiring everyone to change their keys, it may result in better security—and will at least raise the awareness level of the problem, which could result in better security practices by some who were being lax. It is undoubtedly annoying to those who have been careful with their keys, but it isn't that hard to generate and use a new key, even if it is only used for FAS. Raising the level of awareness of these issues is perhaps the only good thing that has come from these high-profile break-ins. It is pretty easy to get complacent about security, reuse passwords on many sites, have password-less SSH keys, and so on. Events like the kernel.org breach can help break us all of our lax security habits. Certainly many sites, projects, and organizations—even those who haven't suffered a breach—are looking at their security practices; it's a good time for individuals to do so as well. Passwords are only part of the story, of course, but they tend to be on the "front-line" of the security of our systems, so it is a good place to start. As xkcd so eloquently put it, the time for relatively short but "hard" to guess passwords may well be behind us: pass phrases are more easily remembered and less easily cracked. It's good to see that Fedora is not enforcing a limit on the password length, it's likely that many other sites do have a fairly short limit that will make using pass phrases harder. The Fedora rules do provide some good guidelines to follow when creating passwords or phrases. Having too many passwords is almost as bad as having too few, because managing them securely can be quite a headache. One suggestion that Fenzi made is to use a password manager program like "revelation, gnome-keyring, seahorse, or keepassx". Looking more closely at those kinds of applications is on my to-do list, for both personal and professional reasons. Look for an article on that topic to appear on your virtual doorstep in the near future.
Brief items Security quotes of the week
The drones are still flying over warzones from Afghanistan to Pakistan to Yemen. There's no sign, yet, that the virus either damaged any of the systems associated with the remotely-piloted aircraft or transmitted sensitive information outside the military chain of command — although three military insiders caution that a full-blown, high-level investigation into the virus is only now getting underway.
-- Wired
reports on a virus infecting US drone aircraft
Nevertheless, the virus has sparked a bit of a firestorm in military circles. Not only were officials in charge kept out of the loop about an infection in America's weapon and surveillance system of choice, but the surprise surrounding that infection highlights a flaw in the way the U.S. military secures its information infrastructure: There's no one in the Defense Department with his hand on the network switch. In fact, there is no one switch to speak of.
If having a keylogger on a weapons system's command-and-control console is
"benign" we don't want to know what "malicious" is — though perhaps
the operators of the Iranian reactor at Beshehr could share some of their
experiences.
-- Marcus J. Ranum
To catch up with the new technologies of malfeasance, FBI director Robert Mueller traveled to Silicon Valley last November to persuade technology companies to build "backdoors" into their products. If Mueller's wish were granted, the FBI would gain undetected real-time access to suspects' Skype calls, Facebook chats, and other online communications—and in "clear text," the industry lingo for unencrypted data. Backdoors, in other words, would make the Internet — and especially its burgeoning social media sector — "wiretappable."
-- Evgeny
Morozov reviews Susan Landau's Surveillance or Security? (via Bruce Schneier)
An analysis of alleged German governmental malwareThe Chaos Computer Club claims to have analyzed a rootkit used by the German government. "The malware can not only siphon away intimate data but also offers a remote control or backdoor functionality for uploading and executing arbitrary other programs. Significant design and implementation flaws make all of the functionality available to anyone on the internet."
WineHQ database compromisedCodeweavers has announced that access to the WineHQ database has been compromised. "On the one hand, we saw no evidence of harm to any database. We saw no evidence of any attempt to change the database (and candidly, using the real appdb or bugzilla is the easy way to change the database). Unfortunately, the attackers were able to download the full login database for both the appdb and bugzilla. This means that they have all of those emails, as well as the passwords. The passwords are stored encrypted, but with enough effort and depending on the quality of the password, they can be cracked." Anybody who has reused a password stored there probably wants to make some changes fairly soon.
New vulnerabilities apache: mod_proxy reverse proxy exposure
cups: arbitrary code execution
cyrus-imapd: access restriction bypass
kdelibs: certificate spoofing
kernel: two information leaks
kernel: multiple vulnerabilities
kernel: denial of service
libxml2: denial of service
openswan: denial of service
php: arbitrary code execution
xorg-x11-server: multiple vulnerabilities
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||