脆弱性保護メカニズムの調査と分析
GSセキュリティコンパイルメカニズム
実際、これまでの実験では GS の影が見えてきましたが、今回の実験では、この GS の保護メカニズムについて詳しく説明します。
コードについては、例として以前に使用したパスワード プログラムを引き続き使用します。
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define PASSWORD "1234567"
int verify_password(char *password){
int authentication;
char buffer[8];
authentication=strcmp(password, PASSWORD);
strcpy(buffer,password);
return authentication;
}
int main(){
int valid_flag=0;
char password[1024];
while(1){
printf("please input password: ");
scanf("%s",password);
valid_flag=verify_password(password);
if(valid_flag)
{
printf("incorrect password!\n\n");
}
else
{
printf("congratulations! you have passed the verification\n\n");
break;
}
}
system("pause");
}
GS コンパイル保護メカニズムの原理はsecurity cookie、関数呼び出しごとに 1 つ追加することです。その前security cookieに、メモリ領域に のコピーが。前の手順に従って関数の戻りアドレスがオーバーフローして上書きされた場合、これも同様に行われます。関数が戻る前に、システムはこれをメモリに保存されているコピーと。両者が矛盾する場合、それは破棄されていることを意味し、システムはただちに例外をスローしてプログラムの実行を停止します。EBP.datasecurity cookiesecurity cookiesecurity cookiesecurity cookie
VS 7.0以降、すべての VS はデフォルトで GS を有効にしています。次に、この GS をオフにして比較してみます。
GSをオフIDAに
デフォルトのバージョンとGSをオフにした後のバージョンを比較してみましょう
GS は関数を呼び出す前にもう 1 つ生成しますsecurity cookie
関数が戻る前にもう 1 ステップ: チェックしてくださいsecurity cookie
RTCの仕組み
RTC はプログラムをコンパイルするときのセキュリティ オプションVisual Studioです
RTC 機構の原理は、VS のCheckStackVars関数CheckStackVarsローカル データへのアクセスが範囲外にあるCCかどうかをint 3プログラムの実行段階で、配列がオーバーフローすると、バッファ オーバーフローが発生した場合、_RTC_CheckStackVars配列の前後の境界が変更されたかどうかがチェックされ、変更が発生すると、プログラムは例外をスローし、どの配列がオーバーフローしたかを確認するプロンプトを表示します。
GS制御実験と同様に、RTCチェックをONにしたプログラムと、RTCチェックを行わなかったプログラムもコンパイルしました。
静的分析のために 2 つのプログラムを IDA にドラッグしてみましょう
オリジナルのバージョンと比較して、RTC メカニズムには初期化フェーズで 2 つの場所が追加されています。sub esp, 40Chこのステップでは、RTC によって導入された関数にスタック スペースを割り当て、予約されているすべてのスタック スペースを初期化します。cc
main 関数内では、配列に関係する操作の前に毎回、スタックとレジスタの正確性をチェックする__RTC_CheckEspためにesp。たとえば、scanf関数が入力したデータを配列Str1に格納する前に、関数が 1 回呼び出されます。Password
プログラムの他の関数の配列操作の前にも、__RTC_CheckEspこの
プログラムの最後で、元のプログラムと比較して、RTC メカニズムは、配列バッファーのオーバーフローを防ぐために、上記の方法で配列の境界をチェックする_RTC_CheckStackVars関数
次に、x32DBG を使用してこれら 2 つのプログラムを動的にデバッグし、メモリに移動して RTC の機能を確認します。
まず RTC 保護のないプログラムを見てみましょう
main 関数にブレークポイントを作成し、ここで直接実行します
scanf 関数の後にブレークポイントを作成し、入力データが存在する場所を確認します。
入力777777
ebp+408ここの場所はpasswordメモリ内の場所です
思い出に行って見てみよう
次に、RTC を有効にしてプログラムを動的にデバッグします。RTC メカニズムがプログラムにいくつかの機能を「何もないところから」作成することがわかります。これらの機能は、上記の保護機能です。
また、同じものを入力し777777、メモリに移動して次passwordの構造を確認します。
passwordRTC を使用しない元のプログラムと比較すると、メモリの位置近くに多くのものが存在することが明確にわかります。ccこれは前に述べたことです。バッファ オーバーフローとデータの範囲外アクセスを保護するccためRTC です。働き方
GS および RTC メカニズムは、基本的に、プログラムをコンパイルするためのデフォルトのオプションになっています。Windows プラットフォームでは、この種のメカニズムは、Linux Canary メカニズムに対してベンチマークされています。セキュリティ メカニズムは、浅いものから深いものまであります。次に、さまざまな CTF プラットフォームに移動して、 PWN トピックを実行する NX とカナリア保護は基本的にデフォルトで有効になっていることがわかります. この観点から, GS と RTC の原理分析は依然として非常に重要です. 原理を学んだ後にのみ、将来そのようなセキュリティ メカニズムをバイパスできます.統合する時間