I have the following in my Logwatch log file

---

A total of 3 possible successful probes were detected (the following URLs contain strings that match one or more of a listing of strings that
indicate a possible exploit):

/?file=../../../../../../proc/self/environ%00 HTTP Response 200
/?mod=../../../../../../proc/self/environ%00 HTTP Response 200
/?page=../../../../../../proc/self/environ%00 HTTP Response 200

---

I found the entries in the log, and in the circumstances, the 200 responses don't necessarily mean anything. Still...

This is a file system issue. How secure are our installations from this form of attack?

A site online recommended remounting /proc with nousid. Currently, I believe the default for /proc is usid.

What think? Suggestions?

I'm running Ubuntu 10.04.

This isn't a file system issue. It's an issue with whatever web app you're running. Patching that should be your priority, not the file system.

This is a combination of issues: both PHP app security vulnerabilities and file system vulnerabilities, exposed by the PHP app.

No it's not /self/proc/environ should be readable by the file system, your issue is with the php app, now if the app could read /etc/shadow then you'd have a file system problem (or your app is running as root which is bad).

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

No to both.

If your web app is accessing random files outside your web root on the file system, the web app is the problem, not the file system. /etc/passwd is also world-readable, I'll point out. If an insecure web app is compromised, there is so much sensitive information that an attacker can read.

The only publicly accessing PHP application I'm running is Drupal. Everything else requires authentication.

Thanks for suggestions. Evidently the consensus is this person is wrong

http://www.thesecuritysamurai.com/2011/ ... c-analyst/

You found the entries in the log, but did you try the URLs yourself? What do you get?

The response code of 200 means nothing. I am angry at many PHP apps that I have to integrate with because not only are they not even basically restful, but many give you a "Blah not found" while the response code is 200 not 404. Some apps will give you 200 when they're handling even 403 or 5xx.

And at any rate, this is not the issue of the app but of PHP environment. It should be locked down (open_basedir comes to mind, SELinux or similar comes to mind) to its allowed directory environment (plus /dev/urandom, /tmp and stuff like that), period.

so:



As secure as you make them. Never rely on the app to take care of its security.

I did, and as you note, all I get is the app's main page, rather than a 404. That's why I'm not sweating the access. But I'm concerned that a 200 return will trigger the hacker into a more determined assault, and I'm tired of the attacks.

I'll look more closely at my PHP installation, see if I can tighten it up further.

Thx

So, according to that post and its source, this vulnerability was fixed in July of 2006 in 2.6.17.5. So why is it a still a concern? The post gives no indication about why we should care about a vulnerability fixed half a decade ago.

It's almost certainly automated and not directly controlled by a human, so it will likely not care whether or not something is vulnerable. It will try anyway. The flu doesn't check whether or not you got a flu shot when someone sneezes at you.