summaryrefslogtreecommitdiff
path: root/doc/security/discussion.mdwn
blob: ddf61c5f8771c581a449fd07f106f62cc3d60026 (plain)

Copied from an email I sent --[[Joey]]

Apart from restricting escape characters and characters with special meanings to the filesystem (such as '/') or the version control system (which may not cope with \n), why limit filenames at all?

Suppose that git-add and git-commit a shell scripts:

#!/bin/sh
/opt/git/git commit $1

#!/bin/sh
/opt/git/git add $1

Ok, that's crappy code, but git add and commit are only run by a trusted user at the command line, so it's hardly a security hole. (And frankly, I'm not all too impressed with the real shell code I've seen in git-* ..)

But there's no security problem until ikiwiki calls it on a filename that a web user made up. Now, suppose that ikiwiki decided to allow spaces in filenames. Nothing else new, just spaces. Of course, the above bad code will fail to add and commit such files.

But it won't just fail, it can even expose private data. Suppose that $1 is "foo.mdwn .ikiwiki/userdb foo.mdwn". Then the userdb, with its passwords and emails is committed, along with foo.mdwn.

Moral: ikiwiki interfaces with code that was not necessarily written for the security context that ikiwiki runs in. Even the most innocuous filenames can do very unexpected things if you let the shell get ahold of them. Ikiwiki needs to sanitize the hell out of user inputted data before letting it anywhere near the shell.