オープンソースのメンテナーがnpmパッケージcolorsとfakerを停止。次にすべきことは？

2022年1月8日、広く利用されているnpmパッケージcolorsのオープンソースメンテナーが、ソースコードに無限ループを追加するコミットを意図的に含むcolors@1.4.1とcolors@1.4.44-liberty-2を公開しました。この無限ループは、パッケージのソースコードの初期化時にただちに実行され、これを使用するNode.jsサーバーでサービス拒否（DoS）を引き起こします。

要約：Snykは、colors@1.4.1にサービス拒否のセキュリティ脆弱性を登録しました。原因はこちらの脆弱なコードです。ただちにcolors@1.4.0に戻し、問題のあるバージョンへの意図しないアップグレードを避けるため、依存関係のバージョンを固定することを強くおすすめします。また、別のパッケージへの移行もおすすめします。影響範囲や深刻度、推奨される対策について、詳しくは以下をご覧ください。

colorsについて

オープンソースのnpmパッケージcolorsは、週に2,000万回以上ダウンロードされ、JavaScriptやNode.js開発者にとって重要なエコシステムプロジェクトとして、数多くのプロジェクトを支えています。GitHubの記録によると、colorsは400万以上のプロジェクトで使用されており、npmjs.orgによると、このnpmパッケージに依存するパッケージは18,962個あります。

colorsに依存するプロジェクトをいくつかご紹介します。

• コマンドライン用ヘルパーprompt（週約50万ダウンロード）

• Unicodeテーブルの整形ツールcli-table3（週約700万ダウンロード）

• AWSが提供するaws-cdk（週約200万ダウンロード）

実際、問題のあるバージョンcolors@1.4.1は非常に多くのユーザーに影響するため、軽視できません。npmjsのパッケージページの統計によると、このブログ記事の執筆時点で同バージョンは95,397回ダウンロードされています。

問題を引き起こすコード

脆弱なcolorsライブラリには、次の問題のあるコードが追加されました。

1for (let i = 666; i < Infinity; i++;) {
2   if (i % 333) {
3       // console.log('testing'.zalgo.rainbow)
4   }
5   console.log('testing testing testing testing testing testing testing'.zalgo)
6}

パッケージのソースコードに含まれるindex.jsファイルのこの無限ループコードは、ターミナルに不気味なZalgoテキストを表示しながら、パッケージのあらゆる利用を妨げます。

colorsパッケージに依存しています。影響を軽減するにはどうすればよいですか？

問題のあるバージョン1.4.1を使用していて、colorsのインシデントの影響を受けている場合は、問題のある無限ループコードを含まない、最後に正常であることが確認されたバージョンcolors@1.4.0に戻すことをおすすめします。たとえば、package.jsonファイルでcolorsの安定した安全なバージョンを固定するには、次のように変更します。

1"colors":"^1.4.0"

次のようにします。

1"colors":"1.4.0"

今後に備え、プロジェクトでオープンソースライブラリを管理する際には、次のベストプラクティスに従うことをおすすめします。

1. package.jsonまたはロックファイルを使用して、依存関係のバージョンを固定しましょう。これにより、インストール時に新しいバージョンが解決されるのを防ぎ、問題を引き起こした修正済みバージョン1.4.1のcolorsがインストールされる事態を回避できます。

2. 今回のインシデントを機に、chalkなど、別の色処理パッケージへの移行を検討しましょう。

3. 利用を検討しているオープンソースパッケージの保守状況と持続可能性を確認し、複数のコントリビューターがいるなど、適切なガバナンスモデルが確立されていることを確かめましょう。

Faker.js：同じメンテナー、同じ顛末？

この出来事に先立ち、同じ人物がメンテナンスしていた人気のnpmパッケージfaker（広くFaker.jsとして知られています）でも、同様のインシデントが発生していました。Fakerは、大量のテスト用データを生成するために多くの開発者が利用しているプロジェクトで、ソフトウェアテストでもよく使われています。

Fakerは週に200万回ダウンロードされ、JavaScriptやNode.jsプロジェクトの依存関係としても広く利用されています。しかし、2022年1月5日、このパッケージのGitHub上のオープンソースリポジトリに強制的なコミットが行われ、元のソースコードが完全に置き換えられました。

その後、faker npmパッケージのバージョンは6.6.6に更新され、ソースコードを含まない空のパッケージとして、公開npmjsレジストリに公開されました。

メンテナーは、今後は無償でパッケージをメンテナンスしないとするissueを作成しました。

その後、作者はプロジェクトのソースを管理していたGitHubリポジトリを削除しました。この影響で、このパッケージを利用していた何千人もの開発者に大きな混乱が生じ、移行先を探さざるを得なくなった可能性があります。

その後、作者は個人ブログでこの件に関する記事を公開し、プロジェクトの収益化やスポンサー獲得を目指した試みが失敗した経緯を詳しく説明しました。また、寄付の現状は持続可能ではないとし、「多くの人と同じように、私にも私を頼りにしている人たちがいて、支払わなければならない請求書があります」と述べました。

同じメンテナーは、ほかにも約170のnpmパッケージに関わっているため、この一件で終わりとは限りません。

オープンソースのガバナンスと資金調達モデルに潜む課題

この出来事は、オープンソースコミュニティで広がる議論の流れを受けたものです。オープンソースコードに依存し、それを本番環境で利用して製品を構築する企業や組織の責任が問われています。

colorsに問題のあるコードを公開した後、メンテナー自身もGitHubでissueを立ち上げ、この件について話し合いました。その中では、問題の「バグ」の原因が見つからず、対応する時間もないと冗談めかして述べています。

Marakは続けて、ほかの著名なNode.js開発者にもタグ付けして対応を求めましたが、彼らは誰もプロジェクトリポジトリに実際にアクセスできません。

こうしたインシデントは、オープンソースコミュニティで最近高まっている議論と一致しています。オープンソースのメンテナーの間では、自社製品でオープンソースソフトウェアを利用し、収益を得る企業や組織への不満を表明する人が増えています。

Log4Shell後のオープンソース批判への対応として、資金援助なしで健全なオープンソースソフトウェアを維持するメンテナーの苦労について、先日取り上げました。

メンテナーがパッケージへのアクセスを完全に遮断する傾向は、今後も続くかもしれません。その心情は十分理解でき、主張にも正当性がありますが、オープンソースパッケージへのアクセスを遮断することで、ほかのオープンソース開発者やメンテナーにも被害が及ぶ点に留意すべきです。

オープンソースセキュリティのベストプラクティスを導入する

オープンソースソフトウェアを利用するなら、こうしたインシデントをはじめ、セキュリティや法務上の問題のリスクを適切に評価し、発生時に対処できるよう備える必要があります。さらに、ベストプラクティスを導入すれば、サプライチェーンセキュリティの潜在的な問題を回避・軽減できます。

今後同様の事態に備えるため、次のような対策や資料をおすすめします。

1. オープンソースプロジェクトのメンテナンス状況と持続可能性を確認しましょう。Snyk Advisorは、パッケージの健全性スコアを把握するのに役立つツールです。

2. 「npmのセキュリティに関するベストプラクティス10選」では、二要素認証の有効化、適切なロックファイルの使用による依存関係の固定などの重要性を解説しています。

3. 依存関係の混同、タイポスクワッティング、悪意のあるパッケージなどを取り上げた最新のソフトウェアサプライチェーンのセキュリティ対策をご覧ください。

4. Snykが悪意のあるパッケージやサプライチェーン攻撃の防止にどのように役立つか、実践的なアドバイスをご紹介します。