Researchers at NGS Software have come up with a method to embed malicious code into a picture. When viewed, the picture could send the attacker the credentials of the viewer. Social sites like Facebook and Myspace are particularly at risk, but the researchers say that any site which includes log ins and user uploaded pictures could be vulnerable. This even includes some bank sites.
The attack is simply a mashup of a GIF picture and a JAR (Java applet). The malicious JAR is compiled and then combined with information from a GIF. The GIF part fools the browser into opening it as a picture and trusting the content. The reality is, the Java VM recognizes the JAR part and automatically runs it.
The researchers claim that there are multiple ways to deal with this vulnerability. Sun could restrict their Virtual Machine or web applications could continually check and filter these hybrid files, but they say it really needs to be addressed as an issue of browser security. They think that it is not only pictures at risk, but nearly all browser content.
More details on how to create these GIFARs will be presented at this week’s Black Hat conference in Las Vegas.
i was hoping the Black hats wouldn’t be on this axis.
interesting. i know you can hide text in blank pixels, but this is new to me.
I had always wondered if this was possible, never thought it would be done with java and gifs, but I had always wondered if you could embed code into a picture file and it be run when read.. I hope Sun fixes this quickly.
Why the heck would this work? JARs aren’t inherently executable, and should only be opened in case of an object or embed tag. Why would an img tag be handled by the Java VM?
This has been done already. Metasploit did it years ago. Except I don’t think it required java to work. Glad to see we STILL are not safe from images. Alwel.
I guess Sun will be “tightening up the graphics” security
I wish Hackaday stopped trying to do information security. They are particularly unread.
For those of you who really want to know how GIFAR attacks and other file combinations work:
When parsing for. ZIP headers a fully compliant program will not care where there header starts. It can start anywhere in the program. You can place the ZIP header at the bottom of a GIF image for example and it will validate by any compliant GIF program and any compliant ZIP program.
.JARs are essentially .ZIPs. That’s right, look it up. They just call it something different so they can set the default program to their JVM. Essentially you can throw this GIF/JAR (GIFAR) into the JVM and because it is compliant it will wait until it sees the ZIP/JAR header and start reading for the program.
This isn’t the only time we’ve seen this. It’s been around for years. Some presenters at Blackhat are going show this in combination with some tricks to get the browser site security model broken. For example… the browser will typically only allow you to do AJAX requests to the domain you are given the javascript from. Java has to follow the same rules (Flash gets around this with crossdomain.xml rules)…
From Sun’s site “applets are not allowed to open network connections to any computer, except for the host that provided the .class files.” Well because you are capable of uploading a GIFAR to a site as they will validate as images (I don’t know any banking sites that do this…) you can include an embed pointing to that GIFAR in another page (hosted anywhere) and make people stumble onto it. It will be allowed to make any network connections it wants to that site in their name.
The attack gets even more dangerous because it isn’t just GIFs and JARs that can act this way.
To prevent this – well there are a variety of ways. Yeah, sun could look for GIF headers or something else… but then they would be non-compliant. It would be possible for a ZIP engine to build a true JAR that gets denied. Perhaps the JVM should only allow network connections when a class file is hosted by a site AND the embed is on the site? I feel that is the direction they will go. XSS is already entailed if you can get your own embed into their webpage.
However, this doesn’t solve the general class of vulnerabilities of file type combinations.
Hackaday, you sound like the media when you talk about information security. A lot of buzz and little comprehension of what you are talking about. However, I think you are the best platform for hardware hacks I have ever stumbled upon. Maybe get some (info-) hackers on your team to blog this stuff?
It is definitely a misrepresentation of the attack to state “When viewed, the picture could send the attacker the credentials of the viewer.” especially when you follow it with “They think that it is not only pictures at risk, but nearly all browser content.”
That makes it sound like listening to music online will allow people to steal your bank credentials. That’s nothing but buzz and hype. It hides the real issues in favor of a doomsday scenario.
I think this issue is easy to solve in the way I stated above. Okay, it does really solve the issue 100%, but someone with XSS can already access your credentials and its even more likely they’ll get them because if you are doing XSS chances are they are logged onto the site.
GIFAR is creative and shiek, but it is not executable code that gets run when you view an image.