Web security vulnerabilities and Javascript

Various recent, unrelated security issues seem to have a common thread: Javascript. It is not the fault of the language, exactly, nor of any particular implementation. It is the fundamental nature of how the language is used that often causes it to be "front and center" when security problems are found on the web.

Imagine that your computer reaches out across the net, to an unverified site, over an unencrypted link and grabs code that it executes with little in the way of further inspection. When put that way, it sounds rather dangerous, but that is exactly what browsers do with Javascript code. There are limits to what Javascript is allowed to do—meant to thwart malicious uses—but it has to have some privileges on the local machine in order to be useful.

One of the recent outbreaks is the "random js" attack, which propagates through Javascript served by legitimate websites. It generates a random .js filename for each visitor—which is where the name comes from—inserting a reference to it in a page on the site. It also stores the IP address of the visitor so that it does not repeat the infection multiple times. The payload then tries to exploit a dozen or more Windows vulnerabilities to install malware of various sorts.

The payload is not a problem for Linux users, but the websites hosting the attack are running Apache, many on Linux. The big unresolved question is how the servers were infected. It could be as simple as getting root access via insecure or intercepted root passwords. Or there could be some, as yet unknown, exploit. That certainly bears watching.

Because of the privileges that Javascript has on a local host, it can be used to spread malware, by exploiting the trust that users—those that even concern themselves with such things—have in the website they are visiting. It can also play a role in redirecting traffic away from a trusted site, even though the site itself has not been compromised.

A post by Nat Torkington at O'Reilly illustrates a common problem that content providers need to worry about. O'Reilly's perl.com site carried advertising that required them to load Javascript from the advertiser's site. All was well until the domain expired. A porn site bought it and started providing the required Javascript file with new contents redirecting the users to their site.

A man-in-the-middle or DNS cache poisoning attack could be used for similar results on a smaller scale basis. One can certainly see how it might be used by phishers as well. It is a difficult problem, as website owners need to be able to call out to advertisers' Javascript, but users typically do not expect to run code from a site they did not directly access.

A theoretical attack on home routers has started to show up in the wild. It uses Javascript to exploit a vulnerability in home routers to change the DNS entries for a popular Mexican bank. After that, accesses to the bank would instead go to the malicious website which would collect usernames and passwords, allowing the attacker to access the accounts. Once again, users probably do not expect that surfing to a random site could suddenly expose them to bank account compromise.

There are some things that can be done. For users, if Javascript cannot be disabled entirely—something increasingly difficult in the "Web 2.0" world—it can at least be leashed using NoScript for Firefox.

For website owners, Google's Caja project, seeks to define a subset of Javascript which implements an object-capability language, which would make it easier to sandbox remote code. If this effort succeeds, one can imagine that users could restrict their browsers to only use the Caja subset some day as well.