Forum OpenACS Development: AOLserver Security Audit

Posted by Jon Griffin on
In my searching through the AOLserver 3.5.1 source I found a couple of potential security problems. Mainly deprecated calls and such.

Is anyone interested in forming a security audit group for AOLserver? I haven't done any real C programming in about 5 years so I am rusty, but I think what I uncovered is valid.

Posted by Tom Jackson on

Yeah, I would be interested. Maybe a bunch of people jumping up and down is better than one. My last reported 'serious' security problem went virtually unnoticed by most. Considering that the bug still exists and allows reading and copying any file readable by the AOLserver user, including the ssl private key file, I don't know how interested the community will be in security bugs. This bug was previously found by aD, and is patched in the ad13 version recommended for OpenACS.

Posted by Jamie Rasmussen on
Tom - for new installations, is there anything that needs to be done other than commenting out the .tmpfile line in form.tcl and using ns_getformfile instead?  (I think that the Ns_QueryToSet check should be added to 3.5.x anyway.)
Posted by Tom Jackson on

A new version of ns_conn creates an list of files: ns_conn files, I think this is in 4.0. Since the code exists, it would be nice to use that method in the future, avoiding the hack of checking for query vars ending in .tmpfile. I seem to remember the query processing code being more efficient. The 3.4.2 version copied the query to a file and then parsed that file, creating new files for each file uploaded in the form. The new version goes directly from the posted data to the separate files, putting the filenames in the ns_conn.

My solution was to patch the C file and patch the form.tcl file, and Rob Mayoff suggested using a different C routine that creates a secure temp file (patching ns_tmpname?). OpenACS may turn out to be fairly easy to fix in any case, if most of the file uploads are handled through ad_page_contract.

Let me find the emails on the subject, and I'll post my version of the files for 3.4.2.

Posted by Jon Griffin on
Some of the problems are insecure temp files and AOL seems to not care. These are exploits and race conditions.

Can I restate my desire for opennsd? I keeping hearing 4.0, 4.0 but I see no notes on and not much here. They have thier agenda and that is fine. We need ours and it is time for a split.

Posted by Tom Jackson on
Here is the contents of one email that gives a quick solution:  you edit the form.tcl file, you config file and restart. I also include Rob Mayoff's response, so there are a number of suggestions floating around:


I have discovered a potential security issue with AOLserver when used in
most recommended configurations.

There are two root causes of the vulnerability.

First, ns_getform creates new files in a temporary directory that is
system dependent. This directory is usually guaranteed to be world
writeable. This allows any local user to create a symbolic link to any
file on the system. Once this is done, AOLserver cannot under any
circumstance determine if the file is actually in the temp directory or

The second issue is that most applications that process
multipart/form-data rely on varname.tmpfile to determine the location of
the temporary file. Nothing prevents an attacker from specifying 'any'
file on the filesystem. Some applications check the directory the file
is in and are only vulnerable to a local attacker.

The most vulnerable files are nsd.tcl, /etc/passwd and any ssl cert

nsd.tcl can be easily protected by placing read-only access to the root
user, the other files cannot be protected in this way. However the ssl
cert files can be moved to an obscure location to make the attack less

I have a proposed solution, which is accomplished by adding two new
configuration params:

ns_section "ns/server/${server}"
        ns_param  CreatMode            644
        ns_param  TmpDir              "/web/stellar2/uploads/tmp"
        ns_param  TmpFileTemplate      "nsgetformXXXXXX"

Oops, actually CreatMode doesn't work, but maybe should be added back
into the mix and used with the call to open.

I have patches for the 4.x series and the 3.x series of AOLserver.

$Header: /cvsroot/aolserver/aolserver/tcl/form.tcl,v 1.3 2000/08/01
20:36:17 kriston Exp $

I have the following patch (to ns_getform and another private proc):

>          set tmpdir [ns_config "ns/server/[ns_conn server]" TmpDir "/tmp"]
>          set tmpfiletemplate [ns_config "ns/server/[ns_conn server]" TmpFileTemplate
<              set tmpfile [ns_tmpnam]
>              set tmpfile [ns_mktemp ${tmpdir}/$tmpfiletemplate]
>          set tmpdir [ns_config "ns/server/[ns_conn server]" TmpDir "/tmp"]
>          set tmpfiletemplate [ns_config "ns/server/[ns_conn server]" TmpFileTemplate
<              set tmpfile [ns_tmpnam]
>              set tmpfile [ns_mktemp ${tmpdir}/$tmpfiletemplate]

for version 1.5 (latest available) of this file this patch works:
$Header: /cvsroot/aolserver/aolserver/tcl/form.tcl,v 1.5 2002/02/08
07:56:16 hobbs Exp $

>              set tmpdir [ns_config "ns/server/[ns_conn server]" TmpDir "/tmp"]
>              set tmpfiletemplate [ns_config "ns/server/[ns_conn server]" TmpFileTemplate
<                        set tmpfile [ns_tmpnam]
>                      set tmpfile [ns_mktemp ${tmpdir}/$tmpfiletemplate]

A more complete solution would be to prevent users from passing in
variables ending in '.tmpfile'
I think the C procedures are in nsd/conn.c for the 3.x series and
currently in nsd/form.c, however there are many installation which will
not patch and recompile and they will need configuration

The configuration advice on the first vulnerability is to recommend
write access only to the user under which the webserver is running.

--Tom Jackson

and from Rob:

1.  ns_mktemp and ns_tmpnam should be changed to use mkstemp.

2.  The user cannot make nsd overwrite an existing file, because
    _ns_parseformfp uses ns_openexcl.

3.  AOLserver should follow standard Unix practice and use $TMP or
    $TMPDIR as the temporary directory, rather than inventing another
    config variable.

4.  The sysadmin should set up a dedicated user id for each instance of
    AOLserver.  That user id should not own any files unless nsd
    absolutely needs write access to the files.  Obviously nsd doesn't
    need write access to its own nsd.tcl

And my patch for the form.c file:

[tom@multi nsd]$ diff form.c form.old
<      if (strstr(k, ".tmpfile")) {
<        Ns_Log(Error,"querystring variable contains .tmpfile");
<        Tcl_DStringFree(&kds);
<        Tcl_DStringFree(&vds);
<        return;
<      }
<      Ns_Log(Notice,"Found %s with value %s", k,

Looks like the 3.x series has completely different code.
This could probably be tuned a little so .tmpfile must appear at the end
of the query key.

Posted by Mat Kovach on
I"d be willing to take part in a team realted to checking security in OpenACS recommended version(s) of AOLserver.  We can, as good AOLserver users, offers the patches back to the AOLserver team.

Arsdigita offered a patched version for AOLserver to use with ACS and I don't think it is completely off the wall for use to consider the same.  While the AOLserver team has improved quite a bit recently in being more responsive to our needs, it  might be a bit unreasonable to expect them to move as quickly as we would like.

Posted by Andrew Piskorski on
Jon, are you on the AOLserver mailing list?  I suspect not, as I don't
see how the many recent improvements discussed there can jive with
your blunt, "we should fork the code" sounding statement.  E.g.:

Scott Goodwin and others (Jeff Davis, etc.) brought many orphaned
modules, inluding the Oracle driver under maintenance in the AOLserver
SourceForge CVS.  I think various folks have made progres on bringing
all the 3.3+ad13 patches into the latest AOLserver versions.  And AOL
just created a new "AOLserver Core Team" to govern AOLserver, with 3
AOL members and 4 non-AOL community members.

If OpenACS needs more input into the AOLserver development, trying out
this new ACT would seem that best route to try first...  FYI, at least
Dan Wickstrom and Robert Mello were offered as nominees, specifically
because folks on the AOLserver list thought their should be strong
OpenACS representation on the ACT, although both declined due to time

That said, an AOLserver security audit team sounds like a good idea.
Shouldn't you ask for volunteers on the AOLserver list as well?
And likewise, if OpenACS needs to offer a patched version of AOLserver
until the patches make it into the AOLserver, that sounds reasonable.

Posted by Jon Griffin on
As Tom stated in the above, his security patch has been ignored. I find that still almost all communication is ignored.

Yes I think we should fork because AOL isn't responsive. Scott G. has improved the site somewhat but it is still not much better.

What about 4.x it was supposed to be released real soon now, months ago. The cvs browser on sourceforge (IMHO the biggest mistake to date was putting stuff there), shows nothing having been done recently etc.

I waited several months since the last time this was mentioned and AOL still hasn't released OR fixed an obvious security flaw that was submitted with a patch. There are other deprecated/insecure calls in the tree that need to be addressed and I don't see any response from the AOL core team.

Posted by Jamie Rasmussen on
Jon - I'd suggest voicing your concerns at one of the next AOLserver AIM chats.  There are usually many experienced developers and members of the ACT at them, and you get much better response time than you do with email!  Unfortunately I have to miss the chat tomorrow, but hopefully you can make it.  I too am curious why this problem wasn't completely fixed.

A 4.0 release has been delayed for many reasons, including the formation of the ACT, documenting what we have, and coding for 3.5 and now 3.6.  Those actions are largely in response to community requests.

The AOLserver code base is *already* forked.  There are at least a half-dozen distributions available, causing untold confusion for new users.  (Yes, I am part of the problem. :-)  The distribution OpenACS is currently recommending is missing numerous bugfixes and features, and has no clear maintainer(s).  I think a revived OpenNSD would probably meet a similar fate.  There are lots of good things happening in the SourceForge tree, let's focus our efforts on integration instead of further division!