do these tcl error indicate insecure code?
nickname
I am doing a security test on a system having an embedded TCL
interpreter. The system receives input from Internet (HTTP) parses it
and passes to customisable TCL scripts. During a fuzzing test (sending
binary garbage in HTTP headers) I have noticed the following errors in
the log:
TCL error: list element in quotes followed by "{}x" instead of
space
while executing "foreach header [ XXXXX ] { }"
or
TCL error: unmatched open quote in list
while executing "foreach header [ XXXXX ] {}"
Here XXXXX is a command returning an array of HTTP headers, as parsed
by the system. Sorry for obfuscating the real command, I hope you
understand I don't want to make too many details public before the
vendor is informed about the security issue (if it turns out to be an
issue).
TCL code producing the error is very simple:
foreach header [ XXXXX ] { }
As far as I can tell, HTTP parsing is done outside of TCL and parsed
values made accessible to TCL via custom commands (possibly
implemented as TCL extension).
So my question are:
1) Are these error tell-tale signs of security problems with the
system, such as insufficient user input validation?
2) If yes, can this condition be exploited to execute arbitrary TCL
statemets by sending the system specially crafted request, a kind of
http://en.wikipedia.org/wiki/Code_injection attack?
3) Are there any "Secure TCL coding practices" document? Any other
source of information on how to safely handle untrusted data?
Best regards,
Alex
http://www.gremwell.com/
Donal K. Fellows
> 1) Are these error tell-tale signs of security problems with the
> system, such as insufficient user input validation?
They're an indication of problems in the parsing code. I'd guess that
the code is assuming that it can assume that a header is a well-formed
Tcl list, which you've found to be wholly unsafe. Sanitization is to
use something like this:
set listOfWords [regexp -all -inline {\S+} $someString]
The resulting collection of words is *guaranteed* to be a well-formed
list, for an arbitrary input string.
> 2) If yes, can this condition be exploited to execute arbitrary TCL
> statemets by sending the system specially crafted request, a kind of
> http://en.wikipedia.org/wiki/Code_injection attack?
Probably not, not unless you then treat that list as code.
> 3) Are there any "Secure TCL coding practices" document? Any other
> source of information on how to safely handle untrusted data?
The simplest method is to do the parsing in a Safe Interpreter:
interp create -safe parsingInterp
parsingInterp eval { make the procedures }
parsingInterp eval [list doTheParse $stringToParse]
Note that we also guarantee that constructed lists (e.g., those out of
[list], and many other commands besides) are eval-safe. That is:
eval [list $a $b $c]
is _exactly_ the same as:
$a $b $c
This is true whatever is in those variables.
Donal.
Andreas Leitgeb
> I am doing a security test on a system having an embedded TCL
> interpreter. The system receives input from Internet (HTTP) parses it
> and passes to customisable TCL scripts. During a fuzzing test (sending
> binary garbage in HTTP headers) I have noticed the following errors in
> the log:
>
> TCL error: list element in quotes followed by "{}x" instead of space
> while executing "foreach header [ XXXXX ] { }"
This looks like a bug in XXXXX. Is that a self-written one?
Typically, a function returning a list of headers is supposed
to really return a list, and if it did so correctly, by using
the "list" command, rather than stitching together a string and
hoping that it will do as a list, then you wouldn't have see this.
As the code in XXXXX is obviously buggy, it is not unlikely that
another bug in it could even allow for code injection. Any such
further bug is, however, not yet deducible from what info we have.
"foreach" itself is safe: if what it gets as a list isn't a
list, it will throw an error, just as you saw.
If, instead, you were using the infamous pre-8.5 idiom:
eval YYYYY [ XXXXX ]
to spread out the list argument into individual arguments,
or if something similar happens inside XXXXX, then code-
injection is an immediate threat! This threat, however,
is primarily a consequence of a bug at the place where
this "non-list" was created. Also, even in pre-8.5 tcl
there are less dangerous, though complicated ways to
spread a dubious list without risking code-injection.
nickname
> This looks like a bug in XXXXX. Is that a self-written one?
I do not know, it is a commercial product, the only user-serviceable
part are TCL scripts which use XXXXX commands. I can see TCL
interpreter is statically compiled into a program running on Linux, I
can see the TCL scripts I write get executed and receive information
about HTTP headers via custom commands. I imagine those commands are
implemented as TCL extensions, but your and Donal's feedback convince
me HTTP parser is also in TCL, hidden somewhere.
> As the code in XXXXX is obviously buggy, it is not unlikely that
> another bug in it could even allow for code injection. Any such
> further bug is, however, not yet deducible from what info we have.
Sorry, I don't have any more info myself. I don't even have access to
the system anymore and not sure I will have in the future.
> If, instead, you were using the infamous pre-8.5 idiom:
> eval YYYYY [ XXXXX ]
> to spread out the list argument into individual arguments,
> or if something similar happens inside XXXXX, then code-
> injection is an immediate threat! This threat, however,
> is primarily a consequence of a bug at the place where
> this "non-list" was created. Also, even in pre-8.5 tcl
> there are less dangerous, though complicated ways to
> spread a dubious list without risking code-injection.
Thanks for this hint.
Regards,
Alex
Andreas Leitgeb
> Sorry, I don't have any more info myself. I don't even have access to
> the system anymore and not sure I will have in the future.
Surely not! Now, that you had your hands on it, and found a weakness
in the software, *you* are considered a threat; not the bad software ;-)