So I can have a file evil_applet.jpg that is a valid jpg and also a valid java applet? The website where the file is uploaded will serve the file with a mimetype of jpg.
If I try to force it as an applet on a 3rd party site:
The java plugin should refuse to load it since it doesn't have a java mimetype. I'm guessing from the article that the java plugin will load it anyway, which I believe is a bug in the java plugin.
I don't think the websites should have to try to filter beyond verifying that it's a valid image file. Besides the fact that re-encoding jpg images reduces their quality, it is conceivable that it won't even solve the problem.
In a perfect world, the java plugin would not have this bug, but in the real world it might not be a bad idea for websites to try to filter out this specific attack in order to pretect their users.
I have some guesses about how this works. JAR is basically ZIP, which puts the directory at the end of the file. I guess that GIF (or at least most GIF decoders) has a header at the beginning of the file and will ignore any garbage at the end of a file. Sites can filter this out without recompressing by canonicalizing images; i.e. removing any data that is not necessary for properly decoding the image.
(The OS X spell checker suggests "cannibalizing" instead of "canonicalizing". I guess you could do that, too.)
A PDF file does not become a plain text file just because some berk serves it with "text/plain" and it shouldn't open directly in the browser showing me a stream of gibberish.
A PDF file also does not suddenly become a security risk worthy of blocking at a firewall because some berk served it as "application/x-initech-file" (true story, name changed).
Use the file extension, that's what it's there for. If it's a .gif, don't load and run it as a Java program!
How do you suggest browsers should handle php, asp, aspx, ace, pl and py files then? How would the browser know if the server-generated content is a RSS feed, a image or a HTML page?
Are you seriously suggesting it's the browser which should support whatever scripting backend which is used on the server?
"The attack relies on a new type of hybrid file that looks like different things to different programs"
Come on, people have been doing this since time began. It's not new to create files that are valid in multiple scenarios.
OK, So how does it steal your account?
I can see that yes, if you can upload an image to a website, and then get it to run as a java applet, your java applet would have the same privileges as any other java applet on that site...
So if you've already given facebook permission to access local files via java applets, then the malicious applet could do bad things to your machine.
But how does it steal your account?
"and most other accounts" - This seems like complete sensationalism to me.
There is a whole java applet security model, and this article just seems to be about spreading FUD.
It's just a form of cross site scripting, with a fairly clever vector, and Java instead of Javascript running. Java applets have fairly strict rules about what they can access, mainly just back to the site it was hosted from.
So the attack would go: 1) your browser opens a malicious java applet, 2) the applet makes a request to change your password, add spammy facebook apps, spam everybody, change your contact email address and request a "forgotten" password, and finally: 3) you lose.
This isn't revolutionary, but it's clever and yet another thing to be aware of with user created content.
I agree. This implies that any java applet can steal your login info of any site and if that were true then java applets would have been banned 10 years ago.
There are a large number of sites that don't. I coded a photo gallery for a group of Photoshop users and it was required to not change the photo uploads unless they were out of the max size spec. They like the images to look exactly like they exported them out of Photoshop.
Mostly plugins and shoddy code. But yeah, I wouldn't necessarily call it an 'inherent' problem, just a difficult one. I've often wondered if it were feasible to run every browser tab in a separate (fork()ed) and chrooted OS process as an unprivileged user. Browsers generally already run plugins in separate processes because they have a habit of crashing or deadlocking. What about distrusting major parts of the browser itself that way?
Every modern browser maintains a single user session that accesses multiple sites simultaneously. This allows a lot of information with security and privacy implications to flow between sites:
* Cookies set in one browser window are delivered with requests made in another browser window
* On site A, click a link to site C, and the same link on site B will change color.
* Files cached for one browser window are available instantaneously in another window
* Site A can use timing to determine if the browser currently has an open HTTP connection to site B
* The browser has a per-browser limitation on the number of concurrent connections to a particular web server. A malicious website could use this to find out when you're browsing another website.
Browsers also provide detailed version info to web servers, including plugin versions, allowing malicious sites to deliver the right exploits.
ECMA Script implementations do not implement proper resource controls. For example, bad JavaScript on one page can cause other pages to have slow responses.
Third-party cookies allow wholesale tracking
Browsers don't complain when the user enters a password into a form that submits to an HTTP url.
Browsers keep many cookies literally forever.
Even if the user turns off cookies, the cache provides equivalent functionality for tracking.
ECMA Script and Flash can pop up modal dialogs that allow one webpage to prevent the user from using others.
Browsers don't provide any good UI tools for checking signatures of non-signed certificates. Many users are conditioned to just click 'Accept Permanently.'
Browsers will recall passwords for pages that are shown in i-frames.
Browsers should provide stronger anti-phishing mechanisms. For example, a way to designate a bookmark as the only allowed way to enter that domain.
There is nothing inherently insecure in browsers. But they do have lots of security problems, mostly they come from trying to support lots of different formats, plugins, programming languages and hence acquiring every security flaw of each and every one of them used (see the vulnerability in pnglib for example) and their sand-boxing is currently very very poor.
Any idea how the attacker is getting the browser to run an image, presumably in an <img> tag, as a java applet? Or maybe it only works if you view the image directly and the browser decides it's an applet by sniffing the contents?
I think the solution is for the java plugin to not execute cross-site content when the content-type is not correct for a JAR. If you want to legitimately serve java, don't do it as image/gif.
What kind of sites let you "upload banking card photos"? That sounds really bush league. Regardless, Sun needs to get on the ball and start respecting the mimetype.
If I try to force it as an applet on a 3rd party site:
<embed type="java" src="http://facebook.com/profiles/12345/evil_applet.jpg">
The java plugin should refuse to load it since it doesn't have a java mimetype. I'm guessing from the article that the java plugin will load it anyway, which I believe is a bug in the java plugin.
I don't think the websites should have to try to filter beyond verifying that it's a valid image file. Besides the fact that re-encoding jpg images reduces their quality, it is conceivable that it won't even solve the problem.
In a perfect world, the java plugin would not have this bug, but in the real world it might not be a bad idea for websites to try to filter out this specific attack in order to pretect their users.