はじめに：TidGi Desktopとフロントエンドエンジニアへの関連性

TidGi Desktopは、TiddlyWikiをデスクトップアプリケーションとして利用するためのツールであり、Electronフレームワークで構築されています。ElectronはHTML、CSS、JavaScriptといったWeb標準技術を用いてデスクトップアプリケーションを開発できるため、多くのフロントエンドエンジニアが関心を持つ分野です。

しかし、Electronアプリケーションは単なるWebページではなく、Node.jsの強力な権限を持ったプロセスで動作します。そのため、ブラウザ上では不可能なファイルシステムの読み書きや、外部プロセスの実行なども可能になります。この特性が、今回見つかったRCE（Remote Code Execution：リモートコード実行）脆弱性の根本原因と深く関わっています。

脆弱性の概要：GHSA-9hc2-hjx8-q6pv

GHSA-9hc2-hjx8-q6pvとして識別されるこの脆弱性は、TidGi Desktopのバージョン0.13.0以前に影響します。深刻度は「Critical」と評価されており、攻撃者はユーザーが単一の悪意あるGitリポジトリをインポートするだけで、そのシステム上で任意のコードを実行できてしまいます。

具体的な攻撃シナリオは非常にシンプルです。ユーザーが悪意のあるTiddlyWikiリポジトリを「ワークスペースの追加」機能を通じてインポートすると、TidGi Desktopがそのリポジトリ内の悪意のあるJavaScriptコードを自動的に読み込み、Node.jsの全権限で実行してしまいます。これにより、攻撃者はファイルの読み書き、リバースシェル、システムへの永続的なアクセスなど、多岐にわたる悪質な操作が可能となります。

技術的な詳細：RCE発生のメカニズム

この脆弱性は、TidGi Desktopが基盤とするTiddlyWikiのモジュールシステムと、Node.js環境での実行が組み合わさることで発生します。根本原因は以下の3つの要素に集約されます。

TidGiがwikiワークスペースを起動する際、`tiddlers/`ディレクトリに配置された全ての`.tid`ファイルが、自動的にTiddlyWikiのストアに読み込まれます。これはwikiのコンテンツを構成するための標準的な動作です。

読み込まれた`.tid`ファイルの中に、`module-type`というフィールドを持つものがあると、TiddlyWikiの起動シーケンス中に`defineTiddlerModules()`関数がそれを「実行可能なモジュール」として自動的に登録します。特に、`module-type: startup`と`type: application/javascript`を持つティドラーは、JavaScriptコードとして解釈され、起動時に実行されるようにマークされます。

登録された`"startup"`タイプのモジュールは、TidGiの起動シーケンス（`$tw.boot.startup()`）中に自動的に実行されます。最も危険なのは、この実行がNode.jsのフル権限を持つプロセス（Wiki Workerプロセス）で行われる点です。モジュールのJavaScriptコードには、`require()`関数を通じて`child_process`や`fs`といったNode.jsの組み込みモジュールにアクセスする権限があるため、任意のシェルコマンド実行やファイル操作が可能となります。

さらに、モジュールの実行前にはプラットフォームの制限をチェックする機能がありますが、`platforms`フィールドが明示的に設定されていない場合、このチェックは無条件に「通過」と判断されます。これにより、攻撃者が作成したコードは、macOS、Windows、Linuxといった全てのプラットフォームで実行される可能性を秘めています。

攻撃の実演（Proof of Concept）

攻撃者が用意する悪意のあるTiddlyWikiリポジトリは、以下のような内容の`.tid`ファイルを`tiddlers/`ディレクトリに含んでいるだけです。

``` title: $:/plugins/poc/startup.js type: application/javascript module-type: startup exports.startup = function() { require('child_process').execSync('touch /tmp/TidGi-RCE-PoC.txt'); console.log('STARTUP_EXECUTED'); }; ```

このファイルがインポートされTidGiが起動すると、`exports.startup`内のコードが実行され、macOSでは`/tmp/TidGi-RCE-PoC.txt`というファイルが作成されることが検証されています。これは、攻撃者が望む任意のコマンドを実行できることを明確に示しています。

対策とフロントエンド開発者への教訓

この脆弱性に対する推奨されるパッチは複数提案されていますが、これらはElectronアプリケーション開発におけるセキュリティのベストプラクティスを示唆しています。

TiddlyWikiは、システムが提供するティドラー（システムティドラー）とユーザーが作成するティドラーを区別すべきです。ユーザーが作成したティドラーには、安全でない可能性のある`module-type`フィールドの定義を許可しないことが重要です。

もしユーザーが作成したモジュールの実行をサポートする必要がある場合、それらをNode.jsの組み込み機能へのアクセスを制限したサンドボックス内で実行すべきです。`vm`モジュールなどを使用し、安全なAPIのみを公開することで、悪意のあるコードの実行を阻止できます。

ユーザーティドラーに許可する`module-type`の値を厳密にホワイトリスト化することも有効です。例えば、`widget`、`macro`、`filter`、`parser`といった、安全性が確認された値のみを許可し、`startup`や`library`などの潜在的に危険なタイプはブロックします。

Electronアプリケーションを開発するフロントエンドエンジニアは、Web技術を使っていても、その背後にはNode.jsの強力な権限が存在することを常に意識する必要があります。ユーザーが提供するコンテンツやコード（今回の例ではTiddlyWikiの`.tid`ファイル）を扱う際は、以下のセキュリティ原則を強く推奨します。

まとめ

TidGi DesktopのRCE脆弱性は、Electronのようなハイブリッドアプリケーション開発において、WebのセキュリティモデルとNode.jsのセキュリティモデルの間のギャップがどのように深刻な脅威につながるかを示す典型的な事例です。フロントエンドエンジニアも、デスクトップアプリケーション開発に携わる際は、単なるUI/UXの実装だけでなく、より深いレベルでのセキュリティメカニズムとリスクを理解し、対策を講じることが求められます。