Easy Server Side Fix for the GIFAR security issue
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.
Below is 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.