34 lines
1.3 KiB
Plaintext
34 lines
1.3 KiB
Plaintext
|
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.
|