禁止JVM執行外部指令Runtime.exec -- 由Apache Commons Collections漏洞引發的思考

update: 2015-11-16

新版apache commons collections 3.2.2修複漏洞

新版本的apache commons collections預設禁止了不安全的一些轉換類。可以通過更新來修複漏洞。參考release說明：

https://commons.apache.org/proper/commons-collections/release_3_2_2.html

Dubbo rpc遠端代碼執行的例子

update: 2015-11-13

重新思考了下這個漏洞，給出一個dubbo rpc遠端代碼執行的例子。

https://github.com/hengyunabc/dubbo-apache-commons-collections-bug

可以說很多公司開放的rpc，隻要協定裡支援java序列化方式，classpath裡有apache commons collections的jar包，都存在被遠端代碼執行的風險。

至于能不能通過http接口再調用dubbo rpc遠端代碼，貌似不太可行。因為資訊難以傳遞。

Apache Commons Collections遠端代碼執行漏洞

最近出來一個比較嚴重的漏洞，在使用了Apache Commons Collections的Java應用，可以遠端代碼執行。包括最新版的WebLogic、WebSphere、JBoss、Jenkins、OpenNMS這些大名鼎鼎的Java應用。

這個漏洞的嚴重的地方在于，即使你的代碼裡沒有使用到Apache Commons Collections裡的類，隻要Java應用的Classpath裡有Apache Commons Collections的jar包，都可以遠端代碼執行。

參考：

• https://github.com/frohoff/ysoserial
• http://blog.chaitin.com/2015-11-11_java_unserialize_rce/

這個漏洞的示範很簡單，隻要在maven依賴裡增加

<dependency>
            <groupId>commons-collections</groupId>
            <artifactId>commons-collections</artifactId>
            <version>3.2.1</version>
        </dependency>           

再執行下面的java代碼：

Transformer[] transformers = new Transformer[] { new ConstantTransformer(Runtime.class),
                new InvokerTransformer("getMethod", new Class[] { String.class, Class[].class },
                        new Object[] { "getRuntime", new Class[0] }),
                new InvokerTransformer("invoke", new Class[] { Object.class, Object[].class },
                        new Object[] { null, new Object[0] }),
                new InvokerTransformer("exec", new Class[] { String.class }, new Object[] { "calc" }) };

        Transformer transformedChain = new ChainedTransformer(transformers);

        Map innerMap = new HashMap();
        innerMap.put("value", "value");
        Map outerMap = TransformedMap.decorate(innerMap, null, transformedChain);

        Map.Entry onlyElement = (Entry) outerMap.entrySet().iterator().next();
        onlyElement.setValue("foobar");           

這個漏洞的根本問題并不是Java序列化的問題，而是Apache Commons Collections允許鍊式的任意的類函數反射調用。攻擊者通過允許Java序列化協定的端口，把攻擊代碼上傳到伺服器上，再由Apache Commons Collections裡的TransformedMap來執行。

這裡不對這個漏洞多做展開，可以看上面的參考文章。

如何簡單的防止Java程式調用外部指令？

從這個漏洞，引發了很久之前的一個念頭：如何簡單的防止Java程式調用外部指令？

java相對來說安全性問題比較少。出現的一些問題大部分是利用反射，最終用Runtime.exec(String cmd)函數來執行外部指令的。如果可以禁止JVM執行外部指令，未知漏洞的危害性會大大降低，可以大大提高JVM的安全性。

換而言之，就是如何禁止Java執行Runtime.exec(String cmd)之類的函數。

在Java裡有一套Security Policy，但是實際上用的人比較少。因為配置起來太麻煩了。

• http://docs.oracle.com/javase/8/docs/technotes/guides/security/PolicyFiles.html
• http://docs.oracle.com/javase/8/docs/technotes/guides/security/permissions.html
• http://docs.gigaspaces.com/xap102sec/java-security-policy-file.html 詳細的權限清單可以參考這個文檔

從文檔裡可以知道，Java裡并沒有直接禁止Rumtine.exec 函數執行的權限。

禁止檔案執行的權限在java.io.FilePermission裡。如果想禁止所有外部檔案執行，可以在下面的配置檔案中把

execute

删除：

grant {
  permission java.io.FilePermission "<<ALL FILES>>", "read, write, delete, execute";
};           

但是Java權限機制是白名單的，還有一大堆的權限要配置上去，非常複雜。

從tomcat的配置就知道了。

http://tomcat.apache.org/tomcat-7.0-doc/security-manager-howto.html

是以Tomcat預設是沒有啟用Security Policy的，可以通過在指令加上-security參數來啟用。

catalina.sh start -security           

那麼有沒有簡單的辦法可以在代碼裡禁止Java執行外部指令？

研究了下，通過擴充SecurityManager可以簡單實作：

SecurityManager originalSecurityManager = System.getSecurityManager();
        if (originalSecurityManager == null) {
            // 建立自己的SecurityManager
            SecurityManager sm = new SecurityManager() {
                private void check(Permission perm) {
                    // 禁止exec
                    if (perm instanceof java.io.FilePermission) {
                        String actions = perm.getActions();
                        if (actions != null && actions.contains("execute")) {
                            throw new SecurityException("execute denied!");
                        }
                    }
                    // 禁止設定新的SecurityManager，保護自己
                    if (perm instanceof java.lang.RuntimePermission) {
                        String name = perm.getName();
                        if (name != null && name.contains("setSecurityManager")) {
                            throw new SecurityException("System.setSecurityManager denied!");
                        }
                    }
                }

                @Override
                public void checkPermission(Permission perm) {
                    check(perm);
                }

                @Override
                public void checkPermission(Permission perm, Object context) {
                    check(perm);
                }
            };

            System.setSecurityManager(sm);
        }           

隻要在Java代碼裡簡單加上面那一段，就可以禁止執行外部程式了。

Java序列化的本身的蛋疼之處

其實Java自身的序列化機制就比較蛋疼，可以參考Effective Java裡的。

http://allenlsy.com/NOTES-of-Effective-Java-10/

并非禁止外部程式執行，Java程式就安全了

要注意的是，如果可以任意執行Java代碼，還可以做很多事情，比如寫入ssh密鑰，進而可以遠端登陸，參考最近的Redis未授權通路漏洞：

https://www.sebug.net/vuldb/ssvid-89715

總結

禁止JVM執行外部指令，是一個簡單有效的提高JVM安全性的辦法。但是以前沒有見到有相關的内容，有點奇怪。

可以考慮在代碼安全掃描時，加強對Runtime.exec相關代碼的檢測。

有些開源庫喜歡用Runtime.exec來執行指令擷取網卡mac等操作，個人表示相當的蛋疼，不會使用這樣子的代碼。