Security
Sovereign Keys for certificate verification
The certificate-authority (CA)-based approach to identity-checking on the web is under heavy fire these days. In theory, when a client like a web browser initiates a secure connection to a remote server, it relies on a chain of trusted cryptographic signatures presented by the server to verify that the public-key encryption certificate belongs to who the browser is expecting. But as the Electronic Frontier Foundation (EFF) has pointed out numerous times in public, the CA system is too-easily circumvented by fake CAs or attackers intercepting and replacing credentials during the handshake.
The problem affects SSL/TLS, SMTPS, and other secure protocols. There are plenty of proposals for replacing the CA portion of system, including Convergence, MonkeySphere, and Public Key Pinning. EFF's chief technologist Peter Eckersley has proposed a new framework called Sovereign Keys that is intended to securely verify associations between domain names and cryptographic keys in a way that is more robust than the CA system in use today, but can piggyback on it.
The Sovereign Key system allows clients to verify the validity of a server's X.509 certificate by referencing a persistent, append-only database mirrored around the world. The Sovereign Key service is designed to prevent man-in-the-middle and server-impersonation attacks — even those where an attacker has compromised a CA — and provides a safe workaround when an attack on SSL/TLS would trigger one of those certificate warning messages that users have grown accustomed to ignoring. Although in theory it could be used to replace the CA system outright, the proposal instead presents it as a way to augment existing techniques, which maximizes compatibility with existing HTTPS and SSL/TLS infrastructure.
A November 18 blog post outlines the Sovereign Keys proposal at a high level, including the weaknesses in the current CA model and links to research showing the ineffectiveness of certificate warnings in modern web browsers. The proposal itself is hosted in the EFF Git repository, although Eckersley warns that it is in draft form only, and not a complete specification. In particular, it does not detail protocol encodings and numerical parameters that would be required before undertaking a real-world implementation.
There is also a set of "issues
" with the current design that
are also hosted
in the repository. Currently five in number, they outline possible attack
vectors and transitional or pragmatic hurdles in the way of possible adoption. Eckersley said that the EFF is working toward a real-world test, but that because of the scope involved, it is still too soon to announce.
The design
As the proposal outlines it, there are two chief problems with the CA system in use today. First, it is vulnerable to variety of attacks, including a compromised CA itself, a CA pressured by a government into maliciously replacing a certificate, a compromised router near either the client or the CA, or even a compromised DNS server in between the client and CA. Second, the default way for browsers to warn users about potential attacks is with a certificate warning message. But research has shown that the majority of certificate warnings are generated by "bureaucratic
" non-attack incidents like mismatches and self-signed certificates, which has trained users to ignore the warnings.
The first goal of the Sovereign Keys design is to allow clients to check the validity of a server's certificate without relying on any third-party that could be compromised like the CA system can. The second is to provide an alternate method for clients to securely connect to the correct server in case the validity check fails (meaning the server the client actually wants to connect to, even if the server originally seen is an impostor).
In the Sovereign Keys system, a definitive "sovereign key" key-pair exists for each service on the Internet. There is a public, master database of all of the (public key) sovereign keys, and any client could use it to check the signature on a particular server's SSL/TLS certificate. The certificate could be changed, but as long as the verified sovereign key signs the new one, the clients would consider it valid. What makes the Sovereign Keys database more trustworthy than a chain of CA-signatures is that it is verifiably read-append-only — meaning that all clients can query it, but that the database server can only append new records, not modify old ones — and replicated by a set of global mirrors.
Because it can be appended to but not changed, the database is a "timeline
" that includes a complete record of new sovereign key registrations, revocations, and other incidents. In the event that a timeline server experiences a fault (such as two events being recorded out-of-sequence), any client can recognize it, flag it as renegade, and stop trusting it. The timeline is a bit like the distributed, public transaction record used by Bitcoin — its authenticity is designed to be verifiable by clients and mirrors. Each entry includes a strictly-incrementing serial number and a monotonically-increasing timestamp, and the entries are cryptographically signed.
The other half of the design is what a client is meant to do if a server's certificate fails the sovereign key-verification test. Rather than allow the user to continue to connect (which may be a man-in-the-middle attack, but even if it is not, reinforces the behavior that continuing to connect is acceptable), the client takes the sovereign key found in the timeline for the service, computes an SHA1 hash of the key, and attempts to connect to that hash value as a hidden .onion service via Tor. If the service does not accept connections on the .onion address, the client is to stop, and not connect at all. In other words, it may ultimately fail to connect, but that is better than making an unsafe connection.
Of course, the use of Tor as an alternate method for connecting to a service introduces its own set of additional requirements. The client must be running Tor and have a proxy set up to properly redirect requests using the .onion pseudo-domain. The server must also be configured to run the hidden service, because the system uses Tor routing rather than DNS or IP addressing to route traffic.
Multiple timelines?
The integrity of the timeline is paramount to making the Sovereign Keys system work. Although, technically speaking, there are multiple trusted timelines, one for each timeline server. The timeline servers inform each other of events, but in keeping with the append-only nature of the timeline, each timeline server has its own timestamp. There are separate record types to distinguish between events that happen on the timeline server and those that are relayed from a peer.
The process starts when the owner of a domain registers a sovereign key
for a new service (officially, this registration calls for both a protocol
— say, HTTPS or SMTPS — and a domain) with a nearby timeline
server. According to the proposal, the registrant must present evidence
that he or she controls the domain at the time of the registration. The
evidence can be either "a CA-signed DER-encoded X.509 certificate
associating the name with the Sovereign Key, or DANE DNSSEC evidence
associating the name with the Sovereign Key, if that is available for this
TLD [top-level domain].
" The timeline server must verify the evidence. The evidence is logged in the timeline entry along with other pertinent data: the timeline's serial number and timestamp, the sovereign key itself, the domain name and protocol(s) registered for it, an optional expiration date, and two auxiliary fields, "wildcard" and "inheriting name(s)."
The proposal estimates that the space required to store such timeline entries for all of the 200 million domains currently in existence is around 300GB (although no estimate is made for how quickly this set of domains is growing, which could also prove relevant). The wildcard field is set by the registrant; if 0 then the sovereign key applies only the exact domain name listed; if 1 then the sovereign key is considered valid for matching subdomains as well. The "inheriting name(s)" are an optional list of other sovereign keys that are granted the right to register a new sovereign key for this domain if and when this current sovereign key is later revoked. Only self-signed revocations are accepted, so, in theory, designating "heirs" at the time of registration prevents later hijacking.
Apart from new sovereign key registrations, the timeline contains three types of entries: registrations-by-reference (registrations that were initiated at other timeline servers), revocations, and reissuances (which might change parameters like the protocols accepted). These entries are shorter, consisting of (in the registration-by-reference example) the original timeline server's id, serial number, and timestamp data, plus the serial number and timestamp that the reference was logged at in this timeline.
The design calls for a set number of timeline servers (10-30); having multiple root timeline servers should increase performance and make the network more reliable, particularly if they are located in different geographic and network regions. The proposal does not address how they are bootstrapped, but they seem to require a priori knowledge of each other in order to propagate registrations-by-reference and other important timeline events. Mirrors, on the other hand, also increase availability and performance from the clients' perspective, but mirrors do not record any new events to the timeline, they only synchronize with the authoritative timeline servers.
Conflicts, mirrors, and sharing
Space in the proposal is dedicated to what happens when one timeline
server seems to violate the rules, such as storing two entries in its
timeline with the same or out-of-order serial numbers, recording a lower
timestamp than a previous entry, or registering a new sovereign key without
verifiable credentials. Because clients are expected to query the mirror
servers and not the root timeline servers directly, mirrors are expected to
catch the misbehavior first. They then record the incident (including the
problematic timeline entries), stop trusting the timeline server, and
propagate the incident to clients that ask. Mirrors are also supposed to
propagate this "renegation
" information to each other;
presumably the managers of the root timeline servers would be notified as well.
A longer discussion is devoted to the mirroring and mirror-querying protocol. Clients are supposed to trust the oldest sovereign key found for a domain in all of the valid timelines — plus whatever revocations and renewals follow it — so replicating the entire timeline could be important to verifying any particular transaction. How long clients and mirrors should cache information is both a performance and security consideration. The proposal recommends a series of trust stages from 24 hours to two weeks in length.
It also discusses how Sovereign Keys could be implemented in parallel with the existing SSL/TLS CA system. Because clients can do sovereign key verification by checking one signature on the certificate presented by a server, the CA system is not needed at all, but Eckersley recommends implementing it at first with sovereign key signatures added-on to existing CA-signed (or self-signed) server certificates.
Issues
The issues/ directory in the Git repository discusses technical and practical problems with the proposal, including concerns with such a CA/Sovereign Keys transitional system. The first is that an attacker who compromises a victim's DNS or web server can generate fraudulent sovereign key registrations complete with the DANE or CA-backed credentials the system is supposed to trust. The authors recommend that domain owners combat this potential attack by preemptively creating a sovereign key with no associated protocols, and outline a series of steps that root timeline server administrators could take to protect against rogue registrations.
There are several potential problems with timeline management discussed as well, including attackers compromising a timeline server (which is particularly troublesome since the timeline servers trust each other unless a renegation is spotted), false alarms caused by system time adjustments, and clock synchronization problems. A separate issue addresses the assumption that the set of authoritative timeline servers is small and well-known. This assumption has implications for renegation tracking and synchronization, but it also limits the decentralization of the Sovereign Keys framework, and in a real sense places critical (if not ultimate) trust in the timeline overseers.
Two attack vectors are considered: denial of service by flooding the timeline servers with registrations or the timeline servers and mirrors with queries, and a Sybil attack against a client by overloading its list of Sovereign Keys mirrors with compromised servers.
Of the vulnerabilities discussed, the false registrations created by breaking the existing CA or DANE DNSSEC system clearly has the largest attack surface. After all, the Internet could not be "switched over" to Sovereign Keys instantaneously even if every server and CA decided to do so. In the meantime, as EFF's other publications regularly show, there are enough attacks on (and security holes in) the CA system now that the Sovereign Keys proposal's reliance on CA as the trust authority for new sovereign key registrations sounds almost illogical. The proposal details ideas for bootstrapping mirror servers in a secure way, but creating verifiable sovereign keys for the 200 million domains is a much larger problem to solve.
It is clear that the current CA system is seriously flawed, and it is clear that browser certificate warnings are an ineffective tool to prevent users from falling victim to attackers. Some parts of the draft Sovereign Keys proposal are intriguing (such as the verifiable, public timeline record), but in other ways to most end users it may sound like replacing one remote authority with another. Falling back on Tor might be good from a technical perspective, but will be a challenge to implement. On either of the two goals of the project, then, its future will depend on how it is received by those outside of the EFF.
Brief items
Security quotes of the week
If you read a report from a vendor that [tries] to sell you something based on protecting android, rim or ios from viruses they are also likely as not to be scammers and charlatans.
I'm left with the conclusion that Adobe's aggregate corporate message is "users of desktops based on free software should immediately uninstall AIR and stop using it".
If Adobe's software was free, and they had a community around it, they could turn over support to the community if they found it too burdensome. Instead, once again, users of proprietary tools on free systems get screwed by the proprietary vendor.
BIND 9 denial of service being seen in the wild
The BIND 9 DNS name server is undergoing a concerted denial of service attack, according to this Internet Systems Consortium advisory. "Organizations across the Internet reported crashes interrupting service on BIND 9 nameservers performing recursive queries. Affected servers crashed after logging an error in query.c with the following message: "INSIST(! dns_rdataset_isassociated(sigrdataset))" Multiple versions were reported being affected, including all currently supported release versions of ISC BIND 9. [...] An as-yet unidentified network event caused BIND 9 resolvers to cache an invalid record, subsequent queries for which could crash the resolvers with an assertion failure. ISC is working on determining the ultimate cause by which a record with this particular inconsistency is cached. At this time we are making available a patch which makes named recover gracefully from the inconsistency, preventing the abnormal exit." We should be seeing distributions releasing updated versions soon.
Certificate fraud: Protection against future "DigiNotars" (The H)
The H looks at a proposal from Google to protect against rogue or compromised certificate authorities. "[Google product manager Ian] Fette said that after that affair, other companies asked Google for a way to protect themselves against bogus certificates. As there are numerous CAs, the possibility that similar illegitimate certificates could be issued remains, explained the developer. However, Fette said that embedding the certification policy for all potential parties into browsers doesn't scale, and that he and his colleagues, Chris Evans and Chris Palmer, therefore advocate the dynamic pinning of public keys." The article goes on to look at the proposal and some complaints about it, along with an alternative based on DNSSEC.
Tool kills hidden Linux bugs, vulnerabilities (SC Magazine)
SC Magazine looks at a tool to help look for holes in Linux. "It identifies similar source files based on file names and content to identify relationships between source packages. Fuzzy hashing using ssdeep produces hashes that can be used to determine similar packages. Graph Theory is used to perform the analysis."
New vulnerabilities
bind9: denial of service
| Package(s): | bind9 | CVE #(s): | CVE-2011-4313 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | November 17, 2011 | Updated: | November 30, 2011 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the ISC advisory: Organizations across the Internet reported crashes interrupting service on BIND 9 nameservers performing recursive queries. Affected servers crashed after logging an error in query.c with the following message: "INSIST(! dns_rdataset_isassociated(sigrdataset))" Multiple versions were reported being affected, including all currently supported release versions of ISC BIND 9. [...] An as-yet unidentified network event caused BIND 9 resolvers to cache an invalid record, subsequent queries for which could crash the resolvers with an assertion failure. ISC is working on determining the ultimate cause by which a record with this particular inconsistency is cached. At this time we are making available a patch which makes named recover gracefully from the inconsistency, preventing the abnormal exit. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
chromium: multiple vulnerabilities
| Package(s): | chromium | CVE #(s): | CVE-2011-3892 CVE-2011-3893 CVE-2011-3894 CVE-2011-3895 CVE-2011-3896 CVE-2011-3897 CVE-2011-3898 CVE-2011-3900 | ||||||||||||||||||||||||||||||||||||||||
| Created: | November 21, 2011 | Updated: | August 30, 2012 | ||||||||||||||||||||||||||||||||||||||||
| Description: | From the Gentoo advisory:
Multiple vulnerabilities have been discovered in Chromium and V8. A context-dependent attacker could entice a user to open a specially crafted web site or JavaScript program using Chromium or V8, possibly resulting in the execution of arbitrary code with the privileges of the process, or a Denial of Service condition. The attacker also could cause a Java applet to run without user confirmation. | ||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||
drupal6-views: SQL injection
| Package(s): | drupal6-views | CVE #(s): | |||||||||||||
| Created: | November 21, 2011 | Updated: | November 23, 2011 | ||||||||||||
| Description: | From the Drupal advisory:
The Views module enables you to list content in your site in various ways. The module doesn't sufficiently escape database parameters for certain filters/arguments on certain types of views with specific configurations of arguments. | ||||||||||||||
| Alerts: |
| ||||||||||||||
freetype: code execution
| Package(s): | freetype | CVE #(s): | CVE-2011-3439 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | November 17, 2011 | Updated: | April 19, 2012 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory: Multiple input validation flaws were found in the way FreeType processed CID-keyed fonts. If a specially-crafted font file was loaded by an application linked against FreeType, it could cause the application to crash or, potentially, execute arbitrary code with the privileges of the user running the application. (CVE-2011-3439) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
kdeutils: directory traversal
| Package(s): | kdeutils | CVE #(s): | CVE-2011-2725 | ||||||||
| Created: | November 22, 2011 | Updated: | March 7, 2012 | ||||||||
| Description: | From the Ubuntu advisory:
Tim Brown discovered that Ark did not properly perform input validation when previewing archive files. If a user were tricked into opening a crafted archive file, an attacker could remove files via directory traversal. | ||||||||||
| Alerts: |
| ||||||||||
kernel: multiple vulnerabilities
| Package(s): | kernel | CVE #(s): | CVE-2011-4131 CVE-2011-4132 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | November 21, 2011 | Updated: | July 10, 2012 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
nfs4_getfacl decoding causes a kernel Oops when a server returns more than 2 GETATTR bitmap words in response to the FATTR4_ACL attribute request. While the NFS client only asks for one attribute (FATTR4_ACL) in the first bitmap word, the NFSv4 protocol allows for the server to return unbounded bitmaps. From the Red Hat bugzilla: A flaw was found in the way Linux kernel's Journaling Block Device (JBD) handled invalid log first block value. An attacker able to mount malicious ext3 or ext4 image could use this flaw to crash the system. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
libcap: unauthorized directory access
| Package(s): | libcap | CVE #(s): | CVE-2011-4099 | ||||||||||||||||
| Created: | November 18, 2011 | Updated: | December 12, 2011 | ||||||||||||||||
| Description: | From the openSUSE advisory:
capsh did not chdir("/") after callling chroot(). Programs could therefore access the current directory outside of the chroot | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
moodle: multiple vulnerabilities
| Package(s): | moodle | CVE #(s): | |||||||||||||
| Created: | November 21, 2011 | Updated: | November 23, 2011 | ||||||||||||
| Description: | Moodle 2.1.2, 2.0.5, and 1.9.14 contain multiple security fixes. | ||||||||||||||
| Alerts: |
| ||||||||||||||
NetworkManager: man in the middle attack
| Package(s): | NetworkManager | CVE #(s): | CVE-2006-7246 | ||||||||||||
| Created: | November 22, 2011 | Updated: | January 19, 2012 | ||||||||||||
| Description: | From the SUSE advisory:
When 802.11X authentication is used (ie WPA Enterprise) NetworkManager did not pin a certificate's subject to an ESSID. A rogue access point could therefore be used to conduct MITM attacks by using any other valid certificate issued by the same CA as used in the original network (CVE-2006-7246). If password based authentication is used (e.g. via PEAP or EAP-TTLS) this means an attacker could sniff and potentially crack the password hashes of the victims. | ||||||||||||||
| Alerts: |
| ||||||||||||||
openldap: denial of service
| Package(s): | openldap | CVE #(s): | CVE-2011-4079 | ||||||||
| Created: | November 17, 2011 | Updated: | November 23, 2011 | ||||||||
| Description: | From the Ubuntu advisory: An OpenLDAP server could potentially be made to crash if it received specially crafted network traffic from an authenticated user. [...] It was discovered that slapd contained an off-by-one error. An authenticated attacker could potentially exploit this by sending a crafted crafted LDIF entry containing an empty postalAddress. | ||||||||||
| Alerts: |
| ||||||||||
phpMyAdmin: arbitrary file reading
| Package(s): | phpMyAdmin | CVE #(s): | CVE-2011-4107 | ||||||||||||||||||||||||
| Created: | November 23, 2011 | Updated: | January 2, 2012 | ||||||||||||||||||||||||
| Description: | From the CVE entry: The simplexml_load_string function in the XML import plug-in (libraries/import/xml.php) in phpMyAdmin 3.4.x before 3.4.7.1 and 3.3.x before 3.3.10.5 allows remote authenticated users to read arbitrary files via XML data containing external entity references, aka an XML external entity (XXE) injection attack. | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
software-center: man-in-the-middle attack/information disclosure
| Package(s): | software-center | CVE #(s): | CVE-2011-3150 | ||||
| Created: | November 21, 2011 | Updated: | November 23, 2011 | ||||
| Description: | From the Ubuntu advisory:
David B. discovered that Software Center incorrectly validated server certificates when performing secure connections. If a remote attacker were able to perform a man-in-the-middle attack, this flaw could be exploited to view sensitive information or install altered packages and repositories. | ||||||
| Alerts: |
| ||||||
spip: privilege escalation/cross-site scripting
| Package(s): | spip | CVE #(s): | |||||
| Created: | November 21, 2011 | Updated: | November 23, 2011 | ||||
| Description: | From the Debian advisory:
Two vulnerabilities have been found in SPIP, a website engine for publishing, which allow privilege escalation to site administrator privileges and cross-site scripting. | ||||||
| Alerts: |
| ||||||
squid: denial of service
| Package(s): | squid | CVE #(s): | CVE-2011-4096 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | November 18, 2011 | Updated: | January 6, 2012 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat bugzilla:
An invalid free flaw was found in the way Squid proxy caching server processed DNS requests, where one CNAME record pointed to another CNAME record pointing to an empty A-record. A remote attacker could issue a specially-crafted DNS request, leading to denial of service (squid daemon abort). | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
system-config-printer: man-in-the-middle package installation
| Package(s): | system-config-printer | CVE #(s): | CVE-2011-4405 | ||||||||||||
| Created: | November 17, 2011 | Updated: | November 23, 2011 | ||||||||||||
| Description: | From the Ubuntu advisory: Marc Deslauriers discovered that system-config-printer's cupshelpers scripts used by the Ubuntu automatic printer driver download service queried the OpenPrinting database using an insecure connection. If a remote attacker were able to perform a man-in-the-middle attack, this flaw could be exploited to install altered packages and repositories. | ||||||||||||||
| Alerts: |
| ||||||||||||||
tintin: multiple vulnerabilities
| Package(s): | tintin | CVE #(s): | CVE-2008-0671 CVE-2008-0672 CVE-2008-0673 | ||||
| Created: | November 21, 2011 | Updated: | November 23, 2011 | ||||
| Description: | From the Gentoo advisory:
Multiple vulnerabilities have been discovered in TinTin++. Remote unauthenticated attackers may be able to execute arbitrary code with the privileges of the TinTin++ process, cause a Denial of Service, or truncate arbitrary files in the top level of the home directory belonging to the user running the TinTin++ process. | ||||||
| Alerts: |
| ||||||
Page editor: Jake Edge
Next page:
Kernel development>>