Búsca en Seguridad y Firewall


Repositorio malintencionado de Git puede conducir a la ejecución de RCE


Los desarrolladores detrás de GIT y varias compañías de servicios de repositorios de GIT, han liberado algunos parches sobre vulnerabilidades criticas en el software de GIT.

El parche está incluida en la versión 2.17.1 la cual viene a solucionar la vulnerabilidad CVE-2018-11233 y la CVE-2018-11235.

CVE-2018-11235


Esta vulnerabilidad es catalogada como la mas peligrosa de las dos ya que permite a un usuario malicioso crear un repositorio git malformado, con un submodulo especialmente construido para dañar a los usuarios. Cuando el usuario clona ese repositorio, da la posibilidad a un atacante ejecutar código remoto en los sistemas de los usuarios, mediante este submodulo creado especialmente para eso.

La versión 2.7.1 podría prevenir la ejecución remota de comandos en los computadores de los usuarios desde repositorios Git malintencionados.

El parche a parte de no permitir la ejecución de código remoto en los usuarios, también permitea  la parte Servidor, lograr detectar repositorios que vengan con submodulos maliciosos, y bloquear cualquier acceso de un usuario a estos repositorios.

Microsoft a su vez también ha lanzado sus parches para la actualización de los servicios de VisualStudio.

Edward Thomson, el Administrador de Programa de VisualStudio dio una explicación de la vulnerabilidad CVE-2018-11235 en ingles:

"A remote repository may contain a definition for a submodule, and also bundle that submodule’s repository data, checked in to the parent repository as a folder. When recursively cloning this repository, git will first checkout the parent repository into the working directory, then prepare to clone the submodule. It will then realize that it doesn’t need to do the clone – the submodule’s repository already exists on disk; since it was checked in to the parent, it was written to the working directory when it was checked out. Therefore git can skip the fetch and simply check out the submodule using the repository that’s on disk. 
The problem is that when you git clone a repository, there is some important configuration that you don’t get from the server. This includes the contents of the .git/config file, and things like hooks, which are scripts that will be run at certain points within the git workflow. For example, the post-checkout hook will be run anytime git checks files out into the working directory. 
This configuration is not cloned from the remote server because that would open a dangerous vulnerability: that a remote server could provide you code that you would then execute on your computer. 
Unfortunately, with this submodule configuration vulnerability, that’s exactly what happens. Since the submodule’s repository is checked in to the parent repository, it’s never actually cloned. The submodule repository can therefore actually have a hook already configured. If when you recursively cloned (and this repository does have to be cloned with --recursive for this vulnerability to manifest) this carefully crafted malicious parent repository, it will first check out the parent, then read the submodule’s checked-in repository in order to write the submodule to the working directory, and finally it will execute any post-checkout hooks that are configured in the submodule’s checked-in repository."

https://www.edwardthomson.com/blog/upgrading_git_for_cve2018_11235.html