LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityCertificates and "authorities"The more we hear about the DigiNotar certificate situation, the worse it seems to get. What started out looking something like the Comodo incident from last March—a serious breach in its own right—has now turned into damning evidence of almost unimaginably lax security at the DigiNotar certificate authority (CA). That led browser makers to do something unprecedented: not to just blacklist the known-bad certificates that had been issued, but to blacklist any DigiNotar-issued certificate. As it turns out, that was the right response (modulo a short-lived whitelisting of some Dutch government certificates) as the scope of the compromise has just continued to grow. The certificates in question are SSL/TLS certificates that are used to authenticate and deliver the keys used to encrypt HTTPS traffic. CAs issue certificates for secure web sites and sign them with their own private keys so that browsers can ensure that the certificates are valid. The public half of those CA keys are stored in a browser's "root store". When they decide to include a given CA's root key, browser makers are explicitly trusting certificates signed by those CAs. In the wrong hands, a certificate signed by a trusted root can be easily used to perform man-in-the-middle attacks against users who are accessing the secure site. Compromise and discoveryThe compromise of DigiNotar's certificate signing systems evidently occurred on or before July 19 and once the CA detected the problem, it issued revocations for the certificates that it was able to determine were wrongly issued. DigiNotar evidently did not notify browser makers or others of the compromise and essentially swept the whole thing under the rug. But the attackers, who may have compromised parts of DigiNotar's systems as far back as May 2009, were able to issue certificates that were not detected when the compromise was uncovered. One of those fake certificates, for *.google.com, was reported to the Gmail help forum by a user in Iran. The user was able to do so because of a Chrome/Chromium browser feature called public key pinning. Essentially, Chrome has a list of the hashes of public keys that are allowed to be used to sign certificates for Google's servers. If one of those public keys is not found in the certificate presented, it is a fatal error, which is what the user observed. It is fortunate for that user—and now the rest of the internet—that Chrome has that feature. Without it, browsers like Firefox, IE, Safari, and others happily accept the bogus certificate. The evidence seems to point to an effort emanating from Iran—likely sponsored or run by the Iranian government—to generate and then use these certificates for man-in-the-middle attacks against Iranians, particularly those who might be involved in protests or other dissent. The evident link to Iran is one that both the Comodo and DigiNotar attacks share. Dutch government sitesOnce the problem was reported, Google then alerted other browser makers who were generally quick to issue updates (though Safari seems to have lagged) that removed the DigiNotar root certificates from the root store, effectively blacklisting all DigiNotar-issued certificates. There is a wrinkle, however, because some Dutch government sites use certificates that are signed by DigiNotar (which is a Dutch company). A blanket ban of DigiNotar-signed certificates would have affected these sites, so, at the request of the Dutch government, an exemption to the ban was added for Firefox and Chrome. As a Mozilla blog update puts it:
These certificates are issued from a different DigiNotar-controlled
intermediate, and chain up to the Dutch government CA (Staat der
Nederlanden). The Dutch government's Computer Emergency Response Team
(GovCERT) indicated that these certificates are issued independently of
DigiNotar's other processes and that, in their assessment, these had not
been compromised. The Dutch government therefore requested that we exempt
these certificates from the removal of trust, which we agreed to do in our
initial security update early this week.
But it seems that the government was a bit hasty in that assessment, because it was fairly quickly revoked. Mozilla described it this way in the update: "The Dutch government has since audited DigiNotar's performance and rescinded this assessment. We are now removing the exemption for these certificates, meaning that all DigiNotar certificates will be untrusted by Mozilla products." In fact, since then, the Dutch government has taken over operational management of DigiNotar, and explicitly "denounces trust in certificates issued by DigiNotar". This is ugly stuff. The CA model relies on trust and part of that trust is that CAs will zealously guard access to their signing authority. In two recent cases—and it is certainly possible there are other compromises as yet unknown—we have seen that some CAs are not taking enough precautions. As it stands, every time another compromise is discovered, browser makers will have to race around to patch their browsers, then Linux distributions need to get updates out (for Firefox and others), and, finally, users actually need to apply the update. Unfortunately, it is not just a Google certificate that is out there in the wild. Early reports were that it was just a handful of bad certificates, but as time went on, the number of certificates issued by the attackers using the DigiNotar keys have risen: first to around 200 and now there are reports of as many as 500. Not only were its signing systems compromised, but it would seem that DigiNotar's logging and audit procedures were circumvented as well. A pastebin posting purporting to be from the attacker (of both DigiNotar and the Comodo affiliate back in March) sheds some light on the extent and motives for the attack. It also indicates that there are four other CAs that have been penetrated, including one that is named: GlobalSign. Since that posting, GlobalSign has, at least temporarily, stopped issuing certificates. Whether that's just based on prudence or whether GlobalSign found evidence of a compromise is unclear. If the pastebin posting is real, however, there are other CAs that are also at risk. Going forwardFor obvious reasons, this recent spate of attacks has raised the profile of the problems inherent in the centralized CA model that is in use today. The central authorities are supposed to reduce the attack surface against SSL/TLS keys, but that depends on the vigilance of those CAs. The number of different CAs trusted by a modern browser is rather eye-opening, and hoping that they will all keep their systems secure is pretty clearly forlorn. Small CAs, like DigiNotar, can be blacklisted when—if—compromises are discovered, but that's much harder to do for large CAs like Comodo or Verisign, for example. Luckily, detecting bad certificates is relatively easy—easier than figuring out if CAs have been compromised. Since web sites must present their certificate each time an encrypted connection is made, both detection and evidence gathering are fairly straightforward. Chrome's "pinning" feature does that in a limited way, though it still places trust in the CAs that do have signing authority for Google's keys; should any of those CAs be compromised, pinning would not catch them. The pinning feature is one that other browsers will likely consider adding. Google has made it clear that it will allow other sites to pin their certificates to specific CA keys, and presumably any other browsers that implement it will do the same. However, that may turn Google, Mozilla, and others into the de facto arbiters of certificate authenticity, which may not be a desirable outcome. It is also possible that Chrome and the other browsers could provide a way for sites to do their own pinning via HTTP Strict Transport Security (HSTS) or some other means. But, other alternatives to the centralized model are certainly being looked at. One that seems to have attracted some attention recently is Moxie Marlinspike's Convergence, which uses "trust notaries" in place of hard-coded lists of CA root keys. These notaries are in multiple locations and compare notes on the certificates that get presented to them, which is an effective way to recognize a certificate-based man-in-the-middle attack. Convergence is a Firefox add-on that is based on ideas from the Perspectives project, along with some of Marlinspike's ideas on trust agility. We will certainly see more problems with compromised CAs down the road, particularly because governments have shown an interest in acquiring "fake" certificates—and using them against their citizens. It's a problem that is not going away soon and one that needs to be addressed. Building webs of trust implicitly via Convergence/Perspectives or more explicitly using something like Monkeysphere is one possible solution, or piece of a solution. Removing or reducing the trust that we currently place in CAs is pretty much required to be part of any solution, but we've known that for quite some time now. The CAs may not like it, but their stranglehold over the issuance of trusted certificates is likely on its way out.
Brief items Security quotes of the week
If you want to be really evil, however, *.google.com is the wrong SSL
certificate to forge. The right one? ssl.google-analytics.com.
-- Colin
Percival
The Certificate Authority system as it stands today is a house of cards and
we're witnessing in public what many have known for years in private. The
entire system is soaked in petrol and waiting for a light.
-- Jacob
Appelbaum
Given that essentially the whole population of Chrome users would use the
default notary settings, those notaries will get a large amount of
traffic. Also, we have a very strong interest for the notaries to function,
otherwise Chrome stops working. Combined, that means that Google would end
up running the notaries. So the design boils down to Chrome phoning home
for certificate validation. That has both unacceptable privacy implications
and very high uptime requirements on the notary service.
-- Adam
Langley on Convergence for Chrome
New Free Tools Simplify Analysis Of Android Malware (Dark Reading)Dark Reading looks at two Google Summer of Code (GSoC) projects that target Android malware analysis: APKInspector and DroidBox. "DroidBox is a sandbox of sorts that lets a researcher or analyst safely run and observe a malicious app. 'It lets you look and see if the app is doing something [malicious] ... and how it's doing it,' [GSoC mentor Ryan] Smith says. 'Once you have a profile of it, and you want to dig into the how and where in the code it's doing something, then you use APKInspector to review the code.' [...] Both tools are aimed at researchers who perform malware reverse-engineering as well as security analysts, he says. And that's a first step toward better securing the Android platform, according to Smith."
New vulnerabilities bcfg2: arbitrary command execution with root privileges
coreutils: command injection
grid components: privilege escalation
kernel: multiple vulnerabilities
mongoose: arbitrary code execution
ncpfs: /etc/mtab truncation
opera: multiple vulnerabilities
otrs: arbitrary file access
perl-Data-FormValidator: taint mode protection bypass
pidgin: denial of service
rails: SQL injection, cross-site scripting, and HTTP response splitting
rsyslog: denial of service
rubygem-actionpack: filter skipping
rubygem-activesupport: cross-site scripting
squid3: buffer overflow
tomcat6: information leak
xen: denial of service
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||