アカウント名:
パスワード:
（今は知ってる人がいるかどうかは知らないけど）アパチコモンズて「100% Pure Java」でしょ？そんなコードでもネイティブ・システムに脆弱性をもたらすのなの？
消せるファイルを手当たり次第に消したり逆に書き込めるパーティションを埋めたり。
今回のはサンドボックス有効なら影響ないけど、普通は意図したときには Runtime.getRuntime().exec("rm -rf /"); したいというのの裏返しで脆弱性があれば許可された範囲内でも充分問題になる
Collections で、そんなことすんのかなぁ？
任意のコードが実行出来るので、何処の脆弱性かは関係ないんじゃ
それを言い出したら、科学・技術計算用ライブラリーでも、exec とからやっていいじゃん？今回の事例は、データベースにアクセスするとか、組み込み機器の制御をするとかじゃない、純粋なデータ処理だけのライブラリーであるはずの Collections だったから、exec とかはないだろうってゆう、想像したんだよ。
お前は何を言ってるんだ・・・
# 本来の用途と脆弱性によって可能になる挙動を一緒くたにするんじゃない
そんなこと百も承知だけどね。例えば「リスト構造」を実装するのにネイティブなプロセスにアクセスしたりせずに、ふつうに Java 言語内で閉じるような実装にするって感覚だよ。それって普通の感覚じゃないの？
機能を実現する方法がいくつもある。20メートル隣りの家に行くにしても、素直に歩いて行くのもいいし、途中で自動車を使うのもいい。だけど普通なら歩いて行くだろう。目的の家が10km離れてるんでも、歩いって行ってもいいし、自動車を使ってもいい。でも大概は自動車などの乗り物を使うだろう。こんなふうに、機能を実現する方法はいくつもあっても、現実には、大よそ決まった方法が使われるものでしょう。自分の感覚だと、Collections の機能を実現するのに、Java で完結しない方法（非 100% Pure Java な方法）は使わないんじゃないかと思ったわけなんだよっ。そんな素朴な意見を理解できないのかなあ？
「ふつうに Java 言語内で閉じるような実装にする」という意図と、結果として「閉じるような実装になった」かどうかに乖離があるから脆弱性というものが生まれるのだけれど。
クラス毎等でMAC [wikipedia.org]等のアクセス制御が設定されているならともかく、任意コード実行される場合はJAVA VMで出来る事は何でも出来てしまいます。
あぁ、そういう意味か。
「なんでCollection実装すんのにこんな脆弱性が入り込む余地があるんだよ」って事ね。
まぁ、javaに関してはもう無理やりな実装してる部分があると個人的に思ってるので（Genericsとか内部はObjectのリストだったりするじゃない）その辺も不思議ではない。
つかメモリを効率よく使うリストなんて参照の連鎖だからねぇ。ほとんどポインタの親戚みたいなもんだからなぁという印象。
脆弱性で任意のPure Javaのコードが実行出来る結果として、Pure Javaな攻撃コードからネイティブのプロセス起動出来るだけ。Collectionsで何で脆弱性発生するんだよって感覚自体は理解できるが、Java言語内で閉じてるかどうかと安全かどうかは直行してると認識しないと危ないよ。
別に100% PureなJavaでも任意のコード実行できる脆弱性は起き得るし、というかそれは100% Pureかどうかには関係ない。Collectionsが100% PureなJavaだったとしても任意のコードを実行できる脆弱性の原因には「なり得る」ので。
ちなみに、補足ですが、「100% Pure Java」の定義では、環境に依存するコードを含まないことが条件なので、Runtime.exec などを含むこーどは、「標準 Java API だけを使うコード」だとしても「100% Pure Java なコード」ではありません。
いちお、http://sp.e-words.jp/w/100-_Pure_Java.html [e-words.jp]
「100% Pure Java 規格」なら、そういうことはありません。「100% Pure Java 規格」を満たしているかどうかは、厳密にいえば （当時の）Sun に認定してもらう必要はありますが･･･。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
100% Pure Java でも？ (スコア:1)
（今は知ってる人がいるかどうかは知らないけど）アパチコモンズて「100% Pure Java」でしょ？そんなコードでもネイティブ・システムに脆弱性をもたらすのなの？
Re: (スコア:0)
消せるファイルを手当たり次第に消したり逆に書き込めるパーティションを埋めたり。
Re: (スコア:0)
今回のはサンドボックス有効なら影響ないけど、普通は意図したときには Runtime.getRuntime().exec("rm -rf /"); したいというのの裏返しで脆弱性があれば許可された範囲内でも充分問題になる
Re: (スコア:0)
Collections で、そんなことすんのかなぁ？
Re: (スコア:0)
任意のコードが実行出来るので、何処の脆弱性かは関係ないんじゃ
Re: (スコア:0)
それを言い出したら、科学・技術計算用ライブラリーでも、exec とからやっていいじゃん？今回の事例は、データベースにアクセスするとか、組み込み機器の制御をするとかじゃない、純粋なデータ処理だけのライブラリーであるはずの Collections だったから、exec とかはないだろうってゆう、想像したんだよ。
Re: (スコア:0)
お前は何を言ってるんだ・・・
# 本来の用途と脆弱性によって可能になる挙動を一緒くたにするんじゃない
Re: (スコア:0)
そんなこと百も承知だけどね。例えば「リスト構造」を実装するのにネイティブなプロセスにアクセスしたりせずに、ふつうに Java 言語内で閉じるような実装にするって感覚だよ。それって普通の感覚じゃないの？
Re: (スコア:0)
機能を実現する方法がいくつもある。20メートル隣りの家に行くにしても、素直に歩いて行くのもいいし、途中で自動車を使うのもいい。だけど普通なら歩いて行くだろう。目的の家が10km離れてるんでも、歩いって行ってもいいし、自動車を使ってもいい。でも大概は自動車などの乗り物を使うだろう。こんなふうに、機能を実現する方法はいくつもあっても、現実には、大よそ決まった方法が使われるものでしょう。自分の感覚だと、Collections の機能を実現するのに、Java で完結しない方法（非 100% Pure Java な方法）は使わないんじゃないかと思ったわけなんだよっ。そんな素朴な意見を理解できないのかなあ？
Re:100% Pure Java でも？ (スコア:1)
「ふつうに Java 言語内で閉じるような実装にする」という意図と、結果として「閉じるような実装になった」かどうかに乖離があるから脆弱性というものが生まれるのだけれど。
Re: (スコア:0)
クラス毎等でMAC [wikipedia.org]等のアクセス制御が設定されているならともかく、任意コード実行される場合はJAVA VMで出来る事は何でも出来てしまいます。
Re: (スコア:0)
あぁ、そういう意味か。
「なんでCollection実装すんのにこんな脆弱性が入り込む余地があるんだよ」って事ね。
まぁ、javaに関してはもう無理やりな実装してる部分があると個人的に思ってるので
（Genericsとか内部はObjectのリストだったりするじゃない）
その辺も不思議ではない。
つかメモリを効率よく使うリストなんて参照の連鎖だからねぇ。ほとんどポインタの親戚みたいなもんだからなぁという印象。
Re: (スコア:0)
脆弱性で任意のPure Javaのコードが実行出来る結果として、Pure Javaな攻撃コードからネイティブのプロセス起動出来るだけ。
Collectionsで何で脆弱性発生するんだよって感覚自体は理解できるが、Java言語内で閉じてるかどうかと安全かどうかは直行してると認識しないと危ないよ。
Re: (スコア:0)
別に100% PureなJavaでも任意のコード実行できる脆弱性は起き得るし、というかそれは100% Pureかどうかには関係ない。
Collectionsが100% PureなJavaだったとしても任意のコードを実行できる脆弱性の原因には「なり得る」ので。
Re: (スコア:0)
ちなみに、補足ですが、「100% Pure Java」の定義では、環境に依存するコードを含まないことが条件なので、Runtime.exec などを含むこーどは、「標準 Java API だけを使うコード」だとしても「100% Pure Java なコード」ではありません。
Re: (スコア:0)
いちお、
http://sp.e-words.jp/w/100-_Pure_Java.html [e-words.jp]
Re: (スコア:0)
「100% Pure Java 規格」なら、そういうことはありません。「100% Pure Java 規格」を満たしているかどうかは、厳密にいえば （当時の）Sun に認定してもらう必要はありますが･･･。