整数がどのように悪用されるかについての詳細な説明を誰かが持っていますか? 私はその概念について多くのことを読んでおり、それが何であるかを理解しており、バッファオーバーフローを理解していますが、整数をその定義されたメモリ....
5 に答える
それは間違いなく悪用可能ですが、もちろん状況によって異なります。
古いバージョンのsshには整数オーバーフローがあり、リモートで悪用される可能性がありました。このエクスプロイトにより、sshデーモンはサイズ0のハッシュテーブルを作成し、そこにいくつかの値を格納しようとしたときにメモリを上書きしました。
ssh整数オーバーフローの詳細:http ://www.kb.cert.org/vuls/id/945216
整数オーバーフローの詳細:http://projects.webappsec.org/w/page/13246946/Integer%20Overflows
私は 60 年代後半に IBM 360/40 で APL/370 を使用していました。APL は、基本的にすべてが多次元配列である言語であり、N 次元から M 次元への再形成など、配列を操作するための驚くべき演算子があります。
当然のことながら、N 次元の配列には 1..k のインデックス境界があり、軸ごとに異なる正の k があり、k は合法的に常に 2^31 未満でした (32 ビット符号付きマシン語の正の値)。ここで、N 次元の配列には、メモリ内に割り当てられた場所があります。軸に対して大きすぎるインデックスを使用して配列スロットにアクセスしようとすると、APL によって配列の上限に対してチェックされます。そしてもちろん、これは N == 1 である N 次元の配列に適用されます。
APL は、RHO (array reshape) 演算子で信じられないほど愚かなことをしたかどうかをチェックしませんでした。APL では、最大 64 次元しか許可されませんでした。したがって、1 ~ 64 次元の配列を作成できます。配列の次元がすべて 2^31 未満の場合、APL はそれを行います。または、 65次元の配列を作成することもできます。この場合、APL は間抜けで、驚くべきことに 64 次元の配列を返しましたが、軸のサイズをチェックできませんでした。(これは、「整数オーバーフローが発生した」場所で有効です)。これは、軸のサイズが 2^31 以上の配列を作成できることを意味していましたが、符号付き整数として解釈され、負の数として扱われていました。
そのような配列に適用される右の RHO 演算子の呪文は、次元数を 1 に減らすことができ、上限は "-1" になります。このマトリックスを「ワームホール」と呼びます (理由はすぐにわかります)。このようなワームホール アレイには、他のアレイと同様に、メモリ内に場所があります。しかし、すべての配列アクセスは上限に対してチェックされます...しかし、配列境界チェックは、APLによる符号なし比較によって行われることが判明しました。したがって、WORMHOLE[1]、WORMHOLE[2]、... WORMHOLE[2^32-2] に異議なくアクセスできます。実際には、マシンのメモリ全体にアクセスできます。
APL には、配列に値を入力できる配列代入演算もありました。したがって、WORMHOLE[]<-0 はすべてのメモリをゼロにします。
APL ワークスペース、APL インタープリター、およびタイムシェアリングを可能にする APL の重要な部分 (当時はユーザーから保護されていなかった) を含むメモリが消去されたため、これを行ったのは 1 回だけです... ターミナル ルームは機械的に非常にうるさい (2741 個の Selectric APL 端末があった) 通常の状態から、約 2 秒で完全に静かになりました。ガラス越しにコンピューター室に入るのが見えた.370のライトがすべて消えたので、オペレーターが驚いて見上げるのが見えた. たくさん走り回った。
当時は面白かったのですが、口を閉ざしていました。
多少の注意を払っていれば、明らかに任意の方法で OS を改ざんできた可能性があります。
一般的なケースは、提供される入力の数を要求し、その制限を適用しようとすることで、バッファオーバーフローを防ぐコードです。私が2^30+10の整数を提供していると主張する状況を考えてみてください。受信システムは、4 *(2 ^ 30 + 10)= 40バイト(!)のバッファーを割り当てます。メモリの割り当てが成功したので、続行できます。11 <2 ^ 30 + 10であるため、11番目の入力を送信しても入力バッファーチェックは停止しません。それでも、実際に割り当てられたバッファをオーバーフローさせます。
変数の使い方次第です。入力整数に追加した整数に基づいてセキュリティ上の決定を下さない場合 (敵対者がオーバーフローを引き起こす可能性がある場合)、どのように問題が発生するかは考えられません (ただし、この種のものは微妙な場合があります)。
繰り返しになりますが、ユーザー入力を検証しない次のようなコードをたくさん見てきました (ただし、この例は不自然です)。
int pricePerWidgetInCents = 3199;
int numberOfWidgetsToBuy = int.Parse(/* some user input string */);
int totalCostOfWidgetsSoldInCents = pricePerWidgetInCents * numberOfWidgetsToBuy; // KA-BOOM!
// potentially much later
int orderSubtotal = whatever + totalCostOfWidgetInCents;
-$21,474,817.95 で 671,299 個のウィジェットを販売する日まで、すべてが厄介です。ボスは動揺するかもしれません。
元の質問についてわかったことをすべて要約したかっただけです。
私が混乱した理由は、バッファ オーバーフローがどのように機能するかを知っており、それを簡単に悪用する方法を理解できるからです。整数オーバーフローは別のケースです。整数オーバーフローを悪用して任意のコードを追加したり、アプリケーションのフローを強制的に変更したりすることはできません。
ただし、整数をオーバーフローさせることは可能です。これは、たとえば、メモリの任意の部分にアクセスするために配列にインデックスを付けるために使用されます。ここから、誤ってインデックス付けされた配列を使用してメモリをオーバーライドし、アプリケーションの実行が悪意のあるものに変更される可能性があります。
お役に立てれば。