アカウント名:
パスワード:
そういうテクニックを使わないといけない状況でも、一旦shellcodeで/bin/shなどを立ち上げてしまえば、次は何でもできるようになりますので、結局「なんでもできる」ことになります。
かなり攻撃側にとっては「きびしー」ように見える状況であっても、大抵は「任意のコードが実行される」と表現しますし、それを狙うexploit codeも沢山あるかと思います。
ということで、確かにgniibeさまのおっしゃるとおりかと思います。
記名だと「クラックに必要な情報を具体的に公表した」とか言われそうで怖いんでACにさせていただきます。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
補足 (スコア:5, 参考になる)
補足すると、Reply-To, Cc, Bcc, Followup-To ヘッダに非 ascii 文字がある場合、内部コード(1.0では locale encoding)に変換した際に元の文字列より長くなる場合にバッファオーバーフローが発生します。
UTF-8 locale の場合はほぼ該当しますが、 EUC-JP でも、 K
Re:補足 (スコア:4, 参考になる)
むぅ。この言明はバッファオーバフローに関するセキュリティの問題に関してはミスリードだし、作っているほうとしてはそういう感もあると思うけど、対応する発言としてはあんまり望ましくないと思います。
セキュリティアドバイザリの文脈で「任意のコードが実行される」危険性というのは、もともとのソフトウェアとして書かれていないコードが送り込まれ、そこに制御が移るという可能性の指摘です。
ここでの問題は、悪意ある(ソフトウェアの作者でない)攻撃がもともとのソフト
Re:補足 (スコア:1, 興味深い)
そういうテクニックを使わないといけない状況でも、一旦shellcodeで/bin/shなどを立ち上げてしまえば、次は何でもできるようになりますので、結局「なんでもできる」ことになります。
かなり攻撃側にとっては「きびしー」ように見える状況であっても、大抵は「任意のコードが実行される」と表現しますし、それを狙うexploit codeも沢山あるかと思います。
ということで、確かにgniibeさまのおっしゃるとおりかと思います。
記名だと「クラックに必要な情報を具体的に公表した」とか言われそうで怖いんでACにさせていただきます。