みんな!私はこのようなプログラム(usemallocを)持っているLD_PRELOADedライブラリと子プロセス
画像:
#include <stdio.h>
#include <stdlib.h>
#define USER_BYTES_SIZE 100
int main(void){
char* userbytes = (char*)malloc(USER_BYTES_SIZE*sizeof(char));
if(!userbytes)
return 1;
for(int i = 0; i <= USER_BYTES_SIZE; i++){ // "i <= USER_BYTES_SIZE" leads to an off-by-one memory overrun.
userbytes[i] = 0;
}
return 0;
}
あなたは、メモリのオーバーフローにつながるオフ対1のバグがあることがわかるよう
。実行時にこのようなバグを検出したい。 LD_PRELOADedライブラリは私の仕事を行うのに適しています。私はlibhijack.soというライブラリを作成して、実際のmalloc の呼び出しを乗っ取って、実際のmallocを呼び出して、実際のmallocでalloctされたメモリストリップの端に赤いゾーンを追加する私のカスタムmallocの呼び出しと置き換えました。このようなlibhijack.soのコード:void* (*real_malloc) (size_t size);
void* malloc(size_t size){
real_malloc = ((void*)(*)(size_t))dlsym(RTLD_NEXT, "malloc");
void* allocbytes = (void*)real_malloc(size + 4); //put 2 bytes at each end, call them red zones
return (allocbytes + 2);
}
私は、このコマンドを使用してライブラリとメインプログラムを実行します。メモリへのアクセスは、赤のゾーンに存在する場合、私はそれらを検出します次に
LD_PRELOAD=./libhijack.so ./usemalloc
をし、メモリオーバーフローのバグとみなします。
このLD_PRELOADソリューションは、メインプロセスにmallocの呼び出しが含まれていても、フォークされた子プロセスがそれを実行すると失敗します。例えば
次のように、私たちは「usemalloc」を変更します。
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h> // +
#define USER_BYTES_SIZE 100
int main(void){
pid_t child = fork();
if(child < 0)
exit(1);
if(child == 0){ //child process
char* userbytes = (char*)malloc(USER_BYTES_SIZE*sizeof(char));
if(!userbytes)
return 1;
for(int i = 0; i <= USER_BYTES_SIZE; i++){ // "i <= USER_BYTES_SIZE" leads to an off-by-one memory overrun.
userbytes[i] = 0;
}
}
else { //the current process
wait(NULL);
}
return 0;
}
子プロセスで発生したオーバーフローのバグがLD_PRELOADedライブラリによって検出されることはありません。
私の質問は、LD_PRELOADedライブラリを使用して子プロセスのオーバーフローのバグを検出するにはどうすればいいですか?それは(LD_PRELOADedライブラリを使用して)可能ですか?そうでない場合、代替手段はありますか? 何か提案が評価されました!!!
コンパイル時に 'valgrind'(&ASANオプション)を使用することを検討しましたか?これは、おそらくLDPRELOADというトリックを使わずに、すでに望むもののほとんどを提供します。 –
valgrindまたはpinが私の計測には重すぎます。 LD_PRELOADのような軽量なソリューションが興味深い機能を乗っ取りたいだけです。とにかく、感謝のために感謝! –
信頼性の高い軽量ソリューションはありません。そのようなバッファオーバーフローのバグに対するハードウェアの支援はなく、コンパイラにパッチを適用する必要があります。 ASANと最近のGCC(future 4.8)やClang(3.2)の最近の取り組みを参照してください。 –