Forum OpenACS Q&A: TCL, Filters, Security
do you know of any (check) lists (Urls, Threads) related in general to security
issues with TCL, AOLServer filters (and how they are used within the
OACS) and Script-Kiddie attacks (On Port 80) against the system?
Are there known vulnerabilites or problems you can think of with the way the request processor is implemented?
As the RP handles all the request, what measures should be done to maximum protect a OACS installation?
How does TCL work with Unicode chars that come in via
ns_conn url? (and are used later with ad_conn url);
This was a well known problem for (mostly) M$ servers:
(this becomes "/../../")
or, what happens if you place an index.adp file in the directory
above "pages" and do:
Does the index.adp come up?
(I have no installation to test it myself at the moment).
How can a Unicode string be transformed to the normal ascii
representation in TCL? (of course, only if it's within the
ascii-range like above)
processor so tricking the request processor is more difficult.
At this time AOLServer and OpenACS is not a big target for script kiddies
due to the fact that it doesn't have a big market share.
If an exploit does show up related to the request processor it should be easy
enough to add a filter to block it. Probably 15 minutes work for an
experienced AOLServer/TCL/OpenACS programmer.
I'm not very familiar with the specifics of OpenACS 4's request processor so I
won't try to say whether it is safe or not. From a quick look at it it appears
complex and any complex piece of code is more vulnerable to subtle errors or
As far as the specific issue Jens raises, i.e. can you walk up the directory tree and get into areas you shouldn't be able to play in, there's no direct way to do this. However as noted the request processor is complex and complex code has a higher probability of being broken than simple code.
the problem with this Unicode approaches is if the code comes to
the point of delivery, e.g. a tcl array might first try to lookup
paths using the unicode thing ( something like nodes(..A~/..) ),
thinks "Oh, the first time we see
this request" und then deliver instead something like
"/www/servers/test/pages/../index.adp" (the Ascii version).
I absolutely don't know when the C-/Tcl-Code is using Unicode
variant and when it's using the Ascii.
tcl/adp/xql page structure is that the RP makes no effort to hide
the files that shouldn't be visible to browsers , so for example
http://foo.com/index.xql will happily pass your query files back to
whoever requests them.
This isn't on the face of it a particularly serious issue, but it's a bit
of information leakage that I'd be happier without. I keep
meaning to have a dig in the RP and fix it, but haven't put the time
We use the following list
*~ (backup files from vi) *.bak (backup files from some text editors) *.include (in-house extension for files to be included *.xql *..* (I think this is handled somewhere already) *. (a trailing "." will reveal source on a windows machine. I don't block this pattern on my Linux machines)
any others that are important?
you block ".."? So you don't work with relative paths for
images and files? Do you block over-long unicode variants also?
should receive a URL containing "..". I use relative URLs all the time with no