ネットワーク経由で取得した共有ライブラリをファイルを作成せずに読み込む

夏休み突入でぇ~す!(CV: 門脇舞以) → 終了、了解! 皆さんはネットワーク経由からローカルにファイルを作成せずに共有ライブラリを読み込みたいと思ったことはありませんか? 僕はありません。 共有ライブラリのロード まずは普通に共有ライブラリをロードしてみる。以下のような共有ライブラリを用意する。 #include <stdio.h> void __attribute__ ((constructor)) hello_init(void); void hello_init(void) { fprintf(stdout,"[+] Hello!\n"); } $ gcc -shared -fPIC hello.c -o hello.so 続いてこの共有ライブラリを読み込む main.c を用意する。 共有ライブラリを読み込むには dlopen(3) を使用する。 #define _GNU_SOURCE #include <stdio.h>#include <stdlib.h>#include <unistd.h>#include <dlfcn.h> void load_shared_object() { printf("[+] Load Start\n"); dlopen("./hello.so", RTLD_LAZY); } int main (int argc, char **argv) { load_shared_object(); exit(0); } これをコンパイルすると無事読み込めたことが確認できる。 $ gcc main.c -ldl $ ./a.out [+] Load Start [+] Hello!

seccompによる制限下にある特権コンテナで breakout する

firefox で moz://a にアクセスすると https://www.mozilla.org/protocol にリダイレクトされる。moz://a ってカッコよくないですか?ズルい。 前回 は CAP_DAC_READ_SEARCH が許可されている状態で open_by_handle_at を利用することでホスト側のファイルを読み出したり、シェルを取得するなどした。 このとき、seccomp で open_by_handle_at が禁止されている場合は Operation not permitted で失敗する。 [root@b8bf54fb1c48 tmp]# ./a.out failed to open_by_handle_at: Operation not permitted しかし、このエントリ で書いたように、ptrace を使用することで seccomp による制限は回避することができる。 環境 今回は明示的に seccomp で open_by_handle_at を拒否し、DAC_READ_SEARCH を許可した Docker コンテナで試した。 なお、この設定は LXC と Docker の Privileged なコンテナとほぼ同じなので、それぞれの Pirivileged Container でも動作する。 $ cat seccomp.json | jq { "defaultAction": "SCMP_ACT_ALLOW", "syscalls": [ { "name": "open_by_handle_at", "action": "SCMP_ACT_ERRNO", "args": [] } ] } $ docker run --rm -ti --cap-add=DAC_READ_SEARCH --security-opt seccomp=seccomp.

open_by_handle_at(2) でコンテナから Break Out する

俺たちの夏休みはこれからだ!(今日が最終日) 前回は ptrace を使用して seccomp による制限を回避してみた 。 今回は seccomp とコンテナの関係、コンテナからホストへの break out についてのメモ。 コンテナと seccomp LXC や Docker でも seccomp が利用されており、コンテナを break out する危険があるようなシステムコールを禁止している。 LXCでは非常に小さなポリシーとなっている。 https://github.com/lxc/lxc/blob/master/config/templates/common.seccomp 2 blacklist reject_force_umount # comment this to allow umount -f; not recommended [all] kexec_load errno 1 open_by_handle_at errno 1 init_module errno 1 finit_module errno 1 delete_module errno 1 カーネルに関する kexec_load や *_module などが禁止されていることが分かる。 Docker は結構いろいろある。 https://github.com/moby/moby/blob/master/profiles/seccomp/default.json しかし open_by_handle_at とは何なのだろうか?

ptrace を使用して seccomp による制限を回避してみる

オススメ整体 or マッサージ情報を募集しています。 前回 は ptrace を使用して簡易的な strace を作成した。 同様にシステムコールの監視を行うものといえば seccomp だ。 seccomp によって特定のシステムコールは呼び出しが禁止されるが、ptrace によって回避することができる。 seccomp のドキュメント には次のような記述がある。 The seccomp check will not be run again after the tracer is notified. (This means that seccomp-based sandboxes MUST NOT allow use of ptrace, even of other sandboxed processes, without extreme care; ptracers can use this mechanism to escape.) ptrace によるトレーサに通知される前(システムコールが呼び出されて実行される前)に seccomp フィルタが適用されるので、seccomp によって検査された後のレジスタを変更することで、制限されているシステムコールを呼び出すことができる。 特定のシステムコールを禁止した環境を作る 以下の seccomp ポリシーを Docker コンテナに適用する。