Tips > 華和梨


※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。

華和梨Phase 8とセキュリティ

ゴーストの受け取るイベントの発生源は、MATERIA・SSP・CROW等の、ベースウェアに限りません。SAORIモジュールがDirect SSTPでイベントを送信する場合、「猫どりふ」のような外部ツールがDirect SSTP/Socket SSTPで送信してくる場合、そしてローカルマシン以外からネットワーク経由でSocket SSTPを送信してくる場合等、さまざまなケースが考えられます。こうしたベースウェア以外のSSTPによるイベントは、ゴーストをマスコットからエージェントへ進化させるポテンシャルを持つとして、以前から注目されていました。しかし、SSTPはネットワークを利用する為、外部からの侵入の可能性があります。また、栞の能力が向上した結果、ゴーストのセキュリティホールが与える影響は非常に大きくなりました。

今回は、華和梨phase 8を使ったゴーストに起こり得る幾つかのセキュリティホールと、その対策を解説します。このセキュリティホールは、仮にsecuritylevelをlowにしない場合でも、幾つかのツールをゴーストと併用した場合に発生します。また、ミドルウェア側で対策が講じてあっても、ゴースト側での処置でセキュリティホールが発生することもあります。対処は割と簡単ですので、是非一読するようお願いします。

セキュリティホールの実体

NOTIFY SSTP/1.1を使い、外部から次のような悪意あるメッセージが来たとします。

NOTIFY SSTP/1.1
Sender: Cr@cker
Event: OnCommunicate
Reference0: 悪党
Reference1: \h\s7消えろ!\e
IfGhost: きぃ
Script: \h\s4\w8\w8\e
Charset: Shift_JIS

このSSTP例は、特に深刻な攻撃の例です。もしこのスクリプトを評価した上で本体に返した場合、ネットワーク更新先を変更された上でネットワーク更新がかかります。もし攻撃が成功してしまった場合、ゴーストはワームと化します。

通常、SecurityLevelをlowにしない限り、華和梨はこうした危険な外部SSTPを処理することがありません。しかし、外部SSTPをローカルSSTPに中継するツールを併用する場合を考えます。ツールがSENDだけではなくNOTIFYも通してしまった場合、 SecurityLevelがlowにした場合と同じ危険があります。こうした不測の事態に備え、次のような対策を取ることをお薦めします。

1.コードとして評価しない

System.Request.*エントリは、こうした攻撃を想定して、内容を文字列として格納しています。従って、${System.Request.Reference1}と書いても、上のSSTP例のKIS部分は「ただの文字列」なので実行されません。しかし、

$( @temp ${System.Request.Reference1})

または

$( ${System.Request.Reference1})

このように書いたが最後、上のSSTP例のReference1は「生きたコード」となり、セーブファイルは破壊されてしまいます。よほどの理由がない限り、エントリへの格納/追加は、 setstrやpushstrといった「str」がついている方のコマンドを使いましょう。エントリ操作コマンドのうち、「str」が付いているコマンドは、格納する対象にKIS、エントリ呼び出しが含まれていても、すべて「文字列」扱いして格納します。外部から「生きた危険なコードで」汚染されているかもしれない場合、文字列として扱うことが重要となります。

さらに、華和梨デバッガの使用するOnShioriEchoイベントは、 $(debugger on)の状態ではReference0を自動的に評価してしまいます。これは華和梨の組み込み動作であり、スクリプトでのオーバーライドが不可能です。デバッグ時は別として、ゴーストを$(debugger on)の状態で配布することは、事実上ゴーストに侵入用裏口を作っているも同然です。必ずデバッグ用のdebuggerコマンドは、配布時に外してください。

2.大事なエントリは保護する

1.の対策で、こうした事態は十分防げる筈です。しかし、二重の安全作として、ネットワーク更新先URLを記録したエントリは、 writeprotectをかけることを強くお薦めします。もしネットワーク更新先URLが書き換えられると、更新をしただけで、栞をスパイウェア付に書き換えられたり、ゴーストが個人情報をばら撒いたり、非常な危険な事態が起こり得ます。

resource.homeurl : "http://shobu.hp.infoseek.co.jp/ghost/"
=kis
writeprotect resource.homeurl;
=end

また、レイヤリング構造自体を改変して、ネットワーク更新先URLを記録するエントリ名自体を変更される恐れもあります。これにも対策したい場合、辞書読み込みが完了した時点で、ミドルウェアレベルでレイヤリング構造にもwriteprotectをかけると良いでしょう。

#kawarirc.kisの最後に、以下を追加する
=kis
listtree @ToProtect System.Callback;
listtree @ToProtect event;
listtree @ToProtect resource;
listtree @ToProtect notify;
foreach @n @ToProtect $(writeprotect ${ @n });
=end

3.危険なさくらスクリプトタグを通さない

1.と2.の対策で、華和梨にとって危険な部分は対処できます。しかし、ゴーストとPCにとって危険はまだ残っています。上のSSTP例は、ゴースト間コミュニケートを装っています。ゴースト間コミュニケートの場合、相手ゴーストを知らなかった時、「○○が何か言ってるね」と相手ゴースト名を言う例をしばしば見かけます。すると、上のSSTP例は相手ゴースト名の中に自己消去タグが含まれている為、相手ゴースト名を言うだけで、自分が消されてしまいます。
また、ワームを含んだページのURLをブラウザに開かせ、対策の甘いPCをワームに感染させてしまう場合も考えられます。勝手にパッシブモードに入ってしまうケースも、十分迷惑です。

こうした事態を防ぐ為、危険なタグを無効化してからReferenceを参照することをお薦めします。例えば、次のようなコマンドを定義します。


=kis
:rem
外部SSTPに存在した場合、危険なタグを無害化
第1引数: 文字列
戻り値: タグを無害化した文字列
:endrem
function KillDangerousTag $(
if $[ $(size @arg) != 2 ] $(return);
setstr @string$@arg[1];
foreach @tag kp.dangeroustag $(
# 無害化したタグを生成
setstr @killedtag " _"$(substr${@tag} 2);
setstr @pos $(match${@string}${@tag});
# 危険タグが存在したら、無害化したタグに置換
if $[${@pos} != -1 ] $(
setstr @string $(gsub${@string}${@tag}${@killedtag});
);
);
return${@string};
);
=end
# KillDangerousTag内部で参照している危険なタグのリスト
# 必ず2文字以上からなるタグを書くこと
kp.dangeroustag (
"\\![updatebymyself]",
"\\![vanishbymyself]",
"\\![enter,passivemode]",
"\\![leave,passivemode]",
"\\![lock,repaint]",
"\\![unlock,repaint]",
"\\![biff]",
"\\![open,browser",
"\\![open,mailer",
"\\![raise",
"\\j["
)
# タグリストが消されて無効化されないよう、エントリを保護
=kis
writeprotect kp.dangeroustag;
=end
=kis
# Reference*参照
# 第1引数: Reference番号
# 戻り値: Reference*の内容
function Reference $(getSystem.Request.Reference$@arg[1][0]);
# 危険なさくらスクリプトタグを無害化した上でReference*参照
# 第1引数: Reference番号
# 戻り値: 危険なさくらスクリプトタグをを無害化したReference*の内容
function SReference $(KillDangerousTag $(Reference$@arg[1]));
=end

そして、バルーン内にReferenceの内容を表示する場合、次のようにして危険なタグを無効化します。この場合、無効化したタグがゴミとしてバルーン内に出ますが、ユーザへの警告になるでしょう。

event.OnCommunicate : (
\1\s[10]
\0\s[0]
$(SReference 0)が何か言ってるね。\w8\w8\n
とりあえず無視しておこっと。\w8\w8
\1危なそうだしな。\w8\w8
\e
)

このようなさくらスクリプトのフィルタリングは、どのタグが危険かの判断が面倒であり、 Referenceの参照が不便になりがちなので、通常はミドルウェアで対処すると良いでしょう。独自レイヤーを使用している場合は、上の例が必要最低限の記述を行っていますので、自由に流用して下さい。特に制限は設けません。

ツールボックス

下から選んでください:

新しいページを作成する
ヘルプ / FAQ もご覧ください。