Security
Fallout from the fraudulent SSL certificates
In 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 risks
MITM 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 certificates
A 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 attack
One 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
Their Comodo username/password was: user: gtadmin password: globaltrust
Their DB name was: globaltrust and instantsslcms
McGee: The real story behind Arch Linux package signing
On 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 issue
Mozilla 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 countries
The 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
| Package(s): | apache2 | CVE #(s): | CVE-2011-1176 | ||||||||||||
| Created: | March 24, 2011 | Updated: | March 31, 2011 | ||||||||||||
| Description: | From the Debian advisory: A configuration parsing flaw has been found in MPM_ITK. If the configuration directive NiceValue was set, but no AssignUserID directive was specified, the requests would be processed as user and group root instead of the default Apache user and group. | ||||||||||||||
| Alerts: |
| ||||||||||||||
conga: privilege escalation
| Package(s): | conga | CVE #(s): | CVE-2011-0720 | ||||||||||||
| Created: | March 29, 2011 | Updated: | April 20, 2011 | ||||||||||||
| Description: | From the Red Hat advisory:
A privilege escalation flaw was found in luci, the Conga web-based administration application. A remote attacker could possibly use this flaw to obtain administrative access, allowing them to read, create, or modify the content of the luci application. | ||||||||||||||
| Alerts: |
| ||||||||||||||
flash-player: arbitrary code execution
| Package(s): | flash-player | CVE #(s): | CVE-2011-0609 | ||||||||||||
| Created: | March 29, 2011 | Updated: | April 1, 2011 | ||||||||||||
| Description: | From the CVE entry:
Unspecified vulnerability in Adobe Flash Player 10.2.154.13 and earlier on Windows, Mac OS X, Linux, and Solaris and 10.1.106.16 and earlier on Android, and Authplay.dll (aka AuthPlayLib.bundle) in Adobe Reader and Acrobat 9.x through 9.4.2 and 10.x through 10.0.1 on Windows and Mac OS X, allows remote attackers to execute arbitrary code or cause a denial of service (application crash) via crafted Flash content, as demonstrated by a .swf file embedded in an Excel spreadsheet, and as exploited in the wild in March 2011. | ||||||||||||||
| Alerts: |
| ||||||||||||||
gdm: privilege escalation
| Package(s): | gdm | CVE #(s): | CVE-2011-0727 | ||||||||||||||||||||||||||||||||
| Created: | March 29, 2011 | Updated: | April 8, 2011 | ||||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory:
A race condition flaw was found in the way GDM handled the cache directories used to store users' dmrc and face icon files. A local attacker could use this flaw to trick GDM into changing the ownership of an arbitrary file via a symbolic link attack, allowing them to escalate their privileges. | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
gnash: symlink attack
| Package(s): | gnash | CVE #(s): | CVE-2010-4337 | ||||||||||||
| Created: | March 28, 2011 | Updated: | March 31, 2011 | ||||||||||||
| Description: | From the CVE entry:
The configure script in gnash 0.8.8 allows local users to overwrite arbitrary files via a symlink attack on the (1) /tmp/gnash-configure-errors.$$, (2) /tmp/gnash-configure-warnings.$$, or (3) /tmp/gnash-configure-recommended.$$ files. | ||||||||||||||
| Alerts: |
| ||||||||||||||
imp4: cross-site scripting
| Package(s): | imp4 | CVE #(s): | CVE-2010-3695 | ||||||||
| Created: | March 28, 2011 | Updated: | March 30, 2011 | ||||||||
| Description: | From the Debian advisory:
Moritz Naumann discovered that imp4, a webmail component for the horde framework, is prone to cross-site scripting attacks by a lack of input sanitizing of certain fetchmail information. | ||||||||||
| Alerts: |
| ||||||||||
libtiff: arbitrary code execution
| Package(s): | libtiff | CVE #(s): | CVE-2011-1167 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | March 29, 2011 | Updated: | June 27, 2011 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory:
A heap-based buffer overflow flaw was found in the way libtiff processed certain TIFF files encoded with a 4-bit run-length encoding scheme from ThunderScan. An attacker could use this flaw to create a specially-crafted TIFF file that, when opened, would cause an application linked against libtiff to crash or, possibly, execute arbitrary code. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
mahara: cross-site scripting and cross-site request forgery
| Package(s): | mahara | CVE #(s): | CVE-2011-0439 CVE-2011-0440 | ||||
| Created: | March 30, 2011 | Updated: | March 30, 2011 | ||||
| Description: | The "mahara" social networking system suffers from cross-site scripting and cross-site request forgery vulnerabilities which, among other things, can allow an attacker to force the deletion of weblogs. | ||||||
| Alerts: |
| ||||||
postfix: TLS plaintext injection
| Package(s): | postfix | CVE #(s): | CVE-2011-0411 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | March 24, 2011 | Updated: | October 2, 2012 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Postfix advisory: The flaw allows an attacker to inject client commands into an SMTP session during the unprotected plaintext SMTP protocol phase (more on that below), such that the server will execute those commands during the SMTP-over-TLS protocol phase when all communication is supposed to be protected. See this LWN article for more information. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
rsync: arbitrary code execution
| Package(s): | rsync | CVE #(s): | CVE-2011-1097 | ||||||||||||||||||||||||||||||||
| Created: | March 29, 2011 | Updated: | May 17, 2011 | ||||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory:
A memory corruption flaw was found in the way the rsync client processed malformed file list data. If an rsync client used the "--recursive" and "--delete" options without the "--owner" option when connecting to a malicious rsync server, the malicious server could cause rsync on the client system to crash or, possibly, execute arbitrary code with the privileges of the user running rsync. | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>