I Am My Avatar - Unix folder permissions and security

01:50 pm June 18th, 2009

You are viewing

boutell's journal
Create a LiveJournal Account Learn more

Explore LJ: Life Entertainment Music Culture News & Politics Technology




			I Am My Avatar - Unix folder permissions and security Big Warm Fuzzy Public Heart

boutell


	Unix folder permissions and security
	Hey Unix geeks, Let's say I have a folder like this: /users/fred/catproject/cache Inside the cache folder, which is completely world-readable, writagle and executable, there will be world-writable, world-readable, world-executable files. Worse, those files are .php files. This is Very Bad because there are other users on the system who could therefore overwrite those files with PHP code of their own and wreak havoc. The good news is that the "fred" folder is not world-readable, writable and executable. Neither is "catproject." So bad guys have to guess the "catproject" part of the full path before they can cause trouble. Unfortunately, "catproject" is supposed to be a friendly project name, so it is not very hard to guess. However, what if the project lived here: /users/fred/23098420398423094/catproject/cache Where that big number is a randomly generated value with a cryptographically reasonable number of digits so that it's statistically impossible to guess it? Then the system seems to be safe... there's no way for an outsider to ever figure out the name of the vulnerable cache folder... provided of course that no error message or readable log file ever, ever, ever leaks out the path information. Am I missing anything here or is this true as far as it goes? Obviously it is better to use virtual machines, chroot jails, dedicated servers, etc. But for sticker-shock reasons it is not always realistic to present those options to a client. At the same time I can't give them a trivially insecure system. Thanks. Tags: geek, unix

13 comments or Leave a comment


	Comments

	From: marnanel	Date: June 18th, 2009 06:14 pm (UTC)		(Link)

Works for Firefox:

tthurman@haematite:~$ ls -l /home/tthurman/.mozilla/firefox/ total 8 -rw-r--r-- 1 tthurman tthurman 94 2008-05-31 20:31 profiles.ini drwx------ 10 tthurman tthurman 4096 2009-06-18 14:13 u9efh3h1.default

(Reply) (Thread)

	From: boutell	Date: June 18th, 2009 06:18 pm (UTC)		(Link)

How does that help Firefox? Don't .mozilla and all of its subfolders have the same user-specific permissions anyway?

(Reply) (Parent) (Thread)

	From: marnanel	Date: June 18th, 2009 06:49 pm (UTC)		(Link)

It's not an identical problem, but it's a similar one. There are situations where a hostile site:

a) can make your browser read from files at an arbitrary location on your filestore
b) cannot read the contents of a directory, and
c) can write to some area of your filestore (notably certain kinds of cache).

Therefore the site only has to:
a) write a file containing some code into the cache,
b) use the known path to get the browser to read it
and it's got code running outside the sandbox.

Therefore Mozilla mandated that the path to your profile should be randomised.

Edited at 2009-06-18 06:51 pm (UTC)

(Reply) (Parent) (Thread)

	From: sambushell	Date: June 18th, 2009 06:40 pm (UTC)		(Link)

Paths can be exposed through all sorts of accidental mechanisms. For example, in arguments to command-line tools that "ps" can display. But you haven't made it clear whether any parent directories are world/group-executable; if one isn't, then a third party can't get in anyhow, no?

(Reply) (Thread)

	From: boutell	Date: June 18th, 2009 07:34 pm (UTC)		(Link)

I did specify that 'fred' is not world-anything. As long as 'fred' is not world-anything and the next level beneath it has a random, too-long-to-guess name, the plan works (provided the path isn't accidentally leaked in about 500 ways, as pointed out elsewhere).

(Reply) (Parent) (Thread)

	From: dr_strych9	Date: June 18th, 2009 08:40 pm (UTC)		(Link)

lsof is another tool

I'm not sure having obscuring the path helps beyond setting the execute permissions on the parent directory. I'd guess that even the most clueless attackers can get the path to a world writable .php file buried down in the cache directory whether the path has a cryptographically random number in it or not.

The trick is opening the file given a path through a directory for which you don't have execute permission. The usual way to do that is to convince something that does have access to the file to create a hard link to it somewhere else where you can access it. Earth-shatter kaboom naturally follows.

(Reply) (Parent) (Thread)

	From: boutell	Date: June 18th, 2009 09:00 pm (UTC)		(Link)

If you're in a position to trick a web site into making hard links I'd imagine you've already cracked it wide open. (True, I never specified this was web stuff.)

(Reply) (Parent) (Thread)

	From: markoutrage	Date: June 18th, 2009 06:42 pm (UTC)		(Link)

consider "chmod 1xxx cache" (maybe 1777)

This will allow multiple users to update /cache/ (and manage their *own* files) while the permissions xxx will affect the files themselves. (do you care if they're readable?)

(look at the manpage where it mentions the sticky bit, this is what mailspool and /pub dirs usually have set)

Remember that httpd usually works based on the permissions of the anonymous (lowest) bit; do the outsiders have filesystem access, or just via httpd?

(Reply) (Thread)

	From: boutell	Date: June 18th, 2009 07:31 pm (UTC)		(Link)

I should have stated a bit more clearly that I am stuck with the 777. It's outta my hands.

(Reply) (Parent) (Thread)

	From: qwrrty	Date: June 18th, 2009 07:00 pm (UTC)		(Link)

I think your assessment is basically correct -- there is no inherent mechanism that will allow them to figure out that path without guessing brute-force.

You know and I know that the risk of the path accidentally getting written to some user-visible location is unpleasantly high.... but like you say, more secure mechanisms often require an uphill battle both-ways-through-the-snow.

(Reply) (Thread)

	From: ronebofh	Date: June 18th, 2009 07:21 pm (UTC)		(Link)

"Inside the cache folder, which is completely world-readable, writagle and executable, there will be world-writable, world-readable, world-executable files. Worse, those files are .php files."

No. Just stop right there. It isn't happening and i will not sanction this in any way.

(Reply) (Thread)

From: hatter	Date: June 18th, 2009 08:49 pm (UTC)		(Link)

Is anything served directly from that resource ? If not (or if you do clever indirect references via a non-777 file caching the randomness) then you could rename the folder each time the app/script runs, just as soon as you change your current working directory to catproject. Inode stays the same, name changes. As long as the random name will be unique in matching a wildcard pattern, your own user can find it with a wildcard match, but people without read access to it's containing dir can't.

the hatter

(Reply) (Thread)

	From: glaucon	Date: June 19th, 2009 05:02 am (UTC)		(Link)

I'm with rone.
don't solve the problem - solve the premise.

(Reply) (Thread)


	13 comments or Leave a comment

profile


User: boutell Name: Tom Boutell Website: Goode Trouble

calendar

page summary

marnanel (no subject) [+2]

sambushell (no subject) [+3]

markoutrage (no subject) [+1]

qwrrty (no subject)

ronebofh (no subject)

hatter (no subject)

glaucon (no subject)