Skypeのアップデート機能にDLLハイジャッキング脆弱性が見つかる 24
ストーリー by hylom
今度はSkypeか 部門より
今度はSkypeか 部門より
あるAnonymous Coward曰く、
Skypeのアップデート機能に脆弱性があることが判明した。攻撃者がこの脆弱性を利用すれば、特権を持たないローカルユーザを完全なシステムレベルの権限に昇格させ、OSのあらゆる場所にアクセスが可能となるという。発見したのはセキュリティ研究者のStefan Kanthak氏（ZDNet、Neowin、Slashdot）。
攻撃者は、悪意のあるDLLをユーザーがアクセス可能な一時フォルダーにダウンロードさせ、そのあと特権を持たないユーザーでも名前が変更可能な「UXTheme.dll」などの正当なDLLに名前を変更することでDLLハイジャックを行う。インストーラが関連ファイルを見つけようとすると最初にハイジャックされたDLLが見つかるため、問題のコードがインストールされるのだという。
Microsoftは9月にKanthak氏からこのセキュリティ上の欠陥を伝えられていたが、修正には大量のコードを書き直す必要があるという。このため、次のメジャーアップデートまでは対応しない方針のようだ
なんか前にも見たような (スコア:1)
elevatedなプロセスが、一般ユーザが書き込めるフォルダに実行ファイルを書き出して実行しちゃうもんだから、
そのタイミングで実行ファイルを置き換えればelevateされた権限で実行できるってやつだよね。
Microsoftがすぐに修正しないのは、「UACはsecurity boundaryではない」（よって脆弱性ではない）っていういつもの立場からだろう。
原因としては、高権限プロセス用の一時フォルダが、標準で存在しないのが問題なのかなあという気がする。
#「UAC security boundary」でググったら「UAC is a security boudanry」っていうTwitterアカウントが見つかって笑った。
Re:南極２８号 (スコア:0)
ＤＬＬの読み込み方法をこれからはちょっと考えるべきだな
仕組みを変えようってことではなく「プラグイン」としての
ＤＬＬの在り方
Re:南極２８号 (スコア:1)
根っこにあるのが、MS-DOSのPATH環境変数や、その周辺の仕様だから難しそう。
.NET FrameworkのReflectionみたいに、ピンポイントでファイル名を指定してロードさせるような仕様ならいいけど、既存の（たとえばWin32API等の）DLLは「規定の順序で探して、最初に見つかったファイル」という形式だし・・・。
Re: (スコア:0)
指定した署名付きの物以外はロードできないようにするオプションをつけるのが手っ取り早い。
Re: (スコア:0)
その認識はちょっと古い。
OSとしては、SetDllDirectoryなどによって、DLLをロードするディレクトリというのは制御可能になっているし現状では、特に問題はない。
これは単純にSkypeというアプリの問題に過ぎない・・・というといい過ぎかな。
しかし、SkypeはもともとMS製じゃないアプリだから、根幹の部分で修正しきれない難しい問題があるのだろう。
Re:南極２８号 (スコア:1)
SetDllDirectoryにせよ、System.Reflection.Assembly.LoadFromにせよ、今後作るアプリへの対策としては十分で、OSの制御としては特に問題ないと思いますよ。
ただ、既にあるレガシーなアプリが、上記の仕組みを組み込めるかは別問題だよねって。
理論的にはSetDLLDirectoryは比較的低コストで従来のWin32アプリに組み込めるとは思うけど、それでも動作検証のコストは莫大になりそうだし。
そしてMS-DOSからの使用を引きずるかぎり、そういったレガシーなアプリのDLL読み込みに「OS側が干渉して不正なDLLから保護する」方式はとれないから、後方互換を維持する限りは延々と続く問題じゃないの？これ。
# 本気でやるならSetDllDirectoryを使う前にDLLをロードしようとしたアプリを停止させるぐらいは必要だけど
# それで古いアプリはこぞって動かなくなるので、それでいいの？って話だと思うの。
Re: (スコア:0)
SetDllDirectory()で対策出来るのは実行時リンクするDLLだけでエントリポイントに達する前にロード時リンクされるDLLに対しては全く対策にならない
Re: (スコア:0)
やっぱりマイクロソフトは標準ユーザーで使わせることをあきらめたのか。標準ユーザーの場合、管理者権限を持つプロセスは別アカウントで動作して一時フォルダーのパスも独立しているし標準ユーザーからはアクセスできないから問題ないんだがな
Re: (スコア:0)
「elevated」の意味分かってるのかい？
標準ユーザーのみで管理を完結させたいと言いたいのならそれは標準ユーザーが管理者ユーザーである事と何の違いもない。
バックドア (スコア:0)
そもそもバックドアがあるものに脆弱性が見つかっても気にならない。skype使う奴なんてアホか気にしない奴だけだろ
次のメジャーアップデートまでは対応しない (スコア:0)
次のメジャーアップデートで再度UWP化して根本的に対策するつもりなのかな。たとえDesktop Bridgeでもアップデートがストアのインフラ任せになるから攻撃を回避できる。
だから実行ファイルはサインしとけってあれほど言ったのに・・・ (スコア:0)
それすら難しいというなら、だったらインストール時に各ファイルのハッシュのリストを取りに行って確認すりゃいいのに。
そんなに根本的なロジックを書き直さなきゃいけない話なのか？
Re: (スコア:0)
ハイジャック側がそういう確認作業をスキップしたりスルーできるから、ハイジャックされた時点でアウト。
Re: (スコア:0)
これは一般ユーザーが書き込めるファイルをインストーラーが勝手にアプリケーションに組み込んでしまうことから起こるバグだから、ハイジャックされる前に一般ユーザーが書き込めないファイルに公開鍵やハッシュリストをダウンロード出来るIPアドレスを書き込んでおけば、攻撃者がローカルでDLLをなんぼ書き換えようと検知して弾けるでしょ。
Re: (スコア:0)
DLLのロードタイミングは早いからね。検知する処理に必要なDLLをロードする途中でハイジャックされるのよ。
Re: (スコア:0)
検知用の機能を実行ファイルに組み込んどけば済む話。
Re: (スコア:0)
それは誰がやるんだ？
Re: (スコア:0)
何か勘違いしてない？
UXTheme.dllは本来はシステムのライブラリで、その名前に変えてインストーラーと同じディレクトリに置いておくと勝手にそれが読み込まれるんだよ。
システムのライブラリのハッシュ持つとかアホな事言ってるわけじゃないよね？
そんなに大変な修正なの？ (スコア:0)
要はローカルユーザーが書き込める場所にダウンロードして実行するのが原因であり、
updater自体は昇格されてるから、ローカルユーザーが書き込めない場所へ。例えば行儀は悪いけどインストール先=program filesにダウンロードしてやればいい。
修正に必要な処理は、保存する場所がローカルユーザーが書き込めないことのチェック程度かな。
Re: (スコア:0)
OS側でAPIを用意してインストール時に一時的に保存する必要のあるファイルを安全に保持できるようにすりゃいいんでは。
Re: (スコア:0)
そんなんじゃ対応まで何年かかるかわからんｗ
Re: (スコア:0)
ローカルユーザーじゃなくて、権限のないユーザー（一般ユーザーなど）ですね。
それに問題は、一般ユーザーが書き込める場所に展開することではなく、
ファイルのパーミッションが、一般ユーザーでも書き換えられるようになっていること。
Re: (スコア:0)
違います。典型的なDLLハイジャックで、ダウンロードしたファイルを書き換えるのではありません。#3363021 も同じ勘違いしてるのかな？
対策考えたいけど・・・ (スコア:0)
ストアアプリ版とデスクトップ版どっちが対象なの？