“Unfixable” Flash flaw puts you at risk
Published Mon, Nov 16 2009 11:22 AM
Technorati Tags: Computers and Internet, Annoyances
“Don’t trust e-mail attachments.” “Don’t click on links you find in unsolicited e-mail.” These are two warnings I’ve given in recent posts, and for good reason. There are people in the world with a malicious bent that are intent upon gaining access to your personal information, or even to your computer, and they use e-mail as a way to do it.
If you’re a web site programmer, I’ve warned you to close security loopholes in your code, and to be aware of malicious attacks such as SQL injection attacks. There are other types of attacks to be aware of such as cross-site scripting and denial of service attacks. But now, there’s a new one.
Well maybe it’s not really all that new – apparently the flaw that can be exploited has been around for a while. But this article warns of a flaw in Adobe’s Flash that can allow attackers to compromise “nearly every web site that allows users to upload content, including Google’s Gmail, then launch silent attacks on visitors to those sites.” The article emphasizes Flash objects, but…
Brad Arkin, Adobe's director for product security and privacy, agreed that the problem can't be solved with a patch to Flash. “We see this as a generic problem that affects any site that allows active scripting, not just Flash, but things like JavaScript and Silverlight as well. Even if Flash figured out some magical safeguard, this would be true for all active content sites that allow users to upload files.”
To emphasize, it’s not just Flash it’s active content. That includes such basic things as JavaScript, the little scripting engine that so many sites use to make things convenient for you. Does your site include a “blogroll” widget? What do you do if the blogroll provider (typically blogrolling.com) is vulnerable? What do your user’s do?
Although Foreground has not detected any in-the-wild attacks using the technique, Murray said that there's evidence hackers are moving toward such tactics. “We’re starting to see Flash used in these ways,” he said, and cited a recent worm that leveraged a similar vulnerability in Adobe's software, which is pervasive on the Web and on users' machines. “The worst-case scenario is that someone would figure this out, and launch silent attacks against the entire Internet.”
…
“Almost everyone using the Internet is vulnerable to a Web site that allows content to be updated inappropriately,” said Murray. "That's not hyperbole, it's just fact. This has the potential to affect any social media site, any career site, any dating site, many retail sites and many cloud applications. That's why this attack is so serious. End users would never know they got exploited.”
If you’re paranoid or even just extremely cautious as an end user visiting the web you can disable JavaScript, Flash, and Silverlight in your browser. If you disable Flash, your web experience will be faster. Many sites use banner ads to raise money. Many banner ads use Flash objects for animation and other eye-catching gimmicks. And many Flash ads are slow. Townhall.com comes to mind. They use Flash objects for advertising heavily. I have had times when I visited their site when my browser would almost lock up – or it would be downloading an ad and hang – leaving me unable to access the content on the rest of the site.
Unfortunately, many sites rely on these technologies to even function. A lot of social media sites seem to depend on JavaScript. Any site that uses AJAX technology for it’s primary function would be broken when you visited it if you disable JavaScript. YouTube won’t work without Flash – in fact the whole service is built around it (YouTube does happen to be safe from this particular vulnerability by the way, as mentioned in the article). If Flash and Silverlight weren’t so darned useful for other things I’d have them blocked in my browsers now.
Think about what that means. The script-kiddies and the black hats are going to see their window of opportunity open even wider when they think about ways to exploit this “unpatchable” flaw.
But if you’re a web site designer and programmer there is STILL something you can do to protect your visitors…
…Adobe has tried to get the word out to Web application designers and site administrators about the danger of allowing users to upload content. “Sites should not allow user uploads to a trusted domain,” Arkin argued. “The real issue here is that developers should be cautious about using techniques that can be misused maliciously. In general, this is a general challenge in managing active content.”
There’s a bit more to protecting your site than that. Even Adobe hasn’t got it right on some of their own properties. If you do allow user content to be uploaded, don’t allow it to be downloaded without some processing first. For example, if you allow image files to be uploaded – process them first. Re-size them, water-mark them, do something to ensure that the original file can’t be downloaded. Your processed file will likely be safer for your end users. Don’t allow users to upload active content. These are just a few of the things you need to do.
I don’t allow users to upload any content to my site. I do allow users to put HTML into the comments on my postings, but I block the use of script. The JavaScript I use on my site is small and simple – hooking up the menus at the top of the page for browsers that don’t handle CSS properly. If you use a more modern browser, the JavaScript I wrote for them is completely unnecessary.
But I do use third party scripting. For some things, you just can’t get around it. The “Blogs Against Nancy Pelosi” blogroll is provided by blogrolling.com. Last I checked, they don’t allow the uploading of user content, so that should be safe. The same is true of Sitemeter and Statcounter. The other web tracking software I use is provided by my ISP, and should be safe for the same reasons – content is uploaded to a different domain.
Be aware that this flaw exists – and that someone is going to exploit it.
Trackback URI for this post: http://perrinelson.com/track.aspx?postid=1394
Permalink URI for this post: http://perrinelson.com/2009/11/16/1394.aspx
Subscribe to this entry's
comment feed. (Atom)
David responded with:
 | *sigh*
Back to browsing in VMs and sandboxing apps... (But wait! I already do that a lot, anyway. *heh*) |
David responded with:
| OT: I just noticed that my browser is reported as Opera 9.80. Since I'm using Opera 10.01 (build 4682, Linux) for this session, I wonder where the reporting discrepancy comes in. Is Opera misreporting itself? Don't have access to your sniffer or Opera's internals (nor would I likely be able to puzzle 'em out if I did), so it's just an interesting lil discrepancy. |
Perri Nelson responded with: Browser sniffer...
 | All I do to identify your browser is look for the browser name and version number in the User-Agent HTTP header. In general very little else is needed. Some browsers don't consistently update this with changes to their version, and others do. Firefox, the browser I use, was initially still identifying itself as Mozilla in early builds of version 3. |
Comments to this entry are closed.