Digg this story   Add to del.icio.us   (page 3 of 3 ) previous 
Rebinding attacks unbound
Federico Biancuzzi, 2007-10-17

Story continued from Page 2

Would using one single pin cache improve the situation?

A common pin database shared by all the technologies in the browser could help defend against rebinding attacks, but there are several limitations to this approach. Replacing the operating system's DNS resolver with a pinning resolver would break the standard semantics of DNS for non-Web applications, and browser vendors appear unwilling to provide their plug-ins an interface to their DNS pins. Worse yet, not all browser technologies are located on the same device. For example, it is difficult to share a common pin database with a proxy server.

What happens if we are using a HTTP proxy to browse the Internet?

Browsers behind HTTP proxies are more vulnerable to these attacks because the proxy is yet another technology that resolves host names. If the attacker embeds a Java applet in his or her Web page, the JVM is unable to pin correctly because it requests the applet by name from the proxy server (which does the DNS resolving). If the applet later attempts to open a socket to attacker.com, the JVM permits this socket connection to go to any IP address.

Do browsers behave differently if we are using a HTTPS connection?

HTTPS offers no protection against rebinding attacks. Because the attacker owns the domain name involved in the attack, he or she can legitimately obtain an SSL certificate and serve the malicious content over HTTPS. Additionally, HTTPS provides no protection to target servers because the attacker has direct socket access and can correctly negotiate an SSL tunnel.

Would DNSSEC help?

DNSSEC provides no protection against DNS rebinding attacks. DNSSEC is concerned with ensuring that all DNS records are valid and authoritative. This is intended to prevent pharming -- an attack which involves compromising a legitimate host name, such as bank.com, but does not prevent rebinding because the attacker is able to sign whatever DNS records he or she wishes for attacker.com.

Is there any workaround that we might deploy quickly?

One workaround is to install the NoScript plug-in for Firefox. Unfortunately, this disables many Web features that users enjoy. End users, unfortunately, have to wait for browser and plug-in vendors to fix this vulnerability.

Did you discuss the topic with vendors? And if so, what did they say?

We're working with vendors to help them fix their rebinding vulnerabilities, but we're unable to disclose details about those discussions until the vendors issue patches. However, some of our work with vendors is public; for example, we attended a Firefox security round table about DNS rebinding.

In the long term, what solutions could we use and which ones do you think will actually be chosen?

I'm hopeful the vendors will reach a consensus to fix these issues using host name authorization, but this requires the vendors to cooperate with each other. One way to bootstrap this cooperation is to leverage existing deployments of this policy in the form of crossdomain.xml files. Flash uses these files to authorize HTTP connections to different origins, but they contain enough information to help prevent rebinding attacks. There is no easy patch for DNS rebinding because it is a vulnerability in the Web's design, but hopefully we will be able to fix the vulnerability without breaking existing applications or disrupting users.



Federico Biancuzzi is freelancer; in addition to SecurityFocus he also writes for ONLamp, LinuxDevCenter, and NewsForge.
    Digg this story   Add to del.icio.us   (page 3 of 3 ) previous 
Comments Mode:


 

Privacy Statement
Copyright 2010, SecurityFocus