JavaのWindows版インストーラーに脆弱性、緊急アップデートがリリースされる 13
ストーリー by hylom
まだまだ出てくる 部門より
まだまだ出てくる 部門より
headless 曰く、
Oracleは5日、Java SE 6/7/8のWindows版インストーラーで見つかった脆弱性に対する緊急アップデートをリリースした（The Oracle Software Security Assurance Blog、Oracle Security Alert for CVE-2016-0603、BetaNews、窓の杜）。
サポート中のバージョンで影響を受けるのは、Java SE 6u111、7u95、8u71、8u72。脆弱性を悪用するには、Java SEのインストール前にユーザーを攻撃用Webサイトに誘導し、悪意のあるファイルをダウンロードさせる必要がある。複雑な攻撃が必要となるものの、実際に悪用が成功するとシステムが完全に乗っ取られる可能性があるとのこと。
脆弱性の影響を受けるのはインストール時のみなので、既にJava SEがインストールされている場合はアップデートの必要はない。ただし、今後のインストールで使用するためにJava SE 6u113、7u97、8u73よりも古いバージョンをダウンロードしている場合、これらは破棄して6u113、7u97、8u73以降のバージョンを使用する必要がある。Java SE 6/7の最新版は一般公開されていないので、通常はJava SE 8u73以降を使用することになるだろう。
Softpediaの記事によると脆弱性はDLLハイジャックが可能になるというもので、Java SE以外でも数多くのアプリのWindows版インストーラーで最近次々と発見されているようだ。OracleではVirtual Boxで見つかった同様の脆弱性について、1月のアップデートで修正しているとのこと。
DLLハイジャック (スコア:0)
要するに、インストーラーがKnownDLLsにもSide-by-Sideアセンブリにも含まれないDLLを不用意に使っていたので、先にそのDLLと同名のファイルをダウンロードさせることができれば、ダウンロードフォルダからインストーラーを実行したときに、正規のインストーラーであるにもかかわらず任意のバイナリを読み込ませることができるわけだ。デスクトップアプリのインストーラーは通常管理者権限を持つから、確かに「攻撃手順は複雑だが、成功するとシステムを完全に乗っ取られる可能性がある」な。
もっとも攻撃の現実性はかなり疑わしいけど。これが成功する(リテラシーのユーザーを想定する)んだったら、もっとシンプルに改ざんしたインストーラーを実行させるだけで同じくらい成功すると思う。インストーラーの署名を確認すればいい? VirtualBoxのインストーラーは署名がSHA-1のままだから、ダウンロード時に表示されるダイアログでは署名されていないのと見分けがつかないしSmartScreenにブロックされてるぞ。マジで大丈夫かOracle。
Re: (スコア:0)
>SetDllDirectory(_T(""));
の一行を書いておけば防げる攻撃なのに
まぁこの一行が必要なのはカレントディレクトリがdllの検索パスに含まれているという歴史的経緯のせいなんだが
Re:DLLハイジャック (スコア:4, 参考になる)
> >SetDllDirectory(_T(""));
> の一行を書いておけば防げる攻撃なのに
いや、以下の2点の理由により防げない。
・ダウンロードフォルダーから実行すると、ダウンロードフォルダーがDLL検索パスで最優先の「アプリケーションのディレクトリ」になってしまう。これはSetDllDirectoryでは変更できない。
・そもそも、暗黙にリンクされるDLLはバイナリが1バイトも実行されないうちにロードさせるので、プログラムコードに何か書いて防ぐことはできない。
対策としては、
・インストーラーをexeにせず、MSIを使う。
・どうしてもexeにする必要があるなら、KnownDLLsに含まれるDLL以外には暗黙にリンクしない。KnownDLLsはWindowsのバージョンによって微妙に異なるので、あまりギリギリを狙わず出来る限り暗黙にリンクするDLLを減らしたほうがいい(修正されたJavaのインストーラーはkernel32.dllとadvapi32.dllにのみリンクしている)。
・comctl32.dllはKnownDLLsに含まれないけど、manifestでバージョン6.0の使用を宣言していれば問題ない(Side-by-Sideアセンブリも通常のDLL検索パスを無視する)。
・明示的リンクするときは、システムディレクトリのフルパスを指定するか、LoadLibraryExにLOAD_LIBRARY_SEARCH_SYSTEM32を指定する。
・CRTはバージョンなしのmsvcrtを使うか、静的リンクする(インストーラーなら言われるまでもなくそうなっていると思うけど)。
ユーザー側の対策は
・インストーラーをダウンロードフォルダーから直接実行せず、ほかにファイルがないディレクトリに移動してから実行する。
Re: (スコア:0)
> ・明示的リンクするときは、システムディレクトリのフルパスを指定するか、
これだけだと指定されたDLLが別のDLLを暗黙にリンクしているとき危険だった。LOAD_WITH_ALTERED_SEARCH_PATHと、あと結局SetDllDirectoryもいるな。LOAD_LIBRARY_SEARCH_SYSTEM32が使えるならそれが一番安全だ。
Re: (スコア:0)
SetDllDirectory("")はアプリケーション側の対策ですが、レジストリの設定で、
すべてのアプリケーションに対してカレントディレクトリを検索させないようにユーザ側で対策できます。
DLL 検索パス アルゴリズムを制御する新しい CWDIllegalInDllSearch レジストリ エントリについて
https://support.microsoft.com/ja-jp/kb/2264107 [microsoft.com]
私は長年この設定で使っていますが、今のところ問題が起きるアプリに遭遇したことはないです。
Re: (スコア:0)
だからこの問題はカレントディレクトリを検索させないようにしても防げないって。
「大昔に発覚しているDLLハイジャックの問題に対応していないアホなインストーラーがまだあるの?」くらいに思っていて正しい対策が周知されていないとしたら、それ自体問題だな。
Re: (スコア:0)
何となく、TCP_TIMEWAIT_LENの件 [linux.srad.jp]を思い出しました。
Re: (スコア:0)
あーそりゃそうか。失礼。
InstallShieldあたりですかね (スコア:0)
これだけ大量のインストーラで同じ脆弱性となると、原因はInstallShieldあたりが使っているDLLですかね。
未知のファイルをダウンロードさせないと攻撃にならないので、限定された状況以外での攻撃は考えづらいですが、
「ダウンロード」フォルダにファイルを置かせるという攻撃シナリオは、なかなか興味深いですね。
「ダウンロード」フォルダにたくさんのファイルを残したままの人は、変なDLLがないか、一度確認したほうがよいかもしれません。
Re: (スコア:0)
リンク先見たけどかなり言いがかりめいたのもあるぞ。%TEMP%\7z.tmp\ にshfolder.dllを置かせることができればそこに展開されたインストーラーが起動されるとき任意コード実行できるとか。
Re: (スコア:0)
まぁもともとリバースエンジニアリングやバイナリハックで使われていた古典的な方法に対する脆弱性だから全部言いがかりみたいなもんだよね。
Re: (スコア:0)
_inmm.dll懐かしい
javaインストーラーでAmazonアシスタントを入れさせようとする脆弱性 (スコア:0)
インストーラーの脆弱性が修正されたと言うから、てっきりAmazonアシスタントとか
検索エンジンがAmazonスマート検索に乗っ取られる件が修正されたのかと思ってたら
違ってた。
ほんとうにがっかりです。