LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityA hole in crypt_blowfishA longstanding bug that was recently found in the crypt_blowfish password hashing library highlights the problems that can occur when a bug is found in a widely used low-level library. Because crypt_blowfish has been around for so long (this bug is said to go back to 1998 or possibly 1997), it has been used by various other packages (PHP for example) as well as some Linux distributions. The security impact is not likely to be huge, because it only affects passwords with somewhat uncommon characteristics, but the impact on those who have stored hashed passwords generated using the library may be a bit more painful. Password hashing is a standard technique that is used by authentication mechanisms (for logging into a system or web application for example), so that the plaintext password does not need to be stored. Instead, something derived from the plaintext password is stored. Typically, one-way cryptographic hash functions like SHA-1 or the Blowfish cipher are used for that purpose. When the user presents the password, the same function is applied to that input and compared to what is stored. The idea is that even if an attacker gets access to the password database, they would need to "crack" the hashed values stored there. As its name implies, crypt_blowfish implements password hashing based on Blowfish. The bug itself is quite simple, and the change to fix it will likely make the problem obvious to C programmers:
Oops. In BF_std.c: BF_std_set_key(), change:
Basically, it is a sign-extension bug. For those who aren't C hackers, a
bit of explanation may be in order. When the byte value stored at
*ptr has its high bit set, it is treated as a negative number.
So, before the value gets boolean ORed with tmp (which is an unsigned
int), it gets promoted to a 4-byte value and sign-extended, so a byte value
like 0x80 becomes 0xffffff80.
As one might guess, ORing the latter where the former is expected gives
incorrect
results.
tmp |= *ptr;
to:
tmp |= (unsigned char)*ptr;
The problem was actually discovered in the John the Ripper (JtR) password cracking program. As part of creating a test suite, "magnum" was attempting to crack a password that consisted of a single non-ASCII character (£ or 0xa3), which was hashed using a library other than crypt_blowfish. Because JtR and crypt_blowfish share their implementation of the Blowfish encryption algorithm, tests using both would pass, but independent implementations would generate the correct hash, thus failing to match what was generated by JtR. JtR and crypt_blowfish developer Alexander Peslyak (aka Solar Designer) analyzed the effects of the bug and found that some password pairs would hash to the same value with only minimal differences (e.g. "ab£" hashed to the same value as "£"), which would make password cracking easier. A further analysis shows that some characters appearing just before one with the high bit set may be effectively ignored when calculating the hash. That would mean that a simpler password than that given by the user could be used and would still be considered valid—a significant weakening of the user's password. It should be noted that Solar Designer has been very forthcoming with details of the problem and its effects. His CVE request is quite detailed, and he takes full responsibility for the error. Other projects who find security holes in their code would do well to follow his lead here. There is no real problem for JtR, as it can get the updated code so that it can crack passwords with high-bit-set characters in them. In addition, it could continue to use the broken code to crack passwords that were hashed incorrectly. But for applications that use crypt_blowfish, it's a different story. Passwords with the high bit set may be fairly uncommon—at least for sites with typically ASCII-only users—but there is no easy way to determine whether stored hashes are invalid or not. The safest solution for administrators with potentially bad password hashes (which could include those running Openwall Linux (Owl), SUSE, and ALT Linux which can use crypt_blowfish for hashing the password database) is to invalidate all passwords and have their users input new ones. That could prove to be a logistical nightmare, however, depending on how easily, and securely, users can set new passwords without authenticating with their existing password. Requiring that users change their existing passwords after logging in is an alternative, but one that might give attackers a window in which to operate. It also leaves passwords unchanged for any users that do not log in. The risks of attackers using this flaw to log in to a site are likely to be fairly small, but they do exist. If a site's login process is susceptible to brute force attacks, this bug makes it somewhat easier to do so, at least for specific password types. On the other hand, if the password database has been exposed, and some passwords were not crackable (at least for attackers using cracking programs other than JtR), this information would give them the means to crack those passwords. In the end analysis, it is an exploitable hole, but not the kind to send administrators into panic mode. It is somewhat amazing that this bug has existed for 13+ years in a fairly widely used library. Up until now, no one has tested it in this way, at least publicly, which should serve as something of a warning to those who are using well-established software, both free and proprietary. With free software (crypt_blowfish has been placed into the public domain which may be a bit legally murky but is in keeping with free software ideals) there are more and easier opportunities to examine and test the code, but that's only effective if the testing is actually done. There are, without doubt, bugs still lurking in various security-oriented libraries that we depend on every day, so testing those libraries (as well as code that is not being used for security purposes) regularly and systematically can only help find them. While it took more than a decade for this bug to come to light, it's worth pointing out that it certainly could have been discovered by others in the interim. Attackers clearly do their own testing, and are generally not inclined to release their results. That may not be the case here, but one should always recognize that public disclosure of a vulnerability is not necessarily tied to its discovery.
Brief items Security quotes of the week
Firefox 4 should be treated as a member of the new breed in that regard,
and have 5 as its security update.
-- Robert
Kaiser
Actually, we are prolonging the security support for 4 and later, it's not just a minimum of six months any more, now it's "forever", just that the security updates always bring features and a new "version" as well. ;-)
I drafted a very short message (perhaps the first was too long?) and sent it to the four, once again from their own accounts: Really wasn't kidding about the insecurity thing. I won't send another message after this -- it's up to you to take your security seriously. You're at the [XYZ Street] Starbucks on an insecure connection, and absolutely anyone here can access your account with the right (free) tool.
-- Gary
LosHuertos runs an experiment with Firesheep
Twenty minutes passed, and all four were still actively using Facebook.
Having known about this problem
since 2003, a "fix" was applied in 2010 for firefox 4 which attempts to
identify credit card numbers in forms and not store them in the form
history. Great, now what about all the other data it is storing some of
which is just as sensitive as credit card numbers, if not more so ? If
credit card details get mis-used, liability is usually on the credit card
company, but not so for social security numbers, bank account numbers,
etc...
-- Daniel
P. Berrangé looks into Firefox's form data storage
Bitcoin raises untested legal concerns related to securities law, the Stamp
Payments Act, tax evasion, consumer protection and money laundering, among
others. And that's just in the U.S. While EFF is often the defender of
people ensnared in legal issues arising from new technologies, we try very
hard to keep EFF from becoming the actual subject of those fights or
issues. Since there is no caselaw on this topic, and the legal implications
are still very unclear, we worry that our acceptance of Bitcoins may move
us into the possible subject role.
-- EFF
stops accepting Bitcoin donations
Yesterday we made a code update at 1:54pm Pacific time that introduced a
bug affecting our authentication mechanism. We discovered this at 5:41pm
and a fix was live at 5:46pm. A very small number of users (much less than
1 percent) logged in during that period, some of whom could have logged
into an account without the correct password. As a precaution, we ended all
logged in sessions.
-- Dropbox drops
authentication for a few hours
The story behind the mysterious CyanogenMod updateA group called Lookout Mobile Security has put out an alert regarding malware which is targeting custom Android builds. "The application follows the common pattern of masquerading as a legitimate application, though a few extra permissions have been added. At first glance, it appears like other recent Android Trojans that tries to take control over the mobile phone by rooting the phone (breaking out of the Android security container), but instead jSMSHider exploits a vulnerability found in the way most custom ROMs sign their system images. The issue arises since publicly available private keys in the Android Open Source Project (AOSP) are often used to sign the custom ROM builds. In the Android security model, any application signed with the same platform signer as the system image can request permissions not available to normal applications, including the ability to install or uninstall applications without user intervention." This, it seems, is the vulnerability closed by the May 2011 CyanogenMod security update. (Seen on The H).
New vulnerabilities ffmpeg mplayer: arbitrary code execution
groff: insecure tmp file usage
kernel: multiple vulnerabilities
klibc: command injection
libvirt: arbitrary host file access
libxml2: code execution
moodle: multiple vulnerabilities
movabletype-opensource: multiple vulnerabilities
Mozilla products: multiple vulnerabilities
nagios: cross-site scripting
pam_ssh: privilege escalation
php: code execution
SUSE Manager: multiple vulnerabilities
SUSE Manager Proxy: insecure SSL settings
torque: remote code execution
unixODBC: buffer overflow
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||