- PR -

.NETやXMLはウイルス作者にとっても最適の環境

1|2 次のページへ»
投稿者投稿内容
autumn
大ベテラン
会議室デビュー日: 2001/07/27
投稿数: 215
投稿日時: 2002-03-27 12:58
「.NETやXMLはウイルス作者にとっても最適の環境」――トレンドマイクロCTOが警告という記事が出ているようですが、皆さんはどう思われますか?
_________________
uda
会議室デビュー日: 2001/12/28
投稿数: 13
投稿日時: 2002-03-27 18:59
この記事を読む限りでは、判断しかねますね。

しかし、.NETのAssemblyは公開暗号方式をとっているので、
普通に開発が楽になったJavaみたいな捕らえ方をされているのであれば、
どうかなと思ってしまいます。
小川誉久
＠ITエディタ
会議室デビュー日: 2001/07/27
投稿数: 111
お住まい・勤務地: 東京都小平市
投稿日時: 2002-03-28 12:21
　autumnさん、udaさん、こんにちは。

　udaさんがおっしゃるとおり、この記事だけでは、具体的に何を指しているのか分かりません。「プログラム開発が簡単になるということは、ウイルス開発も簡単になる」とありますが、これは単純にエディタやデバッガなどの開発環境が使いやすいという意味なんでしょうか？ そうだとすれば一理あるのかもしれませんが、まったく問題の本質を捉えていない発言だと思います。

　現行のWebサービスは、インターネット環境でミッションクリティカルな用途で使うには、あまりに原始的であり、まだまだ知恵を絞るべきポイントは数多いと思います。けれどこれは、通常のHTTPによるWebアクセスで重要な情報を交換するのは危険だということと本質的には同じだろうと思います。「Webサービスは分かりやすく簡単だから悪用される危険性も高い」というくだりは、技術的な側面というよりは、ソーシャル・エンジニアリング的な面を言っているのでしょうか？ 後者なら分かりますが、前者のことを言っているなら、これもあまりに短絡的な結論だと思います。

　「単独では無害なアプリケーションでも、組み合わせると被害を及ぼす危険性」というのも、.NETとかMSILとは直接的にはまったく関係ないように思います。ネットワークを介してアプリケーションが連携するということを言っているのだと思いますが、これも本質的な指摘ではないですね。

　クラッキングなどの脅威は簡単にはなくならないと思いますが、少なくとも.NET Frameworkでは、未チェックバッファ（バッファオーバーフロー）のようなプログラマのケアレスミスが深刻なセキュリティホールにつながる可能性はなくなるものと考えますし、現在よりは安心できるソフトウェア・プラットフォームになりうる数々の特徴を持っていると思います。

arton
会議室デビュー日: 2002/03/22
投稿数: 19
投稿日時: 2002-03-29 00:42
はじめまして。artonと言います。
単純に考えると、もしダウンロードしたコードがすべて同一ディレクトリに格納された場合にはアプリケーションドメインの問題（信頼済みの危険な処理を含むアセンブリを、信頼していないアセンブリが派生して使用したり、ダイナミックに作成して使用したりできる）。というようなことが上げられると思います。
#ただ、以前はリフレクションを利用したモジュールを越えたNonPublicなメソッド呼び出しが可能だったように記憶しているのですが、現在はできなくなっています（抜け道はあるのかも知れませんが−というのは、コンパイラのランタイムライブラリ内のinternalなメソッドやクラスに対して生成したコードから呼び出しができなくて困ってたりするので）
#いずれにしろ、プログラムを作る場合、public,internal,sealedなどはきちんと設定する必要があるでしょう。
「たとえば、それぞれ……」というチャン氏の発言から考えられる点でした。


[ メッセージ編集済み 編集者: arton 編集日時 2002-03-29 00:43 ]

[ メッセージ編集済み 編集者: arton 編集日時 2002-03-29 00:44 ]
NothingBut.NETFX
大ベテラン
会議室デビュー日: 2001/09/13
投稿数: 102
投稿日時: 2002-03-29 02:55
引用:

artonさんの書き込み (2002-03-29 00:42) より:
（信頼済みの危険な処理を含むアセンブリを、信頼していないアセンブリが派生して使用したり、ダイナミックに作成して使用したりできる）。というようなことが上げられると思います。


1票。ですので、自分のコードがその悪さに加担しないように、AllowPartiallyTrustedCallers属性とか正しく設定しなければなりません。StrongNameを与えることは言うまでもありません。あと、できれば必要なもの以外はすべてDenyするようなCASの設定とかも。

Publicにせざるを得ないコードでも、自分が書いたクライアントからしか利用できないようにしてしまうことだってできます。StrongNameIdentityPermissionとか使えば。

で、こういうことができるということと、それを正しく利用するかどうかとはまったくべつの問題ですので、そこがウィルスの温床になる可能性があるんだ、という主張なら理解できます。でもそんなの.NETとXMLに限った話ではないですけどね。きっとキャッチーな話がしたかったんだろうな、くらいにし思ってません、私は。近頃の.netウィルス騒ぎといい、ちょっとマッチポンプの様相すら感じてます。

引用:

#ただ、以前はリフレクションを利用したモジュールを越えたNonPublicなメソッド呼び出しが可能だったように記憶しているのですが、現在はできなくなっています


こんなやつのことでしょうか？モジュールを超えた、というのがちょっと？ですが。
コード:
Type t = Type.GetType("System.Console");
MethodInfo m = t.GetMethod("GetConsoleCPNative", BindingFlags.Static | BindingFlags.NonPublic);
if (m != null) {
  object ret = m.Invoke(null, null);
  Console.WriteLine(ret);
}
arton
会議室デビュー日: 2002/03/22
投稿数: 19
投稿日時: 2002-03-29 10:06
引用:

NothingBut.NETFXさんの書き込み (2002-03-29 02:55) より:

引用:

こんなやつのことでしょうか？モジュールを超えた、というのがちょっと？ですが。

あっ、どうもありがとうございます。おかげで自分の中で現象が整理できました。
以前出来ていたのはそっちで、今出来なくてちょっと困ってるのはダイナミックアセンブラだからだ（コンパイル時点ではリフレクションを使っているけど実際に動くときは静的な呼び出しになっている）、と理解できました。
arton
会議室デビュー日: 2002/03/22
投稿数: 19
投稿日時: 2002-03-31 03:02
[quote]
artonの書き込み (2002-03-29 10:06) より:
引用:

以前出来ていたのはそっちで、今出来なくてちょっと困ってるのはダイナミックアセンブラだからだ（コンパイル時点ではリフレクションを使っているけど実際に動くときは静的な呼び出しになっている）、と理解できました。

間違いなので修正。コンパイルしているプログラムにとっては、ランタイムライブラリは自分自身なので問題なし。コンパイル後のプログラムは別アセンブリなので問題あり。
#で、やっぱり他のアセンブリのNonPublicなメソッドが呼べてたような。で、それはパーミッションの問題で許可されていたのであろうということで、今度はそのへんをまじめに研究します。
NothingBut.NETFX
大ベテラン
会議室デビュー日: 2001/09/13
投稿数: 102
投稿日時: 2002-03-31 04:28
引用:

artonさんの書き込み (2002-03-31 03:02) より:
#で、やっぱり他のアセンブリのNonPublicなメソッドが呼べてたような。で、それはパーミッションの問題で許可されていたのであろうということで、今度はそのへんをまじめに研究します。


私の上記のコードですと、System.Consoleは(自分じゃない)他のアセンブリに入ってますから、他のアセンブリのNonPublicを呼んでいると思うんですが。。。こういうことではない？

どういうことができないのかわからないのでなんともいえませんが、Beta2からRTMでアセンブリのロードで変わった点といえば、Strong Name付きのアセンブリをAssembly.Loadするときは名前は省略できないとか、Assembly.LoadFromでロードしたアセンブリとAssembly.Load（およびメタデータで静的リンク）でロードしたアセンブリはキャッシュが違うとかいうあたりでしょうかねぇ。。。ReflectionはどのみちFullTrustに近いものがないとできませんし。
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）