IT Jobs
Microsoft Internet Explorer SSL security hole lingers
Apple's Safari for Windows browser has same problem
By Tim Greene | Network World US
Published: 16:03 GMT, 18 September 09
Microsoft still does not acknowledge a weakness in its Internet Explorer browser that was pointed out seven weeks ago and enables attackers to hijack what are supposed to be secure Web sessions.
The company says it is still evaluating whether the weakness exists, but Apple, which bases its Safari for Windows browser on Microsoft code, says Safari for Windows has the weakness and the Microsoft code is the reason. If Microsoft doesn't fix the problem, Apple can't fix it on its own, Apple says. Apple has fixed the problem for Safari for Macs.
"Microsoft is currently investigating a possible vulnerability in Microsoft Windows. Once our investigation is complete, we will take appropriate action to help protect customers," a Microsoft spokesperson said via e-mail. "We will not have any more to share at this time."
Internet Explorer under attack warns Microsoft | Microsoft to rush out IE patch | Windows Vista, Windows Server 2008 attack code released
The weakness can be exploited by man-in-the-middle attackers who trick the browser into making SSL sessions with malicious servers rather than the legitimate servers users intend to connect to.
Current versions of Safari for Mac, Firefox and Opera address the problem, which is linked to how browsers read the x.509 certificates that are used to authenticate machines involved in setting up SSL/TLS sessions.
In July two separate talks presented by researchers Dan Kaminski and Moxie Marlinspike at the Black Hat Conference warned about how the vulnerability could be exploited by using what they call null-prefix attacks. The attacks involve getting certificate authorities to sign certificates for domain names assigned to legitimate domain-name holders and making vulnerable browsers interpret the certificates as being authorized for different domain-name holders.
For instance, someone might register www.hacker.com. In many x.509 implementations the certificate authority will sign certificates for any request from the hacker.com root domain, regardless of any sub-domain prefixes that might be appended. In that case, the authority would sign a certificate for bestbank.hacker.com, ignoring the sub-domain bestbank and signing based on the root domain hacker.com, Marlinspike says.
At the same time, browsers with the flaw he describes read x.509 certificates until they reach a null character, such as 0. If such a browser reads bestbank.com\0hacker.com, it would stop reading at the 0 and interpret the certificate as authenticating the root domain bestbank.com, the researcher says. Browsers without the flaw correctly identify the root domain and sign or don't sign based on it.
An attacker could exploit the weakness by setting up a man-in-the-middle attack and intercepting requests from vulnerable browsers to set up SSL connections. If the attacking server picks off a request to bestbank.com, it could respond with an authenticated x.509 certificate from bestbank.com\0hacker.com.
The vulnerable browser would interpret the certificate as being authorized for bestbank.com and set up a secure session with the attacking server. The user who has requested a session with bestbank would naturally assume the connection established was to bestbank.
Email
Print
Comment
Permalink
Contact Us
RSS
Digg
Add your commentComments