It's a shampoo world anyway

Why I do not like taint tracking

Maddin — Wed, 19 Sep 2007 13:31:06 GMT

While I was giving a talk yesterday on our dynamic and language based approaches concerning the avoidance of code injection vulnerabilities at Laboratory for Dependable Distributed System at the University of Mannheim, I came up with a nice description, why I dislike dynamic taint tracking:

Preventing code injection exploits using dynamic taint tracking is like letting a thief in your house and checking his bag for stolen goods at the very moment he tries to leave. It might work, but only if you never lose track of the gangster and if you really know your house. However, I would prefer a solution that does not let thieves in my house in the first place.

(Nonetheless, I think taint tracking obviously has a valid place in the defender's arsenal)

DNS rebinding at CCS'07

Maddin — Thu, 09 Aug 2007 10:47:14 GMT

This year's ACM conference on Computer and Communication Security (CCS) features two excellent papers on DNS Rebinding (the attack formerly known as "anti-DNS-pinning").

Besides discussing DNS rebinding for firewall circumvention, Protecting Browsers from DNS Rebinding Attacks by Jackson et al. also covers DNS-rebinding-based IP-hijacking, which can be used to commit click-fraud (an malicious application of the attack I have not thought of before). Furthermore, the authors propose a couple of defensive strategies, of which two have especially caught my attention:

To protect a given intranet, they propose a firewall solution. This special firewall specifically filters DNS traffic and denies DNS resolution of external hostnames to internal IP addresses. A nice idea that is easy to deploy within a company network.
Furthermore, they suggest to alter the web browser's pinning strategy from strict IP-pinning to class C-pinning. This means DNS rebinding within the same /24 range is permitted. Such a policy would allow using DNS-Rebinding for load-balancing and failure recovery while preventing the discussed attacks. This is a better policy as we enforce in LocalRodeo - it prevents the intranet-targeted attacks as well as we do but also counters IP-hijacking. For allowing dynamic-DNS restricting the IP changes to class C is probably to strict though.

Dynamic Pharming Attacks and the Locked Same-Origin Policies for Web Browser by Karlof et al. shows how pharming attacks can employ DNS-rebinding to subvert strong authentication mechanisms like client-side SSL (another malicious application I had not thought of before). To counter this threat the propose a "locked same-origin policy" that does not only take domain, port, and protocol into consideration but also requires that the private keys of the web page's respective SSL-certs match (an approach that obviously only works for web pages served via https).

I think this solution is a pointer in the right direction. Making the security properties of a web application depended on something that is not directly controlled by the application itself (DNS) was a bad idea in the first place. In the future we should work replacing this policy by something more appropriate and fine-grained.

Update: Giorgio Maone announced that the next major version of NoScript will include the stanford paper's "same subnet" anti-rebinding policy (both in IPV4 and IPV6).

Using eval() in Greasemonkey scripts considered harmful

Maddin — Tue, 26 Dec 2006 14:07:51 GMT

For some time now, there is a vague assumption in the web-security community that browser add-ons like e.g. Firefox extensions can cause security problems. On my flight back from PacSec, I decided to have a closer look on Greasemonkey scripts. I had already downloaded all available Greasemonkey-scripts from userscripts.org a while ago, but never got around to do anything with them. When I was skimming through the files, I noticed that eval() is used quite frequently. It didn't take long to find a userscript that passes non-sanitized user-provided data to a eval()-statement: Mailto Compose In GMail (with choice).

The userscript parses mailto hyperlinks and creates according compose-links to gmail.com. The parsing is done by a simple regexp:

nameValue = param.match(/([=]+)=(.*)/); ... emailTo = emailTo + "%2C%20" + nameValue[2];

These values are used in an eval() to create a new global variable:

eval("var " + emailUrlVarName + " = 'https://mail.google.com/mail?view=cm&tf=0" + (emailTo ... );

As there is no intermediate filtering step, injecting code into this eval is rather simple:

<a mailto="me@th)';your_js_code_here;//>name</a>

If a Firefox with the according userscript installed displays a webpage that contains such a mailto-link, the browser executes the injected JavaScript in the domain of the displayed webpage. Therefore the Greasemonkey-script creates a XSS-problem in all web applications that allow users to create arbitrary mailto-links (as e.g. the default installation of Wordpress does). Go here for a demo. Furthermore, these scripts are executed in the Greasemonkey domain, thus are allowed additional privileges like cross-domain XMLHttpRequests.

I don't consider this issue to be grave or critical. I don't expect the install-base of this particular userscript to be big enough to actually cause any exploitation. Nonetheless I think it is a good example how browser add-ons can create XSS-problems in web apps that are secure themselves.