「Tips/華和梨」の編集履歴（バックアップ）一覧はこちら
「Tips/華和梨」(2012/05/15 (火) 19:31:05) の最新版変更点
追加された行は緑色になります。
削除された行は赤色になります。
<h3><a name="security">華和梨Phase 8とセキュリティ</a></h3>
<p align="left">
ゴーストの受け取るイベントの発生源は、MATERIA・SSP・CROW等の、ベースウェアに限りません。SAORIモジュールがDirect
SSTPでイベントを送信する場合、「猫どりふ」のような外部ツールがDirect SSTP/Socket
SSTPで送信してくる場合、そしてローカルマシン以外からネットワーク経由でSocket
SSTPを送信してくる場合等、さまざまなケースが考えられます。こうしたベースウェア以外のSSTPによるイベントは、ゴーストをマスコットからエージェントへ進化させるポテンシャルを持つとして、以前から注目されていました。しかし、SSTPはネットワークを利用する為、外部からの侵入の可能性があります。また、栞の能力が向上した結果、ゴーストのセキュリティホールが与える影響は非常に大きくなりました。</p>
<p align="left">今回は、華和梨phase
8を使ったゴーストに起こり得る幾つかのセキュリティホールと、その対策を解説します。このセキュリティホールは、仮にsecuritylevelをlowにしない場合でも、幾つかのツールをゴーストと併用した場合に発生します。また、ミドルウェア側で対策が講じてあっても、ゴースト側での処置でセキュリティホールが発生することもあります。対処は割と簡単ですので、是非一読するようお願いします。</p>
<h4><a name="whatssecurity">セキュリティホールの実体</a></h4>
<p align="left">NOTIFY SSTP/1.1を使い、外部から次のような悪意あるメッセージが来たとします。</p>
<blockquote>
<pre>
NOTIFY SSTP/1.1<br />Sender: Cr@cker<br />Event: OnCommunicate<br />Reference0: 悪党<br />Reference1: \h\s7消えろ！\e<br />IfGhost: きぃ<br />Script: \h\s4\w8\w8\e<br />Charset: Shift_JIS
</pre></blockquote>
<p align="left">
このSSTP例は、特に深刻な攻撃の例です。もしこのスクリプトを評価した上で本体に返した場合、ネットワーク更新先を変更された上でネットワーク更新がかかります。もし攻撃が成功してしまった場合、ゴーストはワームと化します。</p>
<p>
通常、SecurityLevelをlowにしない限り、華和梨はこうした危険な外部SSTPを処理することがありません。しかし、外部SSTPをローカルSSTPに中継するツールを併用する場合を考えます。ツールがSENDだけではなくNOTIFYも通してしまった場合、
SecurityLevelがlowにした場合と同じ危険があります。こうした不測の事態に備え、次のような対策を取ることをお薦めします。</p>
<h4><a name="security1">1.コードとして評価しない</a></h4>
<p align="left">
System.Request.*エントリは、こうした攻撃を想定して、内容を文字列として格納しています。従って、${System.Request.Reference1}と書いても、上のSSTP例のKIS部分は「ただの文字列」なので実行されません。しかし、</p>
<blockquote>
<pre>
$( @temp ${System.Request.Reference1})
</pre></blockquote>
<p align="left">または</p>
<blockquote>
<pre>
$( ${System.Request.Reference1})
</pre></blockquote>
<p align="left">
このように書いたが最後、上のSSTP例のReference1は「生きたコード」となり、セーブファイルは破壊されてしまいます。よほどの理由がない限り、エントリへの格納／追加は、
setstrやpushstrといった「str」がついている方のコマンドを使いましょう。エントリ操作コマンドのうち、「str」が付いているコマンドは、格納する対象にKIS、エントリ呼び出しが含まれていても、すべて「文字列」扱いして格納します。外部から「生きた危険なコードで」汚染されているかもしれない場合、文字列として扱うことが重要となります。</p>
<p align="left">さらに、華和梨デバッガの使用するOnShioriEchoイベントは、 $(debugger
on)の状態ではReference0を自動的に評価してしまいます。これは華和梨の組み込み動作であり、スクリプトでのオーバーライドが不可能です。デバッグ時は別として、ゴーストを$(debugger
on)の状態で配布することは、事実上ゴーストに侵入用裏口を作っているも同然です。必ずデバッグ用のdebuggerコマンドは、配布時に外してください。</p>
<h4><a name="security2">2.大事なエントリは保護する</a></h4>
<p align="left">1.の対策で、こうした事態は十分防げる筈です。しかし、二重の安全作として、ネットワーク更新先URLを記録したエントリは、
writeprotectをかけることを強くお薦めします。もしネットワーク更新先URLが書き換えられると、更新をしただけで、栞をスパイウェア付に書き換えられたり、ゴーストが個人情報をばら撒いたり、非常な危険な事態が起こり得ます。</p>
<blockquote>
<pre>
resource.homeurl : "<a href="http://shobu.hp.infoseek.co.jp/ghost/">http://shobu.hp.infoseek.co.jp/ghost/</a>"<br /> =kis<br /> writeprotect resource.homeurl;<br /> =end
</pre></blockquote>
<p align="left">
また、レイヤリング構造自体を改変して、ネットワーク更新先URLを記録するエントリ名自体を変更される恐れもあります。これにも対策したい場合、辞書読み込みが完了した時点で、ミドルウェアレベルでレイヤリング構造にもwriteprotectをかけると良いでしょう。</p>
<blockquote>
<pre>
#kawarirc.kisの最後に、以下を追加する<br /> =kis<br /> listtree @ToProtect System.Callback;<br /> listtree @ToProtect event;<br /> listtree @ToProtect resource;<br /> listtree @ToProtect notify;<br /> foreach @n @ToProtect $(writeprotect ${ @n });<br /> =end
</pre></blockquote>
<h4><a name="security3">3.危険なさくらスクリプトタグを通さない</a></h4>
<p align="left">
1.と2.の対策で、華和梨にとって危険な部分は対処できます。しかし、ゴーストとPCにとって危険はまだ残っています。上のSSTP例は、ゴースト間コミュニケートを装っています。ゴースト間コミュニケートの場合、相手ゴーストを知らなかった時、「○○が何か言ってるね」と相手ゴースト名を言う例をしばしば見かけます。すると、上のSSTP例は相手ゴースト名の中に自己消去タグが含まれている為、相手ゴースト名を言うだけで、自分が消されてしまいます。<br />
また、ワームを含んだページのURLをブラウザに開かせ、対策の甘いPCをワームに感染させてしまう場合も考えられます。勝手にパッシブモードに入ってしまうケースも、十分迷惑です。</p>
<p align="left">
こうした事態を防ぐ為、危険なタグを無効化してからReferenceを参照することをお薦めします。例えば、次のようなコマンドを定義します。</p>
<blockquote>
<pre style="width:1439px;height:.92%;">
<br />=kis<br />:rem<br />外部SSTPに存在した場合、危険なタグを無害化<br />第1引数: 文字列<br />戻り値: タグを無害化した文字列<br />:endrem<br />function KillDangerousTag $(<br /> if $[ $(size @arg) != 2 ] $(return);<br /> setstr @string <a href="mailto:$@arg%5B1">$@arg[1</a>];<br /> foreach @tag kp.dangeroustag $(<br /> # 無害化したタグを生成<br /> setstr @killedtag " _"$(substr <a href="mailto:$%7B@tag">${@tag</a>} 2);<br /> setstr @pos $(match <a href="mailto:$%7B@string">${@string</a>} <a href="mailto:$%7B@tag">${@tag</a>});<br /> # 危険タグが存在したら、無害化したタグに置換<br /> if $[ <a href="mailto:$%7B@pos">${@pos</a>} != -1 ] $(<br /> setstr @string $(gsub <a href="mailto:$%7B@string">${@string</a>} <a href="mailto:$%7B@tag">${@tag</a>} <a href="mailto:$%7B@killedtag">${@killedtag</a>});<br /> );<br /> );<br /> return <a href="mailto:$%7B@string">${@string</a>};<br />);<br />=end<br /># KillDangerousTag内部で参照している危険なタグのリスト<br /># 必ず2文字以上からなるタグを書くこと<br /> kp.dangeroustag (<br /> "<a>\\![updatebymyself</a>]",<br /> "<a>\\![vanishbymyself</a>]",<br /> "<a>\\![enter,passivemode</a>]",<br /> "<a>\\![leave,passivemode</a>]",<br /> "<a>\\![lock,repaint</a>]",<br /> "<a>\\![unlock,repaint</a>]",<br /> "<a>\\![biff</a>]",<br /> "<a>\\![open,browser</a>",<br /> "<a>\\![open,mailer</a>",<br /> "<a>\\![raise</a>",<br /> "<a>\\j</a>["<br />)<br /># タグリストが消されて無効化されないよう、エントリを保護<br />=kis<br />writeprotect kp.dangeroustag;<br />=end<br />=kis<br /># Reference*参照<br /># 第1引数: Reference番号<br /># 戻り値: Reference*の内容<br />function Reference $(get <a href="mailto:System.Request.Reference$@arg%5B1%5D%5B0">System.Request.Reference$@arg[1][0</a>]);<br /># 危険なさくらスクリプトタグを無害化した上でReference*参照<br /># 第1引数: Reference番号<br /># 戻り値: 危険なさくらスクリプトタグをを無害化したReference*の内容<br />function SReference $(KillDangerousTag $(Reference <a href="mailto:$@arg%5B1">$@arg[1</a>]));<br />=end
</pre></blockquote>
<p>
そして、バルーン内にReferenceの内容を表示する場合、次のようにして危険なタグを無効化します。この場合、無効化したタグがゴミとしてバルーン内に出ますが、ユーザへの警告になるでしょう。</p>
<blockquote>
<pre>
event.OnCommunicate : (<br /> \1\s[10]<br /> \0\s[0]<br />が何か言ってるね。\w8\w8\n<br /> とりあえず無視しておこっと。\w8\w8<br /> \1危なそうだしな。\w8\w8<br /> \e<br />)
</pre></blockquote>
<p align="left">このようなさくらスクリプトのフィルタリングは、どのタグが危険かの判断が面倒であり、
Referenceの参照が不便になりがちなので、通常はミドルウェアで対処すると良いでしょう。独自レイヤーを使用している場合は、上の例が必要最低限の記述を行っていますので、自由に流用して下さい。特に制限は設けません。</p>
<h3><a name="security">華和梨Phase 8とセキュリティ</a></h3>
<p align="left">
ゴーストの受け取るイベントの発生源は、MATERIA・SSP・CROW等の、ベースウェアに限りません。SAORIモジュールがDirect
SSTPでイベントを送信する場合、「猫どりふ」のような外部ツールがDirect SSTP/Socket
SSTPで送信してくる場合、そしてローカルマシン以外からネットワーク経由でSocket
SSTPを送信してくる場合等、さまざまなケースが考えられます。こうしたベースウェア以外のSSTPによるイベントは、ゴーストをマスコットからエージェントへ進化させるポテンシャルを持つとして、以前から注目されていました。しかし、SSTPはネットワークを利用する為、外部からの侵入の可能性があります。また、栞の能力が向上した結果、ゴーストのセキュリティホールが与える影響は非常に大きくなりました。</p>
<p align="left">今回は、華和梨phase
8を使ったゴーストに起こり得る幾つかのセキュリティホールと、その対策を解説します。このセキュリティホールは、仮にsecuritylevelをlowにしない場合でも、幾つかのツールをゴーストと併用した場合に発生します。また、ミドルウェア側で対策が講じてあっても、ゴースト側での処置でセキュリティホールが発生することもあります。対処は割と簡単ですので、是非一読するようお願いします。</p>
<h4><a name="whatssecurity">セキュリティホールの実体</a></h4>
<p align="left">NOTIFY SSTP/1.1を使い、外部から次のような悪意あるメッセージが来たとします。</p>
<blockquote>
<pre>
NOTIFY SSTP/1.1<br />Sender: Cr@cker<br />Event: OnCommunicate<br />Reference0: 悪党<br />Reference1: \h\s7消えろ！\e<br />IfGhost: きぃ<br />Script: \h\s4\w8\w8\e<br />Charset: Shift_JIS
</pre></blockquote>
<p align="left">
このSSTP例は、特に深刻な攻撃の例です。もしこのスクリプトを評価した上で本体に返した場合、ネットワーク更新先を変更された上でネットワーク更新がかかります。もし攻撃が成功してしまった場合、ゴーストはワームと化します。</p>
<p>
通常、SecurityLevelをlowにしない限り、華和梨はこうした危険な外部SSTPを処理することがありません。しかし、外部SSTPをローカルSSTPに中継するツールを併用する場合を考えます。ツールがSENDだけではなくNOTIFYも通してしまった場合、
SecurityLevelがlowにした場合と同じ危険があります。こうした不測の事態に備え、次のような対策を取ることをお薦めします。</p>
<h4><a name="security1">1.コードとして評価しない</a></h4>
<p align="left">
System.Request.*エントリは、こうした攻撃を想定して、内容を文字列として格納しています。従って、${System.Request.Reference1}と書いても、上のSSTP例のKIS部分は「ただの文字列」なので実行されません。しかし、</p>
<blockquote>
<pre>
$( @temp ${System.Request.Reference1})
</pre></blockquote>
<p align="left">または</p>
<blockquote>
<pre>
$( ${System.Request.Reference1})
</pre></blockquote>
<p align="left">
このように書いたが最後、上のSSTP例のReference1は「生きたコード」となり、セーブファイルは破壊されてしまいます。よほどの理由がない限り、エントリへの格納／追加は、
setstrやpushstrといった「str」がついている方のコマンドを使いましょう。エントリ操作コマンドのうち、「str」が付いているコマンドは、格納する対象にKIS、エントリ呼び出しが含まれていても、すべて「文字列」扱いして格納します。外部から「生きた危険なコードで」汚染されているかもしれない場合、文字列として扱うことが重要となります。</p>
<p align="left">さらに、華和梨デバッガの使用するOnShioriEchoイベントは、 $(debugger
on)の状態ではReference0を自動的に評価してしまいます。これは華和梨の組み込み動作であり、スクリプトでのオーバーライドが不可能です。デバッグ時は別として、ゴーストを$(debugger
on)の状態で配布することは、事実上ゴーストに侵入用裏口を作っているも同然です。必ずデバッグ用のdebuggerコマンドは、配布時に外してください。</p>
<h4><a name="security2">2.大事なエントリは保護する</a></h4>
<p align="left">1.の対策で、こうした事態は十分防げる筈です。しかし、二重の安全作として、ネットワーク更新先URLを記録したエントリは、
writeprotectをかけることを強くお薦めします。もしネットワーク更新先URLが書き換えられると、更新をしただけで、栞をスパイウェア付に書き換えられたり、ゴーストが個人情報をばら撒いたり、非常な危険な事態が起こり得ます。</p>
<blockquote>
<pre>
resource.homeurl : "<a href="http://shobu.hp.infoseek.co.jp/ghost/">http://shobu.hp.infoseek.co.jp/ghost/</a>"<br /> =kis<br /> writeprotect resource.homeurl;<br /> =end
</pre></blockquote>
<p align="left">
また、レイヤリング構造自体を改変して、ネットワーク更新先URLを記録するエントリ名自体を変更される恐れもあります。これにも対策したい場合、辞書読み込みが完了した時点で、ミドルウェアレベルでレイヤリング構造にもwriteprotectをかけると良いでしょう。</p>
<blockquote>
<pre>
#kawarirc.kisの最後に、以下を追加する<br /> =kis<br /> listtree @ToProtect System.Callback;<br /> listtree @ToProtect event;<br /> listtree @ToProtect resource;<br /> listtree @ToProtect notify;<br /> foreach @n @ToProtect $(writeprotect ${ @n });<br /> =end
</pre></blockquote>
<h4><a name="security3">3.危険なさくらスクリプトタグを通さない</a></h4>
<p align="left">
1.と2.の対策で、華和梨にとって危険な部分は対処できます。しかし、ゴーストとPCにとって危険はまだ残っています。上のSSTP例は、ゴースト間コミュニケートを装っています。ゴースト間コミュニケートの場合、相手ゴーストを知らなかった時、「○○が何か言ってるね」と相手ゴースト名を言う例をしばしば見かけます。すると、上のSSTP例は相手ゴースト名の中に自己消去タグが含まれている為、相手ゴースト名を言うだけで、自分が消されてしまいます。<br />
また、ワームを含んだページのURLをブラウザに開かせ、対策の甘いPCをワームに感染させてしまう場合も考えられます。勝手にパッシブモードに入ってしまうケースも、十分迷惑です。</p>
<p align="left">
こうした事態を防ぐ為、危険なタグを無効化してからReferenceを参照することをお薦めします。例えば、次のようなコマンドを定義します。</p>
<blockquote>
<pre style="width:1439px;height:.92%;">
<br />=kis<br />:rem<br />外部SSTPに存在した場合、危険なタグを無害化<br />第1引数: 文字列<br />戻り値: タグを無害化した文字列<br />:endrem<br />function KillDangerousTag $(<br /> if $[ $(size @arg) != 2 ] $(return);<br /> setstr @string<a href="mailto:$@arg%5B1">$@arg[1</a>];<br /> foreach @tag kp.dangeroustag $(<br /> # 無害化したタグを生成<br /> setstr @killedtag " _"$(substr<a href="mailto:$%7B@tag">${@tag</a>} 2);<br /> setstr @pos $(match<a href="mailto:$%7B@string">${@string</a>}<a href="mailto:$%7B@tag">${@tag</a>});<br /> # 危険タグが存在したら、無害化したタグに置換<br /> if $[<a href="mailto:$%7B@pos">${@pos</a>} != -1 ] $(<br /> setstr @string $(gsub<a href="mailto:$%7B@string">${@string</a>}<a href="mailto:$%7B@tag">${@tag</a>}<a href="mailto:$%7B@killedtag">${@killedtag</a>});<br /> );<br /> );<br /> return<a href="mailto:$%7B@string">${@string</a>};<br />);<br />=end<br /># KillDangerousTag内部で参照している危険なタグのリスト<br /># 必ず2文字以上からなるタグを書くこと<br /> kp.dangeroustag (<br /> "<a>\\![updatebymyself</a>]",<br /> "<a>\\![vanishbymyself</a>]",<br /> "<a>\\![enter,passivemode</a>]",<br /> "<a>\\![leave,passivemode</a>]",<br /> "<a>\\![lock,repaint</a>]",<br /> "<a>\\![unlock,repaint</a>]",<br /> "<a>\\![biff</a>]",<br /> "<a>\\![open,browser</a>",<br /> "<a>\\![open,mailer</a>",<br /> "<a>\\![raise</a>",<br /> "<a>\\j</a>["<br />)<br /># タグリストが消されて無効化されないよう、エントリを保護<br />=kis<br />writeprotect kp.dangeroustag;<br />=end<br />=kis<br /># Reference*参照<br /># 第1引数: Reference番号<br /># 戻り値: Reference*の内容<br />function Reference $(get<a href="mailto:System.Request.Reference$@arg%5B1%5D%5B0">System.Request.Reference$@arg[1][0</a>]);<br /># 危険なさくらスクリプトタグを無害化した上でReference*参照<br /># 第1引数: Reference番号<br /># 戻り値: 危険なさくらスクリプトタグをを無害化したReference*の内容<br />function SReference $(KillDangerousTag $(Reference<a href="mailto:$@arg%5B1">$@arg[1</a>]));<br />=end
</pre></blockquote>
<p>
そして、バルーン内にReferenceの内容を表示する場合、次のようにして危険なタグを無効化します。この場合、無効化したタグがゴミとしてバルーン内に出ますが、ユーザへの警告になるでしょう。</p>
<blockquote>
<pre>
event.OnCommunicate : (<br /> \1\s[10]<br /> \0\s[0]<br /> $(SReference 0)が何か言ってるね。\w8\w8\n<br /> とりあえず無視しておこっと。\w8\w8<br /> \1危なそうだしな。\w8\w8<br /> \e<br />)
</pre></blockquote>
<p align="left">このようなさくらスクリプトのフィルタリングは、どのタグが危険かの判断が面倒であり、
Referenceの参照が不便になりがちなので、通常はミドルウェアで対処すると良いでしょう。独自レイヤーを使用している場合は、上の例が必要最低限の記述を行っていますので、自由に流用して下さい。特に制限は設けません。</p>
