Gifar

Graphics Interchange Format Java Archives (GIFAR) is a term for GIF files combined with the JAR file format. GIFARs could be uploaded to Web sites that allow image uploading, and then run as though they were part of the legitimate code of that site. Java was patched in JRE 6 Update 11, with a CVE published on December 4 2008.^[1]

In this attack, GIF Java archive files (GIFARs) were uploaded to Web sites on the understanding that they are GIFs, and the file was then interpreted as a JAR file when viewed and executed. This circumvented the same-origin policy that browsers impose; bypassing the content validation usually used. Attackers reference this malicious image in the applet code on the hosted site, establishing cross-domain communication with the (your) target domain.

This technique worked because GIF images store their header in the beginning of the file, and JAR files (as with any ZIP archive-based format) store their data at the tail.^[2] This attack is not unique to GIFs and JARs; there is a general class of vulnerabilities of file type combinations such as .doc, .jpg, etc.

A GIFAR allowed an attacker to access the victim's HTTP cookies.^[1] This allows session hijacking, where the victim's logged-in user accounts can be accessed.

GIFARs should not have been executed if the user is viewing the image; it had to be interpreted as a JAR not a GIF to run.

For the attack to work, the victim must be logged into the Web site that is hosting the image.

Any site that includes login sessions with user-uploaded pictures can be vulnerable.

Java archives (JARs)[]

This article needs additional citations for verification. Please help by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources:  –  ·  ·  · scholar · JSTOR (June 2008) (Learn how and when to remove this template message)

JAR files are collections of compiled Java code, intended to be executed as standalone programs. They are ZIP archives mostly containing Java class files.^[3] Developers can create or extract JAR files using the jar command that comes with a JDK.

The zip file format allows for a metadata comment to occur at the end of the file after the central directory.^[4] In zips, because the central directory specifies the offset of each file with respect to the start, it is possible for the first file entry to start at an offset other than zero.

This allows arbitrary data to occur in the file both before and after the zip archive data, and for the archive to still be read by the zip application. A side effect of this is that it is possible to author a file that is both a working zip archive and another format; provided that the other format tolerates arbitrary data at its beginning, middle, or end. Self-extracting archives (SFX) of the form supported by WinZip and DotNetZip, take advantage of this—they are .exe files that conform to the PKZIP AppNote.txt specification and can be read by compliant zip tools or libraries.

This property of the zip format (including JARs) can be exploited to hide harmful Java classes inside a seemingly normal file, such as a GIF image uploaded to the Web. The so-called "GIFAR" exploit was demonstrated as an effective attack against Web applications such as Facebook.^[5]

This made it possible to allow a "considered-safe" site to run Java. For example, a Webmaster could host this file on their site by saying that it is an applet—or an attacking party could upload a GIFAR to an image host; and the end-user's browser would run the applet because it is stated safe.

Although it would not have mitigated this attack, developers can digitally sign JAR files. In this case, the signature becomes part of the (embedded) manifest file. The JAR is not signed, but every file inside the archive is listed, along with each file's signed checksum. Multiple entities may sign the JAR file (which changes the JAR file itself with each signing). When a Java runtime loads signed JAR files, it validates the signature(s) and avoids classes that do not match. If end-users only run JARs signed by trusted parties, malicious code cannot be inserted and run.

SUN & JRE[]

In GIFARs, the Java VM recognizes the JAR part which is run as an applet in the victim's browser as though it were written by the Web site's developers.

Though Sun has patched the Java vulnerability (in advisory #244988 (as of versions JDK and JRE 6 Update 11 (December 2, 2008), JDK and JRE 5.0 Update 17, and SDK and JRE 1.4.2_19)., because some users run installed versions of Java pre-dating the JRE patch, this issue needs to be addressed as an issue of browser security. Sun's patch does not, however, stop applications from taking ownership of user-supplied content.

From Sun; “...applets are not allowed to open network connections to any computer, except for the host that provided the .class files.” One is capable of uploading a GIFAR to a site as they will validate as images. 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.

With the applet running, the attacker can access the victim's account.

GIFs[]

The Graphics Interchange Format (GIF) is based on a bitmap image format that was introduced by CompuServe in 1987. GIF has declined on the World Wide Web but continues to have wide support. GIF images are compressed using the Lempel-Ziv-Welch (LZW) lossless data compression technique to reduce file size without degrading visual quality.

GIF stores multiple images in one file. This technique is used extensively on the Web to produce simple animations.

GIF was one of the first two image formats commonly used on Web sites. CompuServe's GIF appeared in 1987 to provide a color image format to replace the run-length encoding (RLE) format, which was black and white XBM. GIF became popular because it could use data compression, which enabled large images to be downloaded in a short time.

JPEG came later, with the Mosaic browser.

Solutions[]

Some solutions to this issue may be: If you are the Web surfer, update to the latest version of JRE. Webmasters cannot ensure that their customers will be protected because they cannot control the JRE version that their users run.

If you host images, run a backend script that verifies the absence of jar files appended to vulnerable file types (Reference http://securethoughts.com/2009/01/easy-server-side-fix-for-the-gifar-security-issue | A solution that could help an developer filter malicious jar content server side). If the application is able to restrict the upload of malicious files, it solves the problem without worrying about which version of JRE the client is running.

This is ultimately a Web application issue. When a Web app chooses to take ownership of a user-controlled file, serving it from their domain, it weakens the integrity of the domain. The impact of these attacks could also be minimized if Web applications that took user-controlled files served those files from a “throw away” domain. As an application developer, you can also prevent these types of attacks by using a separate domain for user-influenced files.

References[]

External links[]

• LZW and GIF explained
• [1]
• [2]
• JAR File Overview