Server Security

Easy Server Side Fix for the GIFAR security issue

Written by Rachel Carr
Last updated on December 6, 2018 Views: 547 Comments: 0

The GIFAR issue was found by security researchers Billy Rios and Nate Mcfeters. To summarize the exploit, an attacker uploads a malicious image with embedded jar content on a target domain. This malicious image opens in any image viewer correctly and so it bypasses any content validation engine used by a web application. Then an attacker references this malicious image in the applet code on his or her evil site, establishing a cross-domain communication channel with the target domain. This attack is very serious because it breaks the Same Origin Policyprinciple. Also, this problem is not just confined to images, it is applicable to other file types such as doc, etc. Another great writeup on Jar File Issues is on pdp’s blog.

In Billy’s Blog, two solutions have been discussed :-

Solution 1. Update to the latest version of JRE. This will protect you. However, if I am a web application writer, I cannot ensure that my customers will be protected. The reason is I cannot control the JRE version that my customers will be running on their client machines. The JRE updates don’t work like Windows Updates. So their obsolete JRE environments will not get automatically updated, which leaves them vulnerable to cross-domain exploits. So, Billy discusses another solution for the application writer.

Solution 2. Serve user controlled files from a “throw away” domain. However, having a separate domain might not be feasible at all times, for reasons such as cost, management issues, etc.

My Solution. This made me think of some solution that could help an application developer to filter malicious jar content on the server side. If the application is able to restrict the upload of malicious files, it solves the problem on the server side without worrying about which version of JRE the client is running. I found the api JarFile in Java library java.util.jar to be extremely useful. It takes as input a file parameter, and returns a JarFile object if the input file has jar content. Otherwise, it raises a java.util.zip.ZipException exception.

I have constructed Proof of Concept code that tests a input file for malicious jar content.

01.import java.io.*;
02.import java.util.*;
03.import java.util.jar.*;
04.
05.public class DetectGIFAR {
06.public static void main (String args[])
07.throws IOException {
08.
09.if(args.length != 1)
10.{
11.System.out.println(“Usage: java DetectGIFAR image_file”);
12.System.exit(1);
13.}
14.
15.try
16.{
17.JarFile jarFile = new JarFile(args[0]);
18.System.out.println(“This is a malicious image with embedded jar content.nFollowing are the contents:-“);
19.Enumeration jarenum = jarFile.entries();
20.while (jarenum.hasMoreElements()) {
21.JarEntry jarent = (JarEntry) jarenum.nextElement();
22.System.out.println(jarent.getName() + “, ” + jarent.getSize() + ” bytes”);
23.}
24.}
25.catch(java.util.zip.ZipException e)
26.{
27.System.out.println(“This is a benign image file. No jar content detected.”);
28.System.exit(0);
29.}
30.catch (Exception e)
31.{
32.System.out.println(“Error occured. Unable to process GIFAR contents.”);
33.}
34.}
35.}

Below is sample output

 

gifartest sample output

And if you are new to the GIFAR exploit, below is example html applet code that loads a malicious gif hosted on my domain. You need to have the vulnerable JRE 1.6 update 10 or lower to see this applet running. You can play with this applet by typing anywhere inside it :) .

Let me know your thoughts and opinions on this server side fix. I am always open for discussions.

Article comments