LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityMozilla PiCL and multi-level securityFirefox users have been able to synchronize various browser features between multiple desktops and mobile devices for several years: bookmarks, history, preferences, and even installed add-ons. But that synchronization comes with a risk; the data stored remotely on the synchronization server must be protected—some of it has privacy implications, while other data (such as saved passwords) pose much greater problems if stolen. Mozilla only stores encrypted data on the server, but it is still working to make improvements. It recently began to publicize its plans for the future of the Firefox Sync service, called "Profile in the Cloud" (PiCL). The plan calls for a number of changes to the security architecture. One is a move away from requiring full-strength cryptographic keys, while another is the ability to separate high-value and low-value data for separate classes of security. Mozilla developer Brian Warner posted a blog entry about PiCL on July 23. The architecture document on the Mozilla wiki provides an overview of the revised system, which will evidently add to the data types currently synchronized by Firefox Sync (including WebRTC bridging providers, social API preferences, and file storage). Warner's post, however, focuses on the security model. The biggest user-visible change is likely to be the dropping of Firefox Sync's existing credentials (a username, email address, and separate encryption key) in favor of a simpler email-address–plus–password approach. But the real magic takes place behind the scenes: PiCL will offer multiple security levels and will better protect the cryptographic key that protects user data, but users will only need to remember their chosen password. Currently, Firefox Sync randomly generates a full-strength cryptographic key on the browser, encrypts user data with it, and uploads the encrypted file to the Sync server. The key itself is stored on the user's computer, not the server. In addition, users also set up an account on the Firefox Sync server, using an email address and a user-selected password. This email/password combination is only used to completely reset an account if the key is lost. Building levelsThe revised plan as described by Warner rearranges the pieces somewhat. Users will still set up an account using their email address and a selected password, although the account setup system will make use of Mozilla's Persona, which did not exist when the current Firefox Sync system was rolled out. But, more importantly, the email/password pair will be used to derive encryption keys. Yes, there are keys, plural: for starters, one (known as kA) corresponds to the "class A" or low-value data set and one (kB) corresponds to the "class B" or high-value data set. An important facet of the new design is that it offers users the choice between two storage options: class A data can be recovered by Mozilla, while class B data cannot. Users can choose which synchronization data is assigned to which class; Mozilla may default to saving passwords as class B and everything else as class A, but that decision is not yet final. Users can also change their minds after the initial setup, and move data from one class to another. In addition to this feature, the plan also takes steps to make brute-force attacks against account passwords as expensive as possible, even in the event of compromised servers at Mozilla. The higher-security kB key is created client side by the browser, which then sends a verification code—but not kB itself—to the PiCL server. The server, in turn, creates kA when it creates the user's account, which is what allows class A data to be recovered in the event that the user forgets his or her password. Warner describes the key-generation and account-setup process on the Mozilla wiki. Among the salient points is that kB, even though it is derived from a user-selected password, must be strengthened as much as possible to make it resistant to brute-force guessing. PiCL does this by salting and then stretching the email/password pair on the client side. Warner cites Password-Based Key Derivation Function 2 (PBKDF2, from RFC 2898), which is computationally expensive, and scrypt, which is memory-expensive, as the stretching techniques. There are some initial parameters for the stretching algorithms under discussion, but they do not appear to be final as of now. Naturally, even after stretching, kB will not be as random as the cryptographically strong key currently used by Firefox Sync, but the overall PiCL system takes more effort to protect kB against discovery. For comparison, the Firefox Sync system relays the user's key to each synchronized client using the J-PAKE protocol, meaning it is stored locally on multiple devices as well as occasionally being sent across the network. It is not sent in the clear, of course, but it is sent, so there are always possible attack vectors. In contrast, kB does not leave the local machine, and is never stored on any device. In a synchronization session, the client proves to the server that it possesses kB using the Secure Remote Password (SRP) protocol. The client prompts the user for the email/password combination, derives kB, then calculates an SRP verifier code to send to the server. The server can then send encrypted class B data back to the client to use or modify as desired. The situation for class A data is much simpler, as the server generates and possesses kA. The current plan is to use kA and kB to derive several distinct AES HMAC encryption keys (using HKDF, the HMAC-based Key Derivation Function), one for each type of data stored (e.g., passwords or preferences). Whether kA or kB is used to create the per-datatype key depends on the class in which the user wishes to save the data. Encrypting each type (e.g., bookmarks, passwords, or history) separately permits the user to have a change of heart about whether a particular data type should be saved in class A or class B. Architecture and trade-offsPiCL also differs from Firefox Sync in that it uses two separate servers: a keyserver, which stores kA and the kB verification code for each account, and a storage server which retains the actual encrypted data. The benefit is that both the keyserver and the storage server must be compromised for an attacker to gain access to any data, and if that happened, only the class A data would be revealed. This, Warner notes, makes class A data no more vulnerable than any "service provider holds everything" scenario, while also offering a higher level of protection with class B. Another benefit is that an attacker compromising the storage server alone would not be able to steal any keys. Warner also points out the known vulnerabilities of the system. A user's email provider, for instance, can intercept the account-setup and account-reset emails, and obtain access to class A data. For that matter, the email provider can fake the entire password-reset process and hide that fact from the user. As for class B data, even though kB is never sent over the network (nor are the password and salt that generates it), the keyserver does retain a copy of the kB verifier code, so an attacker could attempt to guess the password by brute force. Furthermore, an attacker that compromises the keyserver can perform this attack offline. The password-stretching process is meant to make this attack as expensive as possible, but ultimately if you choose a guessable password you will make the attacker's life easier. PiCL is still under heavy development; Warner asked for feedback on the keyserver protocol in his blog post. But there are already several features of note. First, the ability to separate high-value and low-value data will likely garner fans, especially among those who have lost an irrecoverable Firefox Sync password previously. Interestingly enough, some earlier draft documents on the wiki discuss even more security levels, so Mozilla clearly sees this as a feature desired by its users. Second, separating the keyservers and storage servers on Mozilla's end does offer some additional protections, although it does so at the cost of additional complexity. Mozilla can presumably afford to manage this complexity, but one of the nicest features of Firefox Sync is that it is possible to run a private synchronization server. It will be harder for self-hosting users to take advantage of the split-server model. Finally, it is an interesting question (probably open for lengthy debate) whether or not the stretched-password kB key in PiCL is more secure than the random key in Firefox Sync. One is more random and thus harder to guess, but it is also transmitted over the network and stored. Since users cannot memorize the random Firefox Sync key, it must be stored—but that makes it more vulnerable to theft. The one thing everyone will agree with is that the two systems illustrate the classic security/convenience trade-off. The name "Profile in the Cloud" certainly suggests the ability to synchronize lots and lots more data, and "the cloud" is not exactly synonymous with secure storage of private data. Thus, it will be interesting to watch where PiCL heads next. Perhaps simply forcing users to actively think about security "classes" will, if nothing else, raise awareness of the risks of storing personal information remotely.
Brief items Security quotes of the week
The two [Jeremiah Grossman and Matt
Johansen] discovered that even reputable ad networks do a poor job of vetting
the java script that is bundled with ad images. "As long as it looks
pretty, they have no problem with it," Johansen said. "The folks we were
dealing with (at the ad networks) didn't really have the javascript reading
skills to know the difference anyway."
— ITworld
reports on a Black Hat security conference presentation
In the [Bradley] Manning case, the prosecution used Manning's use of a standard, over
15-year-old Unix program called Wget to collect information, as if it were
a dark and nefarious technique. Of course, anyone who has ever called up
this utility on a Unix machine, which at this point is likely millions of
ordinary Americans, knows that this program is no more scary or spectacular
(and far less powerful) than a simple Google search. Yet the court
apparently didn't know this and seemed swayed by it.
— Cindy
Cohn of the Electronic Frontier Foundation (EFF)
We've seen this trick before. In a case EFF handled in 2009, Boston College police used the fact that our client worked on a Linux operating system with "a black screen with white font" as part of a basis for a search warrant. Luckily the Massachusetts Supreme Court tossed out the warrant after EFF got involved, but who knows what would have happened had we not been there.
What would a spoofing attack look like in practice? Suppose the spoofer's
goal is to run the target vessel aground on a shallow underwater
hazard. After taking control of the ship's GPS unit, the spoofer induces a
false trajectory that slowly deviates from the ship's desired
trajectory. As cross-track error accumulates, the ship's autopilot or
officer of the watch maneuvers the ship back into apparent alignment with
the desired trajectory. In reality, however, the ship is now off
course. After several such maneuvers, the spoofer has forced the ship onto
a parallel track hundreds of meters from its intended one. Now as the ship
moves into shallow waters, the ECDIS display and the down-looking depth
sounder may indicate plenty of clearance under the keel when in truth a
dangerous shoal lies just underwater dead ahead. Maybe the officer of the
watch will notice the strange offset between the radar overlay and the
underlying electronic charts. Maybe, thinking quickly, he will reason that
the radar data are more trustworthy than the ship's GPS-derived position
icon displayed on the ECDIS. And maybe he will have the presence of mind to
deduce the ship's true location from the radar data, recognize the looming
danger, and swing clear of the shoal to avert disaster. Or maybe not.
— Todd
Humphreys on GPS spoofing as reported by ars technica
To call Prime Minister Cameron a "clown" at all might reasonably be taken by some as an affront to clowns and jesters reaching back through history. Because Cameron's style of clowning is far more akin to the nightmarish, sneering "clowns" of "B" horror movies, not the bringers of entertainment under the big top.
— Lauren Weinstein
Cameron, through a series of inane and grandstanding statements and pronouncements both deeply technically clueless and shamelessly politically motivated, has been channeling Napoleon by placing the clown prince crown on his own head. Laughing at his antics would be a terrible mistake. For his wet dream of Internet censorship poses an enormous risk not only to the UK, but to other nations around the world who might seek comfort in his idiocy for their own censorship regimes (already, calls have been made in Canada to emulate Cameron's proposed model).
Janik: Tor exit node for less than a weekOn his blog, Tim Janik reports on his efforts to run a Tor exit node. Unfortunately, he was shut down quickly—because of the terms of service of his server provider. "It turned out the notice had a twist to it. It was actually my virtual server provider who sent that notice on behalf of a complaining party and argued that I was in violation of their general terms and conditions for purchasing hosting services. Checking those, the conditions read: "Use of the server to provide anonymity services is excluded." Regardless of the TMG [German telecommunications law], I was in violation of the hosting provider’s terms and conditions which allowed premature termination of the hosting contract. At that point I had no choice but stopping the Tor services on this hosting instance."
Ubuntu's forums returnCanonical has announced the return of the Ubuntu forums to normal service; there is also a detailed description of how the system was compromised. "In summary, the root cause was a combination of a compromised individual account and the configuration settings in vBulletin, the Forums application software. There was no compromise of Ubuntu itself, or any other Canonical or Ubuntu services. We have repaired and hardened the Ubuntu Forums, and as the problematic settings are the default behaviour in vBulletin, we are working with vBulletin staff to change and/or better document these settings." It all started with a cross-site scripting attack.
Now That It’s in the Broadband Game, Google Flip-Flops on Network Neutrality (Wired)Wired has a report on Google's response [PDF] to Douglas McClendon's complaint about "servers" being prohibited on Google Fiber. The response, which was ordered by the US Federal Communications Commission (FCC), states that Google Fiber can prohibit servers by noting, in part, that other providers' Terms of Service do likewise. But that flies in the face of earlier support for network neutrality as espoused by the company. "But, it turns out that Google's real net neutrality policy is that big corporate services like YouTube and Facebook shouldn't get throttled or banned by evil ISPs like Verizon, but it's perfectly fine for Google to control what devices citizens can use in their homes. We, it seems, are supposed to be good consumers of cloud services, not hosting our own Freedom Boxes, media servers, small-scale commercial services or e-mail servers."
New vulnerabilities 389-ds-base: information disclosure
bind9: denial of service
fdupes: file permission overwrite
gnupg: information leak
java-1_6_0-ibm: multiple unspecified vulnerabilities
java-1_7_0-ibm: multiple unspecified vulnerabilities
lcms2: denial of service
mysql: multiple vulnerabilities
openafs: two encryption flaws
phpmyadmin: multiple vulnerabilities
rubygem-passenger: insecure temporary directory usage
wireshark: multiple vulnerabilities
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||