Security
Extended validation certificates
A new 'security' feature being touted by Microsoft and Verisign has raised a number of red flags for the open source community, but it appears that the new "Extended Validation" (EV) SSL certificates are not some kind of attempt to squeeze out the competition. Neither of those two companies are known for their ability to play well with competitors, so any collaboration between the two requires some close scrutiny to try and ensure a level playing field. In this case, the field seems level, but the security provided by the new feature is somewhat dubious.
SSL certificates are used by the HTTPS protocol for encrypted traffic between a web browser and the web server; they are issued by various certificate authorities (CAs) such as Verisign. An SSL certificate is generated for the domain at which it resides and then signed by a CA after it does some verification of the entity requesting the signature. Because CAs have traditionally done very little in the way of validation, a signed SSL certificate does not tell you very much about the identity of the domain; it essentially just verifies that the domain owner was willing to spend $50-100 to get the signature.
When presented with a certificate, a web browser attempts to verify any signature using a set of public keys for the CAs that the browser developers have decided to trust. Verisign has generated a new set of keys to sign the EV certificates and Microsoft has already incorporated that public key into IE7. In addition, when presented with a properly signed EV certificate, IE will turn the address bar green to indicate some purported higher level of security. For browsers that do not support EV, Verisign will presumably still sign EV certificates with their current key and those browsers will still display the padlock icon.
So, what does it take for a site to get this EV certificate? One would guess that more money would be involved and that is certainly the case. One would hope that more investigation of the entity requesting the signature would be part of it as well and that seems to be the case, but the actual requirements are, as yet, unspecified. The Verisign FAQ indicates that the requirements are soon to be released by the CA/Browser Forum. This organization (which appears to have no website) is a group of CAs and browser developers that is said to include both Microsoft and Mozilla (as well as Opera and KDE) and has been working on EV certificates for 18 months or so.
The two big concerns about all of this are that either Verisign will monopolize the EV certificate generation or that Microsoft will monopolize the verification of them. Neither appears to be the case as Verisign clearly states that other CAs will be able to generate EV certificates and other browsers will be able to validate them and, presumably, turn their address bars green too. Mozilla has EV on its radar and it is listed as a feature to be added, but Verisign and Microsoft are the first to market.
An article in The Register was the first to alert most people to the new feature; it quoted Tim Callan, a marketing director at Verisign, bemoaning the slow pace of adoption by Mozilla. Callan has since clarified his statements and says that he did not indicate any displeasure with the pace of adoption by the Mozilla Foundation. Commercial browser developers can move more quickly on adopting new CA keys because there is a financial motive, whereas open source browsers need to ensure that they have consistent policies about adopting new CAs and keys.
It is interesting to note that the perceived inadequacies of current SSL certificates are a problem that the CAs created for themselves. Because they were willing to sign any certificate with extremely minimal verification of anything other than the credit card charge to pay for it, they made SSL certificates and the padlock icon relatively meaningless for anything other than an indication that the traffic is encrypted. Unless the verification of the entity is extremely thorough (which would be very costly), it is unclear that EV certificates will really do anything to change that. Even then, few people actually look at the name attached to an SSL certificate, and many might be surprised at the names that show up if they did.
The end result is that anyone wanting to abuse HTTPS will figure out a way to get a signed EV certificate and, one day, the green address bar will be no more trusted for identity verification than the padlock icon is today. Identity verification is a hard problem and EV certificates are just a quick fix, the problem will need to be addressed again; perhaps we will see 'Super Extended Validation' certificates somewhere down the road.
New vulnerabilities
ImageMagick: buffer overflows
| Package(s): | ImageMagick | CVE #(s): | CVE-2006-5456 | ||||||||||||||||||||||||||||||||||||||||||||
| Created: | October 31, 2006 | Updated: | March 8, 2007 | ||||||||||||||||||||||||||||||||||||||||||||
| Description: | Multiple buffer overflows in GraphicsMagick before 1.1.7 and ImageMagick 6.0.7 allow user-assisted attackers to cause a denial of service and possibly execute execute arbitrary code via (1) a DCM image that is not properly handled by the ReadDCMImage function in coders/dcm.c, or (2) a PALM image that is not properly handled by the ReadPALMImage function in coders/palm.c. | ||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||
mutt: race conditions
| Package(s): | mutt | CVE #(s): | CVE-2006-5297 CVE-2006-5298 | ||||||||
| Created: | October 30, 2006 | Updated: | November 1, 2006 | ||||||||
| Description: | A race condition in the safe_open function in the Mutt mail client 1.5.12
and earlier, when creating temporary files in an NFS filesystem, allows
local users to overwrite arbitrary files due to limitations of the use of
the O_EXCL flag on NFS filesystems. (CVE-2006-5297)
The mutt_adv_mktemp function in the Mutt mail client 1.5.12 and earlier does not properly verify that temporary files have been created with restricted permissions, which might allow local users to create files with weak permissions via a race condition between the mktemp and safe_fopen function calls. (CVE-2006-5298) | ||||||||||
| Alerts: |
| ||||||||||
ruby: denial of service
| Package(s): | ruby | CVE #(s): | CVE-2006-5467 | ||||||||||||||||||||||||||||||||||||||||
| Created: | October 30, 2006 | Updated: | December 13, 2006 | ||||||||||||||||||||||||||||||||||||||||
| Description: | The CGI library in Ruby 1.8 allowed a remote attacker to cause a denial of service via an HTTP request with a multipart MIME body that contained an invalid boundary specifier, which would result in an infinite loop and CPU consumption. | ||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||
screen: denial of service
| Package(s): | screen | CVE #(s): | CVE-2006-4573 | ||||||||||||||||||||||||||||
| Created: | October 26, 2006 | Updated: | November 6, 2006 | ||||||||||||||||||||||||||||
| Description: | The screen virtual terminal application has a denial of service vulnerability related to the handling of UTF-8 combining characters. If an attacker can trick a user into displaying maliciously created output, a denial of service can result. The attacker may also be able to exploit the vulnerability in order to run arbitrary software with the privileges of the user. | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
WordPress: multiple vulnerabilities
| Package(s): | wordpress | CVE #(s): | CVE-2006-5705 | ||||||||
| Created: | October 30, 2006 | Updated: | November 17, 2006 | ||||||||
| Description: | This vendor announcement identifies several vulnerabilities in WordPress versions prior to 2.0.5. | ||||||||||
| Alerts: |
| ||||||||||
xsupplicant: stack overflow
| Package(s): | xsupplicant | CVE #(s): | |||||
| Created: | October 30, 2006 | Updated: | November 1, 2006 | ||||
| Description: | Yannick Van Osselaer discovered a stack overflow in Xsupplicant, which could potentially be exploited by a remote, authenticated user to gain root privileges. | ||||||
| Alerts: |
| ||||||
Page editor: Jonathan Corbet
Next page:
Kernel development>>