A directory traversal vulnerability exists in the Ars Digita Community System. A remote attacker could exploit this vulnerability to read arbitrary files with the permissions of the web server.
Ars Digita Community System (ACS) 3.4.9, 3.4.10, and probably earlier versions
Ars Digita Community Education Solution (ACES) 1.1
OpenACS all versions
Ars Digita Community System (ACS) 4.2
ACS-Java 3.4, 4.0, 4.7.4
A remote attacker could exploit this vulnerability to read sensitive files on the affected system. Possible targets could include files containing passwords, private keys for SSL certificates, and web server logs.
RFC2396 permits the use of escaped characters in a URI string, consisting of a percent sign followed by two hexadecimal digits corresponding to the ASCII value of the character. For example, a space would be encoded as %20.
The unencoding of these values is typically handled by the web server. Affected versions of ACS perform their own decoding operation after that done by the web server, so that URIs containing %25, the encoded form of the percent character, are decoded twice.
Web servers traditionally also perform sanity checks on URLs to prevent them from accessing files in the directory tree outside of the web server's configured root directory. One of the most common restricted sequences is "../", which refers to the parent directory of the current working directory.
Because the second URI decoding that ACS performs occurs after the sanity checks done by the web server, encoded forms of "../" are not properly escaped, leading to the possibility of URIs that access files outside of the web server's root directory.
In the request-processor-procs.tcl file, replace the line
set url [ns_urldecode [ns_conn url]]
set url [ns_conn url]
This example will retrieve the UNIX password file from a vulnerable host with a web root fewer than 8 directories deep from the root directory.
Thanks to Eve Andersson for finding the source of the bug in the application code and providing a fix.
Thanks to the OpenACS development team for helping confirm their software is not vulnerable.
-- Elliot Kendall <email@example.com> Network Security Engineer Brandeis University