あれあなでしこ学習日記

お久しぶりです。

今回はちょっとなでしこをセキュリティの面から見てみようと思います。

なでしこは、現状でも非常に簡単な文章で高度な事が出来る言語です。

ただ、簡単さを求めるが故に、多少危険な処理があるようにも見えます。

MLでも書いたのですが、なでしこには"取り込む"というプリプロセス命令があります。

この命令を利用すると、外部にあるなでしこで記述されたテキストファイルを実行する事が出来ます。

この機能が何の役に立つかと言えば、たとえば自作のソフトにプラグイン的な物を作成したり、

処理の一部をモジュールとして外部ファイル化することで全体をいじることなく簡単に修正が出来たりする、といった事です。

ただし、この"取り込む"命令には危険な面もあります。

それは、取り込まれる側のファイルにどんなコードが書かれてようが、問答無用で実行されてしまうのです。

つまり、なでしこの構文に規準したテキストファイルであれば、悪意のある物だったとしても、その悪意のある処理は

ユーザーの確認なしに実行されてしまいます。

これはさすがに不味いのではないかと思い、自分でも対策をいろいろと考えましたが、

現在のなでしこでは"取り込む"はプリプロセス命令であるため、

言語本体をいじらないとこの問題には対処出来ないような気がします。("ナデシコする"等すれば可能ですが、それはそれで危険。)

そんなことを考えているうちに、なでしこを新規開発する"なでしこ2.0"というプロジェクトが活発になってきていました。

そこで、なでしこ2.0では現在のなでしこと同じように簡単。それであって安全な言語にできたらなぁと思いました

言語を新規開発するとして、どのような処理をすれば安全に"取り込み"出来るか、少し考えてみました。

完全に安全とは言い切れませんが、ソフト別に対策するかヘッダ情報を読み取り悪意のあるソースを出力するプログラムが無い限りは安全です。

簡易な署名的な物です。

まず、今まで通りに取り込む側(取り込むを利用する側)のプログラムをユーザーに書いてもらいます。

そこで出来上がった日本語構文のテキストを中間言語に変換します。

ここで、中間言語に変換したソースコードから、ハッシュ値(MD5等)を抜き出します。

この情報は取り込まれる側のファイルにて利用されます。

この後、取り込む側はバイナリとして出力します。

取り込まれる側は、日本語構文で書かれたテキストを中間言語に変換したモジュールのヘッダ情報に

先ほどのハッシュ値を書き込みます。

この後、取り込まれる側のヘッダにあるハッシュ値とバイナリ側にあるハッシュ値が一緒でなければ取り込めないような処理を組み込めば

現在よりだいぶ安全にはなると思います。

ただ、この方法だと少し問題が出来ます。

本体側のソースが少しでも変わってしまった場合、ハッシュ値が変わってしまうため

処理上互換性があるのに今まで取り込めていたファイルはハッシュ情報が違うため取り込めなくなってしまいます。

そこで、先ほどのハッシュ値の代わりにユーザーが指定出来るコンシューマキーを利用する、というのもどうかと思いました。

特にビルド時(?)に明示されていない場合はハッシュ値による制限、ユーザーが設定したいのであれば設定。という風にすれば良いかと思います。

ただ、初心者の方にはとっつきにくくなるかもしれないという部分はあります。

ですが初心者の方には後者の機能は必要無いかと思われますので、エディタのオプションに上級者用モードか何かの設定をもうけて

それがオンであった場合にのみこのオプションを表示する、等すれば良いかなと思います。

思いつきで一気に書いたため、文章がぐちゃぐちゃで見苦しいかもしれません。。。

何か問題、良い案等あれば指摘していただけるとありがたいです。

なでしこで作られた実行ファイルがNorton2010にてかなり誤検出されてしまう模様...

自分の環境ではこんな感じでした。

・cnako 暗号化なし(cnako_DisableSecure.exe) 誤検出

・cnako 暗号化あり(cnako_EnableSecure.exe) 誤検出

・gnako 暗号化なし(gnako_DisableSecure.exe) 誤検出

・gnako 暗号化あり(gnako_EnableSecure.exe) 誤検出

・vnako 暗号化なし(vnako_DisableSecure.exe) 正常

・vnako 暗号化あり(vnako_EnableSecure.exe) 正常

いずれも未知のウィルスとして扱われてしまいます。

2009の時は全くそういう事が無かったので、2010になって未知のウィルスへの対策エンジン(SONAR)が

2.0になったのが原因かと思われます。

調べてみたところ、HSPなどで作られたアプリケーションも誤検出されてしまうようです。

ホック系処理を行っているネイティブアプリケーションに関しても、かなりの確率で誤検出されます。(DxWnd等)

NIS2010を使ってる方向けにテスト用ファイル一式を用意しました。

中にはなでしこフリー版で作成したテスト用アプリのソースと各実行形式の実行ファイルを梱包しています。

DL(area Project)

いやはや･･･困った。

とりあえずメモ。

[Main.nako]

//////////////////

!`MAIN`にネームスペース変更 //現在の最優先？ネームスペースを"MAIN"に変更する。

!LOAD=1 //ネームスペース"MAIN"中でLOADという定数を宣言。中身は1。

!`Sub.nako`を取り込む //Sub.nakoをInclude

!`SUB`にネームスペース変更 //対象(最優先？)なネームスペースを"SUB"に変更する

もし(LOAD=2)なら //この場合ネームスペース"SUB"の"LOAD"定数が参照される。

　　`Sub.nakoは正常に取り込まれています。`という

//////////////////

[Sub.nako]

//////////////////

!`SUB`にネームスペース変更 //現在のネームスペースを"SUB"に変更する。

!LOAD=2 //ネームスペース"SUB"の中でLOADという定数を宣言。中身は2。

!`MAIN`にネームスペース変更 //対象(最優先？)なネームスペースを"MAIN"に変更する。

もし(LOAD=1)なら //この場合ネームスペース"MAIN"の"LOAD"定数が参照される。

　　`Main.nakoは正常に取り込まれています。`という

//////////////////

実行順序はこんな感じ？

実行開始。[Main.nako]

ネームスペースの変更。[Main.nako]→[MAIN]

定数"LOAD"の宣言。[MAIN] LOAD=1

"Sub.nako"の取り込みを開始[MAIN]

"Sub.nako"を実行開始。[Sub.nako]

ネームスペース変更。[Sub.nako]→[SUB]

定数"LOAD"の宣言。[SUB] LOAD=2

ネームスペースの変更。[SUB]→[MAIN]

条件分岐。[SUB]

└>条件が一致したためメッセージを表示。

"Sub.nako"の実行が完了したため処理が"Main.nako"に戻る。

ネームスペースの変更。[MAIN]→[SUB]

条件分岐。[MAIN]

└>条件が一致したためメッセージを表示。

実行完了。

待機。

# うーん･･･すんげーややこしい･･･

# やっぱり[名前空間:オブジェクト]で出来た方が自然だし楽だよねー。。。

ネームスペースの件UDさんのおかげで直ったようですね、うれしいばかりです。

現在私のやる気が猛烈に無くなっておりこのような状態ですのでコラムはしばらくお待ちください

http://aoikujira.com/nadesiko/bugbbs/mbbs.php?m=thread&threadid=460

名前空間をサポートしてるなでしこ。

でも取り込み元の名前空間を取得出来なかったら…おしいなぁ…(某CM風に

# どうでもいいけどC++とかでもNameSpaceを名前空間って読んでるのに

　 日本語プログラミング言語のなでしこがネームスペースってどういうことなの(ｗ