BugTraq
S21SEC-024 - Vignette TCL Injection May 26 2003 02:14PM
S21SEC (vul-serv s21sec com) (1 replies)
Re: S21SEC-024 - Vignette TCL Injection May 28 2003 10:15AM
Stefan Bethke (s bethke tallence com)
Am Montag, 26.05.03, um 16:14 Uhr (Europe/Berlin) schrieb S21SEC:

> The affected Vignette commands are:
> - NEEDS
> - VALID_PATHS
>
> All the TCL templates or scripts, that use this commands, are
> vulnerable to remote code injection.

This is overly broad. The actual vulnerability depends on the code path
taken in the NEEDS Tcl procedure.

> SET queryString [SHOW HTTP_QUERY_STRING] <---
> (!)

This problematic line was already identified by Bas Scheffers (IIRC).
http://bas.scheffers.net/vgn-needs-login-exploit.html

> regsub -all {; } [SHOW HTTP_COOKIE] { } cookieString
> <--- (!)
>

> -- Lines 1272/1277 (VALID_PATHS command) --

> system_error "Invalid path \"$_Path\" for template (referer='[SHOW
> HTTP_REFERER]')" <--- (!)

> As seen, the value of some unfiltered variables is used and evaluated
> with the SHOW command. If the external variable contains Vignette
> code, then arbitrary TCL execution is posible. The affected input
> variables are:
> - HTTP_QUERY_STRING, converted to queryString in NEEDS command.
> - HTTP_COOKIE, converted to cookieString in NEEDS command.
> - HTTP_REFERER, showed in VALID_PATHS command.

This is incorrect. While this might enable XSS attacks, it does not
allow for Tcl code injection. The problematic command here is not SHOW,
but SET.

A (simplified) version of the Vignette SET command would look like this:

proc SET {var val {noeval {}} {
if {$noeval != "NOEVAL"} {
set val [EVAL $val]
}
namespace eval ::VgnDefaultNamespace [list set $var $val]
}

That is, unless a third argument of "NOEVAL" is passed to the SET
command, the value will be interpreted as a Vignette Tcl template
piece, and any Tcl command embedded in it in the form of "[code]" will
be executed.

> Solution
> --------
>
> Replace the offending SHOW evaluations in stdlib.tcl with directly
> passed variables. For example:
>
> instead: SET queryString [SHOW HTTP_QUERY_STRING]
> use ==> SET queryString $HTTP_QUERY_STRING

This is incorrect, and will likely break your application.

--
Stefan Bethke <s.bethke (at) tallence (dot) com [email concealed]>
Tallence GmbH, Steinhöft 11, D-20459 Hamburg, Germany
Mobile +49 170 3460140, Office +49 40 36099860, Fax +49 40 36099869

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus