Git Security Vulnerability Mei 2018, PENTING!

Komunitas Git telah mengungkapkan kerentanan keamanan di seluruh industri di Git yang dapat menyebabkan eksekusi kode arbitrer ketika pengguna beroperasi dalam repositori berbahaya. Git security vulnerability mei 2018, kerentanan yang diketahui pada Mei 2018 ini telah ditetapkan sebagai CVE 2018-11235 oleh Mitre, organisasi yang menetapkan angka unik untuk melacak kerentanan keamanan dalam perangkat lunak.

 

CVE 2018-11235 adalah kerentanan keamanan baru di seluruh industri Git yang dapat menyebabkan eksekusi kode secara arbitrer ketika pengguna beroperasi dalam repositori berbahaya.

Berdasarkan pengumuman yang dilakukan @ssxio di twitter memerintahkan untuk segera mengupdate versi Git. Dalam cuitannya berisi link menuju blog Microsoft MSDN.

Dalam pengumumannya, Edward Thomson menjelaskan kerapuhannya:

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 doeshave 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.

Segera update Git Anda ke versi Git 2.17.1 (2) atau lebih baru karena dalam rilis Git 2.17.1 masih mengandung masalah.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.