こんにちは！WantedlyのEngagementで開発している、エンジニアの渡邉(@eityans)です。

私達は今、長野の松本で開催されているRubyKaigi2023に参加しています。現地の状況を皆さんにお伝えしたく、たくさんブログを書いているので見てください！

本記事では、2日目の講演である、 RubyGems on the watch の内容を紹介します！

この発表では、RubyGemsセキュリティに関する内容でした。発表者は Mend社 の Maciej Mensfeld さんで、RubyGems セキュリティ チームのメンバーです。脆弱性のあるパッケージの報告や、発生した脆弱性の影響調査などを行っており、gemの安全を守っています。

普段お世話になっているRubyGemsのセキュリティを守るために、どのような活動が行われているのか興味深いですね。

8秒に一個新しいgemが追加されるRubyGems

オープンソースのサプライチェーンの概念はとてもシンプルです。ソースを公開したい人と、ソースを利用したい人がいる。それだけです。ソースが変わったらバージョンを変更して、使いたい人はバージョンを選んで利用する。今日の1.1.0の内容と、2週間後の1.1.0は同じであるべきですし、そうであると多くの人が思っています。 --- でも本当にそうなのでしょうか？

2つの脆弱性の紹介

この発表では、2つの脆弱性が紹介されていました。「CVE-2022-29176」と「CVE-2022-29218」です。

どちらも、「開発者が想定していないパッケージをpublishできる」というものでした。現在は解決済みです。

CVE-2022-29176

RubyGemsにバグが含まれており、所有していないパッケージのバージョンを削除し、悪意のあるコンテンツを含む自分のパッケージをアップロードすることができるというものです。

本来、パッケージのバージョンは不変であるべきなのですが、特定のプラットフォームにおいてはCPUタイプに基づくバージョンが存在しました。この制約を悪用することで、パッケージの乗っ取りが可能になったというものでした。

この乗っ取りの過程で所有者が切り替わる挙動が発生するため、影響範囲を特定することができ、結果3つの研究用のパッケージで問題が見つかりましたが、幸いにも悪用されたケースは発見されなかったとのことです。

これに対応するために、パッケージの変更や置き換えを検知するための外部システムが作られました。

CVE-2022-29218

上記の脆弱性の2週間後の話だそうです。

RubyGemsに存在したバグによって、検証がクラッシュしたときに、S3にアーティファクト（gem）が残ってしまう問題がありました。通常、S3にあってもリリースされなければ問題になることはありません。

ただし、悪意のある攻撃者がFastlyを介してアーティファクトをキャッシュし続け、後に正当なリリースがあったときにそのキャッシュが配布される可能性がありました。

これはあくまで可能性の話で、実際にはそのようなことはなかったのですが、それがないことを確認するために、ありえそうな全てのS3ファイルのチェックを実施し、問題ないことを確認したそうです。

更に、このような問題が発生しないことを確認するために、CI/CDに組み込んでアーティファクトの変更を監視し、RubyGemsからサーバーまでの間で何も変更されていないことを確認するようにしたとのことです。

発表ではどのように影響がないことを調査したのかが具体的な数字とともに詳細に語られていました。結果的に悪用されていなかったとはいえ、これらの確認作業を行っているときの状況を想像すると胃が痛くなりそうです。発表者本人曰く、「最高の一ヶ月ではなかった」と語っていました。

余談ですが、このような脆弱性のからくりに対して、発表者が「beautiful」と表現していたのが面白かったです。これらの脆弱性は、特定の条件が重なり合うと発生するタイプのもので、確かに話を聞いていてそこまでピースが噛み合うことあったらキレイだなと思いました。

これまで紹介してきた脆弱性は技術的なものですが、発表の後半では様々な脆弱性のトピックがありました。その中で特に面白かったものを紹介します

Brandjacking

Brandjackingとは、主に特定の企業の名前を含んだgemの名前を騙ってリリースする手法です。例えば、google-ruby-api みたいな名前を出すようなものです。雰囲気だけでinstallすると痛い目をみることになるかもしれません。

また、RubyGemsに公開しないでgemを開発する状況がもつ脆弱性について紹介されていました。これは、開発のリポジトリのREADMEには bundle install xxx と書かれているものの、対象のgemはまだRubyGemsにないという状況です。もし、悪意のある人が先回りしてその名前でRubyGemsに（もとのgemとは全く関係ない）コードでpublishしたとします。そして、READMEを見た別の開発者がbundle installしたら。。。という話です。

話を聞いていて、普通に有り得そうな話で怖いと思いました。

全ての人がセキュリティに関心を持つ

発表の最後で、セキュリティに対する姿勢について話をしていました。

攻撃者が企業の環境を攻撃したいと思った時、手っ取り早いのが開発者を狙うことです。開発者はOSSをの世界で活動しており、そのプラットフォームは悪意のあるユーザーの攻撃を完全に防ぐことはできません。もちろんできる対策はされていますが、結局のところ、各自の対策が重要なのです。

感想

何気なく利用しているRubyGemsですが、その安全性を高めるための活動について知ることができてとても有意義でした。発表でも述べられていたように、どのようなリスクが考えられるのかを常に意識して、油断せず楽しく開発していきたいと思いました。