libc.soはld-linux-x86-64.soの構造体を参照している。関数ではなく構造体なので、メンバの配置が一致している必要があり、異なるオプションでビルドされていると、誤ったメンバを参照してしまう。これをどうにかするのは難しそう。

libc.soとld-linux-x86-64.soの整合性の問題なので、libcと一緒にld-linux-x86-64.soが配布されているならば、動かすことができる。追記を参照。

詳細

CTFのうち、サーバーで動作している攻撃対象プログラムの脆弱性を突いてフラグを盗み出せという問題（PwnやExploitと呼ばれる）では、攻撃対象プログラムとともに、サーバーで使われてるlibc.soが提供されることが多い。

Pwnでは、バッファオーバーフローなどの脆弱性を経由してシェルを動かし、サーバー内のflag.txtなどのファイルを読む。攻撃対象のプログラムのコードだけではシェルを実行することができない場合には、libcのsystem関数などを使ってシェルを実行する。systemなどのアドレスはlibcによって異なるので、サーバーで実際に使われているlibcが必要になる。

単にsystemを呼び出すだけならば、systemのアドレスが分かれば良いのだが、ASLRによって攻撃をする度にアドレスが変わるので、実際には、

攻撃対象プログラムが使用しているprintfなどの関数のアドレスを得る
ASLRでは関数の相対位置はずれないので、printfからsystemのアドレスを計算する
systemを呼び出す

という流れになる。また、system関数の引数に渡したい/bin/shという文字列も、攻撃中に与えることが無理ならば、libcの中にあるものを使うことになる。攻撃するスクリプトをいきなり完成させることは難しいので、与えられたプログラムを手元で動かしてデバッグする。このときは、プログラムは手元のlibcで動作するから、リモートのサーバーを攻撃するときには各関数や文字列のアドレスを調節することになる。この作業が面倒なので、手元のlibcを与えられたlibcに差し替えて、プログラムを動かせると楽。

これをやりたいのだけど、何か方法は無いのだろうか。
"与えられたlibcで手元で動かしたかったのでいろいろ試行錯誤していたが結局だめだった"
SECCON 2016 online のwriteup - 忖度https://t.co/3uxMBBlYKt
— kusanoさん@がんばらない (@kusano_k) 2016年12月12日

この前のSECCON 2016 オンライン予選のjmperで試してみる。x64。この問題はsetjmpのjmp_bufをヒープオーバーフローで書き換える必要があるらしい。単にsystem関数を呼び出すよりも、libcへの依存が大きそうなので、特に与えられたlibcでデバッグしたい（setjmpやmallocの動作はそうそう変わらないと思うけど）。

とりあえず、バイナリエディタでjmper中のlibc.so.6を./bc.so.6に書き換え、与えられたlibcをbc.so.6にリネームして同じディレクトリに置いた。

わざわざこんなことをしなくても、LD_PRELOADを使うという手もあるらしい。

@kusano_k 普通にLD_PRELOADじゃだめですかね
— れっくす (@xrekkusu) 2016年12月12日

動かしてみたところ、Segmentation fault。残念。

kusano@ubuntu:~/ctf/seccon2016q$ ./jmper_bc
Segmentation fault (コアダンプ)

gdbで動かして、どこで落ちたかを見てみると、__libc_start_main。

[----------------------------------registers-----------------------------------]
RAX: 0xec8148ff8941d589
RBX: 0x0
RCX: 0x0
RDX: 0x470
RSI: 0x7fffffffe5d8 --> 0x7fffffffe7f7 ("/home/kusano/ctf/seccon2016q/jmper_bc")
RDI: 0x7ffff7ffe5d8 --> 0x7ffff7ffe168 --> 0x0
RBP: 0xf7de9950
RSP: 0x7fffffffe500 --> 0x7fffffffe5d8 --> 0x7fffffffe7f7 ("/home/kusano/ctf/seccon2016q/jmper_bc")
RIP: 0x7ffff7a33fdf (<__libc_start_main+399>:   call   rax)
R8 : 0x7ffff7dd1e80 --> 0x0
R9 : 0x7ffff7de78e0 (push   rbp)
R10: 0xd ('\r')
R11: 0x1
R12: 0x0
R13: 0x7ffff7de70f0 (push   r15)
R14: 0x7ffff7ffe168 --> 0x0
R15: 0x0
EFLAGS: 0x10202 (carry parity adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x7ffff7a33fd3 <__libc_start_main+387>:      add    rdx,0x47
   0x7ffff7a33fd7 <__libc_start_main+391>:      shl    rdx,0x4
   0x7ffff7a33fdb <__libc_start_main+395>:      lea    rdi,[r14+rdx*1]
=> 0x7ffff7a33fdf <__libc_start_main+399>:      call   rax
   0x7ffff7a33fe1 <__libc_start_main+401>:      add    r12d,0x1
   0x7ffff7a33fe5 <__libc_start_main+405>:      mov    r13,QWORD PTR [r13+0x40]
   0x7ffff7a33fe9 <__libc_start_main+409>:      cmp    ebp,r12d
   0x7ffff7a33fec <__libc_start_main+412>:      jne    0x7ffff7a33fc7 <__libc_start_main+375>

めちゅくちゃなアドレスをcallしようとしている。対応するlibcのソースコードはこの部分。

 248       struct audit_ifaces *afct = GLRO(dl_audit);
 249       struct link_map *head = GL(dl_ns)[LM_ID_BASE]._ns_loaded;
 250       for (unsigned int cnt = 0; cnt < GLRO(dl_naudit); ++cnt)
 251         {
 252           if (afct->preinit != NULL)
 253             afct->preinit (&head->l_audit[cnt].cookie);
 254 
 255           afct = afct->next;
 256         }

libc-start.c

GLROマクロなどの定義はldsodefs.hにあって、afctはextern struct rtld_global_ro _rtld_global_roのメンバを指すようになっている。

libcのインポートテーブルなどを確認すると、ld-linux-x86-64.soを参照している。#ifdefマクロが大量にあって、メンバの有無が変わっているので、どれかが異なっていると誤ったメンバを参照してしまう。

kusano@ubuntu:~/ctf/seccon2016q$ ldd bc.so.6
        /lib64/ld-linux-x86-64.so.2 (0x0000559a127d8000)
        linux-vdso.so.1 =>  (0x00007fff52dba000)
kusano@ubuntu:~/ctf/seccon2016q$ readelf -s bc.so.6 | grep _rtld_global_ro
     6: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND _rtld_global_ro@GLIBC_PRIVATE (24)
kusano@ubuntu:~/ctf/seccon2016q$ readelf -s /lib64/ld-linux-x86-64.so.2 | grep _rtld_global_ro
    26: 0000000000225ca0   368 OBJECT  GLOBAL DEFAULT   17 _rtld_global_ro@@GLIBC_PRIVATE

gdbでafctの値を確認してみても、ld-2.23.soのメモリになっている。

[-------------------------------------code-------------------------------------]
   0x7ffff7a33fa8 <__libc_start_main+344>:      call   QWORD PTR [rdx+0xd0]
   0x7ffff7a33fae <__libc_start_main+350>:      jmp    0x7ffff7a33ef3 <__libc_start_main+163>
   0x7ffff7a33fb3 <__libc_start_main+355>:      mov    r13,QWORD PTR [rax+0x120]
=> 0x7ffff7a33fba <__libc_start_main+362>:      mov    rax,QWORD PTR [rip+0x39be27]        # 0x7ffff7dcfde8
   0x7ffff7a33fc1 <__libc_start_main+369>:      xor    r12d,r12d
   0x7ffff7a33fc4 <__libc_start_main+372>:      mov    r14,QWORD PTR [rax]
   0x7ffff7a33fc7 <__libc_start_main+375>:      mov    rax,QWORD PTR [r13+0x18]
   0x7ffff7a33fcb <__libc_start_main+379>:      test   rax,rax

gdb-peda$ i proc map
process 30812
Mapped address spaces:

          Start Addr           End Addr       Size     Offset objfile
            0x400000           0x401000     0x1000        0x0 /home/kusano/ctf/seccon2016q/jmper_bc
            0x601000           0x602000     0x1000     0x1000 /home/kusano/ctf/seccon2016q/jmper_bc
            0x602000           0x603000     0x1000     0x2000 /home/kusano/ctf/seccon2016q/jmper_bc
      0x7ffff7a12000     0x7ffff7bcc000   0x1ba000        0x0 /home/kusano/ctf/seccon2016q/bc.so.6
      0x7ffff7bcc000     0x7ffff7dcc000   0x200000   0x1ba000 /home/kusano/ctf/seccon2016q/bc.so.6
      0x7ffff7dcc000     0x7ffff7dd0000     0x4000   0x1ba000 /home/kusano/ctf/seccon2016q/bc.so.6
      0x7ffff7dd0000     0x7ffff7dd2000     0x2000   0x1be000 /home/kusano/ctf/seccon2016q/bc.so.6
      0x7ffff7dd2000     0x7ffff7dd7000     0x5000        0x0
      0x7ffff7dd7000     0x7ffff7dfd000    0x26000        0x0 /lib/x86_64-linux-gnu/ld-2.23.so
      0x7ffff7ff3000     0x7ffff7ff8000     0x5000        0x0
      0x7ffff7ff8000     0x7ffff7ffa000     0x2000        0x0 [vvar]
      0x7ffff7ffa000     0x7ffff7ffc000     0x2000        0x0 [vdso]
      0x7ffff7ffc000     0x7ffff7ffd000     0x1000    0x25000 /lib/x86_64-linux-gnu/ld-2.23.so
      0x7ffff7ffd000     0x7ffff7ffe000     0x1000    0x26000 /lib/x86_64-linux-gnu/ld-2.23.so
      0x7ffff7ffe000     0x7ffff7fff000     0x1000        0x0
      0x7ffffffde000     0x7ffffffff000    0x21000        0x0 [stack]
  0xffffffffff600000 0xffffffffff601000     0x1000        0x0 [vsyscall]

ビルドオプションごとのld-linux-x86-64.soを用意しておくという手もあるかもしれないが、そんなことをするよりは、作問者が使っているライブラリみたいなものを作っておくほうが良さそうである。

Win32 APIのcbSizeのように、構造体の中身が異なっても動く仕組みがあれば良いのに……。

追記

ld-linux-x86-64.soを特に使うわけでもないのに、libc.soと一緒に配布している問題をちらほら見る。例えばこの問題。

同じ環境のld-linux-x86-64.soとlibc.soがあれば、動かすことができる。そもそもld-linux-x86-64.soが何かというとプログラムをロードするためのプログラムである。配布されたld-linux-x86-64.soで問題プログラムをロードすれば良い。

$ LD_PRELOAD=./libc-2.31.so ./ld-2.31.so ./pwn08
Coins : 1500
Gacha stack : 0
1. do_gacha!
2. view_history
3. clear_history
4. ceiling
9. exit

ld-linux-x86-64.soはELFファイルに絶対パスが埋め込まれている。上のように起動するとデバッガなどで扱いづらいなら、書き換えれば良い。それを行ってくれるpatchelfというコマンドがある。また、patchelfでは共有ライブラリを探すパスも書き換えることができる。

$ cp pwn08 pwn08_2
$ cp libc-2.31.so libc.so.6
$ patchelf --set-rpath . --set-interpreter ./ld-2.31.so ./pwn08_2
$ ldd pwn08_2
        linux-vdso.so.1 (0x00007ffd31f64000)
        libc.so.6 => ./libc.so.6 (0x00007ff73398a000)
        ./ld-2.31.so => /lib64/ld-linux-x86-64.so.2 (0x00007ff73395d000)
$ ./pwn08_2
Coins : 1500
Gacha stack : 0
1. do_gacha!
2. view_history
3. clear_history
4. ceiling
9. exit

カレントディレクトリが変わっても動くようにしたいならば、相対パスではなく絶対パスで指定しましょう。

この記事を最初に書いたときには使っていなかったpwntoolsを使うようになった。各種シンボルのアドレスはpwntoolsの関数で取れるから、ローカルとリモートでpwntoolsに読み込ませるlibcを変えるだけ。この記事のようなシチュエーションだとそもそもあまり困っていない。

今でも差し替えたいのはヒープ問題を解くときである。malloc周りの挙動はlibcのバージョン間で大きく変わる。ヒープ問ではPwngdbが便利で、ヒープの状況が見られる。

で、libcを差し替えると、差し替えたlibcのデバッグ情報が無くてmain_arenaのアドレスが取れないため、この機能が動かない。

gdb-peda$ parseheap
Can not get libc version
Cannot get main_arena's symbol address. Make sure you install libc debug file (libc6-dbg & libc6-dbg:i386 for debian package).
can't find heap info

libcのバージョンごとにVMを用意しておくのが一番かもしれない。