Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

On one of my web applications, I accidentally left the .git directory readable by the web server for the last few weeks. Index listing was disabled. Visiting the website.com/.git URL would result in a 404 error that was indistinguishable from any other 404 error, but browsing to website.com/.git/config for example would download the file.

What kind of risks are there with my applications? Is it possible that enough information is exposed that someone could have downloaded the entire application's source code?

share|improve this question
    
Did you try a git clone http://website.com/.git? That is the major risk (being able to clone the full repo). –  VonC Aug 24 '11 at 14:28
    
I'll have to test it on my dev server... I just realized the vulnerability while daydreaming and fixed the bug ASAP. –  Thomas Hunter Aug 24 '11 at 14:45

2 Answers 2

up vote 3 down vote accepted

Yes, it's possible to download the entire repository contents (including history) – a simple git clone would do it. However, this assumes someone knew about the existence of that .git directory...it's more likely that nobody has even noticed it. You can always check your web server's logs to be sure.

share|improve this answer
1  
except if you have some "auto-testing" folks around there which curl $URL/.git/config all day long for every url they see ... :) –  akira Aug 24 '11 at 14:30
    
With the .git folder being in the root, someone only would have needed to run git clone domainname.com? And it would have worked with the directory listing disabled? –  Thomas Hunter Aug 24 '11 at 14:41
    
@Thomas: Git does not use directory listings, since their format varies greatly between web servers. All required information is in refs and packed-refs. –  grawity Aug 24 '11 at 15:05
    
Thanks for the advice. I checked my lighttpd access logs and didn't see any requests to the git directory (other than my own panicked checking today). –  Thomas Hunter Aug 24 '11 at 15:19

A simple git clone on the document root is not entirely accurate. Cloning an exposed GIT repository is not possible with "dumb" servers, such as an accidental exposure of .git via HTTP, unless git update-server-info is executed on the server. While some of the metadata is available, obtaining the contents of the .git/objects directory (aka the juicy stuff) is not always possible. It is possible to recover objects that aren't packed. Should not be the case with a working copy/repository on a production server.

It's a different story for a development machine with committed changes that aren't pushed to a remote. In this case, the garbage collector is not usually called, unless you invoke git gc, hence the files aren't part of packfiles, yet. You may recover via HTTP the files which are committed since the last push.

update-server-info basically creates a map of the refs (.git/info/refs) and of the packfiles (.git/objects/info/packs). While .git/packed-refs may be used to substitute the first, obtaining the packfiles isn't possible without having the directory index enabled or actually brute-forcing SHA-1's (which is a bad idea from the start).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.