Packagist é o host por detras do Composer, e possui atualmente mais de 435 milhões de pacotes para instalação.
A vulnerabilidade foi anunciada pelo investigador de segurança Max Justicz, o especialista descobriu que o campo de entrada “Enviar pacote” para enviar novos pacotes PHP através da página inicial do repositório de pacotes permitiu que um invasor executasse um comando malicioso no formato “$ (execute me) “.
“You could type $(execute me) into a big text field on the site and it would execute your command in a shell (twice).” reads the security advisory published by the expert.
“You upload packages to Packagist by providing a URL to a Git, Perforce, Subversion, or Mercurial repository. To identify what kind of repository the URL points to, Packagist shells out to git, p4, svn, and hg, with application-specific commands that include this URL as an argument,”
O especialista apontou que quando um utilizador fornecia uma URL para o Packagist, ela estava sendo aproveitada pelos atacantes que podiam executar conteúdo mal intecionado através de um shell.
A mitigação da falta foi simples. Para que os atacantes não tirasse partido da falha originada pela falta de segurança, os developers do repostitório Packagist implementaram um procedimento de sanitização para os parametros relevantes do repositório do Composer.
“The Packagist team quickly resolved this issue by escaping the relevant parameters in the Composer repository,” explained Justicz.
O especialista alertou ainda para o baixo nível de segurança do gestor de pacotes, o que poderia abrir portas para futuros ataques e outro tipo de cyber-danos.
“Package manager security is not always great, and you should probably plan on your package manager servers being compromised in the future. In the past year or so I have found bugs that let me execute arbitrary code on rubygems.org, execute code on some of npm’s official mirrors (not the main registry), delete arbitrary release files from PyPI, serve arbitrary JS on every site using a popular CDN for npm, and now execute arbitrary code on packagist.org.” concludes the expert.
“I think it is a security anti-pattern to have application build pipelines pull fresh downloads of packages from upstream servers on every build if the packages are not expected to change. If for some reason you have to do this, you should pin dependencies using a cryptographically secure hash function.”