RedHat Linuxプラットフォームでは、「Java」プロセスがglibcライブラリに依存していることがわかります。
[root@hpproliant1 ~]# ldd /usr/bin/Java
linux-gate.so.1 => (0xffffe000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf7f77000)
libjli.so => /usr/Java/32bit/jre1.6.0_26/bin/../lib/i386/jli/libjli.so (0xf7f6e000)
libdl.so.2 => /lib/libdl.so.2 (0xf7f69000)
libc.so.6 => /lib/libc.so.6 (0xf7e11000)
/lib/ld-linux.so.2 (0xf7f97000)
Java APIは間接的に問題のあるglibc関数を呼び出しますか?その場合、jvmは脆弱な関数を脆弱な方法で使用していますか?
たぶん。
Glibcで脆弱な2つの関数は、gethostbynameとgethostbyname2です。 Javaはglibcにリンクされていますが、脆弱であるためには、これらの特定の関数にリンクする必要があります。
ELFバイナリをスキャンして、プログラムreadelfでリンクされたライブラリを調べることができます。
最近、procmailが脆弱であることが判明しました。このアプローチが既知の脆弱なプログラムで機能することを確認しましょう。
readelf --dyn-syms /usr/bin/procmail |grep gethostbyname
46: 0000000000000000 0 FUNC GLOBAL DEFAULT UND gethostbyname@GLIBC_2.2.5 (2
そしてそうです!
Jvm実行可能ファイルを使用できる場合、gethostbynameへの参照は見つかりません。
Javaに含まれているライブラリをスキャンすると、次のようになります。
readelf --dyn-sym libdt_socket.so |grep gethostbyname
19: 0000000000000000 0 FUNC GLOBAL DEFAULT UND gethostbyname@GLIBC_2.2.5 (4)
これが悪用可能かどうかは、さらに分析する必要があります。ただし、別の方法で証明されるまでは、glibcライブラリを更新する必要があります。