From: Joey Hess Date: Wed, 30 Jan 2008 20:24:39 +0000 (-0500) Subject: copying an intersting bit from an email I'm writing X-Git-Tag: 2.40~159 X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=8ba2c11c3c81f90a07f30954ba643e75245d58f1;p=ikiwiki.git copying an intersting bit from an email I'm writing --- diff --git a/doc/security/discussion.mdwn b/doc/security/discussion.mdwn new file mode 100644 index 000000000..ddf61c5f8 --- /dev/null +++ b/doc/security/discussion.mdwn @@ -0,0 +1,33 @@ +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.