ほぼすべての主要なLinuxディストリビューションでローカルユーザーがroot権限を取得可能な脆弱(ぜいじゃく)性「Dirty Frag」が報告されました。セキュリティ専門家によると攻撃の成功率は極めて高く、また、攻撃に失敗してもカーネルパニックを引き起こさないため危険性も高いとのことです。
「Dirty Frag」は、xfrm-ESPとRxRPCに存在する脆弱性を組み合わせることでroot権限を取得できる攻撃手法です。セキュリティ研究者のキム・ヒョヌ(@V4bel)氏は、2022年3月に公表された「Dirty Pipe」や2026年4月に公表された「Copy Fail」の後継クラスと表現しています。
対象となるLinuxディストリビューションとしてはUbuntu 24.04.4、RHEL 10.1、openSUSE Tumbleweed、CentOS Stream 10、AlmaLinux 10、Fedora 44と、主要なものがすべて挙げられています。
先行する「Copy Fail」は、カーネルの「algif_aead」モジュールの無効化によって軽減させる対策がありましたが、「Dirty Frag」はalgif_aeadモジュールが有効か無効かにかかわらず悪用される可能性があります。
このため、パッチが利用可能になるまで「esp4」「esp6」「rxrpc」の各モジュールをブロックしてロードできないようにすることが推奨されています。また、攻撃を受けた可能性がある場合はページキャッシュが汚染されているため破棄する必要があるとのこと。
なお、キム氏によると、各ディストリビューションが対応を調整する前に責任ある開示の公開禁止が破られたため、「Dirty Frag」を構成する2つの脆弱性に対するCVE識別子の割当は行われていないとのこと。
セキュリティを最優先に掲げるAlmaLinuxは、脆弱性が深刻であることと悪用が極めて容易であることを考慮し、CentOS StreamとRHELのアップデートに先駆けてパッチ適用済みカーネルを構築。testingリポジトリに提供し、コミュニティによる検証が済み次第、本番リポジトリにリリース予定となっています。
⇧ う～む...
- 脆弱性が深刻であること
- 悪用が極めて容易であること
にもかかわらず、「CVE識別子」が割当されないのは、脆弱性管理という意味では芳しくない気がしますが...
兎にも角にも、「パッチ適用済みカーネル」がリリースされるまでは、脆弱性の無い「バージョン」の「OS（Operation System）」に置き換えるぐらいしか手立てが無い気がしますが...
仮に、今回の「脆弱性」の対象となる「Linuxディストリビューション」の「バージョン」を利用している環境の場合、「クラウドサービスプロバイダー」の「サービス」で、且つ、「IaaS（Infrastructure as a Service）」以外の「サービス」であれば、「責任共有モデル」的に「クラウドサービスプロバイダー」側が責任を負うことになる気はしますが、それ以外の場合、対応が必要になると思われるのだが対応のタイミングが悩ましいですな...
まぁ、「IaaS（Infrastructure as a Service）」を利用して「マルチテナント」な「サービス」を提供している場合、対応の負担が大きそうね...
公式のtsgolintがメンテナンスされなくなっているらしいが...
ネットの情報を漁っていたところ、
⇧ 上記サイト様によりますと、公式の「tsgolint」がメンテナンスされなくなっているらしく、公式を「fork」されたものがメンテナンスされている状況らしい。
そもそもの発端として、
The core value proposition of TypeScript is an excellent developer experience. As your codebase grows, so does the value of TypeScript itself, but in many cases TypeScript has not been able to scale up to the very largest codebases. Developers working in large projects can experience long load and check times, and have to choose between reasonable editor startup time or getting a complete view of their source code.
https://devblogs.microsoft.com/typescript/typescript-native-port/
We know developers love when they can rename variables with confidence, find all references to a particular function, easily navigate their codebase, and do all of those things without delay. New experiences powered by AI benefit from large windows of semantic information that need to be available with tighter latency constraints. We also want fast command-line builds to validate that your entire codebase is in good shape.
https://devblogs.microsoft.com/typescript/typescript-native-port/
To meet those goals, we’ve begun work on a native port of the TypeScript compiler and tools. The native implementation will drastically improve editor startup, reduce most build times by 10x, and substantially reduce memory usage. By porting the current codebase, we expect to be able to preview a native implementation of tsc capable of command-line typechecking by mid-2025, with a feature-complete solution for project builds and a language service by the end of the year.
https://devblogs.microsoft.com/typescript/typescript-native-port/
⇧ 上記にありますように、「大規模」な「開発プロジェクト」において、「TypeScript」の「パフォーマンス」の問題があり、
- TypeScriptのコンパイラ（TypeScript compiler）
- TypeScriptのツール（TypeScript tools）
を「Go言語」に移植したという話がある模様。
一応、2016年時点の「TypeScript」の「アーキテクチャ」は、
Layer Overview
⇧ 上図のような構成になっている。
で、「tsgolint」は、「TypeScriptのツール（TypeScript tools）」の話になると思われる。
「Go言語」に移植後の「アーキテクチャ」が公開されてい無さそうなので、「TO BE」の状態が分からないのだが、
⇧ 上記サイト様によりますと、「Go言語」が選ばれた理由は、「実装」上の「コスト」の問題らしい。
とりあえず、
■ typescript-eslint/tsgolint
About
✨ Experimental proof-of-concept typescript-go powered JS/TS linter written in Go
■ oxc-project/tsgolint
⇧ まだ、2つとも「アーカイブ」されているわけでもなく、普通に公開されているので、非常にややこしい...
とりあえず、
⇧ 上記サイト様によりますと、「oxc-project/tsgolint」を利用しておけば良さそうではある。
ただ、
⇧ 上記のスライドの内容を見る限り、「保守・運用」面の負担が大きくなりそう...
とは言え、「大規模」な「開発プロジェクト」で「TypeScript」を利用するのであれば、「Go言語」に移植された
- TypeScriptのコンパイラ（TypeScript compiler）
- TypeScriptのツール（TypeScript tools）
を利用していかざるを得ない気がするので、選択肢はあって無いようなものという状況な気もする...
と言うか、「TypeScript」は「Microsoft」が開発したものだと思うので、
- TypeScriptのコンパイラ（TypeScript compiler）
- TypeScriptのツール（TypeScript tools）
についても「Microsoft」が「メンテナンス」を継続して欲しかったのだが...
TypeScript はマイクロソフトによって開発され、メンテナンスされているフリーでオープンソースのプログラミング言語である。TypeScriptはJavaScriptに対して、省略も可能な静的型付けとクラスベースオブジェクト指向を加えた厳密なスーパーセット（既存のものを全て含んだ上でより機能が拡張されている上位互換となるモノ）となっている。
C#のリードアーキテクトであり、DelphiとTurbo Pascalの開発者でもあるアンダース・ヘルスバーグがTypeScriptの開発に関わっている。TypeScriptはクライアントサイド、あるいはサーバサイド (Node.js) で実行されるJavaScriptアプリケーションの開発に利用できる。
TypeScriptは大規模なアプリケーションの開発のために設計されている。
⇧ 上記によると、そもそも「大規模」な「アプリケーション開発」向けを想定しているらしいので、「TypeScript」を利用するのであれば「Go言語」移植版の
- TypeScriptのコンパイラ（TypeScript compiler）
- TypeScriptのツール（TypeScript tools）
を利用していく感じになるのですかね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
