30

This came up in a comment to another question and I'd love it if someone could explain the reasons for this to me.

I suggested having Apache log the errors for a given VHost to a user's home directory. This was shot down because it was insecure. Why?

I asked for clarification in a reply comment but all I got was that it's insecure to have root writing in a folder not owned by root. Again, could someone explain?

Thanks,

Bart.

drAlberT
  • 10,949
  • 7
  • 39
  • 52
Bart B
  • 3,457
  • 6
  • 31
  • 42
  • 4
    What's Apache doing running as root - the principle of least privilege cries out against that! – Jonathan Leffler Sep 29 '09 at 14:31
  • 1
    Apache is running as www, but is being started as root so it can bind to port 80 as is the norm. Apparently it also logs as root. – Bart B Sep 30 '09 at 16:16

2 Answers2

34

Because an evil user can maliciously try to point the file root is writing to a different location. This is not so simple, but really possible.

As an example, if a user would find the way to make a symlink from the supposed Apache log to, say, /etc/shadow you'll suddenly have an unusable system. Apache (root) would overwrite your users' credentials making the system faulty.

ln -s /etc/shadow /home/eviluser/access.log

If the access.log file is not writable by the user it can be difficult to hijack it, but avoiding the possibility is better!

A possibility could be to use logrotate to do the job, creating the link to a file not already existing, but that logrotate will overwrite as soon as the logs grows:

ln -s /etc/shadow /home/eviluser/access.log.1

Note:

The symlink method is only one of the possible attacks, given as a proof of concept.

Security has to be made with a White List mind, not blacklisting what we know to be an issue.

drAlberT
  • 10,949
  • 7
  • 39
  • 52
  • Is there a way to set permissions on it so they can only read the file and not delete, edit, or do anything else (like chown, chmod, etc.)? – Joshua Sep 22 '09 at 15:46
  • you should do this operation on every possible target file! this writeable file is the liked one, not the link itself that is owned by the attacker as he created it. – drAlberT Sep 22 '09 at 15:54
  • 2
    @Joshua: chown can only be performed by root. chmod can be performed by whoever owns the file. IIRC, renaming can be done by whoever owns the directory. As AlberT mentions, creating a link *before* root creates the file can be done by whoever can write to the directory. – atk Sep 22 '09 at 15:54
  • Oh, and there's a good resource at http://seclists.org/bugtraq/2000/Jan/0016.html – atk Sep 22 '09 at 15:55
  • 2
    @atk: In addition, whoever owns the directory can generally remove files from it (unless the sticky `+t` bit is set), even if they have no write permission to the files themselves (because unlink() is a write to the directory, not the file). Even if root creates the file ahead of time, the directory owner could still be able to delete it and replace it with a symlink to something else. – James Sneeringer Sep 24 '09 at 08:00
  • 1
    If eviluser can write in /home/eviluser (or can change the permissions on the directory - they own it, IOW), then it doesn't matter what the permissions on access.log are; the eviluser can (re)move the file and place their symlink in its place. Another question is whether the software pays attention to what it opens. – Jonathan Leffler Sep 29 '09 at 14:33
  • @James: the user who owns a directory can remove the sticky bit, remove the file, and (if desired) replace the sticky bit. You can complicate life for the user by creating a non-empty sub-directory that they can't get at - but the can still move that out of the way, even if they can't remove it altogether. – Jonathan Leffler Sep 29 '09 at 14:35
  • Yes, this is very well in general, but it's not actually a practical attack against Apache, which carefully guards against these tricks, eg by using `O_NOFOLLOW`. – poolie Nov 23 '10 at 21:15
  • Yes, but the point is not the symlink *example* ... the number of possible attacks is only a matter of fantasy and the preparation of the attacker. BTW, O_NOFOLLOW is linux specific, Apache is not :) – drAlberT Nov 25 '10 at 09:31
2

The general principle of not having processes write into a directory they don't own or trust is a good one. But in this particular case, it's reasonable to trust that the Apache code opens the log with O_NOFOLLOW etc: logging into a user's home directory is a common setup.

poolie
  • 1,165
  • 1
  • 9
  • 17