It's a shampoo world anyway

Why I do not like taint tracking

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)

... Link

DNS rebinding at CCS'07

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).

... Link

Using eval() in Greasemonkey scripts considered harmful

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 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 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 + "
    = '"
    + (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.

... Link

online for 6728 Days
last updated: 09.04.14 16:14
Youre not logged in ... Login
... home
... topics

... antville home

April 2020
the shampoo world is
the personal weblog of Martin Johns.

xml version of this page

Made with Antville
powered by
Helma Object Publisher

...welcome to the long tail...