LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityBrowserID: A new web authentication schemeIdentity and authentication on the internet is still an unsolved problem. Some sites are delegating the problem to Facebook, Twitter, and others, but that has obvious privacy and control problems, which makes it worrisome for at least some users. OpenID has never really gained much traction, and alternate user-centric proposals, like the related OpenID Connect, haven't either. There are both technical and "social" barriers that haven't been overcome. Mozilla's recent BrowserID proposal looks toward solving a subset of the identity problem by making it easier for users to log in to web applications without having to remember (or duplicate) multiple usernames and passwords. One of the main differences between BrowserID and the other solutions is that it decouples the identity question from that of authentication. Essentially, using the Verified Email Protocol (VEP) that underlies BrowserID will simply authenticate that a given email address corresponds to the browser that is being used to sign in. OpenID and others supplement that authentication with the idea of a verified identity that could include things like email address, real name, physical address, photo, and so on. BrowserID and VEP forgo all of that, which may or may not make it more palatable to web site operators. For users who control their own email domain, or whose email provider implements the protocol, VEP's operation is fairly straightforward. The email provider acts as an "authority" to authenticate its email addresses. A user who wants to have a verified email address would authenticate with the authority (via a username/password in web mail application for example) and the authority would make a JavaScript call that tells the browser that the authentication was successful. That call would then generate a public/private key pair, sending the public key to the authority and storing the private key locally. A user could have multiple identities, each tied to a unique email, at one or more authorities. When the user logs into a site that allows VEP authentication (i.e. a "relying party" or RP), they would be prompted to choose one of their email addresses to use. The browser would then create an "assertion" that listed the email address, a timestamp, and some other information, sign it with the private key, and send it to the site. The site then contacts the authority to get the public key for the user and verifies that the assertion is correctly signed. At that point, the web site can be sure that it is talking to a browser that is (or was at one point) controlled by a user with that email address. Obviously, email providers are not likely to be falling all over themselves to implement an in-progress protocol, and it may be years—if ever—before they do, so VEP has the concept of "secondary verifiers" that would be stand-ins for the email provider authorities. If the user trusted the secondary (to respect their privacy for example), they could establish their control of a particular email address via a link in an email sent by the secondary. That would include the browser in the transaction so that the key pair could be generated and the public key sent to the secondary. If an RP also trusted the secondary, it could retrieve the public key from there and verify the authenticity of the email-browser connection that way. In addition, some smaller web sites might wish (or need) to farm out the verification to a verification service run by a trusted third party. As the VEP wiki page notes: "These services obviously have tremendous power and would need to be constructed with both technical and legal care." Doing a round-trip SSL transaction to an authority (or secondary verifier) whenever a user logs in may add unacceptable latency to the log in process. It would also leak information about which sites a user is visiting to the authority. One way to handle that is with an "identity certificate" that contains the user's public key and is signed by the authority. That way, a web site would only be retrieving the authority's public key, not the user's, and that authority key could be cached by the site to eliminate all but one of the retrieval round-trips. But that raises the problem of key revocation. VEP is certainly not alone in having that particular problem. To a certain extent, all public key encryption mechanisms suffer from key revocation problems. In fact, key management is one of the hardest problems to solve for public key cryptography. As the VEP page notes, there are already problems with revocation for SSL certificates:
Just as with site-identifying certificates, the RP is required to either
retrieve a revocation list or use an online status check (that is, a CRL
[Certificate Revocation List] or
OCSP [Online Certificate Status Protocol]) to make sure an identity certificate is still valid. These steps have
proven to be problematic for the site-identifying CAs [certificate authorities] that power the SSL
site-identification infrastructure, and there is little reason to think
that email hosts would be any more capable of handling them at larger
scale. It may be realistic to think that the internet could support
identity certificate revokation at scale; perhaps we should focus our
attention instead on limiting the scope of breaches, for example by
encouraging short-lived identity certificates and automated certificate
refresh.
Much of the actual guts of the protocol are still being worked out, and it is interesting to see that some flexibility in the protocol is envisioned. The wiki document describes it this way:
The basic message flow that makes this system work is independent of the
exact cryptographic protocols and message formats that encode the
messages. For purposes of clarity, however, it is described it using a
specific set of protocols. The reader is asked to understand that those
choices are for illustrative purposes, and that multiple encodings of the
trust relationships described herein are possible.
Specifically: The explanation contained here will assume that user data lookups occur through the Webfinger protocol, that site-level metadata is retrieved through HTTPS using the .well-known/host-meta mechanism described in IETF RFC 5785 and draft-hammer-hostmeta, that assertions are generated and signed according to the JSON Web Tokens draft, and that asymmetric cryptography is performed using either RSA or ECDSA keypairs. When reference to a public key certificate is made, it is usually assumed that this would be an X509 certificate but there is no strong requirement that it be. There are, of course, some concerns about BrowserID, not least the fact that an enormous amount of sensitive information would be stored by the browser (i.e. any public keys the user has generated) on a user's computer or device. In some ways, though, that's not much different than the current practice of storing username/password pairs for multiple web sites. Protecting that data store is clearly of utmost importance (whether BrowserID ever takes off or not). BrowserID itself is a JavaScript implementation of VEP that will run in "all modern browsers, including recent versions of IE, and on mobile browsers" according to the Mozilla announcement. In addition to that and the VEP documents, Mozilla has set up browserid.org as the central location for information about the protocol and implementation. Mozilla would clearly like to see other browser makers, users, and web sites work with it to firm up BrowserID and see it headed in a direction toward deployment. It's unclear whether that will happen or whether BrowserID will be yet another failed identity experiment. It certainly does have some interesting properties, and would allow sites to gather the extra information from users that they crave (i.e. beyond just an email address). When a user sets up an account, the application could request or require much more than just the email address it needs for authentication. The lack of that extra information is part of the reason that OpenID has never really taken off (and why OpenID Connect was proposed). One thing seems sure, solutions to this problem (or related set of problems) will keep coming up until something that is easy to use and can cater to privacy-conscious users actually becomes widespread.
Brief items Security quotes of the week
War texting is something that [Don] Bailey demonstrated earlier this year
with personal GPS locators. He demonstrated how to hack vendor Zoombak's
personal GPS devices to find, target, and impersonate the user or equipment
rigged with those consumer-focused devices. Those low-cost embedded
tracking devices in smartphones or those personal GPS devices that track
the whereabouts of your children, car, pet, or shipment can easily be
intercepted by hackers, who can then pinpoint their whereabouts,
impersonate them, and spoof their physical location, he says.
-- Dark
Reading looks at talk at the upcoming Black Hat conference
What he found is that the batteries are shipped from the factory in a state
called "sealed mode" and that there's a four-byte password that's required
to change that. By analyzing a couple of updates that Apple had sent to fix
problems in the batteries in the past, [Charlie] Miller found that password and was able to put the battery into "unsealed mode."
-- Threat
Post on a Black Hat talk about Apple laptop battery vulnerabilities
From there, he could make a few small changes to the firmware, but not what he really wanted. So he poked around a bit more and found that a second password was required to move the battery into full access mode, which gave him the ability to make any changes he wished. That password is a default set at the factory and it's not changed on laptops before they're shipped. Once he had that, Miller found he could do a lot of interesting things with the battery.
Stage 1 (hiding): All participants registered for the backdoor hiding
game are given a set of requirements for a software program. Before the
deadline, they must submit the source code for a program that fulfills
these requirements plus includes a backdoor. They must also send a
description explaining how to exploit the backdoor.
-- The 2nd Open
Backdoor Hiding and Finding Contest to be held at DEFCON 0x13
Stage 2 (finding): All players registered are given a bundle with the different pieces of source code. To each bundle the organizers will add a few placebos (source codes that fulfill the requirements but should not include a backdoor). Before a deadline, the players must answer for each source code if they believe it includes a backdoor or not.
This archive contains 18,592 scientific publications totaling
33GiB, all from Philosophical Transactions of the Royal Society
and which should be available to everyone at no cost, but most
have previously only been made available at high prices through
paywall gatekeepers like JSTOR.
-- Gregory
Maxwell protests the charges against Aaron Swartz
Embedded Web Servers Exposing Organizations To Attack (Dark Reading)Dark Reading previews another talk from the upcoming Black Hat conference, this time on embedded web servers that have been connected to the internet, probably unknowingly. "[Michael] Sutton used Amazon EC2 computing resources to constantly scan large blocks of addresses and to detect any embedded Web servers. Sharp and Ricoh copiers digitally archive past photocopies, he notes, so if that feature is enabled and the copier is sitting on the Net unsecured, an attacker could retrieve any previously photocopied documents, he says. Even the fax-forwarding feature in some HP scanners could be abused if the scanner were open to the Internet: An attacker could access any faxed documents to the user by having them forwarded to his fax machine, for example."
New vulnerabilities cifs-utils: /etc/mtab file corruption
freetype: arbitrary code execution
icedtea-web: multiple vulnerabilities
kernel: denial of service
kernel: multiple vulnerabilities
libsndfile: arbitrary code execution
logrotate: symlink and hard link attacks
mapserver: multiple vulnerabilities
opensaml2: XML signature wrapping attack
opie: privilege escalation/code execution
phpmyadmin: multiple vulnerabilities
qemu-kvm: privilege escalation
rgmanager: privilege escalation
ruby: predictable random numbers
samba: multiple vulnerabilities
squirrelmail: multiple vulnerabilities
systemtap: privilege escalation
wireshark: denial of service
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||