Linuxカーネル4.6以上でsys_execveをフックする

Question

カーネルが4.6より小さい場合は、fork、clone、execなどの重要なシステムコールのフックを強くするためにアセンブリスタブを使用します。特に、execveの場合、Kernel-4.5のスニペットは、execve：

ENTRY(stub_execve) 
    call sys_execve 
return_from_execve: 
... 
END(stub_execve) 

システムcall tableは、このスタブのアドレスが含まれており、さらにこのスタブは、元はexecveを呼び出します。ですから、この環境でexecveにフックするには、フックルーチンでスタブにcall sys_execveを貼り付け、必要な作業を行った後に元のexecveを呼び出します。これはすべて、Linux用のプロセス実行監視ユーティリティであるexecmonで確認できます。私はexecmonがUbuntu 16.04でカーネル4.4で正常に動作することをテストしました。

カーネル4.6以降、クリティカルコール保護の上位スキームが変更されました。

\funcはexecveの呼び出しのため sys_execveに拡大していきます

ENTRY(ptregs_\func) 
    leaq \func(%rip), %rax 
    jmp  stub_ptregs_64 
END(ptregs_\func) 

：今スタブは次のようになります。ここでも、システムcall tableにはこのスタブが含まれています。このスタブは元のexecveを呼び出しますが、現在はcall sys_execveを実行する代わりに、より安全な方法で呼び出されます。 この新しいスタブ、RAXレジスタ内の関数のアドレスと呼ばれる店舗と、以下に示す別のスタブ（コメントは削除）にジャンプ：

ENTRY(stub_ptregs_64) 
    cmpq $.Lentry_SYSCALL_64_after_fastpath_call, (%rsp) 
    jne 1f 

    DISABLE_INTERRUPTS(CLBR_NONE) 
    TRACE_IRQS_OFF 
    popq %rax 
    jmp entry_SYSCALL64_slow_path 

1: 
    jmp *%rax  /* called from C */ 
END(stub_ptregs_64) 

このスタブにコメントや他の参照先のラベルを見てthis上で見てください。

私は、この保護を克服し、フック機能で元の呼び出しにパッチを当てるためにいくつかのロジックを思いついたが、まだ成功しなかった。 誰かが私に加わり、そこから抜け出すのを助けたいですか？

Answer 1

セキュリティアングルをどこから取っているのか分かりません。

funcの前と現時点のどちらも「強化」されていません。

あなたはなぜexecveにフックしたいのですか？

標準的なフックメカニズムはkprobesを使用しています。したがって、コンシューマーの例としてsystemtapを確認できます。

私は前述の 'execmon'コードを見ましたが、それは品質が悪く、学習に適していないことがわかりました。例えばhttps://github.com/kfiros/execmon/blob/master/kmod/syscalls.c#L65

• ユーザースペースメモリに直接（なしGET_USER、copy_from_userなど）にアクセス
• は、それが二回ありません。最初に長さを計算してからバインドします。特に、誰かが文字列を長くした場合は、の後にがコンパイルされた後、コピーされる前にバッファオーバーフローが発生します。