On Sat, 13 Sep 2003 16:08:52 +0100,
Jim Dabell <ji********@jimdabell.com> wrote:
I'm in the middle of writing a small app for Linux that needs to create
directories that take their names from untrusted data. If possible, I'd
like to preserve special characters rather than switching them with dummy
I was once told about a security seminar where the speaker explained there
are two approaches to rules, the American "Everything not forbidden is
permitted" and the Prussian "Everything not explicitly allowed is
forbidden." For security, you really want to go with the Prussian approach
of picking a set of legal characters and discarding anything not in the set,
rather than the American approach of '; and / are forbidden; everything else
is permitted." You might someday find a security hole stemming from allowing
the $ character, at the cost of a break-in; another day you might find
another hole by getting broken into again. It's better to start with a safe
set, and increase the set very cautiously as necessary.
A sneaky approach might be to hex-encode everything; the input filename
'foo' becomes the on-disk filename '666f6f'. Unreadable, but attackers have
no way to create special characters.
characters. For instance, using bash, I'd just escape characters with
backslashes when I want to create a directory name with, say, a slash in.
I don't believe you can do this on Unix systems; the kernel always assumes
that slashes indicate multiple directory levels, so foo\/bar would be a
directory named 'foo\' containing a file named 'bar'.
Also, are there any other things I should watch out for (e.g. excessively
long names)?
'..' in paths; someone could provide a filename of ../../<a bunch more
...'s>/etc/passwd. If you just open the path and write to it (and happen to
be running as root), bang, you've just blown away your /etc/passwd. Long
names will fail after a certain point -- most filesystems seem to have a
256-byte limit -- but that doesn't seem to present a security risk.
--amk