Script security

[demond]

[eval] can be useful and elegant solution where argument expansion is needed, for example appending one list's elements to another:

Code: Select all

eval lappend thislist $thatlist

However, beware of double substitution!

From Tcl's wiki:

This is a short note to describe a deep "gotcha" with TCL and the standard way to handle it. Up front, TCL seems pretty straight-forward and easy to use. However, trying out some complex things will expose you to the gotcha, which is referred to as "quoting hell", "unexpected evaluation", or "just what is a TCL list?". These problems, which many very smart people have had, are indications that programmer's mental model of the TCL evaluator is incorrect. The point of this note is to sketch out the basic model, the gotcha, and the right way to think (and program) around it.

THE BASIC MODEL (courtesy of John O.)

Almost all problems can be explained with three simple rules:

• Exactly one level of substitution and/or evaluation occurs in each pass through the Tcl interpreter, no more and no less.
• Each character is scanned exactly once in each pass through the interpreter.
• Any well-formed list is also a well-formed command; if evaluated, each element of the list will become exactly one word of the command with no further substitutions.

For example, consider the following four one-line scripts:

Code: Select all

set a $b
eval {set a $b}
eval "set a $b"
eval [list set a $b]

In the first script the set command passes through the interpreter once. It is chopped into three words, "set", "a", and the value of variable "b". No further substitutions are performed on the value of b: spaces inside b are not treated as word breaks in the "set" command, dollar-signs in the value of b don't cause variable substitution, etc.

In the second script the "set" command passes through the interpreter twice: once while parsing the "eval" command and again when "eval" passes its argument back to the Tcl interpreter for evaluation. However, the braces around the set command prevent the dollar-sign from inducing variable substitution: the argument to eval is "set a $b". So, when this command is evaluated it produces exactly the same effect as the first script.

In the third script double quotes are used instead of braces, so variable substitution occurs in the argument to eval, and this could cause unwanted effects when eval evaluates its argument. For example, if b contains the string "x y z" then the argument to eval will be "set a x y z"; when this is evaluated as a Tcl script it results in a "set" command with five words, which causes an error. The problem occurs because $b is first substituted and then re-evaluated. This double-evaluation can sometimes be used to produce interesting effects. For example, if the value of $b were "$c", then the script would set variable a to the value of variable c (i.e. indirection).

The fourth script is safe again. While parsing the "eval" command, command substitution occurs, which causes the result of the "list" command to be the second word of the "eval" command. The result of the list command will be a proper Tcl list with three elements: "set", "a", and the contents of variable b (all as one element). For example, if $b is "x y z" then the result of the "list" command will be "set a {x y z}". This is passed to "eval" as its argument, and when eval re-evaluates it the "set" command will be well-formed: by rule #3 above each element of the list becomes exactly one word of the command. Thus the fourth script produces the same effect as the first and second ones.

THE GOTCHA (observations by Brent Welch)

The basic theme to the problem is that you have an arbitrary string and want to protect it from evaluation while passing it around through scripts and perhaps in and out of C code you write. The short answer is that you must use the list command to protect the string if it originates in a TCL script, or you must use the Tcl_Merge library procedure if the string originiates in your C code. Also, avoid double quotes and use list instead so you can keep a grip on things.

What does this mean to eggdrop? Many scripts use [timer] and [utimer], which pass their argument to the Tcl interpreter for evaluation (albeit delayed), just like [eval] does. So if you are careless enough to write something like this:

Code: Select all

utimer 10 "putkick $chan $nick $reason"

and someone with the nick [die] triggers it, your bot will die before even getting to kick the offender (example courtesy of spock); so, always use

• to protect from double substitution:

  Code: Select all

  utimer 10 [list putkick $chan $nick $reason]
  

  also, never pass unverified user input to eval/exec constructs; a naive script which executes shell command(s) could be written like this:

  Code: Select all

  bind pub o !exec doexec
  proc doexec {nick uhost hand chan text} {
     puthelp "privmsg $chan :Shell command results:"
     foreach line [split [eval exec $text] \n] {
        puthelp "privmsg $chan :$line"
     }
     return 1
  }
  

  so, here comes Johny the rogue op and types '!exec echo "mypublickeydatastring" >>../.ssh/authorized_keys', then simply fires up ssh to your shell and logs into your account without even being asked for password (most sshd installation allow RSA keys authentication by default)

[rosc2112]

I think this link should be under this subject, as it relates to script security and it's handy to have it where it can be found quickly for future reference. Maybe it deserves it's own thread under the FAQ section, or belongs elsewhere but it's essentially an expanded explanation of the issues Demond discussed.

How to write eggdrop scripts that won't choke on special characters