[English | Japanese]
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.
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;
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
!#/usr/bin/perl
$ENV{QUERY_STRING}=~s/y=%09/y=%20/g;
system("/usr/local/lib/namazu.cgi");
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.
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.
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.
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.
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.
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.
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"