memologue RSSフィード

書いている人

日記というよりは備忘録、ソフトウェア技術者の不定期メモ。あるいはバッドノウハウ集。プライベートで調査した細々した諸々のスナップショット。嘘が散りばめられています。ISO/IEC 14882(C++)とPOSIX, GCC, glibc, ELFの話ばかりで、WindowsやMacの話はありません。特に記載がなければLinux/x86とILP32が前提です。時間の経過と共に古い記事は埋もれてしまいます。検索エンジンから飛んできた場合は、ページ内検索をご利用いただくかgoogleキャッシュを閲覧してみてください。技術的な記事を書きためる場所として使っています。言及してもらえると喜びます。主要な記事の一覧を書いておきます:

にんきコンテンツ: [GCC] mainを一度も呼ばないばかりか蹂躙する / Binary2.0 Conference 2006 発表資料 / C++ で SICP / ついカッとなって実行バイナリにパッチ / hogetrace - 関数コールトレーサ

昔のPOSIX関係の記事: シグナルの送受に依存しない設計にしよう / シグナルハンドラで行ってよい処理を知ろう / マルチスレッドのプログラムでのforkはやめよう / スレッドの「非同期キャンセル」を行わない設計にしよう / スレッドの「遅延キャンセル」も出来る限り避けて通ろう / マルチスレッドプログラミングの「常識」を守ろう / C++でsynchronized methodを書くのは難しい / シグナルハンドラからのforkするのは安全か? / g++ の -fthreadsafe-statics ってオプション知ってます? / 非同期シグナルとanti-pattern / localtimeやstrtokは本当にスレッドセーフにできないのか / UNIXの規格について / マルチスレッドと共有変数 - volatile?なにそれ。 / type punning と strict aliasing / アセンブラで遊ぶ時に便利なgdb設定 / 最近の記事は一覧から

2006-06-18

[] ld -z relro で GOT overwrite attack から身を守る

GOT overwrite?


"GOT overwrite" という、(ここでは特にLinuxの)プログラムに対する攻撃方法があります。攻撃が成功すると、そのプロセスの権限での任意コード実行等、深刻な被害を受けます。最近のGNU ld(リンカ)のオプションを用いると、この攻撃から身を守ることができるそうですので、紹介します。

最初にまとめ (こまかいことはあとで)


GOT overwrite から身を守るには、gccでプログラムをリンクするときに、 -Wl,-z,now,-z,relro をつけるだけです。起動時間が遅くなるというトレードオフがありますが、GOTがreadonlyになります。GOTがreadonlyなら、GOT overwrite attack を受けたときに、プロセスがSEGVしてくれますので、安全性が高まります。プロセスのメモリマップを確認すると、きちんと w が落ちています。

% gcc -Wl,-z,now,-z,relro foo.c
% readelf -S a.out | grep .got
  [20] .got              PROGBITS        08049fd8 000fd8 000028 04  WA  0   0  4
% ./a.out &
[32304]
% cat /proc/32304/maps | grep 08049
08049000-0804a000 r--p 00000000 08:02 6391415                            /home/yupo/tmp/a.out
                  (^ 普通のバイナリと違ってGOTにw (=書き込み許可) が無い)

GOTは libhoge.so も個々に持っていますので、それら共有ライブラリを作成する際にも同じオプションを使うと良いでしょう*1。最近のglibcは最初から -Wl,-z,now,-z,relro になっているそうです*2。お手元のglibcがそうなっているかどうかは、readelfコマンドで、ELFのプログラムヘッダを読めば確認できます。PT_GNU_RELRO があれば、-z relro されています。

% readelf -l /lib/libc-2.4.so | grep GNU_RELRO
  GNU_RELRO      0x12d0c0 0x00c9a0c0 0x00c9a0c0 0x01f40 0x01f40 R   0x1

% readelf -d /lib/libc-2.4.so | grep NOW
 0x0000001e (FLAGS)                      BIND_NOW STATIC_TLS
 0x6ffffffb (FLAGS_1)                    フラグ: NOW

起動時間とセキュリティ強度のバランスを取るには、DSOのチューニングについて理解する必要があります(って私も怪しい限りですが :-)。このpdfにいろいろ書いてあります。あと、このサイトをDSOとかPICとかPIEで検索して把握すると良いと思います(私もちゃんと読んでいませんが orz)。

PLT/GOT経由の関数呼び


ここからstep-by-stepの解説です。なにげに(Web上には)あまり解説がないので...目新しい話ではないですが&間違いがあったらゴメンナサイですが、一応。興味がなければ、「GOT overwrite attack の実験」までスキップしてください。


GOTというのは、ごく単純に書くと、「別の共有ライブラリ中の関数(例えばlibc.soの中のputs関数)を呼ぶときに参照する間接ジャンプテーブル」です。詳しくは Linkers & Loaders などを参照してください。


例えば、次のようなコードを書いたとして

% cat hello2.c
#include <stdio.h>
int main() {
  puts("hello\n");
  return 0;
}

% gcc -Wall -o hello2 hello2.c

main関数周辺を逆アセンブルしてみると、次のようになります。

% objdump -d hello2 | grep -A 10 '<main>:'
08048384 <main>:
 8048384:       8d 4c 24 04             lea    0x4(%esp),%ecx
 8048388:       83 e4 f0                and    $0xfffffff0,%esp
 804838b:       ff 71 fc                pushl  0xfffffffc(%ecx)
 804838e:       55                      push   %ebp
 804838f:       89 e5                   mov    %esp,%ebp
 8048391:       51                      push   %ecx
 8048392:       83 ec 04                sub    $0x4,%esp
 8048395:       c7 04 24 64 84 04 08    movl   $0x8048464,(%esp)
 804839c:       e8 07 ff ff ff          call   80482a8 <puts@plt>
 80483a1:       b8 00 00 00 00          mov    $0x0,%eax
...

C言語でのputs() は、<puts@plt> の call になっています。この <puts@plt> は、libc内のputs関数ではありません。本物のputs関数を呼び出すwrapperのようなものです。libc内のputs関数が、実行時にどのアドレスに貼り付けられるかは、実行時にしかわかりませんので、ここにアドレスを書くことはできないわけです。


ということだけ覚えておいて <puts@plt> を見ると、

% objdump -d hello2 | grep -A 10 '<puts@plt>:'
080482a8 <puts@plt>:
 80482a8:       ff 25 5c 95 04 08       jmp    *0x804955c
 80482ae:       68 00 00 00 00          push   $0x0
 80482b3:       e9 e0 ff ff ff          jmp    8048298 <_init+0x18>

080482b8 <__libc_start_main@plt>:
 80482b8:       ff 25 60 95 04 08       jmp    *0x8049560
 80482be:       68 08 00 00 00          push   $0x8
 80482c3:       e9 d0 ff ff ff          jmp    8048298 <_init+0x18>

080482c8 <__gmon_start__@plt>:
...

となっています。<puts@plt> 先頭行 (80482a8 の jmp *0x804955c) に注目。アドレス 0x804955c に格納されている値にジャンプすることになっています。この、アドレス 0x804955c 周辺がGOT(Global Offset Table)という 間接ジャンプテーブル です。ちなみに、<puts@plt> などが存在するアドレス周辺は PLT (Procedure Linkage Table) と呼ばれています。


GOTとPLTの開始アドレスは、readelfコマンドでセクション情報を表示させれば得ることができます。それぞれ、0x08048298と0x0804954cのようです。

% readelf -S hello2 | egrep -e '( .got | .plt )'
  [11] .plt              PROGBITS        08048298 000298 000040 04  AX  0   0  4
  [20] .got              PROGBITS        0804954c 00054c 000004 04  WA  0   0  4

遅延BIND


で、肝心の「アドレス 0x804955c の値」ですが、これは dynamic linker が実行時に決めます。dynamic linker がいつどのように決めるかの戦略は二種類あります。

  1. オブジェクトがロードされた時(プログラムの起動時)に、dynamic linkerが全てのGOTのエントリに本当の関数のアドレス(libc.soのputsなど)を埋める
  2. オブジェクトがロードされた時(プログラムの起動時)には、GOTに特別な値を入れておき、本当の関数のアドレス調査を、その関数の初回呼び出し時まで遅延する

どちらの戦略を取るかは、プログラムをリンクするときに決めることができます*3

% gcc -Wall -o hello2 -Wl,-z,now hello2.c
% readelf -d hello2 | grep NOW
 0x00000018 (BIND_NOW)
 0x6ffffffb (FLAGS_1)                    フラグ: NOW

上記のように、-Wl でリンカ(ld)に -z now オプションを渡せば1.の戦略が取られます。1. なオブジェクトかどうかは、readelf -d すればわかります。1. の戦略が取られた場合、<puts@plt> の先頭のjmpで、いきなりlibc.soのputsに制御が移ります。まさに単なるwrapperです。わかりやすいですね。

080482a8 <puts@plt>:
 80482a8:       ff 25 5c 95 04 08       jmp    *0x804955c
 80482ae:       68 00 00 00 00          push   $0x0

そうではなく、-z now を渡さなかった場合、2.の戦略が取られます(lazy relocation)。こちらがデフォルトです。PLTは2.の戦略のため(など)に存在しています。


2. の戦略の場合、「アドレス 0x804955c の値」は、デフォルトで <puts@plt> の2行目になっています。ここでは、0x80482ae ですね。ですから、jmp先は <puts@plt> の2行目(次の行!)ということになります。0x80482ae から先は、dynamic linker(具体的には__dl_runtime_resolve関数)に、「アドレス 0x804955c の値」を本物のputs関数のアドレスに書き換えてもらった上で、本物のputs関数にジャンプする処理になっています*4。objdump結果を読んだり、gdbでstepiして追ったりすればわかります。2.の戦略の場合でも、2度目以降の <puts@plt> 呼び出しでは、<puts@plt> の先頭のjmpで、いきなりlibc.soのputsに制御が移ります(1度目で「アドレス 0x804955c の値」が書きかわるため)。

ここまでのまとめ


(1) 別のsoの関数呼びは、次のようにPLTを経由する。

% objdump -d hello2 | grep -A 10 '<main>:'
08048384 <main>:
...
 804839c:       e8 07 ff ff ff          call   80482a8 <puts@plt>

(2) PLTの先頭で、GOT(のputs用のエントリ)に書かれているアドレスにジャンプする。このアドレスは次のどちらかである。

  • libc.soのputsのアドレス
  • <puts@plt>の2行目
080482a8 <puts@plt>:
 80482a8:       ff 25 5c 95 04 08       jmp    *0x804955c
 80482ae:       68 00 00 00 00          push   $0x0

GOT overwrite attack の実験


というように、PLT経由の関数呼び出しはいろいろめんどくさいんですけど、攻撃するのは非常に簡単です。"format string bug" 等の、「アドレス空間中の任意の4バイトを書き換え可能」なプログラムの欠陥を悪用して、GOT(の例えばputs関数用)の値をお好きな値Xに書き換えてしまえば良いわけです。そうすれば、プログラムが次にputsを呼ぼうとした瞬間に、PLT経由でアドレスXのコードが実行されます。


実際に試してみましょう。次のコードを gcc hello.c -o hello でコンパイルします。

// hello.c (IA32)
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

static int my_puts(const char* s) {
  write(1, "HEHE\n", 5);
  _exit(1);
}

int main(int argc, char** argv) {
  unsigned int* got_addr = (unsigned int*)strtoul(argv[1], NULL, 16);
  *got_addr = (unsigned int)my_puts;

  puts("hello");
  return 0;
}

次に、GOT(のputs用エントリの場所)を調べます。

% objdump -d hello | grep -A 1 '<puts@plt>'
08048324 <puts@plt>:
 8048324:       ff 25 68 96 04 08       jmp    *0x8049668
...

0x8049668 らしいので、そこを書き換えるように指定しつつ hello を実行します。

% ./hello 0x8049678
HEHE

puts("hello\n"); を呼んだはずが、my_puts() が呼ばれてしまいました。簡単に攻撃成功です。

GOT overwrite attack 防御


GOTを書き込み禁止にしてしまえばこの問題は解決します。


普段から書き込み禁止にしておいて、dynamic linkerがGOTをいじる瞬間だけdynamic linkerが自ら、mprotect(2)で書き込み許可を出す方法もありますが、これはmprotectの呼び出し回数が多くなってしまい、非常にコストがかかる(実行が遅くなる)そうで、現実的ではないそうです。


そこで、

  • 遅延BINDしない。プログラム実行開始時にGOTを全部書き換える
  • 全部書き換え終わったら、GOTを書き込み禁止にする

という現実的な方法が考えられました。gccの-Wlオプションをちょっといじるだけでこういう動作にできます。

% gcc -Wall -g -o hello_ro -Wl,-z,now,-z,relro hello3.c

% objdump -d hello_ro | grep -A 1 '<puts@plt>:'
08048344 <puts@plt>:
 8048344:       ff 25 e8 9f 04 08       jmp    *0x8049fe8
% ./hello_ro 0x8049fe8
zsh: segmentation fault  ./hello_ro 0x8049fe8

確かに、SEGVしてくれました。どこでSEGVしたかを一応確認すると、

% catchsegv ./hello_ro 0x8049fe8
*** Segmentation fault
Register dump:

 EAX: 08049fe8   EBX: 00c9bff4   ECX: 00000000   EDX: 08048444
 ESI: 00b69cc0   EDI: 00000000   EBP: ffffbfb8   ESP: ffffbf90

 EIP: 080484b0   EFLAGS: 00010286
...

ダンプのEIP(プログラムカウンタ)によれば、080484b0 の命令で死んだことがわかります。プログラムを混合モードでobjdumpすると、

% objdump -S hello_ro | grep -B 16 80484b0
 8048480:       83 ec 24                sub    $0x24,%esp
  unsigned int* got_addr = (unsigned int*)strtoul(argv[1], 0, 16);
 8048483:       8b 41 04                mov    0x4(%ecx),%eax
 8048486:       83 c0 04                add    $0x4,%eax
 8048489:       8b 00                   mov    (%eax),%eax
 804848b:       c7 44 24 08 10 00 00    movl   $0x10,0x8(%esp)
 8048492:       00
 8048493:       c7 44 24 04 00 00 00    movl   $0x0,0x4(%esp)
 804849a:       00
 804849b:       89 04 24                mov    %eax,(%esp)
 804849e:       e8 c1 fe ff ff          call   8048364 <strtoul@plt>
 80484a3:       89 45 f8                mov    %eax,0xfffffff8(%ebp)
  *got_addr = (unsigned int)my_puts;
 80484a6:       b8 44 84 04 08          mov    $0x8048444,%eax
 80484ab:       89 c2                   mov    %eax,%edx
 80484ad:       8b 45 f8                mov    0xfffffff8(%ebp),%eax
 80484b0:       89 10                   mov    %edx,(%eax)  <--- ここ

x86アセンブラに目が慣れていないとつらいですが、確かに、*got_addr に書き込んだ場所で死んでくれています。


(補足 6/22) ちなみにこの攻撃は、exec-shieldによるコード実行禁止(NX)、exec-shieldによるライブラリ/スタックアドレスのランダム化、SSPによるスタックベースバッファオーバーフローの検出あたりが有効になっていても成功します。上に書いたようにRELROするか、バイナリをPIEにするとよいでしょう(gcc -fPIE -pie hello.c)。PIE最強。

まとめ


冒頭の「最初にまとめ」のところをご覧くださいませ。おっと、cat /proc/<pid>/maps よりも /usr/bin/pmap <pid> のほうが出力が見やすいかな。題名の [GCC] というタグも不適切だけどまぁいいか。


PT_GNU_RELRO で検索したところ、日本語の情報がなかったので書いてみました。

*1:未検証

*2:for i in *.so ; do readelf -l $i | grep GNU_RELRO > /dev/null && echo $i ; done などで調べると良いでしょう。Fedora5ではそれなりの数のsoがrelroされていました

*3:環境変数LD_BIND_NOWでも制御できるが、略

*4:蛇足: _dl_runtime_resolveは、80482aeでpushされた0x0によって、putsの解決を要求されていると理解します

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証