問題タブ [buffer-overflow]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c# - Java と C# のメモリ管理はどのように異なりますか?
私は2010 CWE/SANS Top 25 Most Dangerous Programming Errorsを読んでいましたが、エントリの 1 つはBuffer Copy without Checking Size of Inputです。この問題を防止または軽減する機能を備えた言語を使用することを提案し、次のように述べています。
たとえば、Java や Perl など、独自のメモリ管理を行う多くの言語は、バッファ オーバーフローの影響を受けません。Ada や C# などの他の言語では通常、オーバーフロー保護が提供されますが、プログラマは保護を無効にすることができます。
メモリ管理に関して、Java と C# が意味のある点で異なることを知りませんでした。Java はバッファ オーバーフローの影響を受けないのに、C# はオーバーフローからのみ保護するのはなぜですか? また、C# でこの保護を無効にするにはどうすればよいですか?
c - GCC、Windows XP、x86 でバッファ オーバーフロー エクスプロイトを作成する方法は?
上記のデモはここからです:
http://insecure.org/stf/smashstack.html
しかし、ここでは機能しません:
そして、著者は次のように考えていますが、なぜ8なのかわかりません。
少し計算すると、距離は 8 バイトであることがわかります。
呼ばれる私のgdbダンプ:
私の場合、距離は - = 5 のはずですが、うまくいかないようです..
ローカル変数に56バイトfunction
が必要なのはなぜですか?( )sub $0x38,%esp
visual-c++ - 「sprintf」メソッドのデフォルトのバッファ長はありますか?
VS 2008 を使用する C++ コンソール アプリケーションで、sprintf メソッドを使用して、ファイルに書き込みたい文字列にデータをフォーマットしました。入力は、さまざまな変数と値を持つ特定のメッセージです (例: Type 'int' and Value ' 10' / タイプ文字列と値 "abc" など) 2 つのメッセージを送信すると、完全に機能します。しかし、2 つ以上のメッセージを送信すると、0xC0000005: Access violation reading location 0xababababという実行時エラーが発生します。なぜこうなった?メソッド「sprintf」にデフォルトのバッファ長があるためですか?どうすればこの問題を克服できますか?
wcf - WCFコントラクトのバイト配列である[DataMember]はセキュリティ上の問題ですか?
サービスをバッファオーバーフロー攻撃にさらしていますか?もしそうなら、あなたはこれに対してどのように防御しますか?
c - 学生のバッファオーバーフローの図(Linux、C)
私の友達はCSの1年生の先生です。バッファオーバーフローの悪用を示したいと思います。しかし、最新のディストリビューションは単純なバッファオーバーフローから保護されています。
debianで(それを非難する)
現代の商用redhat
同じ検出器は、インターネットからのより合成的な例では失敗します。
最新の非GPLディストリビューションでバッファオーバーフローをどのように実証できますか(クラスにはDebianはありません)
どうしたらいいの
- スタック内のカナリアワードチェックを無効にしますか?
- strcpy / strcatのバリアントのチェックを無効にしますか?
- 作業バッファオーバーランを使用した例(プレーンC)を記述しますか?
c - バッファオーバーフローについて
私は倫理的なハッキングの世界に不慣れであり、最も重要なことの1つはスタックオーバーフローです。とにかく、char名[400]ステートメントを持つ脆弱なCプログラムをコーディングしましたが、401Aでプログラムを実行しようとすると、オーバーフローしませんが、私がフォローしている本はオーバーフローしなければならないと言っており、論理的な意味はそう言っているので、何が問題なのですか?
assembly - アセンブラの Printf が印刷されない
バッファオーバーフローを使用してプログラムをハックする宿題があります(逆アセンブルで、プログラムはC ++で書かれており、ソースコードを取得していません)。私はすでにそれを管理していますが、問題があります。画面にメッセージを出力する必要があるので、printf 関数のアドレスを見つけて、"HACKED" のアドレスと "%s" のアドレスの順でスタックにプッシュし、その関数を呼び出しました。呼び出されたコードは問題なく通過しましたが、何も出力されていませんでした。
プログラムの他の場所と同じように環境をシミュレートしようとしましたが、何か問題があるはずです。出力がないということで、私が何を間違っているのか分かりますか?どうもありがとう
編集:
このプログラムは、Windows XP SP3 32b で実行され、C++、Intel asm で記述されています。
「ハック」コードがあります
プログラムの冒頭:
私はアセンブラが初めてで、バッファオーバーフローのバグのためにヌルバイトがあってはならないので、このコードは本当に醜いです
c - バッファ オーバーランのヘルプが必要
絶対に理解できないバッファオーバーランがあります(Cで)。まず第一に、それはおそらく 10% 程度の確率でしか発生しません。毎回DBから引き出されるデータは、実行間でそれほど異なるようには見えません...少なくとも、いつ発生するかについて識別可能なパターンを見つけるのに十分な違いはありません。Visual Studio からの正確なメッセージは次のとおりです。
hub.exe でバッファ オーバーランが発生し、プログラムの内部状態が破壊されました。Break を押してプログラムをデバッグするか、Continue を押してプログラムを終了します。
詳細については、ヘルプ トピック「バッファ オーバーランの問題をデバッグする方法」を参照してください。
デバッグすると、コンパイラの /GS フラグからのものであると確信している壊れていることがわかり、__report_gsfailure()
これはヒープではなくスタックでのオーバーランであることも示しています。また、それが終了するときにこれをスローした機能もわかりますが、この動作を引き起こす可能性のあるものは何も見えません。この機能は長い間存在していました (10 年以上、若干の変更はありますが)私が知る限り、これは一度も起こったことはありません。
関数のコードを投稿したいと思いますが、かなり長く、多くの独自の関数/変数/などを参照しています。
私は基本的に、私が探していないものを探しているか、おそらく役立つツールを探しているだけです。残念ながら、私が見つけたほぼすべてのツールは、ヒープでのオーバーランのデバッグにしか役立ちません。私が間違っていない限り、これはスタック上にあります。前もって感謝します。
c - argv にジャンプしますか?
私はシェルコードを試していて、nop-slide テクニックを見つけました。buffer-size をパラメーターとして取り、次のようなバッファーを構築する小さなツールを作成しました。SC | SC | RET ]、NOP がバッファーの半分を取り、その後にシェルコードが続き、残りは (推測された) 戻りアドレスで埋められます。彼の有名な論文で説明されているツール aleph1 に非常に似ています。
私の脆弱なテストアプリは、彼の論文と同じです:
私はそれをテストしましたが、うまくいきます:
しかし、正直なところ、私には理由がわかりません。さて、保存された eip は意図したとおりに上書きされましたが、バッファのどこかにジャンプする代わりに、argv にジャンプしたと思います。
strcpy() が呼び出される前に、gdb は次のアドレスを表示しました。
little_array のアドレス:
strcpy() の後:
それで、ここで何が起こったのですか?私は604バイトのバッファを使用してlittle_arrayをオーバーフローさせたため、保存されたebp、保存されたeip、argc、および推測されたアドレス0xbffff458でargvを確実に上書きしました。
その後、戻った後、EIP は 0xbffff458 を指していました。しかし、little_buffer は 0xbfffefe8 にあり、1136 バイトの違いがあるため、little_array を実行していないことは確かです。stepiコマンドで実行を追跡したところ、0xbffff458 以降で NOP を実行し、シェルコードに到達しました。
なぜこれが起こっているのかよくわかりません。まず第一に、彼が私のシェルコードを little_array ではなく argv で実行するのは正しいですか? そして、ローダー(?) は argv をスタックのどこに配置しますか? argc の直後に続くと思っていたのですが、argc と 0xbffff458 の間に 620 バイトのギャップがあります。0xbffff1ec に保存されている eip のはるか上にあるアドレス 0xbffff458 の NOP-Pad に、彼が首尾よく「着陸」できるのはどうしてでしょうか?
誰かがこれを明確にできますか?なぜこれが機能しているのか、実際にはわかりません。私のテスト マシンは、ASLR のない Ubuntu 9.10 32 ビット マシンです。犠牲者には、execstack -s で設定された実行可能なスタックがあります。
前もって感謝します。