LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityFallout from the fraudulent SSL certificatesIn last week's edition, we looked into a late-breaking disclosure of some fraudulent SSL certificates that had been issued. Due to problems with certificate revocation, it was necessary for Mozilla, Google, and other browser makers to release updates that blacklisted the certificates in question. Since that article was published, we have learned some more about the incident via postings from some of those involved. An update would seem indicated, along with some ideas of possible ways to deal with these kinds of problems in the future. An attack from Iran?Perhaps the most interesting update came from Comodo, which is the certificate authority (CA) that is responsible for the fraudulent certificates. Based on the information Comodo gathered from the attack, it would appear that the attacker was based in Iran. The set of domain names for which fraudulent certificates were issued (mail.google.com, www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org, and login.live.com) strongly point to a government-sponsored attack. A "regular" criminal attacker would seem more likely to go after certificates for banks and payment sites, but that is circumstantial evidence at best. Another interesting, if unconfirmed, update is the message from the "Comodo hacker". That message indicates that the Comodo partner (the InstantSSL.it registration authority) had some alarmingly lax security. It also claims that the attack was not sponsored by the "Iranian Cyber Army", and was, instead, just the work of single person. The message contains fairly convincing sounding details of the attack, but there has been speculation that it could have come from the Iranian government as it tries to cover its tracks. We may never know the truth of the matter, as there are interests on all sides with reasons to obfuscate. Authentic or not, the lack of security attributed to the registration authority unfortunately rings true. Mozilla also followed up its earlier message about the certificates with a recognition that the project should have been more forthcoming. Withholding information about the existence of the fraudulent certificates was really only helpful to the attacker. Knowledge of the certificates would have allowed users to make their own decisions about mitigating the threat posed by a man-in-the-middle (MITM) attack that used them. Mitigating the risksMITM attacks are, by their very nature, focused on a small subset of the internet—or a small subset of its users—as the risk of detection rises as a function of the number of users affected. That means that checking certificates from multiple locations in the internet will be quite successful in detecting a local MITM attack. That is exactly what the Perspectives project is working on. The project provides multiple "network notaries" that are located in different places, both physically and based on internet routing, which monitor the certificates presented by different sites. These notaries store the certificate fingerprint, along with a date and time, so that they have a history of the certificates presented by a given site. When a client wishes to connect to a domain using SSL, it can compare the certificate fingerprint it gets with those stored by several notaries. If they all match, the chances are extremely low that there is some kind of MITM attack going on. Rather than doing all of that checking manually, though, the project has a Firefox extension that will do that checking, and alert the user if it detects something has gone awry. In addition, the Perspectives extension can override the Firefox error page that comes up for self-signed certificates if it finds that multiple notaries have all recently seen the same certificate. Obviously, clients must make secure connections to the notaries, so that the attacker can't just spoof their response, so the notary list includes each notary's public key. In addition, notaries could keep track of the responses of other notaries so that malicious notaries could be detected. Each notary would act as a "shadow server" for several other notaries, and clients could check with the shadow server to ensure that the information it received is consistent with what the notary has reported in the past. The shadow server idea is described in the Perspective paper [PDF], but does not seem to be implemented yet. If and when notaries that are not under the control of the project are added, one would imagine that shadow server functionality would be added. Detecting changed certificatesA simpler mechanism for detecting possible MITM attacks is embodied in the Certificate Patrol Firefox add-on. Essentially, it locally keeps track of which certificate has been seen for a given domain, and alerts the user if that certificate changes. The idea behind it is "trust on first use" (aka TOFU), which means that the first time a valid certificate is seen, it should be trusted. Certificate Patrol (CP) does display the certificate information it receives on first use so that the user can potentially note any red flags. If ever the certificate changes down the road, though, the user will be alerted to that change. There are plenty of valid reasons why a site might change its certificate, however, so there could be various false positives from CP. When a certificate changes, CP will examine the new certificate and rate the likelihood that it indicates some kind of attack. For example, CP tries to detect certificates that were replaced because they were near to their expiration, and rates that change appropriately. It also tracks the CA used to sign the certificate, as a new certificate from the same CA as the old is less likely to have been issued fraudulently. One good outcome of the attackOne good thing that resulted from these fraudulent certificates is that folks are thinking and talking about better ways to handle problems like that in the future. Some would claim that the CA model is broken, but we have to have something to replace it before we can even consider dumping it, or reducing its role. Neither Perspectives nor Certificate Patrol are targeted at that particular problem, but may provide reasonable stopgap measures for now. Toward the end of Jacob Appelbaum's post outlining his detective work in discovering that there were fraudulent SSL certificates floating around "in the wild", he mentions a number of proposals and projects that might offer some alternatives to the current system. We looked at one of those, Monkeysphere, early last year. The others he mentions, DANE, CAA, and HASTLS seem worthy of a look at some point as well. There were already plenty of grumbles about the CA system before this particular incident, but the volume of those complaints is growing, so thinking about alternative solutions is certainly useful.
Brief items Security quotes of the week
The worst part about Comodo's letter to the public was how they claimed
that they never thought a nation state would attack them. If that's not
part of your threat model, what business do you have being part of Internet
infrastructure?
-- Dave
Aitel
Since VoIP calls may traverse untrusted networks, packets should be
encrypted to ensure confidentiality. However, we show that it is possible
to identify the phrases spoken within encrypted VoIP calls when the audio
is encoded using variable bit rate codecs. To do so, we train a hidden
Markov model using only knowledge of the phonetic pronunciations of words,
such as those provided by a dictionary, and search packet sequences for
instances of specified phrases. Our approach does not require examples of
the speaker's voice, or even example recordings of the words that make up
the target phrase.
-- Charles
V. Wright, et al. abstract for "Uncovering Spoken Phrases in Encrypted Voice over IP Conversations"
I hacked Comodo from InstantSSL.it, their CEO's e-mail address mfpenco@mfpenco.com
-- "A message from Comodo
hacker" — supposedly anyway
Their Comodo username/password was: user: gtadmin password: globaltrust Their DB name was: globaltrust and instantsslcms
McGee: The real story behind Arch Linux package signingOn his blog, Arch Linux developer (and Pacman lead) Dan McGee strongly disagrees with an LWN article on the lack of Arch Linux package signing (from this week's Security page). In the posting, he covers the history of the feature in great detail. "You can imagine at this point, a year down the road from the first patches, none of the primary pacman developers are very interested in implementing this themselves. Perhaps this is true, with the ironic twist that more than half of the patches on our long-lived gpg branch are from the three main contributors. I think the most truthful statement is that no one wanted to take the lead on this and finish it by themselves. At this point, the work is nearly where it stands today, as most of the additional work I merged in the last few days was simply bitrot cleanups (aside from pacman-key). However, nowhere have you seen any sense of 'even if you produce good work and get things finished we won't take it' attitudes from Allan [McRae] or I."
Mozilla's followup on the Comodo certificate issueMozilla has sent out a followup laying out what it knows about the Comodo certificate compromise and evaluating its own response. "Mozilla did not publish the information we received prior to shipping a patch. In early discussions, we were concerned that any indication that we knew about the attack would lead to attackers blocking our security updates as well. We also recognized that the obvious mitigation advice we might offer (to change Firefox's security preferences to require a valid OCSP response in all cases, or to remove trust from Comodo's certificates, or both) risked causing a significant portion of the legitimate web to break as well... In hindsight, while it was made in good faith, this was the wrong decision. We should have informed web users more quickly about the threat and the potential mitigations as well as their side-effects."
Microsoft kills Hotmail HTTPS access in several countriesThe EFF is reporting that Microsoft has disabled HTTPS access to its Hotmail service for users in Bahrain, Morocco, Algeria, Syria, Sudan, Iran, Lebanon, Jordan, Congo, Myanmar, Nigeria, Kazakhstan, Uzbekistan, Turkmenistan, Tajikistan, and Kyrgyzstan. "The good news is that the fix is very easy. Hotmail users in the affected countries can turn the always-use-HTTPS feature back on by changing the country in their profile to any of the countries in which this feature has not been disabled."[Update: Microsoft has acknowledged and fixed the problem, which was due to a bug and not done deliberately.]
New vulnerabilities apache2: privilege escalation
conga: privilege escalation
flash-player: arbitrary code execution
gdm: privilege escalation
gnash: symlink attack
imp4: cross-site scripting
libtiff: arbitrary code execution
mahara: cross-site scripting and cross-site request forgery
postfix: TLS plaintext injection
rsync: arbitrary code execution
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||