バッファオーバーフローについて

2019/05/06 07:37 編集

エクスプロイトをおこないたいので、eipを書き換えたいですm(_ _)m 私が今読んでいるセキュリティコンテストチャレンジブックという本の内容で同じようなことをしているのですが、私の環境ではうまくいかないため質問しました。最近アセンブリ学び始めたので、EIPがプログラムカウンタというのも初めて知りました。PCじゃないんですね...w

2019/05/06 07:57

「EIPを書き換えられない」と判断したのはどのような方法でしょうか？ gdb で？それともセグメンテーションフォールトで落ちるから？でしょうか。 ESPに不正な値をロードしたら、RET命令実行時に存在しないスタック領域からPOPしてしまう場合があり、そうだとアクセスして落ちるので、EIPの書き換えもままなりません。あと、検証環境も詳しく書きましょう。ubuntu 18.xx 32ビットとか。

2019/05/06 08:19 編集

判断した理由はgdbを使用してです。ディスアセンブリの最後のほうにも書いてありますが、0x4141413dがESPにロードされるため不正な値となってしまいます。検証環境は追記しますm(__)m

cateye

2019/05/06 09:46 編集

>PCじゃないんですね...instruction pointer・・・EはExtendかな？参考：http://e-words.jp/w/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%A0%E3%82%AB%E3%82%A6%E3%83%B3%E3%82%BF.html

2019/05/06 09:46

IPの別称知らなかったのは恥ずかしいですね。参考サイトまでありがとうございますm(_ _)m

行動規範の内容に同意します

回答2件

**回答の一部を修正し、追記しました：**2019/05/09 00:22

mainの中でバッファオーバーフローをしようとすると、EIPを書き換える直前でESPの書き換わるような挙動

...

これは何かのセキュリティが働いているのでしょうか？

~~セキュリティの問題ではなく、~~bof.c のmain関数で~~実装しているコードに問題があり~~意図する動きを阻害しています。逆アセンブルした結果で、ret直前のコードが

 0x5655622d <+116>:    lea    esp,[ecx-0x4] <=　この部分でespに[ecx - 0x4](0x4141413d)がロードされる　
   0x56556230 <+119>:    ret

とのことでしたが、espに不正な値がロードされていることで、ret命令の実行時に不正なアドレスのスタック領域、ss:[0x4141413d]をアクセスしてeipにロードしようとするので、SIGSEGVが発生し、retが完了せず、結果としてeipに所望の値、すなわち0x4141....がロードできずに終わっています。

シンプルな例で行うとmainのreturn時にeipが書き換わることを確認できます。

C
1/* t7.c simple bof */
2int i;  /* ※ループ実行時に破壊されないよう、static領域に配置*/
3int main(int argc, char *argv[]) {
4    char s[8];
5    for (i = 0; i < 128; i++) {
6        s[i] = 'A';
7    }
8
9    return 0;
10}

以下、上のソースコードをUbuntu16.04 (x64)の環境でコンパイルしてgdbで追った例です。(長くなりますがご容赦ください）return 0; のところにブレイクポイントを張り、runします。

bash
1user01@ubuntu1604-x64:~$ gdb ./t7
2GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
3Copyright (C) 2016 Free Software Foundation, Inc.
4License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
5This is free software: you are free to change and redistribute it.
6There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
7and "show warranty" for details.
8This GDB was configured as "x86_64-linux-gnu".
9Type "show configuration" for configuration details.
10For bug reporting instructions, please see:
11<http://www.gnu.org/software/gdb/bugs/>.
12Find the GDB manual and other documentation resources online at:
13<http://www.gnu.org/software/gdb/documentation/>.
14For help, type "help".
15Type "apropos word" to search for commands related to "word"...
16Reading symbols from ./t7...done.
17(gdb) list
181	int i;
192	int main(int argc, char *argv[]) {
203	    char s[8];
214	    for (i = 0; i < 128; i++) {
225	        s[i] = 'A';
236	    }
247	
258	    return 0;
269	}
2710	
28(gdb) b 8
29Breakpoint 1 at 0x804840e: file t7.c, line 8.
30(gdb) run
31Starting program: /home/user01/t7

ブレイクした時点でスタックが0x41で上書きされているので、argcやargvが0x41...に書き換わっていることも分かります。

Breakpoint 1, main (argc=1094795585, argv=0x41414141) at t7.c:8
8	    return 0;
(gdb) disassemble
Dump of assembler code for function main:
   0x080483db <+0>:	push   %ebp
   0x080483dc <+1>:	mov    %esp,%ebp
   0x080483de <+3>:	sub    $0x10,%esp
   0x080483e1 <+6>:	movl   $0x0,0x804a01c
   0x080483eb <+16>:	jmp    0x8048404 <main+41>
   0x080483ed <+18>:	mov    0x804a01c,%eax
   0x080483f2 <+23>:	movb   $0x41,-0x8(%ebp,%eax,1)
   0x080483f7 <+28>:	mov    0x804a01c,%eax
   0x080483fc <+33>:	add    $0x1,%eax
   0x080483ff <+36>:	mov    %eax,0x804a01c
   0x08048404 <+41>:	mov    0x804a01c,%eax
   0x08048409 <+46>:	cmp    $0x7f,%eax
   0x0804840c <+49>:	jle    0x80483ed <main+18>
=> 0x0804840e <+51>:	mov    $0x0,%eax
   0x08048413 <+56>:	leave  
   0x08048414 <+57>:	ret    
End of assembler dump.
(gdb) info r
eax            0x80	128
ecx            0x2fa1db1e	799136542
edx            0xffffdc14	-9196
ebx            0x0	0
esp            0xffffdbd8	0xffffdbd8
ebp            0xffffdbe8	0xffffdbe8
esi            0xf7fb2000	-134537216
edi            0xf7fb2000	-134537216
eip            0x804840e	0x804840e <main+51>
eflags         0x212	[ AF IF ]
cs             0x23	35
ss             0x2b	43
ds             0x2b	43
es             0x2b	43
fs             0x0	0
gs             0x63	99

ここからgdbのstepiコマンドでret直前までステップ実行していきます。

bash
1(gdb) stepi
29	}
3(gdb) info r
4eax            0x0	0
5ecx            0x2fa1db1e	799136542
6edx            0xffffdc14	-9196
7ebx            0x0	0
8esp            0xffffdbd8	0xffffdbd8
9ebp            0xffffdbe8	0xffffdbe8
10esi            0xf7fb2000	-134537216
11edi            0xf7fb2000	-134537216
12eip            0x8048413	0x8048413 <main+56>
13eflags         0x212	[ AF IF ]
14cs             0x23	35
15ss             0x2b	43
16ds             0x2b	43
17es             0x2b	43
18fs             0x0	0
19gs             0x63	99
20(gdb) disassemble
21Dump of assembler code for function main:
22   0x080483db <+0>:	push   %ebp
23   0x080483dc <+1>:	mov    %esp,%ebp
24   0x080483de <+3>:	sub    $0x10,%esp
25   0x080483e1 <+6>:	movl   $0x0,0x804a01c
26   0x080483eb <+16>:	jmp    0x8048404 <main+41>
27   0x080483ed <+18>:	mov    0x804a01c,%eax
28   0x080483f2 <+23>:	movb   $0x41,-0x8(%ebp,%eax,1)
29   0x080483f7 <+28>:	mov    0x804a01c,%eax
30   0x080483fc <+33>:	add    $0x1,%eax
31   0x080483ff <+36>:	mov    %eax,0x804a01c
32   0x08048404 <+41>:	mov    0x804a01c,%eax
33   0x08048409 <+46>:	cmp    $0x7f,%eax
34   0x0804840c <+49>:	jle    0x80483ed <main+18>
35   0x0804840e <+51>:	mov    $0x0,%eax
36=> 0x08048413 <+56>:	leave  
37   0x08048414 <+57>:	ret    
38End of assembler dump.
39
40(gdb) stepi
410x08048414	9	}
42(gdb) disassemble
43Dump of assembler code for function main:
44   0x080483db <+0>:	push   %ebp
45   0x080483dc <+1>:	mov    %esp,%ebp
46   0x080483de <+3>:	sub    $0x10,%esp
47   0x080483e1 <+6>:	movl   $0x0,0x804a01c
48   0x080483eb <+16>:	jmp    0x8048404 <main+41>
49   0x080483ed <+18>:	mov    0x804a01c,%eax
50   0x080483f2 <+23>:	movb   $0x41,-0x8(%ebp,%eax,1)
51   0x080483f7 <+28>:	mov    0x804a01c,%eax
52   0x080483fc <+33>:	add    $0x1,%eax
53   0x080483ff <+36>:	mov    %eax,0x804a01c
54   0x08048404 <+41>:	mov    0x804a01c,%eax
55   0x08048409 <+46>:	cmp    $0x7f,%eax
56   0x0804840c <+49>:	jle    0x80483ed <main+18>
57   0x0804840e <+51>:	mov    $0x0,%eax
58   0x08048413 <+56>:	leave  
59=> 0x08048414 <+57>:	ret    
60End of assembler dump.
61(gdb) info r
62eax            0x0	0
63ecx            0x2fa1db1e	799136542
64edx            0xffffdc14	-9196
65ebx            0x0	0
66esp            0xffffdbec	0xffffdbec
67ebp            0x41414141	0x41414141
68esi            0xf7fb2000	-134537216
69edi            0xf7fb2000	-134537216
70eip            0x8048414	0x8048414 <main+57>
71eflags         0x212	[ AF IF ]
72cs             0x23	35
73ss             0x2b	43
74ds             0x2b	43
75es             0x2b	43
76fs             0x0	0
77gs             0x63	99
78
79(gdb) x/20xb 0xffffdbec
800xffffdbec:	0x41	0x41	0x41	0x41	0x41	0x41	0x41	0x41
810xffffdbf4:	0x41	0x41	0x41	0x41	0x41	0x41	0x41	0x41
820xffffdbfc:	0x41	0x41	0x41	0x41

この時点でebpは0x4141...になっていますが、espは壊されていません。なので、retできます。
ここからgdb で再度stepiコマンドを実行し、ret命令が実行されると、eipが書き換わっているのが分かります。

bash
1(gdb) stepi
20x41414141 in ?? ()
3(gdb) stepix/20bx 0xffffdbec 0xffffdbecb 20info r
4eax            0x0	0
5ecx            0x2fa1db1e	799136542
6edx            0xffffdc14	-9196
7ebx            0x0	0
8esp            0xffffdbf0	0xffffdbf0
9ebp            0x41414141	0x41414141
10esi            0xf7fb2000	-134537216
11edi            0xf7fb2000	-134537216
12eip            0x41414141	0x41414141
13eflags         0x212	[ AF IF ]
14cs             0x23	35
15ss             0x2b	43
16ds             0x2b	43
17es             0x2b	43
18fs             0x0	0
19gs             0x63	99

eip=0x4141...のまま続行すると、当然SIGSEGVが発生します。

bash
1(gdb) stepi
2
3Program received signal SIGSEGV, Segmentation fault.
40x41414141 in ?? ()
5(gdb) quit

**以下、追記部分です：**2019/05/09 00:22

mainの中でバッファオーバーフローをしようとすると、EIPを書き換える直前でESPの値が書き換わるような挙動を起こしてしまうためEIPを書き換えられません。

追って調べたところ、言葉のとおりでした。main関数に限って、ret直前に lea esp, [ecx-4]のコードが入る場合と入らない場合があります。質問者であるkonataroさんのC言語コードでは入ってしまい、拙作の例示用C言語コードでは入りません。その為、動きに差が出ています。

bof.c を"-S"オプション付きでコンパイルしてアセンブリ言語ソースで出力すると、main関数のret命令付近のエピローグコードは、以下のようになります。注目すべきコードであるleal -4(%ecx), %espが入っています。(質問者のkonataroさんが既に提示されたものとほぼ等価なものですが、説明の為に掲げています)

    call    strcpy
    addl    $16, %esp
    .loc 1 13 0
    movl    $0, %eax
    .loc 1 14 0
    movl    -4(%ebp), %ecx
    .cfi_def_cfa 1, 0
    leave
    .cfi_restore 5
    leal    -4(%ecx), %esp
    .cfi_def_cfa 4, 4
    ret
    .cfi_endproc

これをkonataroさんが既に指摘されているように、mainではなく、普通の関数funcに変えてコンパイルすると、

C
1//bof.c
2#include<stdio.h>
3#include<string.h>
4
5char buffer[32];
6
7int func(int argc, char *argv[])
8{
9    char local[32];
10    printf("buffer 0x%x\n", &buffer);
11    fgets(local, 128, stdin);
12    strcpy(buffer,local);
13    return 0;
14}
15
16int main(int argc, char *argv[])
17{
18    return func(argc, argv);
19}

アセンブリ言語のソースは、以下のように変わります。leal -4(%ecx), %espは消滅しています。

    call    strcpy
    addl    $16, %esp
    .loc 1 13 0
    movl    $0, %eax
    .loc 1 14 0
    leave
    .cfi_restore 5
    .cfi_def_cfa 4, 4
    ret
    .cfi_endproc

.cfi_restoreとは何か？をWEBで検索してみると以下のas(gas)のドキュメントがヒットし、
7.10 CFI directives

内容として下の説明がありました。

7.10.17 .cfi_restore register
.cfi_restore says that the rule for register is now the same as it was at the beginning of the function, after all initial instruction added by .cfi_startproc were executed.

どうも、このディレクティブで関数先頭でのレジスターの値と同じようにすることを指示するもののようで、main内で関数を呼び出すコードを書くとleal -4(%ecx), %espのコードが挟み込まれます。拙作のmainの例示コードでは関数を呼び出さない為、目的を達成できるコードが生成できたようです。あくまで勝手な推測ですが、SSPなどの仕組みの一部で、mainを呼び出したCランタイムのスタートアップルーチンに正しく戻れるよう保証する動作の一端でしょうか。少し検索した限りでは、なぜそうなっているかを説明しているgccやbinutilのドキュメントは見つけることはできませんでした。この辺り、gcc周りの事情にお詳しい方にフォローや突っ込みをお願いしたいところです。

ですので、少なくとも本質問の内容の限りにおいては、gccに"-fno-stack-protector"オプションを追加した上で、

main関数以外の関数内に目的のコードを書く。
main関数内に書くときは、標準関数を含む他の関数を呼び出さない。

ようにすると所望の動作をするコードになるので、それを踏まえてコードを書く必要があると考えます。

私自身の参考として - IPA - 第10章著名な脆弱性対策 - バッファオーバーフロー: #5 運用環境における防御

投稿2019/05/07 05:40

編集2019/05/08 15:22

総合スコア9293

2019/05/07 15:14

もしかして、簡単にリターンアドレスが書き換えられないように、こんなコードを出力しているとか。さすがに深読みしすぎ?

2019/05/08 09:05 編集

回答したものの、改めて考えてまだ解せない点があったので追っていました。 > 簡単にリターンアドレスが書き換えられないようにリターンアドレスを書き換えられないように、と言う訳ではなさそうなのですが、どうも、mainに限ってret命令の直前に"lea esp,[ecx-0x4]"を挿入してespの値を保証しよう、とするgccのコンパイル動作があるようです。あとで追記します。

2019/05/08 11:52

ま、勝手な深読みなので、あまり気にされないように。ただ、EIPの書き換えができない件は、これ以上、深入りしないつもり。ハック以上の意味が無さそうななので。

2019/05/11 16:25

詳しく調査していただきありがとうございます。私もこれ以上最後のlea命令がなぜ生成されるかについて、知っている方が現れるまでは検索しないことにします。また、「ベストアンサーを選べ」と急かされてますが根本的に解決していないため、質問はこのまま放置しておこうかと思います。m(_ _)m

2019/05/11 16:31

そうですね。私もgccの.cfi_restore周りの動作仕様を把握できなかったので、まだ釈然としない思いはあります。質問を閉じるかどうかの判断はお任せします。

行動規範の内容に同意します

セキュリティ云々じゃなくて、単に、バッファーオーバーフローが発生して、スタックの内容が壊されている。その結果、EIPより、先に、ESPが壊されただけじゃないですか?
アセンブラの先頭から、スタックの動きを追えば、分かると思います。(ちと、面倒ですが)

[追記]
ざっとですが、スタックの中身を追ってみました。

スタックなので、負方向に延びます。一応、[ 00] が スタックの先頭ですが、
 <+4> のところで、16バイト単位の調整が行われているの位置は正確ではありません。
[-40]: eax (printf()用)	<+45>
[-3C]: eax (printf()用)	<+38>
[-31 : -38]: ?	<+29>
[-11 : -30]: local[32] (local[0]: [-30],,,local[31]: [-11]	<+15>
[-10]: ecx (ESP+4)<+14>	<+113> の popで ecxにセットされる値
			<+116> でこの値から、呼び出し時のespを復元し、retしている
[-0C]: ebx	<+13>		<+114> の popで ebxにセットされる値
[-08]: ebp	<+10>		<+115> の popで ebpにセットされる値
[-04]: DWORD PTR [ecx-0x4](本来の戻りアドレス)	<+7>
--- (16 byte境界に合わせる) :	<+4>
[ 00]: EIP (戻りアドレス) <-- main()の呼び出し時

ローカル変数 local[32] に 32バイト以上の書き込みを行うと、関数の終了時に、ecx, ebx, ebpの順に上書きされます。

投稿2019/05/06 08:43

編集2019/05/07 15:12

総合スコア6385

2019/05/06 08:55 編集

アセンブラを読む練習も兼ねて上から順に処理を追っていったのですが、pepperleaf様の言った通り先にESPが不正な値になってしまうためsegmentation faultが起こってしまうようです。ただ、関数内でバッファオーバーランを引き起こした場合は綺麗にリターンアドレスが書き換えられていました。本ではmain内でバッファオーバーランを起こしてEIPの書き換えができているようで、これはコンパイラによって生成されるコードの違いなのでしょうか。下は私がアセンブラの処理を追っていったときのpdfです。 https://drive.google.com/file/d/10rxFvgV_UNItXEmkLnuzWB-APWZcRxNs/view?usp=sharing

2019/05/06 09:03

アセンブラ出力まで、見る事は少ないので、断定はできませんが、コンパイラによって異なるのは当然かと思います。先日、ちょっと見たら、ローカル変数が宣言順に確保されてませんでした。(VS2019) また、最適化があると、スタックでなく、レジスタのみで済ます場合(可能ならば)もあるようです。

2019/05/06 09:22 編集

gccのバージョンごとにも生成されるバイナリは結構違うとしても、変更された部分があるとして今回のlea命令もしくはpop ecxの部分を出力しないようオプションなどに変更が加えられてないものでしょうか... 本の内容でも書いてあったのですが、ローカル変数が宣言順にスタック確保されていないのはASLRでアドレスの一部がランダム化されている影響からです？ちなみに、私の今回の環境ではASLRをOFFにした状態でバッファオーバーフローを起こしています。

2019/05/06 09:29

コンパイラの内部事情には詳しくないので、その辺は分かりません。 (特に最近のもの)　同じコンパイラでも実行環境で出力コードが違うのもありましたが。

2019/05/06 09:36

コンパイラだけでも学ぶことが本当多いです。同じlinux kernelでもディストリビューションによって出力コードが違うとかもあるんでしょうかｗ

2019/05/06 09:56

「関数内でバッファオーバーランを引き起こした場合はOK、と言うのが少し分からないのですが、同じように('A'=0x41)をバッファに書き込んだ場合はOK、結果的にEIPに0x4141....とロードされる、と言うことですか？