JavaScript: A Tool, A Weapon
I am somewhat at a loss for words, having sung this same tune for almost 20 years.
Back when JavaScript was first introduced, many of us in the network security realm immediately realized how devastating it could be as an attack platform -- and here we are.
Malicious embedded JavaScript has become the flavor du Jour for web criminals.
Yet, criminals have latched on to it as a easy way to compromise users -- "low hanging fruit".
The corollary could be drawn to any number of technologies that provide functionality, but yet in the wrong hands, can wreak havoc, and be used for ill intentions.
Unfortunately, this is exactly what is happening today in the criminal underground with malicious JavaScript, and in a major, major way.
And again, unfortunately, there are more tools to develop malicious JavaScript than there are to detect them.
In my opinion, we are at a turning point -- how do we move forward?
It is my belief that a major effort needs to be undertaken to detect malicious JavaScript scripts, functional sandboxing methodologies, and ways to bring "NoScript" -style functionality to the masses.
I challenge Microsoft to step up the the plate here (and to include ActiveX).
This is going to be a major, major challenge for all of us in the coming year(s).
- ferg
posted by Fergie @ 1/03/2008 07:44:00 PM
5 Comments:
I used to recommend that people disable JavaScript due to the potential for abuse (and a few active exploits). However, I no longer recommend this. Today, too many sites require JavaScript for access. If you disable JavaScript, then you will lose access to much of the Web.
In the old days, the problems with JavaScript were based on escaping the sandbox. While that still is a risk today, most exploits are not around privilege escalation. Instead, the exploits are around malicious pop-ups, self-encoded web pages for obscuring malicious sites, strategically positioned windows to cover address bars (phishing), and arbitrary network access.
Fergie wrote: "It is my belief that a major effort needs to be undertaken to detect malicious JavaScript scripts, functional sandboxing methodologies, and ways to bring 'NoScript' -style functionality to the masses."
I would alter this: we need to increase the scope of the sandbox. Should JavaScript be allowed to access arbitrary sites, use arbitrary protocols (HTTP, FTP, and even 'gopher'), redirect browsers, place windows in specific locations, or self-decode web pages?
From a technical viewpoint, what is the difference between "malicious" behavior and benevolent-yet-complicated code? Detection malicious behavior is a double-edge sword; if it is done incorrectly, it could cripple useful functionality.
The issue here, as Dr. Neal well knows (and I appreciate his parry), is that JavaScript now (well, has always) has the ability to directly write to the users' system, whether disk or memory.
In fact, some of the more sophisticated acted exploits we are seeing actually patch running processes.
This is extremely dangerous behavior.
So, I ask again -- is this an acceptable parameter?
Initially I say "Yes", only because it is not intentionally evil.
Where are the roadblock for it not to be so?
That is the real question here.
- ferg
We believe that certain javascript should be filtered. We take the "you only hide (obfuscate) something if you have something to hide" approach.
If we see "unescape" we filter it. We also filter iframe. Yes this does break some sites, but we'd rather error on the side of safety than to just let all these possibly malicious sites run whatever code they want.
I personally would like to see the entire web development world come to some new agreement and avoid using these potentially malicious functions. However, its been my experience that very few web designers/developers will agree to not using certain functionality. I've always received a "hey, security is your problem. Don't tell me how to create web pages and I won't tell you how to protect networks".
My opinion is that the javascript execution environment (activeX would be in this camp too) needs to be extended to provide security controls. For example, the functionality that permits file system access could have ACLs associated with it. That is the easy part though. The hard part is defining reasonable default ACLs and a means for joe-home-user to adjust when/if needed. It isn't fail-safe, in fact far from it, but like almost everything in the anti-malware battlefront it provides a band-aid raising the bar for the next super-malware to be created.
Until the world decides to treat malware and the driving forces behind it as an epidemic, this battle front is just going to be a continual circle of measure and counter-measure escalation.
One of the bigger issues is the use of malware with "hidden" iframes.
Why not just have as NoScript support an option to not run "hidden" iframes?
It's an easy fix that makes it harder for the bad guys to hide malicious code. It also doesn't break most sites.
Post a Comment
<< Home