Forum OpenACS Q&A: TCL, Filters, Security

Posted by Jens Strupp on 01/17/02 11:02 AM

Hi,

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?

Thank you,
Jens.

2: Response to TCL, Filters, Security (response to 1)

Posted by Jens Strupp on 01/17/02 05:16 PM

Let me be more specific with an example:

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:

http://www.yourxyzsite.com/..%c0%af../
(this becomes "/../../")

or, what happens if you place an index.adp file in the directory
above "pages" and do:

http://www.yourxyzsite.com/..%c0%af

or: http://www.yourxyzsite.com/..%c0%afindex.adp

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)

Thanks.

3: Response to TCL, Filters, Security (response to 1)

Posted by David Walker on 01/17/02 05:49 PM

All of the string transformation is done before the string hits the request
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
unpredicted functionality.

4: Response to TCL, Filters, Security (response to 1)

Posted by Jade Rubick on 01/17/02 06:30 PM

Perhaps once we all get our OACS 4 sites up, one of us can volunteer to have their site be targeted for attack, and we can all spend some time trying to get in. It would be a good way to find out what the vulnerabilities are with OACS, and it would be more proactive than waiting for the vulnerabilities to arise. If nothing else, it would be good for all of us to learn how people try and break in -- and save us time from when they actually do.

5: Response to TCL, Filters, Security (response to 1)

Posted by Don Baccus on 01/17/02 07:00 PM

Yes, setting up a target server such as Jade suggests would be fun. We could organize it as an informal contest ...

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.

6: Response to TCL, Filters, Security (response to 1)

Posted by Jens Strupp on 01/17/02 07:35 PM

Hi Don,

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.

Jens.

7: Response to TCL, Filters, Security (response to 1)

Posted by russ m on 01/18/02 12:14 AM

One issue I've noticed with the RP and OACS's combined
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
aside yet...

8: Response to TCL, Filters, Security (response to 1)

Posted by David Walker on 01/18/02 01:41 AM

Is there a list of blocked files in there somewhere?

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?

9: Response to TCL, Filters, Security (response to 1)

Posted by Jens Strupp on 01/18/02 11:31 AM

Hi David,

you block ".."? So you don't work with relative paths for
images and files? Do you block over-long unicode variants also?

10: Response to TCL, Filters, Security (response to 1)

Posted by David Walker on 01/18/02 12:55 PM

Relative paths in your URLs are resolved by the client. The server never
should receive a URL containing "..". I use relative URLs all the time with no
problems.