关于GIFAR

前两天GIFAR刚出来的时候和0day之王讨论了下，开始0day之王认为GIFAR是一个特殊的文件格式，还google了一下，说能找到些资料。还想找啥java函数看能否生成这么个格式的文件。

不过我认为PDP的风格比较土，比较猥琐，应该不会玩这种高级货，所以我认为他应该只是简单的把文件贴到一起了。后来翻到PDP去年在blackhat上的关于客户端安全的paper里，他果然是用 copy /B 来整的。

不过我和0day之王当时都很疑惑这玩意要怎么跑起来，难道是



就能当成jar运行吗？ 测试过后，发现显然是不行的。


其实我们还是浮躁了啊，没好好看news和paper，今天抽了点时间复习了下这几天的讨论，发现这个啥GIFAR原来是这么玩的，果然符合PDP一贯的猥琐风格。

1. 用 copy /B 或者类似手段把一个jar贴到一个gif后面，文件后缀还是叫 fvck.gif

2. 把这个新的gif文件上传到你要攻击的站点，比如baidu

3. 在第三方站点，注意，这里才是关键，第三方站点，你自己的，或你黑下来的。上面整一个applet标签，然后引用你刚才的图片。


现在应该看明白了，原来这是一个类似跨域的问题，那么为什么会有这个问题呢？原因在于applet这个标签，因为applet标签是不怎么计较文件格式的，所以任意文件格式他都当作jar来执行，也不判断文件头，只要内容里有jar就行。

在codebase里引用了url后:

The Java browser plugin sees a codebase URL of the target site and consequently adds a  allowing the applet to connect back to it and make full requests.

几乎就能干任意事情了，而最要命的是，applet在连接target的时候会自动调用浏览器保存的cookie，所以这个时候baidu的cookie就危险啦~~

It turns out that when an applet makes an HTTP request to a website the Java browser plugin will slap on the relevant cookies from the browser cookie store (even if the applet is unsigned).


这个漏洞现在很清楚了，就应该是这么利用的，不是像XSS一样直接攻击，而是类似跨域攻击。


至于修补方案可以从三方面考虑

首先SUN可以升级JRE，限制这种跨域连接

其次浏览器可以限制applet标签

最后，对于website来说，麻烦一点，需要扫描上传的文件内容。

实际上回到我昨天写的关于设计安全的文件上传的文章上来，其中

第三点：使用独立的域名作为上传文件的域名

就起到的很重要的作用，就算由于上传文件的问题导致被跨域，也只能拿到该文件服务器的域下的cookie，从而降低了风险。



不过也可以看出，这个漏洞猥琐归猥琐，还确实是非常严重的！