git.oblomov.eu Git - ikiwiki/blob - doc/security/discussion.mdwn

   1 Copied from an email I sent --[[Joey]]
   2
   3 > Apart from restricting escape characters and characters with special
   4 > meanings to the filesystem (such as '/') or the version control system
   5 > (which may not cope with \n), why limit filenames at all?
   6
   7 Suppose that git-add and git-commit a shell scripts:
   8
   9         #!/bin/sh
  10         /opt/git/git commit $1
  11
  12         #!/bin/sh
  13         /opt/git/git add $1
  14
  15 Ok, that's crappy code, but git add and commit are only run by a trusted
  16 user at the command line, so it's hardly a security hole. (And frankly,
  17 I'm not all too impressed with the real shell code I've seen in git-*
  18 ..)
  19
  20 But there's no security problem until ikiwiki calls it on a filename
  21 that a web user made up. Now, suppose that ikiwiki decided to allow
  22 spaces in filenames. Nothing else new, just spaces. Of course, the above
  23 bad code will fail to add and commit such files.
  24
  25 But it won't just fail, it can even expose private data. Suppose that $1
  26 is "foo.mdwn .ikiwiki/userdb foo.mdwn". Then the userdb, with its
  27 passwords and emails is committed, along with foo.mdwn.
  28
  29 Moral: ikiwiki interfaces with code that was not necessarily written for the
  30 security context that ikiwiki runs in. Even the most innocuous filenames can do
  31 very unexpected things if you let the shell get ahold of them. Ikiwiki needs to
  32 sanitize the hell out of user inputted data before letting it anywhere near the
  33 shell.