Last Updated: 2008-03-02 20:24:22 UTC
by Raul Siles (Version: 2)
A new Thunderbird version, 184.108.40.206, has been released. This version fixes four (4) known vulnerabilities: 1 critical, 2 high and 1 moderate.
MFSA 2008-12 Heap buffer overflow in external MIME bodies
MFSA 2008-05 Directory traversal via chrome: URI
MFSA 2008-03 Privilege escalation, XSS, Remote Code Execution
MFSA 2008-01 Crashes with evidence of memory corruption (rv:220.127.116.11)
We were told by the security people at Mozilla a couple of weeks ago, when Firefox 18.104.22.168 was released, that this Thunderbird version contains security fixes that will never be fixed in a 1.5 version. So, if you're still running Thunderbird 1.X, it is time to update!
Thanks Jason for the heads up.
Updated 2008-03-02 - Mozilla recently updated their webpage concerning MFS2008-07. Thunderbird 22.214.171.124 was incorrectly noted as being vulnerable but lacks the <canvas> functionality necessary to read sensitive data from memory. As such only 4 known vulnerabilities were fixed in this version. For more information on the flaw and the updated vendor advisory, please see the following:
MFSA 2008-07 Possible information disclosure in BMP decoder
Last Updated: 2008-02-27 19:50:23 UTC
by Raul Siles (Version: 1)
PEAP (Protected EAP) is one of the most commonly used EAP methods for strong wireless 802.11 authentication in WPA/WPA2 Enterprise mode (using 802.1x/EAP), as native support is available in the Windows, Mac OS X and Linux supplicants (like xsupplicant). When PEAP is used, the user is authenticated through username and password using MSCHAPv2, and the infrastructure (specifically the RADIUS server) is authenticated through digital certificates using TLS/SSL.
Recently, multiple vulnerabilities on the digital certificate validation process associated to PEAP have been released, due to the supplicant or the deployment failing to properly validate the RADIUS server certificate:
- During the Shmoocon 2008 conference, Wright and Antoniewicz released the details about how the Windows XP, Mac OS X and other commercial supplicants are affected by the lack of certificates verification. All the details are available on their presentation.
- Vocera's VoIP handsets do not perform certificate validation because it's too much "processing overhead required", as is clearly stated in the documentation.
- Cisco's 7921 Wi-Fi VoIP model does not validate certificates. EAP-TLS is Cisco's suggested short term workaround, what implies a full PKI.
In the first case (best scenario), by using the default PEAP settings on Windows the certificate is validated, but the matching between the name (common name or CN) of the RADIUS server and the name on the certificate are not. As a consequence, an attacker can provide its own infrastructure (access-point plus malicious RADIUS server) and present a valid certificate (signed by a trusted CA), but belonging to the attacker's RADIUS server. The client will accept it as valid, and the attacker will get access to inner EAP authentication credentials (MSCHAPv2 challenge and response) and can perform dictionary attacks on the credentials.
Do not think just on wireless deployments! If you are using strong layer-2 authentication through 802.1x in your wired network (something I've always promoted), you may be using the same vulnerable supplicant. Since 2005 I've been teaching the renamed SANS "Wireless Security Penetration Testing" course, and during the last day we build up a complete WPA Enterprise setup in class, using a CA, RADIUS, 802.1X & PEAP, where I do not provide any DNS infrastructure on purpose to show this flaw.
For the first scenario, the workaround is to properly configure the supplicant using strict authentication settings. Be very careful on configuring the supplicants appropriately and validate the digital certificate for the server, the CA, plus the common name. For example, on Windows this means to check (see slide 37 of 42 on the presentation above):
- Validate server certificate
- Connect to these servers, and provide the hostnames for the servers
- Select the CA you used to issue the certificates for your network infrastructure
- Do not allow users to authorize new servers or CA's
For the VoIP network devices there is no easy and overall solution right now, so it is recommended to select long and complex passwords to avoid the dictionary attack to succeed.
My guess is that we're going to start seeing more and more issues like this one in other supplicants from various wireless and wired network devices, and for other EAP types that also use digital certificates, such as EAP-TTLS, and PEAP v1 and v2. Most EAP types are complex authentication protocols.