[ SecurityFocus: BID #5025 describes this issue; may it be noted that older versions are NOT vulnerable. ] In Xitami 2.5 Beta, a GSL feature was implemented. GSL is an XML-type server-side language. Xitami demonstrates this with two sample scripts. Errors.gsl is used for error processing in servers where it has been enabled. (Disabled by default) Errors.gsl poorly checks the hostname of the input request, only filtering SCRIPT (case insensitive filter) out of the host. So, events can be fired to run code: http://www.<IMG%20SRC=""%20ONERROR="alert(document.cookie)">.target.com/erro r404 It also does not check the User-Agent field AT ALL: [ telnet target.net 80 ] GET / HTTP/1.0 User-Agent: <SCRIPT>alert(document.cookie);</SCRIPT> [ End sent data ] Xitami will return the script in the output. If an attacking page can control the User-Agent (or any part of it), it can run code on a visiting browser in the name of the site running the Beta. Vendor: iMatix has forwarded my original post to the discussion forum, and will update the script in future beta releases. References: iMatix Home Page (iMatix) http://www.imatix.com Xitami Home Page (iMatix) http://www.xitami.com Other Issues: Xitami Web Server Plaintext Administrator Password Storage (SecuriTeam [By ace; shellcode@attbi.com]) Defaults.aut Displays Un-encrypted Admin Password http://www.securiteam.com/windowsntfocus/5CP0M0A7FU.html Xitami Reserved Device DoS Vulnerability (SecuriTeam [By neme-dhc; neme-dhc@hushmail.com]) AUX Device Access Causes Server Hang http://www.securiteam.com/windowsntfocus/5PP0R1F41O.html Xitami CGI Processing Failure Vulnerability (SecuriTeam) CGI Script Processing Error Allows Code Disclosure http://www.securiteam.com/securitynews/5TP0L0075K.html
