ほぼ全てのウィルス対策ソフトウェアに「有害なプログラムの挙動を検知できない」脆弱性あり 18
ストーリー by hylom
過信するなということで 部門より
過信するなということで 部門より
あるAnonymous Coward 曰く、
セキュリティテスト機関Matousecが、Windows上で動くほぼ全てのウィルス対策ソフトウェアに通じる脆弱性を発見したそうだ(The Register、本家/.)。
ウイルス対策ソフトは通常、Windows APIにフックを仕掛け、APIに渡されたパラメータをチェックして安全を確認してからそのAPIを実行する。しかし、パラメータはユーザー空間に格納されているため、パラメータのチェック後に値を書き換えることが可能という。これを利用し、まずは「安全」なパラメータをAPIに渡し、ウイルス対策ソフトによるチェックが完了して本来のAPIが実行される寸前でパラメータを書き換えることで、チェックをすり抜けて危険な処理を実行させることができるという。マルチコアシステムでは同時実行されているスレッドを把握できないことも多いため、より実行しやすいとのこと。
調査レポートによるとこの方法は「権限を制限したWindowsアカウントでも実行可能」とのことだが「標的のマシンに大量のコードをロードする必要があるため、シェルコード攻撃やその他スピードを要する攻撃、またステルス的な攻撃には実用的ではない」とのこと。また、攻撃は標的マシンでバイナリを実行できる状況でのみ可能とのことだ。
ちなみに本家/.コメントによるとこの手法は以前から知られていたもので、NetBSDやOpenBSDでの脆弱性としてすでに報告されているという。
鯖屋がアップを始めたようです (スコア:2)
水牛ルータにDeep Packet Inspectionツールを入れた本来のファイアウォールが販売されるようになるに1.013*10^5ジンバブエドル。
ユーザーモード側で書き換えてるのなら (スコア:1)
一見そうとは見えない rootkit を仕込まれていて、APIのフック順でオリジナルのAPIに近い側を取られていてそちらで書き換えられてしまっているのなら打つ手無しです。
Re:ユーザーモード側で書き換えてるのなら (スコア:1, 興味深い)
常にコピーする必要はないです。システムコールで読むデータのページを書き込み禁止にしておいて、書き込みがあったときだけコピーを作ればほとんど重くはならないと思います。一種のコピーオンライトですね。ウイルス対策ソフトではなく、OSがサポートする必要がありそうですが。
でもこれって (スコア:1, 興味深い)
普通はブラックリストだから実行段階に入る前に蹴るはず。
APIに不正動作をさせるパラメータがあるとしたら、それはセキュリティベンダが対策するべきではなくMSに投げてエクスプロイトを一定時間後に公開でもすればいい。
だけど、根本的にヒューリスティックの精度が低すぎる現状では、回避するまでも無く誤爆と見過ごしの境界線をすり抜けることが可能だから大して意味がある話ではないんじゃないかと思うけど。
特定のプログラムに干渉して、return to libc系のテクニックも使って規定外の動きをさせるプログラムを数年公開しているけれど、今までアンチウィルスに検出された事はない。
誤検出はあったけれど、ランタイム側のコードがオフセット込でパターン登録されていて、偶然オフセットが一致した誤検出に過ぎなかった。
こんなタイミング勝負の博打うつより、すりぬけるコード書くほうが数倍楽なんじゃねぇかな
タイミング勝負の博打を打つコードってのもヒューリスティックに検出させるべき系統の話だし、ヒューリスティックの技術が未熟すぎる現状ではちょっと先走った研究だと思う。
制限ユーザーでも有効なんですか。 (スコア:0)
ウィルス対策ソフトが万能ではないことは今更そんなこと言われなくても知ってるよ、て感じですが、個人的には制限ユーザーでも有効な方法だということがショッキングです。対処法は特に無い?
Re:制限ユーザーでも有効なんですか。 (スコア:2, 興味深い)
権限の確認はシステムコールが実行されるに実施され、システムコールの中で権限の確認をしていないからでしょうか。
非常に気になります。
APIをフックしたアンチウィルスソフトをさらにフックするウィルスってこと? (スコア:0)
このタイミングで値の操作って可能なんですか?
Re:APIをフックしたアンチウィルスソフトをさらにフックするウィルスってこと? (スコア:4, 参考になる)
>> ウイルス対策ソフトによるチェックが完了して本来のAPIが実行される寸前
> このタイミングで値の操作って可能なんですか?
値がユーザーモード空間に存在していて、まだスケジューラもユーザーモードスレッドへの切り替えを許している状態なので可能です。
なおこれはスケジューラやAPIの脆弱性ではありません。なぜならば本来のAPIが実行される寸前は本来ならユーザモードのコードが実行されていたはずで、APIはユーザーモード空間からパラメータをコピーする必要があるからです。その前にサードパーティーのドライバがカーネルパッチで割り込んでいても、OSはそれを認識していないのですからどうしようもありません。サードパーティーソフトの側が自分の責任で対策する必要のあることです(で、ほとんどすべてのソフトが対策をサボってたと)。
マルチコアのシステムではスケジューラに関係なく別スレッドから値の書き換えが可能なので、さらに攻撃しやすいわけです。
OSの認識する方法(たとえばフィルタドライバ)で割り込んでいる場合には、パラメータはすでにコピーされているので問題は発生しません。
Re: (スコア:0)
書き換えるタイミングはどう計ってるんだろう。
チェックが済む前に割り込んでも意味がないから、その数STEPを見計らって書き換えないといけないよね?
ブルートフォースで、偶然にベストタイミングで割り込むまでひたすらトライしてるのかな。
ユーザーモードとカーネルモード (スコア:0)
今回のはユーザーモードでアンチウィルスソフトがすり抜けられるという話ですが、カーネルモードなら何でもありです。
ルートキットはカーネルを好む傾向、検出・削除が困難に
http://internet.watch.impress.co.jp/cda/news/2008/06/19/19999.html [impress.co.jp]
最近のルートキットはファイルシステムまでもを乗っ取ります。
そこで、最近のアンチウィルスソフトでは直接パーティションにアクセスして独自にntfsを解析して駆除します。
しかし、今後パーティションまで乗っとるルートキットが出てきてもおかしくはありませんし、いたちごっこは続くでしょう。
Windows 7ではカーネルドライバに著名が必要になったので安全かと思いきや、勝手証明書の鍵の登録に管理者権限が必要なぐらいなので、まぁ片手落ちでしょう。
Re: (スコア:0)
別スレで話題になってるSSDT hookなんかもそうですが、こうした問題に
対処するのはなかなか難しいですね。ハイパーバイザー使ってOSを仮想化
に置いて監視するという方法は有効としても、こんどはハイパーバイザー
を狙うroot kitが現れる(すでにある?)でしょうしハイパーバイザーの
ハイパーバイザーの…で無限ループに陥りかねない。
オープンソースでは、ソースが公開されていることが安全を担保する
という考え方があって、実際にある程度は有効と思うけど
ユーザーがコードをいちいち精査して自分でビルドしてインストール……
という手順を踏んでるわけではないので、危険なバイナリをインストールして
しまうことだって起きる。
ハイパーバイザーを秘中の秘として公開せず、ハイパーバイザーで
動くVMに穴がないなら安全は確保できるかも。でも穴を完全にふさぐことが
可能なのかという話にもなるわけで、なんとなく永遠に続くネタのような
気がしないでもないですねえ。
部門名 (スコア:0)
通信するな、と見間違えた。
Re:マイクロソフトにしてみれば (スコア:2, 興味深い)
カーネルにパッチとは何のことでしょうか?
今回の問題は、ウィルス対策ソフトが検知のために使っている仕組みが、Microsoftがデバッグ用として提供しているフック用APIを使った方法であることに起因しています。この方法は、アプリケーションのデバッグ目的に非常に有効です。Microsoft自身が「Application Verifire」というツールを提供していて、API呼び出しに問題がある場合(引数がNULLだったとか)レポートしてくれるという超便利ツールがこの仕組みを使っています。
ほえほえ
Re:マイクロソフトにしてみれば (スコア:2, 参考になる)
> Microsoft自身が「Application Verifire」というツールを提供していて、
どこにそんなこと書いてますか? レポートでは
SSDT hook [matousec.com]とその問題 [matousec.com]について説明しているようですが。SSDT hookはまさにMSがやるなと言っている方法です。
逆にApplication Verifierについて言及している箇所は見つけられませんでした。
Re:マイクロソフトにしてみれば (スコア:2)
おー、了解です。ありがとうございます。カーネルの一歩手前の話ですか。なるほど。AppVは関係ないですね。失礼いたしました。
ほえほえ
Re:マイクロソフトにしてみれば (スコア:1, 参考になる)
だから原文をちゃんと読めってあれほど言っただろ、って感じのコメントですね。
> In other words, 100 % of the tested products were found vulnerable. The only reason there are not more products in the following table is our time limitation.
とのことなので、MSのプロダクトが載ってないのは行儀がいいからじゃなくて単にテストされてないだけ。
Re: (スコア:0)
Security Essentialsは影響を受けないと確認されました [twitter.com]よ?
原文には確かにすべてをテストしていないとありましたが、攻撃手法の原理上Security Essentialsが影響を受けないことはほぼ確信してたのでフライングを承知で書いたのです。