アカウント名:
パスワード:
ファイルの圧縮や展開がセキュリティに影響するような状況ってどういう感じなのでしょうか。 イメージとしては、圧縮や展開は単純にデータの繰り返し部分や不合理な部分を置換する作業であって、 不正コードの実行なんかとは無関係に思うのですが。
ライブラリには影響しないのかもしれないけど、httpdのdeflateに使われていたらアップロードされたモノで攻撃が成立するかもしれない。
mod_deflateは圧縮しかしないから関係ない [srad.jp]そうだよ。どっちもすば洞が付いてるあたり、いかにモデレータが脊髄反射しかしていないかよくわかる。# そしてこのコメントは脊髄反射でフレームのもとや荒らしにされる予定なのでAC
その昔、Solarisかなんかのアーカイバがワークメモリをゼロクリアせず使ってたところ、 権限チェックをする関係上/etc/passwd(違ったかも)が直前に読み込まれてた領域で、 中身が出力されてしまうセキュリティホールがあったとセキュアコーディングに関する書籍で 読んだ記憶があります。
という訳で、malloc()した領域を未初期化部分までファイル出力しただけで状況によっては セキュリティホールになりうるので注意が必要ですね。
#ファイル自体は過去の遺物で実際には利用されておらず、パスワード部分もハッシュされた #状態で格納されていたので直接の実害はなかったとか。
まさにその例通りのセキュリティホールが発生した問題で、確かにその主張は正当だと思うんですが、 それはセキュアなOSの実装として望ましいという話であってコードの側で対策しなくてもよい(=OSの不手際) か、というとそれは別の話ではないかと思います。
領域をクリアするにもコストがかかる訳で、このコストの回避を自前で対処することと引き替えに 行いたいかもしれない。その選択肢はプログラマの手にゆだねてもいいんじゃないかと。 実際、この問題の回避手段としては危険なメモリ領域はfree()する前にゼロクリアしておく、というの でも十分可能ではないでしょうか。 OSレベルでしか対処できない、というのなら確かにOSのセキュリティホールだと思うんですけどね。
もちろんプログラマがポカミスをすることもあると思うのでユーザの選択としてメモリクリアを行って くれるセキュアなOSを採用する、という手段はあると思うのですが、組み込み用OSや発展途上のOSなど その優先順位や状況によってセキュアでないOSが世の中から無くなることはないように思いますし、 その選択もユーザが必要に応じて行うべきことだと思います。
ですので、この問題はアプリプログラマ側からみると環境依存の話何じゃないかと。 自分の書いたコードが利用される環境が完全にわかっているなら環境依存でもいいと思うのですが、 非環境依存のセキュアコーディング、という視点で見ると今回の問題は危険な領域は開放する前に クリアしておくべき、ファイル出力するような領域もクリアしておくのが望ましいとかそのあたり なのじゃないかなと。
#一プログラマとしては、何も気をつけなくていい楽ちん環境が当たり前になってくれるとうれしいのですけどね～。 #何か問題起きてもOSのせいにできちゃうような。OS開発者はたまったもんじゃないと思いますけど。
malloc(初期化しない)/calloc(初期化する）に相当するような初期化するfreeがOSにあればそれを使うべきだし、無い以上は必要ならアプリケーション側で初期化する必要がある。
OSレベルで実装されていようがいまいが（実装されていれば「それはいいＯＳですね」というだけのこと）、結局アプリケーション側で考慮しないといけないのは同じ。
オフトピだけど続けてみよう。そのバグは昔踏んだことがあって、SunOS4のtarで固めたファイルを友人に送ったら「ホームディレクトリのディレクトリエントリが見える」って言われた。# はずかしいファイル名が含まれていたかどうかは秘密だ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
不思議 (スコア:0)
ファイルの圧縮や展開がセキュリティに影響するような状況ってどういう感じなのでしょうか。
イメージとしては、圧縮や展開は単純にデータの繰り返し部分や不合理な部分を置換する作業であって、
不正コードの実行なんかとは無関係に思うのですが。
Re: (スコア:0, すばらしい洞察)
ライブラリには影響しないのかもしれないけど、httpdのdeflateに使われていたらアップロードされたモノで攻撃が成立するかもしれない。
Re: (スコア:2, 参考になる)
mod_deflateは圧縮しかしないから関係ない [srad.jp]そうだよ。
どっちもすば洞が付いてるあたり、いかにモデレータが脊髄反射しかしていないかよくわかる。
# そしてこのコメントは脊髄反射でフレームのもとや荒らしにされる予定なのでAC
Re:不思議 (スコア:4, 興味深い)
その昔、Solarisかなんかのアーカイバがワークメモリをゼロクリアせず使ってたところ、
権限チェックをする関係上/etc/passwd(違ったかも)が直前に読み込まれてた領域で、
中身が出力されてしまうセキュリティホールがあったとセキュアコーディングに関する書籍で
読んだ記憶があります。
という訳で、malloc()した領域を未初期化部分までファイル出力しただけで状況によっては
セキュリティホールになりうるので注意が必要ですね。
#ファイル自体は過去の遺物で実際には利用されておらず、パスワード部分もハッシュされた
#状態で格納されていたので直接の実害はなかったとか。
スルースキル：Lv2
Keep It Simple, Stupid!
Re:不思議 (スコア:3, 参考になる)
気にすることに越したことはありませんが、C2レベルのセキュリティ基準も守れてないことになるので
今のOSではありえないでしょう。
例えば、rootで動いているdaemonが/etc/shadowの内容の書かれたメモリ内容をfree()したとして
一般ユーザが同じアドレスを確保した場合に/etc/shadowの中身が見えてると、いくらファイルで
パーミッションを600にしても意味がないということになるのでそれはセキュリティホールになるよね。
#今のOSで見つけたらそれは危険なセキュリティホールなので報告すべきだと思う
Re:不思議 (スコア:2, 興味深い)
まさにその例通りのセキュリティホールが発生した問題で、確かにその主張は正当だと思うんですが、
それはセキュアなOSの実装として望ましいという話であってコードの側で対策しなくてもよい(=OSの不手際)
か、というとそれは別の話ではないかと思います。
領域をクリアするにもコストがかかる訳で、このコストの回避を自前で対処することと引き替えに
行いたいかもしれない。その選択肢はプログラマの手にゆだねてもいいんじゃないかと。
実際、この問題の回避手段としては危険なメモリ領域はfree()する前にゼロクリアしておく、というの
でも十分可能ではないでしょうか。
OSレベルでしか対処できない、というのなら確かにOSのセキュリティホールだと思うんですけどね。
もちろんプログラマがポカミスをすることもあると思うのでユーザの選択としてメモリクリアを行って
くれるセキュアなOSを採用する、という手段はあると思うのですが、組み込み用OSや発展途上のOSなど
その優先順位や状況によってセキュアでないOSが世の中から無くなることはないように思いますし、
その選択もユーザが必要に応じて行うべきことだと思います。
ですので、この問題はアプリプログラマ側からみると環境依存の話何じゃないかと。
自分の書いたコードが利用される環境が完全にわかっているなら環境依存でもいいと思うのですが、
非環境依存のセキュアコーディング、という視点で見ると今回の問題は危険な領域は開放する前に
クリアしておくべき、ファイル出力するような領域もクリアしておくのが望ましいとかそのあたり
なのじゃないかなと。
#一プログラマとしては、何も気をつけなくていい楽ちん環境が当たり前になってくれるとうれしいのですけどね～。
#何か問題起きてもOSのせいにできちゃうような。OS開発者はたまったもんじゃないと思いますけど。
スルースキル：Lv2
Keep It Simple, Stupid!
Re:不思議 (スコア:1, 興味深い)
malloc(初期化しない)/calloc(初期化する）に相当するような初期化するfreeが
OSにあればそれを使うべきだし、無い以上は必要ならアプリケーション側で初期化
する必要がある。
OSレベルで実装されていようがいまいが（実装されていれば「それはいいＯＳです
ね」というだけのこと）、結局アプリケーション側で考慮しないといけないのは同じ。
Re: (スコア:0)
Re:不思議 (スコア:1)
オフトピだけど続けてみよう。
そのバグは昔踏んだことがあって、SunOS4のtarで固めたファイルを友人に送ったら「ホームディレクトリのディレクトリエントリが見える」って言われた。
# はずかしいファイル名が含まれていたかどうかは秘密だ。