I would like to know how many people are going to be affected
and what is there feeling about a change in Tcl8 semantics that
impact on the way subst is working:
potential problem :
---8<--- crude code sample ---8<---
set mysecret "valuable passwd"
proc process_net {netstring} {
set exported1 "can leak 1";
set exported2 "can leak 2";
# ...
return_to_net {subst -nocommands $netstring};
}
---8<--- end code sample ---8<---
In previous Tcl version, you were guaranteed, whatever content
"netstring" could be, that whatever would be returned to the net was
only the value of locally defined variables (here exported*).
In Tcl8, with the automagic namespace scoping, if the netstring
happens to contain "$::mysecret" you are going to leak your data.
Some people here would argue that you should use safe interpreters
to handle unsafe data, but the point is that subst -nocommands was an
efficient and safe way to perform a number of needed tasks.
I'll try to at least provide a new "-secure" flag to subst command
that would currently mean no commands and no "::" in variables;
but this does not solve the potential problem of existing
scripts that would need to be checked and changed before an upgrade.
So I'd like to know :
+ Do you know a script that would be badly affected
by the security problem of subst if it's tclsh/wish was
upgraded from Tcl7 to Tcl8 ?
+ Do you have any opinion about possible solutions ?
Thanks for your attention
You can reply by email if you feel that your answer (for instance
you know a well known CGI script that would break) would
be a security problem by itself.
NB: Tcl8 is going final "very soon now" so if you have strong feeling
hurry to answer ! (and send me a mail CC, in case our news feed would
be slow)
--
Laurent Demailly (dl) * Sun labs * SunScript - Tcl/Tk team