One in every 600 websites has .git exposed • Hacker News Board

Re: One in every 600 websites has .git exposed

#211

Post by yrro » Wed, Jul 29, 2015, 11:39 PM UTC

smtddr wrote: post #207

tokenizerrr wrote: post #206

Earlier quoted context omitted.

If you can get it to exec some arbitrary bash command (or otherwise access the environ of a process) you can also have it cat any file on the server, and even the memory of the running processes that belong to the same user as the exploited process, and also execute network requests. So if you get that far, pretty much nothing will protect you.

Sure, but there are some shops that do their security from a point-of-view of "Attacker can run commands on your server as the user that started whatever-public-service/webapp/api" , and go from there. I happen to think that's the best way to think about it. Now, if an attacker manages to get root access then it's game over[1]. That just shouldn't happen. But nobody should be running their webserver as root. So, what…

If an attacker can run an arbitrary command on your server, it's already time to rotate all the credentials in your system and let any data subjects whose data you hold know that you fucked up, big time. That's just the Linux model.

Re: One in every 600 websites has .git exposed

#212

Post by vidarh » Thu, Jul 30, 2015, 8:56 AM UTC

yrro wrote: post #210

vidarh wrote: post #170

Earlier quoted context omitted.

The example above is someone who have stupidly started a process with the environment variables exposed on the command line

Ok, but that's not a problem caused by the exposure of the environment, it's caused by the exposure of the command line.

I agree - I was just explaining what the issue the above commenter raised. It just means you should use a saner way of initializing your environment with sensitive values.

Re: One in every 600 websites has .git exposed

#213

Post by vog » Fri, Jul 31, 2015, 7:16 AM UTC

pmx wrote: post #172

juliangregorian wrote: post #158

Earlier quoted context omitted.

Great point. How much do you want to bet most of these are PHP, where it takes special discipline not to make your top directory web-accessible?

It takes very little effort in php. You simply have your index.php and any public assets in the document root and then use index.php as a bootstrap to bring up your application. Everything else goes outside of the document root.

Yet, almost all well-known PHP applications don't have a public directory. And almost all non-PHP webapplications do have a public directory (e.g. practically all Python/Django and Ruby/Rails projects).

So the connection to PHP is apparent till today, although it may have to do more with crappy super-cheap hosting providers than with the language itself.

Re: One in every 600 websites has .git exposed

#214

Post by sago » Sun, Aug 02, 2015, 4:41 AM UTC

beagle3 wrote: post #153

sago wrote: post #86

Earlier quoted context omitted.

Amen! Use rsync --checksum --ignore="..." unless you have a damn good reason not to (--checksum is essential to prevent corruption/malicious modification, without it you are implicitly assuming the version on the remote machine is exactly how you left it: that assumption is why Linus built git around shasum in the first place). rsync is even easier than SSHing to git pull, or opening up a pushable repo on a server. F…

> (--checksum is essential to prevent corruption/malicious modification, without it you are implicitly assuming the version on the remote machine is exactly how you left it: that assumption is why Linus built git around shasum in the first place) That's not true (though not completely wrong). rsync is stateless. It does not assume the version on the remote machine is "exactly how you left it"; Rather, it compares fil…

> Whether the cost in disk activity is worth it

If the comparison is with using Git, then it is clear you're not so resource constrained that you can't countenance running MD5s, since Git would run shasum.

I think in our current laissez-faire climate w.r.t. security, I think recommending leaving security on the basis of saving a few cycles isn't very wise.

> It does not assume the version on the remote machine is "exactly how you left it"

I was ambiguous and sloppy, sorry. It doesn't not check for changes in a secure way, but assumes that, as long as the meta-data for the file matches, the content is as you left it.

When Linus built git, he specifically did so around sha1 to ensure that you ensure the data you think you have in the file, you do in fact have. rsync --checksum is thus a reasonable replacement for git deployment, but rsync --no-checksum isn't, imho.

Sorry if I was vague or misleading, thanks for the clarification.