アカウント名:
パスワード:
トランポリンコードに対しては、Solar Designer(OpenWall) と同じ ELF拡張ビット があって、バイナリごとに制限を無視 させられるんですが、それではダメですか?
OpenWallでは、そもそも JAVA自体が、これを設定しないと動かない はずなんですが…
-- 大外しかもしれないのでAC~って最初からアカウントないやん
たとえば、何らかの認証をするプログラムでバッファオーバーフローがあったとします。
0x00123456 : 認証関数をコールしてる所のアドレス 0x00123478 : 認証OKの場合の処理のアドレス
という形で、認証関数で次のようにバッファが取られている場合
char buf[10];
スタックは
低位← →高位 buf[10] 0x00123456
となっているはず。(かなり省略してますが) ここで、buf[10]に14byte書き込んで直後の0x00123456を0x00123478に書換えできれば認証をスルーする事ができる(事にする)
この書換えが本当にできるかどうかですが、x86というかリトルエンディアンの場合、0x00123456は0x56 0x34 0x12 0x00という順番でメモリ上にあるので、0x78 0x34 0x12 0x00 が書ければ良い訳ですが、0x00が明示的に書けなくてもASCIIZ文字列(文字列の終端が\0)である、たとえばC言語などでは、0x78 0x34 0x12まで書いたら、勝手にその後に0x00を補ってくれてしまいます。 ですから、それ程難しい話ではないような予感。
しかし、スタック内のリターン・アドレスやヒープ内の関数 ポインタを狙った純粋なオーバーフロー攻撃はすべて阻止できると思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
exec-shield (スコア:1, 参考になる)
exec-shield (スコア:1, 参考になる)
trampoline code (スコア:1, 参考になる)
そのあたりがこのパッチでどう解決しているのかと思ったら、特定アドレスで起こしたsegmentation faultがsigreturnとして機能するなんて仕組みになってるんですね。豪快というか泥臭いというか…。
%00 (スコア:1)
レアケースになるでしょうが、デコード後に '\0' になり、その時点でバッファオーバーフローが起き得る Webサーバであればアウトではないでしょうか。
ただ、外部からのバッファオーバーフローの大半のケースにおいて効果が期待できるし、Oracle みたいな商用アプリケーションも恩恵を受けられるので、この実装は大歓迎です。
JIT処理系が書きにくくなるなあ (スコア:1)
まつもと ゆきひろ /;|)
Re:JIT処理系が書きにくくなるなあ (スコア:1, 興味深い)
トランポリンコードに対しては、Solar Designer(OpenWall) と同じ ELF拡張ビット があって、バイナリごとに制限を無視 させられるんですが、それではダメですか?
OpenWallでは、そもそも JAVA自体が、これを設定しないと動かない はずなんですが…
--
大外しかもしれないのでAC~って最初からアカウントないやん
Re:JIT処理系が書きにくくなるなあ (スコア:2, 興味深い)
ただ、exec-shieldのあるプラットフォームを判別して、chstkするというのはポータブルなコードとしては面倒なことですよね。
まつもと ゆきひろ /;|)
Re:JIT処理系が書きにくくなるなあ (スコア:0)
Re:JIT処理系が書きにくくなるなあ (スコア:0, 参考になる)
っつ~か、Cのsignalの処理などをアセンブラ(マシン語)にコンパイルする時に出てくる話です>トランポリン
Re:JIT処理系が書きにくくなるなあ (スコア:0)
Buffer Overflow対策 (スコア:0)
> (0x00が表現できない)ASCII文字を使ったバッファオーバフローでは
> ライブラリのルーチンへジャンプが難しくなっている。
わたしゃix86のアセンブラ知らないのですが、間接ジャンプ命令だけで、回避できませんか?この対策。
Re:Buffer Overflow対策 (スコア:2, 興味深い)
あと、コードを持ち込むのではなく、コードの一部をスキップさせたりは簡単にできそうな気がします。
たとえば、何らかの認証をするプログラムでバッファオーバーフローがあったとします。
0x00123456 : 認証関数をコールしてる所のアドレス
0x00123478 : 認証OKの場合の処理のアドレス
という形で、認証関数で次のようにバッファが取られている場合
char buf[10];
スタックは
低位← →高位
buf[10] 0x00123456
となっているはず。(かなり省略してますが)
ここで、buf[10]に14byte書き込んで直後の0x00123456を0x00123478に書換えできれば認証をスルーする事ができる(事にする)
この書換えが本当にできるかどうかですが、x86というかリトルエンディアンの場合、0x00123456は0x56 0x34 0x12 0x00という順番でメモリ上にあるので、0x78 0x34 0x12 0x00 が書ければ良い訳ですが、0x00が明示的に書けなくてもASCIIZ文字列(文字列の終端が\0)である、たとえばC言語などでは、0x78 0x34 0x12まで書いたら、勝手にその後に0x00を補ってくれてしまいます。
ですから、それ程難しい話ではないような予感。
Re:Buffer Overflow対策 (スコア:0)
元ACさんの「間接ジャンプで・・・」というのとは別の話ね。
Re:Buffer Overflow対策 (スコア:0)
常にオーバーフローが起こるスタック上のアドレスが固定ならね。
Re:Buffer Overflow対策 (スコア:0)
Re:Buffer Overflow対策 (スコア:0)
スタック・ヒープのどちらかです。
このどちらかがくだんのASCII-armor領域になければ、セグメンテーションを利用してジャンプ命令を実行させないことはできるのでは。
Re:お約束ですが (スコア:0)
しきい値 (スコア:0)
Re:お約束ですが (スコア:0)
「どうでもいいことだけど」
だったら書き込みしなくても。
Re:お約束ですが (スコア:0)
知れない。
だから親切心で書いたんじゃないかな。
Re:お約束ですが (スコア:0)
「気にしてないからね」という編集者へのフォローのつもりで「どうでもいい」と書いたのですが、ちょっとぶっきらぼうな表現だったかもしれません。
でも直したほうが後の人が読みやすいかなと思ったので書かせていただきました。
前者の「ライブラリ」の方は普及している外来語ではあるものの、一応専門用語なので、違う分野(この分野を知らない)人が読んだと