Mozilla HacksのLetting users block injected third-party DLLs in Firefoxを読みました。Firefox 110で、Windows版Firefoxに読み込まれる第三者DLLを利用者がブロックできるようになった、という記事です。
Windowsでは、ウイルス対策ソフト、ドライバー、スクリーンリーダー、銀行系ソフトなどが、別プロセスへDLLを注入して連携することがあります。記事では、Windows版Firefox利用者の70%以上で少なくとも1つの第三者DLLが確認されていると説明されています。一方で、こうしたDLLはFirefox内部の関数にフックすることがあり、クラッシュ、性能低下、セキュリティ上の懸念につながる場合があります。
記事の要点
- Firefox 110では、about:third-party から、問題を起こしている第三者DLLを確認し、利用者がブロックできるようになりました。
- Mozillaは以前から既知の問題DLLを静的にブロックする仕組みを持っていましたが、それは多数のクラッシュを起こすような場合の最後の手段です。
- すべてのDLL注入を既定で止めると、スクリーンリーダーや地域固有の銀行・行政系ソフトなど、利用者に必要な機能まで壊す恐れがあります。
- ブロックに失敗したり問題が起きたりした場合は、Troubleshoot Modeで一時的にDLLブロックを無効化できます。
- 技術的には、FirefoxのLauncher Processが起動の早い段階でブロックリストを渡し、DLL読み込み時の処理をフックして、対象DLLのロードを失敗させます。
参照リンクから見えたこと
記事中のリンク先も確認しました。サポート記事では about:third-party が、読み込まれたモジュール名、発行元、発生回数、ロード時間、クラッシュ関与の警告などを表示するページとして説明されています。利用者が「Firefoxが不安定」と感じたときに、原因がブラウザ本体なのか、注入された外部モジュールなのかを切り分ける入口になっています。
関連するMozilla Hacks記事のSite IsolationやFirefox 100のProcess Isolationも読むと、Firefoxが信頼できないWebコンテンツをプロセス分離で閉じ込めようとしている流れが分かります。第三者DLL注入は、その分離されたプロセスの中へ外部コードが入ってくる話なので、別方向からブラウザの安定性と安全性を揺らす問題です。
技術面では、Launcher Process、WindowsのCreateFileMapping、WriteProcessMemory、NtMapViewOfSection周辺の説明が重要です。さらにFirefox Source DocsのWindows DLL Blocklistingでは、静的ブロックリストと利用者向けの動的ブロックリストの違いも整理されています。
気づき
今回の気づきは、この機能が「外部DLLは危険だから全部止める」という設計ではなく、「必要な連携は残しつつ、問題が見えたときに利用者が止められる」設計になっていることです。ブラウザの安全性を高めるだけなら一律ブロックが単純ですが、実際の環境ではアクセシビリティ、業務、地域固有のサービスが絡みます。Firefoxはそこで、診断情報と選択肢を利用者に渡す方向を選んでいます。
コメントを残す