colorsやfakerといったnpmパッケージの悪意あるコードが公開された事件について

本記事は2022年1月9日に公開した英語ブログ[Open source maintainer pulls the plug on npm packages colors and faker, now what?](https://snyk.io/blog/open-source-npm-packages-colors-faker/)を日本語化した内容です。

[![logo-solid-background.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2216557/b46a6afe-19c2-e6a4-a924-687823dfef3a.png)](https://snyk.io/jp)


#はじめに
2022年1月8日、大人気の[colors](https://snyk.io/advisor/npm-package/colors)というnpmパッケージのオープンソースのメンテナー（管理者）が、[ソースコードに無限ループを追加する問題のあるコミット](https://github.com/Marak/colors.js/commit/074a0f8ed0c31c35d13d28632bd8a049ff136fb6)を意図的に導入した `colors@1.4.1`と`colors@1.4.44-liberty-2`を公開しました。この無限ループは、パッケージのソースコードの初期化時に直ちにトリガーされ実行され、これを使用しているNode.jsサーバーにサービス拒否（DoS）を引き起こす可能性があります。

TL;DR：Snykは、[この脆弱なコード](https://github.com/Marak/colors.js/commit/074a0f8ed0c31c35d13d28632bd8a049ff136fb6#diff-92bbac9a308cd5fcf9db165841f2d90ce981baddcb2b1e26cfff170929af3bd1R18)を受けて、[colors@1.4.1にサービス拒否のセキュリティ脆弱性を発表しました](https://security.snyk.io/vuln/SNYK-JS-COLORS-2331906)。**`colors@1.4.0`に戻し、依存関係のバージョンを固定し、問題のあるバージョンへの無条件のアップグレードを避けることを強くお勧めします。また、別のパッケージに移行することをお勧めします。**範囲、影響、推奨される対策の詳細については、本ブログ記事を引き続きお読みください。


#`colors`とは？
オープンソースnpmパッケージの`colors`は、週に 2000 万回以上ダウンロードされ、JavaScript と Node.js の開発者にとって重要なエコシステムプロジェクトであり、多くのプロジェクトをサポートしています。GitHubの記録では、`colors`プロジェクトは400万以上の他のプロジェクトで使用されており、npmjs.orgはこのnpmパッケージが18,962の他のパッケージから依存されていることを示しています。

例えば下記のようなプロジェクトでcolorsが利用されています。

* [prompt](https://snyk.io/advisor/npm-package/prompt)コマンドラインヘルパー (~500,000 weekly downloads)
* ユニコードテーブルフォーマット[cli-table3](https://snyk.io/advisor/npm-package/cli-table3)(~700万週次ダウンロード)
* AWS独自の[aws-cdk](https://snyk.io/advisor/npm-package/aws-cdk)（～200万件の週間ダウンロード）

実際、壊れた`colors@1.4.1`版は大量のユーザーに影響を与え、軽視することはできません。npmjsのパッケージページの統計によると、このブログ記事を書いている時点で、このバージョンは95,397回ダウンロードされていることがわかります。

![image1-28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2216557/4b8bea95-7693-3797-9dcc-6c0468bb3c35.png)


#破壊されたコード

脆弱性のある`colors`ライブラリに、以下のような悪意のあるコードが導入されていました。

```
for (let i = 666; i < Infinity; i++;) {
   if (i % 333) {
       // console.log('testing'.zalgo.rainbow)
   }
   console.log('testing testing testing testing testing testing testing'.zalgo)
}
```

この無限ループのコードは、パッケージのソースコードの`index.js`ファイルにあり、ターミナルに非常に不穏な結合文字（zalgoテキスト）を表示しながら、パッケージの利用を不可能にします。

![image5-10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2216557/066c63f4-2793-fe21-7bcd-12e2dca273ab.png)

#この`colors`パッケージに依存している場合、どうしたらよいでしょうか？

現在、壊れたバージョン`1.4.1`を使用しているために`colors`事件の影響を受けている場合は、問題のある無限ループコードを含まない最新の既知の良好な`colors@1.4.0`バージョンに戻すことをお勧めします。たとえば、`package.json`ファイルで`colors`パッケージの安定かつ安全なバージョンを特定するには、以下のように対応します。

```
"colors":"^1.4.0"
```

を

```
"colors":"1.4.0"
```


に置き換える。

今後の参考として、プロジェクトにおけるオープンソースライブラリの管理について、以下のベストプラクティスを推奨します。

1. `package.json`またはロックファイルを使って、依存関係を固定する。これにより、新しいバージョンのインストール時に、この問題を引き起こした `colors`の`1.4.1`パッチ版のインストールが必要になるのを避けることができます。

2. この事件は、[chalk](https://snyk.io/advisor/npm-package/chalk)などの代替カラーハンドリングパッケージへの移行を検討するきっかけになるはずです。

3. 使用する予定のオープンソースパッケージのメンテナンスと持続可能性の側面を検討し、複数の貢献者がいるなど、適切なガバナンスモデルがあることを確認する。

# Faker.js：模倣した事件？

今回の事象は、同一人物がメンテナを務める人気npmパッケージfaker（一般には[Faker.js](https://github.com/Marak/faker.js/)として知られる）に関連する同様の事象に続くものです。Fakerは、ソフトウェアのテストによく使われる大量の偽データを生成するプロジェクトとして、多くの開発者に利用されています。

Fakerは、毎週200万ダウンロードされており、JavaScriptやNode.jsのプロジェクトの利用するパッケージとしても非常に人気があります。しかし、2022年1月5日、このパッケージのGitHub上のオープンソースリポジトリは、パッケージの元のソースコードを完全に元に戻す強制コミットを受けました。

![image3-19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2216557/53d11022-4929-ffeb-e0ec-a389117393f2.png)

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

![image6-14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2216557/4fd6eb1f-a4a0-b8f3-96fe-8bf7c433f249.png)

メンテナは、もうこのパッケージを無償でメンテナンスしないことを表明する[issueを作成しました](https://web.archive.org/web/20210704022108/https://github.com/Marak/faker.js/issues/1046)。

![image2-29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2216557/b96dba4b-1d35-fbe4-d8e3-0b6b68cb6d3f.png)


その後、作者はプロジェクトのソースであるGitHubリポジトリを削除し、このパッケージを使用している何千人もの開発者に大きな混乱を引き起こした可能性があります。それらの開発者はおそらく現在移行を模索していることでしょう。

その後、作者は[個人ブログでこの件に関する記事を公開し](https://web.archive.org/web/20210628030444/https://marak.com/blog/2021-04-25-monetizing-open-source-is-problematic)、プロジェクトを収益化したりスポンサーをつけたりする試みが失敗したことを詳しく説明し、寄付の現状は維持できないこと、「ほとんどの人と同じように、私には私を頼りにしている人がいて、支払うべき請求書がある」と表現しました。

同じメンテナーが他の約170のnpmパッケージにも参加しているので、この件はこれで終わらないかもしれません。

#オープンソースのガバナンスと資金調達モデルの危険性

この出来事は、オープンソースコミュニティにおける一般的な傾向に従って発生しており、それはオープンソースコードに依存してプロダクトを構築している企業や組織の責任に関するものです。

問題のコードが`colors`で公開された後、メンテナーも自らGitHubのissueを開設してこの問題を議論しており、その中でメンテナーは概して、この「バグ」の原因を見つけることができず、それを処理する時間がないと冗談を述べています。

![image7-9.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2216557/e29edfcf-5f4b-554d-8a37-af26c1716a8d.png)

Marakは、この問題に協力するために、他の非常に多くのNode.js開発者をタグ付けして続けますが、彼らの誰もプロジェクトのリポジトリに実際にアクセスすることができません。

![image4-16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2216557/70fd6c38-df95-887f-a4c6-58a3288f1e6e.png)

これらの事件は、最近のオープンソースコミュニティにおける議論の傾向と一致しています。企業や組織がオープンソースソフトウェアを収益化して製品に利用することに対して不満を表明するオープンソース管理者が増えてきているのです。

私たちは、[Log4Shell以降のオープンソースへの批判に応え](https://snyk.io/blog/responding-to-open-source-criticism-post-log4shell/)、最近、資金がないもののオープンソースソフトウェアを健全に維持している管理者の苦労を取り上げました。

メンテナの方々が自分たちのパッケージへのアクセスを完全に遮断する傾向が続く可能性はあります。その気持ちは確かに理解できますし、その主張は正当ですが、オープンソースパッケージへのアクセスを遮断するこのやり方は、他のオープンソース開発者や管理者を傷つける結果にもなることに注意すべきです。

# オープンソースのセキュリティベストプラクティスを取り入れる

オープンソースソフトウェアを使用するということは、そのような事故やセキュリティ問題、法的問題のリスクを適切に評価し、その展開に対応できるように十分に準備しておく必要があるということです。さらに、サプライチェーンのセキュリティに関する潜在的な問題を回避・軽減するためのベストプラクティスを採用できれば、なおよいでしょう。

このような事態に備えるために、下記をお勧めします。

1. オープンソースプロジェクトのメンテナンスと持続可能性の状況を確認してください。[Snyk Advisor(スニークアドバイザー)](https://snyk.io/advisor/)は、パッケージの健全性スコアを測定するのに役立つツールです。ご活用ください。

2. [npmのセキュリティに関する10のベストプラクティス](https://snyk.io/blog/ten-npm-security-best-practices/)では、2要素認証の有効化、ロックファイルの適切な使用による依存関係の固定化などの重要性について言及しています。ご参照ください。

3. 依存関係の混乱、URLハイジャッキング、悪意のあるパッケージなどのトピックについて、[最新のソフトウェアサプライチェーンを保護するための記事](https://snyk.io/blog/software-supply-chain-security/)を提供しています。

4. [悪意のあるパッケージやサプライチェーンへの攻撃を防ぐためのSnykの活用法について実践的なアドバイス](https://snyk.io/blog/preventing-malicious-packages-and-supply-chain-attacks-with-snyk/)を記事にて提供しています。

#最後に
Snykの公式ウェブサイトを公開しました。またSNSにて最新の脆弱性情報などを発信しているので、ぜひフォローをお願いします。

* [Snyk公式ウェブサイト](https://snyk.io/jp)
* [Snyk Japan Twitter](https://twitter.com/snykjp)
* [Snyk Japan Facebook](https://www.facebook.com/snykJP/)

またSnykは無料でお試しいただけます。ぜひお試しください！

https://qiita.com/SnykSec/items/aa80a976eb17299fff62


Snykを活用したブログは、ぜひQiitaアドカレ2021もご参照ください。

https://qiita.com/advent-calendar/2021/snyk