PHP Composer 的安全性問題

ComposerPHP 上新一代的套件管理軟體。

Composer 與之前各種方案不同的地方在於,後面掛了 Packagist 這個 PHP package archivist,讓使用者很方便的取得套件 (以及更新)。

其中有一個功能是 replace,表示我所開發的這個套件「宣稱」可以取代其他套件 (通常是 API compatible)。

看到這個功能的時候,以為是要讓 Packagist 能夠串起連結。畢竟偶而會發生「這個套件最新版是 2008 年了,到底有沒有後續維護啊」的情況。如果 Packagist 官方網站可以串起連結,可以節省開發者時間,而且也可以利用 Packagist 上的熱門度來決定要用哪一個後繼者。

但實際上與預期的不同,Composer 的預設值是會「自動」尋找更新並且真的使用,也就是前幾天被丟出來的議題:「Composer is wide open with a massive security vulnerability」。

攻擊者只要在 Packagist 上面上傳一堆含有惡意程式碼的套件 (並且利用 replace 宣稱可以取代 ZF2 或是 Laravel),受害者在 composer update 的時候就有機會抓到這些有惡意程式碼的套件。

而最糟糕的是,主要開發者認為這不是問題,還寫了一大篇文章顧左右而言他之後說「錯覺啦~」:「Composer: Replace, Conflict & Forks Explained」:

Replace is not a bug. Don’t run composer update in automated systems. Forks are allowed on Packagist. Don’t be an idiot when publishing a fork. Got an unexpected fork on update? Your dependencies conflict with the original package. Use conflict (syntax like require) in your composer.json to blacklist the fork and see an explanation of the dependency issue.

於是發現問題的人就爆炸了。

依照往例,vendor 不覺得是問題的安全漏洞,只能把事情弄大爆出來逼 vendor 修。

修正在「Limit Replace / Provides to packages required by name in root package or any dep」這裡。最新版的 Composer 裡已經納入這個修正了。

This entry was posted in Computer, Murmuring, Network, Programming, Security, Software and tagged , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *