0

No this is not a duplicate of this and this. I have a more specific problem.

The situation

I have a root bash daemon that makes symlinks of files in a directory. It gets the filename of every file and makes a symlink of it. The problem arises when web-users can upload files to a folder where the files in it needs to be symlinked (yes this needs to be done, don't post an answer like: "you shouldn't"). My concern is that users can get root privilege when they craft a filename in such a way that they can 'escape' the symlink command and execute code as root.

My question

Is it indeed possible to craft such a malicious payload in a filename (with limits of allowed characters in a linux file name system) to get root escalation?

Community
  • 1
  • 1
  • 6
    That depends on how you are calling `ln`, but `ln "$fname"` should be safe. You aren't using `eval`, so nothing in the value of `fname` is going to be treated as code. The only issue I can think of is a potential buffer overflow if `fname` is extremely long, but I think the risk there is minimal to non-existent. – chepner Oct 01 '15 at 15:02
  • 4
    We **hope** you are not using `eval`... And [you **must** properly quote all variables](http://unix.stackexchange.com/q/171346/4667). – glenn jackman Oct 01 '15 at 15:21
  • Any way, you could add some extra check in the daemon to make sure that the filename doesn't hide any malicious command before creating the symlink – rkachach Oct 01 '15 at 15:39
  • This fully answers my question: http://unix.stackexchange.com/questions/171346/security-implications-of-forgetting-to-quote-a-variable-in-bash-posix-shells –  Oct 01 '15 at 16:32

1 Answers1

2

Is it indeed possible to craft such a malicious payload in a filename [...] to get a root escalation?

The first step is to run an arbitrary command; getting a root escalation is then a question of exploiting separate privilege escalation bugs in the local system, which is a bit out-of-scope for a question about bash.

In terms of whether one can run an arbitrary command by data passed to a shell script: Not if the shell script is written correctly. If it has arbitrary, and potentially buggy, contents, then perhaps so. Without seeing a specific script to audit, how are we to say?

My concern is that users can get root privilege when they craft a filename in such a way that they can 'escape' the symlink command and execute code as root.

This isn't possible if your script is correctly written.

Use -- to prevent names from being treated as options, and double-quotes to prevent string-splitting and glob expansion.

ln -- "$source" "$dest"

Arguments such as -s and -f must go before the --, which asserts that all following arguments are interpreted as positional.

Other parts of the script are also relevant: If you're parsing ls, using eval, or performing eval-equivalent operations (such as expanding user-controlled variables in strings which are treated as scripts; ssh arguments are an example of such; so are unquoted heredocs performing expansions), these can introduce vulnerabilities.

Which is to say: There are numerous things that can be done right (or wrong), and we'd need to see your code to audit it. Not that StackOverflow is the right place for that -- perhaps the Code Review StackExchange site? Be sure to run contents through http://shellcheck.net/ before submitting them for human review as well.

Charles Duffy
  • 280,126
  • 43
  • 390
  • 441