アカウント名:
パスワード:
完璧でなければならないなんて前提がそもそも無茶すぎだろそーゆーのは「なんでも叩けるアンチに都合のいい詐欺手法」でしかないから
Appleの「審査してるからとにかく安全！！」みたいなのは利用者の警戒心を失わせて被害を拡大させるという面で問題だが、システム的な安全機構そのものは「やらないよりはやるだけまし」でいいんだよ
レビュアーの指摘を人格攻撃みたいに捉えて逆上する直情コーダーですか？
君の事？
穴が見つかったのなら塞がなければならないというだけの話だろ。誰が完璧でなければならないなんて言ってるよ。あーそれとも、Windowsは穴が見つかっても批判しちゃいけないという話ですかね?MSってやらないよりやるだけましって態度でセキュリティやってたんですね。ひどいっすねー#そんなわけないだろ。MSのセキュリティはかなりのもんだぞ。#アンチアップルのMS信者のフリしてMSディスってんじゃねえぞ
鉄壁ではない。Microsoft自身がそういってる。
https://support.microsoft.com/ja-jp/kb/2458544 [microsoft.com]>このようなセキュリティ緩和策テクノロジでは、脆弱性を悪用できないことは保証されません。>しかし、悪用の実行を可能な限り困難にするように機能します。
おしりにH付けると奴隷のように働いて、頭のE削ると滅びてしまう方を連想した。
#最初からオフトピ
>WoW64環境では実行時にプロテクトモードとロングモードを切り替えることが可能となっているが、これにより純粋な32ビット環境にはない攻撃手段が利用可能となる。
複雑化していくと穴もボコボコ出てしまうのは世の常とは言え。セキュリティ関係は暗い話しか最近見ないね。
そもそも32bitのASLRは弱くてブルートフォースで破れる [wikipedia.org]ので、セキュリティーを気にするなら32bitプロセスを使うべきではありません。
それはそうなんですけれど、（もはや言うまでもない前提の話）この話題は「今まで思われていた以上に脆弱なパターンがあるんだよ」っていう話なんじゃないですか？
これにより純粋な32ビット環境にはない攻撃手段が利用可能となる。
この部分。
それ以前に、ASLRはブラウザのJavaScriptコンパイラの様な実行時にバイナリを生成して呼び出すようなプログラムとは相性が良くない。バッファオバーフローを利用してコンパイラが生成したヒーブ上のバイナリを書き換えてJavaScriptから呼びだすとか、
どこが？
32-bit向けにビルドされながら実行中に64-bitモードに移行するプログラムがそんなにあるとは思えないので、単にユーザコードからのロングモードへの移行を禁止する設定を導入してしまうのがよい気がします。
例えばEMETのオプションとして導入すれば、必要なプログラムだけホワイトリストで許可することもできますので、実用上問題ないのでは。
> そんなにあるとは思えない
全ての32bitアプリが該当しますが。
どゆこと？
WOW64はユーザモードのまま64bitモードに切り替えた後、APIのパラメータを変換して64bitシステムコールを呼び出す構造になってます。
なので
> 単にユーザコードからのロングモードへの移行を禁止する設定を導入
なんてことをしたら32bitアプリは全滅するわけです。
MSには、せっかくなのでWindows 10はOS Xのように64bit版だけの提供、という形にしてほしかったですね……。7で64bitへの移行がだいぶ進んだので、個人的には8あたりから完全64bit化をしてもよかったような気がします。32bitはRTだけにするとか。
64bit版Windowsで発生しているこの問題に対して何の解決にもならんのになぜ今ここでそんな話？
あと、どうでもいいけどOS Xでも32bitアプリは動くよ。そこに起因する脆弱性がないなんて保証はどこにもない……。
# そのOS Xからの書き込みだけどさ。
＃業務アプリでも、そもそもライブラリ互換性が保たれているわけではないので、VB6 どころでなく .NET アプリでも動かないのがころごろ出ますぜ。
Mac OS X で 32bit アプリが動くのは他のACさんも書いている通り。
> 個人的には8あたりから完全64bit化をしてもよかったような気がします。
8に失敗作の烙印が押されることろまで見えた
そもそも、32bitのOSが必要なCPUがまだIntelから出てる。Atom系にそういうのがあるよ。
でも 禁止=例外発生=OSで捕捉ではないの?そうなら OS でシステム(wow64)のコードか検証して切り替えればいいだけな気がするけど。
例外の実行コストがどんだけ高いか分かった上で言ってんのお前？
すぐに投げ捨てるべき
と垂れ込むべきではないのか
どうしても３２びっとブラウザが使いたければ、３２びっとWindowsにしないさいと
32bitブラウザが危険なのではありません32bitのアプリケーションが危険なのです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
不十分もなにも (スコア:2, すばらしい洞察)
完璧でなければならないなんて前提がそもそも無茶すぎだろ
そーゆーのは「なんでも叩けるアンチに都合のいい詐欺手法」でしかないから
Appleの「審査してるからとにかく安全！！」みたいなのは
利用者の警戒心を失わせて被害を拡大させるという面で問題だが、
システム的な安全機構そのものは「やらないよりはやるだけまし」でいいんだよ
Re:不十分もなにも (スコア:1)
レビュアーの指摘を人格攻撃みたいに捉えて逆上する直情コーダーですか？
Re: (スコア:0)
君の事？
Re: (スコア:0)
穴が見つかったのなら塞がなければならないというだけの話だろ。
誰が完璧でなければならないなんて言ってるよ。
あーそれとも、Windowsは穴が見つかっても批判しちゃいけないという話ですかね?
MSってやらないよりやるだけましって態度でセキュリティやってたんですね。ひどいっすねー
#そんなわけないだろ。MSのセキュリティはかなりのもんだぞ。
#アンチアップルのMS信者のフリしてMSディスってんじゃねえぞ
そもそも、EMETは気休め (スコア:2, 参考になる)
鉄壁ではない。
Microsoft自身がそういってる。
https://support.microsoft.com/ja-jp/kb/2458544 [microsoft.com]
>このようなセキュリティ緩和策テクノロジでは、脆弱性を悪用できないことは保証されません。
>しかし、悪用の実行を可能な限り困難にするように機能します。
E MET H (スコア:1)
おしりにH付けると奴隷のように働いて、頭のE削ると滅びてしまう方を連想した。
#最初からオフトピ
>WoW64環境では実行時にプロテクトモードとロングモードを切り替えることが可能となっているが、これにより純粋な32ビット環境にはない攻撃手段が利用可能となる。
複雑化していくと穴もボコボコ出てしまうのは世の常とは言え。
セキュリティ関係は暗い話しか最近見ないね。
そもそも32bitのASLRは弱い (スコア:1)
そもそも32bitのASLRは弱くてブルートフォースで破れる [wikipedia.org]ので、セキュリティーを気にするなら32bitプロセスを使うべきではありません。
Re:そもそも32bitのASLRは弱い (スコア:1)
それはそうなんですけれど、
（もはや言うまでもない前提の話）
この話題は「今まで思われていた以上に脆弱なパターンがあるんだよ」
っていう話なんじゃないですか？
この部分。
Re: (スコア:0)
それ以前に、ASLRはブラウザのJavaScriptコンパイラの様な実行時にバイナリを生成して呼び出すようなプログラムとは相性が良くない。
バッファオバーフローを利用してコンパイラが生成したヒーブ上のバイナリを書き換えてJavaScriptから呼びだすとか、
Re: (スコア:0)
どこが？
ロングモードへの移行を禁止すればいいのでは (スコア:1)
32-bit向けにビルドされながら実行中に64-bitモードに移行するプログラムがそんなにあるとは思えないので、
単にユーザコードからのロングモードへの移行を禁止する設定を導入してしまうのがよい気がします。
例えばEMETのオプションとして導入すれば、必要なプログラムだけホワイトリストで許可することもできますので、
実用上問題ないのでは。
Re: (スコア:0)
> そんなにあるとは思えない
全ての32bitアプリが該当しますが。
Re: (スコア:0)
どゆこと？
Re:ロングモードへの移行を禁止すればいいのでは (スコア:2)
というか、WoW64 はそういうことのためのもののはずかと…
（32bit の世界に OS はいませんから）
Re:ロングモードへの移行を禁止すればいいのでは (スコア:2, 参考になる)
WOW64はユーザモードのまま64bitモードに切り替えた後、
APIのパラメータを変換して64bitシステムコールを呼び出す構造になってます。
なので
> 単にユーザコードからのロングモードへの移行を禁止する設定を導入
なんてことをしたら32bitアプリは全滅するわけです。
Re: (スコア:0)
MSには、せっかくなのでWindows 10はOS Xのように64bit版だけの提供、という形にしてほしかったですね……。7で64bitへの移行がだいぶ進んだので、個人的には8あたりから完全64bit化をしてもよかったような気がします。32bitはRTだけにするとか。
Re:ロングモードへの移行を禁止すればいいのでは (スコア:1)
64bit版Windowsで発生しているこの問題に対して何の解決にもならんのになぜ今ここでそんな話？
あと、どうでもいいけどOS Xでも32bitアプリは動くよ。
そこに起因する脆弱性がないなんて保証はどこにもない……。
# そのOS Xからの書き込みだけどさ。
Re:ロングモードへの移行を禁止すればいいのでは (スコア:1)
＃業務アプリでも、そもそもライブラリ互換性が保たれているわけではないので、VB6 どころでなく .NET アプリでも動かないのがころごろ出ますぜ。
Mac OS X で 32bit アプリが動くのは他のACさんも書いている通り。
Re: (スコア:0)
> 個人的には8あたりから完全64bit化をしてもよかったような気がします。
8に失敗作の烙印が押されることろまで見えた
Re: (スコア:0)
そもそも、32bitのOSが必要なCPUがまだIntelから出てる。
Atom系にそういうのがあるよ。
Re: (スコア:0)
でも 禁止=例外発生=OSで捕捉ではないの?
そうなら OS でシステム(wow64)のコードか検証して切り替えればいいだけな気がするけど。
Re: (スコア:0)
例外の実行コストがどんだけ高いか分かった上で言ってんのお前？
32bit ブラウザは危険 (スコア:0)
すぐに投げ捨てるべき
と垂れ込むべきではないのか
どうしても３２びっとブラウザが使いたければ、３２びっとWindowsにしないさいと
Re: (スコア:0)
32bitブラウザが危険なのではありません32bitのアプリケーションが危険なのです。