アカウント名:
パスワード:
不謹慎承知でいうなら「いいアイデア」だと思った。
最初Delphi狙いのウイルスというと「メソッドポインタ用のコード書き換え部分を攻撃されたか?」とか思ったんだが、もっと素朴というか単純かつ的確で効果的な攻め方だった。
Delphiは殆どのEdition(大雑把にいえば無料版以外かな)にライブラリ「のソース」が添付している。そいつのひとつ…できるだけ根っこの部分の…を何らかの攻撃でもって書き換えてしまえば、今回のようなことが出来てしまうわけだね。
でさ。これって別にDelphiに限ったことではないよね。VisualStudioだろうがgccだろうが、同じ手法は原理的に成り立つし、Delphiならではの攻め方をしたわけでもない(のだろう)から、他にも応用がきく。
さあ。キミの手元のライブラリソースは大丈夫か?
ああ。別にネイティブコンパイラ系だけじゃなくインタプリタ系も心配だよね。Javaの*.classや*.jarもそうだし、rubyのgem(ローカルリポジトリ)だって心配だ。
しかもだ、発覚するまではツール作者のほうが責められがちになり、真の攻撃者は逃げ切る時間的余裕がかなり有るときたもんだ。
Vectorかどうかなんてのは仔細すぎる問題だ。問題は無料ソフトでも自由ソフトでもなく(ましてそれの配布サイトの問題でもなく)「ソフトを作ること」全般への攻撃だ。考えてもみろ。上記攻撃手法にちょっと一手間くわえて「書き換えコードをLIBにコンパイルするときのオプションをランダム化」してみろ。とたんに凄まじく検出しにくいウイルスになるぞ。なにせ成果物はバイナリパターンにひっかからないんだからな。アプリ(本来の)作者から出てくるソフトを改組する"必要"もないわけだし。作者が気づかないままだといつまでたってもアレなままだ。
ライブラリのソースもMD5とかで常にチェックしないとならないご時世、ってことかな?
今回の問題は、・感染する各PCにライブラリソースが入っていることではなく、・ウィルス作成者がライブラリソースにアクセス可能なため、比較的容易に「トロイ入りのライブラリ」を作成できたという点でしょう。
感染方法として、・インストール済のソースを改変してからライブラリをビルド・上書きするという点については、> 記攻撃手法にちょっと一手間くわえて「書き換えコードをLIBにコンパイルするときのオプションをランダム化」してみろというところまでやってしまえば、凄い大きな意味がありますが、現状では、ライブラリのバイナリに直接感染(差し替え)するプログラムでも、結果は同じです。
・コンパイラのバージョンごとに差し替え用ライブラリバイナリを用意しなくてもいい
という、ウィルス本体のコンパクト化に貢献しているぐらいじゃないでしょうか。
でも、ライブラリのソースがあると、デバッグ時にライブラリの中にまでトレースできるし、ライブラリの挙動については、下手なドキュメントを読むよりソースを見る方がわかりやすいことが多いし、ライブラリソースがあるというのは、凄い便利なんですけどね。
たまにライブラリのバグに対処するのに、自前でパッチ当ててライブラリを作りなおしたりするし。
先日のATL関連の不具合(MS09-034/MS09-035)は VisualStudioのソースともいえるライブラリに脆弱性 [microsoft.com]があったために、特定の関数を使ったプログラムが全て影響を受けるという結果になったんですよね。
だから、DirectX/OS/MediaPlayer/DHTML/OutLook [microsoft.com]/FlashPlayer [adobe.com]/ShockWavePlayer [adobe.com]/Cisco Utility [cisco.com]などが挙げられていますが、氷山の一角だと思われます。
これをヒントにウィルスを作ったとか…まさかね。(備考:脆弱性の公開が7/24, ウィルスの確認が8/18)
・過去に類を見ないほど“怖い”脆弱性、MSがパッチを緊急リリース [nikkeibp.co.jp]・開発ソフトが影響を受ける条件 [microsoft.com]
そういえば、Vector は前回 フリーソフトのチェックはトレンドマイクロのウィルス対策ソフトだけでやっていて(部門全体には3種類導入してたみたいですが)、パターンファイルの非対応が原因で感染したので確実に3種類のセキュリティソフト通すようにしたみたいですよね。うちはセキュリティソフトをすり抜けてくるウィルスが結構あるので定期的に手動でチェックしています。これ [livedoor.jp]は、私が実際にやってるチェックの方法の一部。
# セキュリティソフトで検出できないソフトのほとんどがSpywareやネットゲームの情報読み取りなんだけど何でだろう。
zlib とか png とかの方もインパクトは大きかったように思いますが……。 ATL の脆弱性の件に関しては、この手の「よく使われるライブラリ」に見つかった脆弱性とさほど差があるものとは思えません。
# 上記 2 つは Windows も使っていますし。
「ソースに不具合がある(通常のバグ全般?)」ってのと「ソースを書き換える」ってのは全然意味が違うと思いますが。「ソースを書き換えた事に依りソースの不具合に類する事を起せる」ってのは確かにそうだが、それは当たり前の話だし。
どっちかって言うと「現状のウイルスチェック方法って抜け穴が無い?」って感じの話じゃないかな。
login.c [xight.org] の件とかですかね。ちょっと違うかな…?
スモール、ラージ、ヒュージだったか ... (遠い目)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
やられた>手法的に (スコア:0)
不謹慎承知でいうなら「いいアイデア」だと思った。
最初Delphi狙いのウイルスというと
「メソッドポインタ用のコード書き換え部分を攻撃されたか?」
とか思ったんだが、
もっと素朴というか単純かつ的確で効果的な攻め方だった。
Delphiは殆どのEdition(大雑把にいえば無料版以外かな)にライブラリ「のソース」が添付している。
そいつのひとつ…できるだけ根っこの部分の…を何らかの攻撃でもって書き換えてしまえば、今回のようなことが出来てしまうわけだね。
でさ。これって別にDelphiに限ったことではないよね。
VisualStudioだろうがgccだろうが、同じ手法は原理的に成り立つし、
Delphiならではの攻め方をしたわけでもない(のだろう)から、他にも応用がきく。
さあ。キミの手元のライブラリソースは大丈夫か?
ああ。別にネイティブコンパイラ系だけじゃなくインタプリタ系も心配だよね。
Javaの*.classや*.jarもそうだし、rubyのgem(ローカルリポジトリ)だって心配だ。
しかもだ、発覚するまではツール作者のほうが責められがちになり、
真の攻撃者は逃げ切る時間的余裕がかなり有るときたもんだ。
Vectorかどうかなんてのは仔細すぎる問題だ。
問題は無料ソフトでも自由ソフトでもなく(ましてそれの配布サイトの問題でもなく)「ソフトを作ること」全般への攻撃だ。
考えてもみろ。
上記攻撃手法にちょっと一手間くわえて「書き換えコードをLIBにコンパイルするときのオプションをランダム化」してみろ。とたんに凄まじく検出しにくいウイルスになるぞ。なにせ成果物はバイナリパターンにひっかからないんだからな。アプリ(本来の)作者から出てくるソフトを改組する"必要"もないわけだし。作者が気づかないままだといつまでたってもアレなままだ。
ライブラリのソースもMD5とかで常にチェックしないとならないご時世、ってことかな?
Re:やられた>手法的に (スコア:2, すばらしい洞察)
今回の問題は、
・感染する各PCにライブラリソースが入っていること
ではなく、
・ウィルス作成者がライブラリソースにアクセス可能なため、比較的容易に「トロイ入りのライブラリ」を作成できた
という点でしょう。
感染方法として、
・インストール済のソースを改変してからライブラリをビルド・上書きする
という点については、
> 記攻撃手法にちょっと一手間くわえて「書き換えコードをLIBにコンパイルするときのオプションをランダム化」してみろ
というところまでやってしまえば、凄い大きな意味がありますが、
現状では、ライブラリのバイナリに直接感染(差し替え)するプログラムでも、結果は同じです。
・コンパイラのバージョンごとに差し替え用ライブラリバイナリを用意しなくてもいい
という、ウィルス本体のコンパクト化に貢献しているぐらいじゃないでしょうか。
でも、ライブラリのソースがあると、デバッグ時にライブラリの中にまでトレースできるし、
ライブラリの挙動については、下手なドキュメントを読むよりソースを見る方がわかりやすいことが多いし、
ライブラリソースがあるというのは、凄い便利なんですけどね。
たまにライブラリのバグに対処するのに、自前でパッチ当ててライブラリを作りなおしたりするし。
それを言うなら先日のATL (スコア:1)
先日のATL関連の不具合(MS09-034/MS09-035)は VisualStudioのソースともいえるライブラリに脆弱性 [microsoft.com]があったために、特定の関数を使ったプログラムが全て影響を受けるという結果になったんですよね。
だから、DirectX/OS/MediaPlayer/DHTML/OutLook [microsoft.com]/FlashPlayer [adobe.com]/ShockWavePlayer [adobe.com]/Cisco Utility [cisco.com]などが挙げられていますが、氷山の一角だと思われます。
これをヒントにウィルスを作ったとか…まさかね。(備考:脆弱性の公開が7/24, ウィルスの確認が8/18)
・過去に類を見ないほど“怖い”脆弱性、MSがパッチを緊急リリース [nikkeibp.co.jp]
・開発ソフトが影響を受ける条件 [microsoft.com]
そういえば、Vector は前回 フリーソフトのチェックはトレンドマイクロのウィルス対策ソフトだけでやっていて(部門全体には3種類導入してたみたいですが)、パターンファイルの非対応が原因で感染したので確実に3種類のセキュリティソフト通すようにしたみたいですよね。
うちはセキュリティソフトをすり抜けてくるウィルスが結構あるので定期的に手動でチェックしています。
これ [livedoor.jp]は、私が実際にやってるチェックの方法の一部。
# セキュリティソフトで検出できないソフトのほとんどがSpywareやネットゲームの情報読み取りなんだけど何でだろう。
Re:それを言うなら先日のATL (スコア:1)
zlib とか png とかの方もインパクトは大きかったように思いますが……。
ATL の脆弱性の件に関しては、この手の「よく使われるライブラリ」に見つかった脆弱性とさほど差があるものとは思えません。
# 上記 2 つは Windows も使っていますし。
Re: (スコア:0)
「ソースに不具合がある(通常のバグ全般?)」ってのと「ソースを書き換える」ってのは全然意味が違うと思いますが。
「ソースを書き換えた事に依りソースの不具合に類する事を起せる」ってのは確かにそうだが、それは当たり前の話だし。
どっちかって言うと「現状のウイルスチェック方法って抜け穴が無い?」って感じの話じゃないかな。
Re: (スコア:0)
(広い意味での)ライブラリは、作成者以外は改変できない。としておけば今回のような問題は発生しない。
無茶な話ではなく、.NET で10年前からやってることだ。
Re: (スコア:0)
# Delphi 7 と 2009 を併用しているので AC
Re: (スコア:0)
不思議なことにちょうど新バージョンが出てきたところです。
つい最近も、古い製品向けアップデーターのダウンロードを停止したり(ユーザーによる再配布も禁止ですって)
使用許諾入手サイトを止めたりとかしていますしねぇ
Re: (スコア:0)
ソースコードに感染するウイルスというかワームと言うか、
その手の攻撃手法はすでにあったはず。
Re:やられた>手法的に (スコア:1)
login.c [xight.org] の件とかですかね。ちょっと違うかな…?
ソースコードが標的ではないですが (スコア:0)
なんだけど、インターネット以前の世界なのでオンラインの資料が出てこない。
不便になったものよ。CIS のフォーラムに残っていた記憶があります。
Re: (スコア:0)
DOSレベルのファイル管理だと簡単にやれます。権限ないのはこういうところで怖いですね。
というか、この手法がいまさら出てきたことに驚かされます。
Re: (スコア:0)
スモール、ラージ、ヒュージだったか ... (遠い目)