glibc fnmatchの脆弱性：どのようにしてこの脆弱性を公開しますか？

Question

glibc-2.9を実行している私たちの64ビットシステムの脆弱性を検証する必要があります。

http://scarybeastsecurity.blogspot.in/2011/02/i-got-accidental-code-execution-via.html

上記のリンクは渡されたときにマジックナンバーが明らかに任意のコード実行につながるスクリプトを提供します。しかし私のシステム上で試してみると、何も起きていないようです。 何か間違っていますか？脆弱性が存在する場合、システムがクラッシュしますか？偶発的なコードの実行を検出するにはどうすればよいですか？

Answer 1

64ビットマシンでこの問題に遭遇した場合は、元のコードを模倣する必要がありますが、スタックを64ビットマシンにラップする番号を指定する必要があります。提供元の数は以下のとおりであった：

$ bc 
z=1073741796 
z+28 
1073741824 
(z+28)*4 
4294967296 
2^32 
4294967296 
quit 
$ 

そこで、入力された番号を記述する一つの方法は、（ULONG_MAX - 112）である/ 4

64ビットマシンのアナログ番号であります4611686018427387876：

$ bc 
x=2^64 
x 
18446744073709551616 
y=x/4 
y 
4611686018427387904 
y-28 
4611686018427387876 
quit 
$ 

しかし、この作業のチャンスを立って、あなたがstrtroull()または類似のものを使用することが報告コードを変更する必要があると思います。 atoi()は通常32ビットの整数に制限されており、上記の64ビットの数字には使用できません。コードも含まれています

num_as = atoi(argv[1]); 
if (num_as < 5) { 
    errx(1, "Need 5."); 
} 
p = malloc(num_as); 

どこnum_asがsize_tとpがchar *です。だから、malloc()は膨大なスペース（ほぼ4 EiB）にできる必要があります。ほとんどの人は、バッキングのためのディスク容量があっても、マシン上に十分な仮想メモリを持っていません。さて、たぶん多分、おそらく、Linuxはあなたが過度にコミットする（そしてOOM Killerを後で起動させる）が、malloc()は失敗する可能性が高いでしょう。

64ビットシステム（まだ）に影響を与えない方法で、32ビットシステムに関連して影響を与える他の機能がありました。

64ビットマシンでそれを再現するには、おそらく32ビットのコンパイルが必要です。その後、風があなたの後ろにあり、関連するソフトウェアの適切な古いバージョンがあれば、おそらくそれを再現することができます。

Answer 2

64ビットマシンで実行している場合、バグの元の状態は適用されません。 Chrisのブログでもわかるように、彼は32ビットのUbuntu 9.04システムを使用しています。攻撃は、スタックポインタを32ビットアドレス空間について折り返してスタックの破損を引き起こすことに依存しています。

私はglibc 2.5で64ビットシステムで簡単に試しましたが、クラッシュではなくmalloc（）の失敗を見ました。

$ ./a.out 3000000000 
a.out: malloc() failed. 

偶発的なコードの実行を特定する方法を尋ねました。悪用/ペイロードを持たないおもちゃプログラムでは、CPUがスタックの迷った部分を "実行"しようとしたときにSIGSEGV、SIGILL、またはSIGBUSのいずれかが見えることが予想され、それぞれのエラーとして表示されますシェルからのメッセージ。