[English | Japanese]

Namazu: Security Considerations


Fundamental policy

It should be safe the latest version of Namazu is, however we can't make a promise about it. THERE IS NO WARRANTY FOR NAMAZU. You are responsible yourself for using the software. But we try our best to fix security issue. If you find any problem, please contact to security@namazu.org.

Known problems

Discussion

Cross-Site Scripting Vulnerability

Cross-Site Scripting (XSS) is the problem anyone can embed any HTML tags to output of CGI by external input (like CGI parameters) , and interpret it as valid HTML tags or client side script (like JavaScript).
It is no effects on server side. However, it should be important effects on client side. If you use HTTP cookie, there is possibility of discovering value of HTTP cookie by malicious people. It is dangerous in some situation.

The following links are helpful information about XSS;

CA-2000-02: Malicious HTML Tags Embedded in Client Requests
(CERT)
The Cross Site Scripting FAQ
(Cgisecurity.com)
Information about cross-site scripting vulnerability on web sites (Written in Japanese)
(IPA security center)

The problem produced when query begins from a tab (%09)

2.0.13 Up to before namazu.cgi begins from a tab (%09). If query is specified, a reference character sequence will no longer be sanitized and cross-site scripting brittleness will occur. 2.0.14 By henceforth, this problem was coped with by deleting a top tab.

Workaround to 2.0.13 and before :

1. move namazu.cgi and .namazurc to a place where you cannot access with http. Assuming you move to /usr/local/lib.

2. create the script blow named namazu.cgi, and grant execution permission.
2.1. script by sh

#!/bin/sh
QUERY_STRING=`echo "$QUERY_STRING" | sed -e 's/y=%09/y=%20/g'`
export QUERY_STRING
/usr/local/lib/namazu.cgi
2.2. script by perl
!#/usr/bin/perl
$ENV{QUERY_STRING}=~s/y=%09/y=%20/g;
system("/usr/local/lib/namazu.cgi");

Around Standard Error Issue

namazu.cgi (2.0.10 or earlier) outputs warning messages to standard error. It causes cross-site scripting issue because some implementations of web server, for example, Microsoft Internet Information Server 4.0 and 5.0, treat standard error as same as standard output.

To solve the issue, we changed namazu.cgi (since 2.0.11) to output warning messages to NMZ.warnlog file instead standard error.

According to CGI specification, it isn't mentioned about standard error. We suspect it is failure of web server implementation. However, we think all CGI developers need to notice this fact because such implementations exist.

Waste of resources

Namazu supports regular expression search. It wastes CPU power when it used with complex regular expression.

The server can be prevented from negatively affecting other processing by excessive operation of CGI in limiting the server resource used.

In Apache 2.0, the server resource can be limited by using the RLimitCPU/RLimitMEM/RLimitNPROC directive.

[Only UNIX]
namazu.cgi stops the process in 60 seconds by default. Up to 2.0.13, it can configured by SUICIDE_TIME directive.

[UNIX/Windows]
It can disabled regular expression search by REGEX_SEARCH directive.

If you use Namazu for external use, you need to configure such directives properly.

Attention concerning OLE control filter(Windows limitation)

When the Office document file (Word, Excel, Powerpoint, and Ichitaro document and others) including the macro virus is processed when the OLE control filter is used with Namazu of the Windows version, the possibility that catches the wog cannot be completely denied.
The Office do application of the Office document file including the macro virus (Word, Excel, PowerPoint, Visio, and Ichitaro and others) and the dangers of this extent ..the opening...

There is a possibility that the macro is executed when an old version and the security setting of Microsoft Office have been changed.
Please remove the virus to the document processed with mknmz beforehand with the anti virus software to make sure.

Moreover, the virus check works when the OLE control filter opens the Office document file when the anti-virus software corresponding to anti-virus API is installed. We will recommend this function to be used together.

Example) Norton AntiVirus 2005

The OLE control filter that Namazu Project offers is olemsword.pl, oleexcel.pl at present, olepowerpoint.pl, oletaro.pl, olertf.pl, and olevisio.pl.
Besides this, there is OLE control filter that the third party made, too.

Attention of --decode-base64 option (Windows limitation)

Option --decode-base64 ..the addition.. does to E-mail/NetNews the decipherment it as for the appended Base64 encode part and puts out .. taking out.. to mknmz of Namazu 2.0.15.

It takes out by --decode-base64 when the Office document file including the macro virus is appended to E-mail/NetNews and there is an infected possibility with the virus as well as "Attention concerning the OLE control filter" when processing it with the OLE control filter.

Please remove the virus to E-mail/NetNews processed with mknmz beforehand with the anti virus software to make sure.

Attention of archive file(Windows limitation)

There is an infected possibility with the virus as well as "Attention concerning the OLE control filter" when processing it with the OLE control filter when the Office document file including the macro virus is included in the archive file.
Please remove the virus to the archive file processed with mknmz beforehand with the anti virus software to make sure.

Directory traversal

Namazu uses some template files for different languages. It is identified by LANG environment or lang parameter of CGI. In some situation, any remote user can access files in server by lang parameter with relative directory representation. It is called as directory traversal.

The problem caused by the following sequence:

There is the same problem on result cgi parameter.

Especially in Windows environment, relative path with non-existence directory is accessible. The following is an example:

C:\Documents and Settings\Administrator>type ..\..\foo\..\boot.ini
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
(snip)
The above example, C:\foo is not exist. Linux system can't access any file with non-existence directory, but we didn't recognize other Unix-like systems, but almost systems would be not effected.

The problem was fixed in Namazu 2.0.16. If you use Windows, we strongly suggest to upgrade it. It was reported by Jeff Porter,thank you.

pnamazu pure perl implementation of namazu.cgi, also effects the problem. If you use pnamazu, upgrade it.

Weakness of retrieval type that is UTF-7 encoding by misidentification of encode automatic operation recognition of Web browser

Namazu.cgi before Namazu 2.0.17 doesn't output charset to ContentType of the response header in default.
Therefore, Web browser displays encode from the output result of namazu.cgi recognizing it automatically.

When the character string that is the UTF-7 encoding is specified for the retrieval type, the character string that is the UTF-7 encoding is included in the output of namazu.cgi almost as it is. At this time, it is likely to misidentify it to UTF-7 by the encode automatic operation recognition of Web browser. (Chiefly for an English site. )Therefore, there is a possibility being executed for an arbitrary script in user's browser when the script that is the UTF-7 encoding is specified for the retrieval type.
(cross site scripting weakness)

It was corrected that charset was output to ContentType of the response header without fail in Namazu 2.0.18 for this measures. This problem can be evaded by the version's improving to Namazu 2.0.18.

Moreover, Namazu : ContentType of the response header since 2.0.6. The function to specify directly with .namazurc is possessed. Therefore, this problem can be evaded even by the version before Namazu 2.0.17 by specifying it for ContentType of .namazurc including charset.

Example 1) For Japanese(UNIX)

ContentType "text/html; charset=EUC-JP"

Example 2) For Japanese(Windows)

ContentType "text/html; charset=Shift_JIS"

Example 3) For English

ContentType "text/html; charset=ISO-8859-1"

Charset corresponding to the language is automatically added when charset is not included in ContentType since Namazu 2.0.18. Charset corresponding to the language can be specified by the Charset directive for the language not supported by default by Namazu.

The example) Eo (Esperanto) is associated with ISO-8859-3. 

Charset "eo" "ISO-8859-3"

Namazu Homepage

$Id: security.html.en,v 1.23 2011-07-18 14:31:53 opengl2772 Exp $
webmaster@namazu.org