アカウント名:
パスワード:
読んでおこうぜ
https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36b8d83b3a [github.com]
これOSSにとって今後大きな問題になるような…。元メンテナがやる気を無くした時に、誰か他の人にメンテナやりますって言われたらそりゃ喜んで渡してしまうわけで。
今回はそれが悪意あるユーザーで、いろんなとこで使われているライブラリにマルウェアが仕込まれてしまったわけだけど。ユーザーの方も、まさか有名ライブラリがそんな事になるなんて思いもしないし、かといって元メンテナに無限に続けてもらうわけにはいかないし、今後もこの手の攻撃が増えるんではなかろうか？
実は目新しくない人間(エンドユーザーや開発者)に対するソーシャルハックなんですよ。OSSに限らずイソジン [srad.jp]やら、イソジンのコメントにもある味覇と創味シャンタンDX [wikipedia.org]みたいな例も有ります。プロプラでは、流石にトロイ的な事 [security.srad.jp]はあまりないですが、次バージョンでゴミ化とかEOSになったりとか有りますし。# 燃費やら検査データ改ざんみたいな例とかも有りますけど。
閑話休題。自動更新によって突如マルウェア化する人気Chrome拡張 [security.srad.jp]とか色々前例は有ったり。使用者が外部依存しているリソースのチェックを怠り続ける限り今後も何処かで起きるでしょうね。最近有った事例だと、StatCounter [security.srad.jp]みたいな話題にならなかった物も含め。
とはいえ、Web界隈はシステムの複雑化と開発速度優先により、容易に外部ライブラリを使用し、その外部ライブラリも別の外部ライブラリを呼び、人間が管理しきれなくなり、言語ではなく、ロジックが理解しきれない事によるバベルの塔崩壊前夜な感じにも見えます。
たしかに管理者が変わったのに、パッケージ名という名前空間でしか管理していないために、ブランドに対する信用をそのまま機械的に引き継げてしまうシステムが問題を大きくする要因の一つでしょう。しかし、悪意あるオデュッセウスが見つかっていないだけという可能性だってあります。究極的には対処法は外部リソースは基本的に信じず、信頼できる方法で確認し続ける事が必要なのでしょう。そして、それって最初に書いた通り、別にOSSに限った話ではないのですよね。# で、誰がコストを負担するかで揉めたり、確認が追いつかずライブラリやランタイムのバージョンが古いままで地獄を見るのだ。
left-pad問題もそうだったけど、javascript/ES のモジュール再利用はちょっと異常。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
元メンテナのコメント (スコア:1)
読んでおこうぜ
https://gist.github.com/dominictarr/9fd9c1024c94592bc7268d36b8d83b3a [github.com]
Re:元メンテナのコメント (スコア:2, 興味深い)
これOSSにとって今後大きな問題になるような…。
元メンテナがやる気を無くした時に、誰か他の人にメンテナやりますって言われたらそりゃ喜んで渡してしまうわけで。
今回はそれが悪意あるユーザーで、いろんなとこで使われているライブラリにマルウェアが仕込まれてしまったわけだけど。
ユーザーの方も、まさか有名ライブラリがそんな事になるなんて思いもしないし、かといって元メンテナに無限に続けてもらうわけにはいかないし、今後もこの手の攻撃が増えるんではなかろうか？
Re:元メンテナのコメント (スコア:1)
実は目新しくない人間(エンドユーザーや開発者)に対するソーシャルハックなんですよ。
OSSに限らずイソジン [srad.jp]やら、イソジンのコメントにもある味覇と創味シャンタンDX [wikipedia.org]みたいな例も有ります。
プロプラでは、流石にトロイ的な事 [security.srad.jp]はあまりないですが、次バージョンでゴミ化とかEOSになったりとか有りますし。
# 燃費やら検査データ改ざんみたいな例とかも有りますけど。
閑話休題。
自動更新によって突如マルウェア化する人気Chrome拡張 [security.srad.jp]とか色々前例は有ったり。
使用者が外部依存しているリソースのチェックを怠り続ける限り今後も何処かで起きるでしょうね。
最近有った事例だと、StatCounter [security.srad.jp]みたいな話題にならなかった物も含め。
とはいえ、Web界隈はシステムの複雑化と開発速度優先により、容易に外部ライブラリを使用し、
その外部ライブラリも別の外部ライブラリを呼び、人間が管理しきれなくなり、
言語ではなく、ロジックが理解しきれない事によるバベルの塔崩壊前夜な感じにも見えます。
たしかに管理者が変わったのに、パッケージ名という名前空間でしか管理していないために、
ブランドに対する信用をそのまま機械的に引き継げてしまうシステムが問題を大きくする要因の一つでしょう。
しかし、悪意あるオデュッセウスが見つかっていないだけという可能性だってあります。
究極的には対処法は外部リソースは基本的に信じず、信頼できる方法で確認し続ける事が必要なのでしょう。
そして、それって最初に書いた通り、別にOSSに限った話ではないのですよね。
# で、誰がコストを負担するかで揉めたり、確認が追いつかずライブラリやランタイムのバージョンが古いままで地獄を見るのだ。
Re: (スコア:0)
left-pad問題もそうだったけど、javascript/ES のモジュール再利用はちょっと異常。