Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Comment: Re:Broken security model (Score 3, Insightful) 355

by Lobster Quadrille (#30084052) Attached to: Flash Vulnerability Found, Adobe Says No Fix Forthcoming

Maybe you should have read the whole article. Cross-site scripting is never mentioned, and seeing how Mike Bailey, the researcher in question, won $10,000 with a Cross-site scripting attack, I think he probably knows the difference

This is a flash attack, dealing with content ownership and poor security controls on flash's part. The end result can indeed be cross-site scripting, but that's not a requirement, and actionscript has different capabilities than javascript.

Comment: Re:Patents (Score 1) 355

by Lobster Quadrille (#30083974) Attached to: Flash Vulnerability Found, Adobe Says No Fix Forthcoming

It isn't to imply that the patent itself was ridiculous (Though it is. The patent makes it sound much neater than it is: a carboard sleeve for insulating your coffee cup from your hand).

I really just found that bit of verbiage humorous... the need to define the cup, and the wording used to do so. I recognize that it is necessary in this type of thing, but that doesn't make it less funny.

Comment: Re:Broken security model (Score 2, Interesting) 355

by Lobster Quadrille (#30083316) Attached to: Flash Vulnerability Found, Adobe Says No Fix Forthcoming

Off the top of my head, here are a few possible changes:

1. Deny connections by default, unless the server specifically says "this application can connect" (This is already how adobe determines policies on remote servers. It would not be so hard to make the object's origin follow the same rules)
2. Check whether the content-type headers of the server delivering the object actually match those of a flash object, preventing the content overloading attacks described in the paper.
3. Implement a signing policy, so that unsigned flash objects are not given permission to access the server.
4. Run embedded flash objects in the context of the page they are embedded in, rather than that of the origin server. (Flash objects accessed directly, like javascript run through the javascript: uri handler, have no permissions)

Maybe not ideal, but a hell of a lot better than having everybody vulnerable by default, and expecting the server administrators to fix it for them on a case by case basis.

Comment: Re:Client or server? (Score 1) 355

by Lobster Quadrille (#30082586) Attached to: Flash Vulnerability Found, Adobe Says No Fix Forthcoming

If I allow you to upload a flash object to my site, I should sanitise it before I allow my server to give it to anyone.

And if you allow me to upload a zip file to your site, will you strip out the swf file that's prepended to it? This is key: It's still a perfectly-formatted zip file.

You may start checking for prepended swf files now, but you sure as hell weren't yesterday.

How exactly is this FUD?

Comment: Re:Uploading a swf with a jpg extension? (Score 1) 355

by Lobster Quadrille (#30082450) Attached to: Flash Vulnerability Found, Adobe Says No Fix Forthcoming

Browsers do use MIME type to decide on the parser, except with embed tags, where they use the content-type attribute of the embed tag to decide which plugin to invoke.

The plugin, in turn, *should* check the MIME type to determine whether the file it's loading is valid. The Flash plugin does not.

Comment: Re:OH NO!!! (Score 2, Insightful) 355

by Lobster Quadrille (#30082384) Attached to: Flash Vulnerability Found, Adobe Says No Fix Forthcoming

On the other hand, the more arcane the attack, the less likely it is to get fixed, and so the more websites remain vulnerable. The end result is that an attacker well-versed in a variety of obscure attacks can find a way into just about everything.

This one, though, does affect an awful lot of sites- it's rare to find a site that doesn't allow users to upload some kind of file. The impression I get is that image uploads may be more or less simple to validate, but most other filetypes aren't.

Comment: Re:Broken security model (Score 4, Insightful) 355

by Lobster Quadrille (#30082186) Attached to: Flash Vulnerability Found, Adobe Says No Fix Forthcoming

If you can write an SWF that can be executed to compromise a website, despite the fact that it looks like, acts like, and in fact is a valid MS Word document, I'd call that a problem.

Your JAR example is actually a pretty good one... as TFA mentions, a similar attack with JAR files that looked like GIFs came out in 2008. Sun fixed their plugin.

Comment: Re:Why does a login form need CSRF protection? (Score 3, Insightful) 355

by Lobster Quadrille (#30082122) Attached to: Flash Vulnerability Found, Adobe Says No Fix Forthcoming

In this case, it was used to log the user into the attacker's account, which contained the malicious SWF uploaded as an attachment. If the user then logged into gmail (the video uses a registration email to prompt the user to do so), his account would be compromised.

In Gmail's case, there are other privacy consequences to the login CSRF. For example, if the user is logged into an account that I have access to, I can actually view his google search history.

Comment: Re:Uploading a swf with a jpg extension? (Score 3, Informative) 355

by Lobster Quadrille (#30082084) Attached to: Flash Vulnerability Found, Adobe Says No Fix Forthcoming

You'd think so, but you'd be wrong. Embedded content can specify the content-type in HTML (in order for the browser to know what plugin to use to load that content), and Flash trusts that declaration, not the content-type supplied by the server. A properly-designed plugin should trust the server, not the HTML that calls it.

Security

+ - Adobe Flash Vulnerability Found - Adobe Won't Fix ->

Submitted by Anonymous Coward
An anonymous reader writes "Security researchers at Foreground Security have found an issue with Adobe Flash. Any site that allows files to be uploaded could be vulnerable to this issue (whether they serve Flash or not!). Adobe has said that no easy fix exists and no patch is forthcoming. Adobe puts the responsibility on the website administrators themselves to fix this problem, but they themselves seem to be vulnerable to these problems (see this story: http://www.computerworld.com/s/article/9140768/Flash_flaw_puts_most_sites_users_at_risk_say_researchers )

Every user with Flash installed is vulnerable to this new type of attack and — until IT administrators fix their sites — will continue to be."

Link to Original Source

fortune: cpu time/usefulness ratio too high -- core dumped.

Working...