Mozilla HacksのImproved Process Isolation in Firefox 100を読みました。Firefox 100で到達したWindows向けのWin32k Lockdownを中心に、ブラウザのプロセス分離を強めるために何を作り替えたのかを解説する記事です。
FirefoxはWebコンテンツを別プロセスで動かすことで、攻撃者がページ経由でcontent processを突破しても、OSやブラウザ全体へ簡単には届かないようにしています。ただ、content processが従来どおりWindowsの広いAPIへ触れる状態では、まだ攻撃面が残ります。この記事の主役であるWin32k Lockdownは、特にwin32k.sys系のグラフィックやウィンドウ管理まわりのシステムコールをcontent processから切り離す取り組みです。
記事の要点
- Firefox 100では、Windowsのcontent processでWin32k Lockdownを進め、win32k.sysへのアクセスを大きく制限しました。
- この変更は単独では成立せず、Fission / Site IsolationやRLBoxと並ぶ、大きな防御強化の流れに位置づけられています。
- WebRenderによって、ページ描画の多くはcontent processではなくGPU Process側へ移せるようになりました。
- Canvas 2DやWebGLは、描画命令やGPU関連処理をIPC越しに扱う必要があり、性能と安全性の両方を見ながら調整されています。
- フォーム部品、スクロールバー、複雑な文字の改行処理、第三者DLL読み込みなど、一見サンドボックスと関係なさそうな領域まで影響が及んでいます。
- 同じ基盤整理により、macOSではWindowServerへのアクセス制限、Linuxではcontent processからX11 Serverへの接続削除にもつながっています。
参照リンクから見えたこと
記事中の参照先も確認しました。Site Isolationの記事では、異なるサイトを別プロセスに分け、Spectre系の攻撃で別サイトのメモリを読まれにくくする考え方が説明されています。今回の記事は、その分離したcontent process自体の権限をさらに削る話です。
RLBoxの記事も合わせると、Firefoxの防御は一枚岩ではないことが分かります。サイト単位で分ける、content processのOS権限を削る、さらにライブラリ単位で細かく隔離する、という複数の層を重ねています。
また、WebRender、MDNのCanvas API、WebGL APIを見ると、描画パイプラインの整理がセキュリティ強化にも効いている点が見えてきます。レンダリングの責任をGPU Process側へ移せる設計になっていたからこそ、content processからWindowsのグラフィック系APIを遠ざけられたわけです。
気づき
今回の気づきは、プロセス分離は「別プロセスにする」だけでは終わらないということです。分離した先のプロセスが、描画、フォーム、文字処理、DLL、GPU、OSウィジェットに直接触り続けるなら、攻撃面は残ります。Firefox 100の改修は、境界を引くだけでなく、その境界を越えていた責任を1つずつ別の安全な場所へ移す作業だったと言えます。
コメントを残す