Tips > 華和梨

華和梨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の参照が不便になりがちなので、通常はミドルウェアで対処すると良いでしょう。独自レイヤーを使用している場合は、上の例が必要最低限の記述を行っていますので、自由に流用して下さい。特に制限は設けません。