wp-02-0008: Apache Tomcat Cross Site Scripting
Westpoint Security Advisory Title:Apache Tomcat Cross Site Scripting Risk Rating: Low Software: Apache Tomcat v4.0.3 Platforms:WinNT, Win2k, Linux Vendor URL: jakarta.apache.org Author: Matt Moore [EMAIL PROTECTED] Date: 10th July 2002 Advisory ID#: wp-02-0008 Overview: = Apache Tomcat is the servlet container that is used in the official Reference Implementation for the Java Servlet and JavaServer Pages technologies. Tomcat has a couple of Cross Site Scripting vulnerabilities. Details: Cross Site Scripting By using the /servlet/ mapping to invoke various servlets / classes it is possible to cause Tomcat to throw an exception, allowing XSS attacks: tomcat-server/servlet/org.apache.catalina.servlets.WebdavStatus/SCRIPTalert(document.domain)/SCRIPT tomcat-server/servlet/org.apache.catalina.ContainerServlet/SCRIPTalert(document.domain)/SCRIPT tomcat-server/servlet/org.apache.catalina.Context/SCRIPTalert(document.domain)/SCRIPT tomcat-server/servlet/org.apache.catalina.Globals/SCRIPTalert(document.domain)/SCRIPT Linux and Win32 versions of Tomcat are vulnerable. (angle brackets omitted) The DOS device name physical path disclosure bug reported recently by Peter Grundl can also be used to perform XSS attacks, e.g: tomcat-server/COM2.IMG%20src= Javascript:alert(document.domain) This is obviously Win32 specific. Vendor Response: None. Patch Information: == Upgrading to v4.1.3 beta resolves the DOS device name XSS issue. The workaround for the other XSS issues described above is as follows: The invoker servlet (mapped to /servlet/), which executes anonymous servlet classes that have not been defined in a web.xml file should be unmapped. The entry for this can be found in the /tomcat-install-dir/conf/web.xml file. Two Nessus plugins should be available to test for these vulnerabilities from www.nessus.org: apache_tomcat_DOS_Device_XSS.nasl apache_tomcat_Servlet_XSS.nasl This advisory is available online at: http://www.westpoint.ltd.uk/advisories/wp-02-0008.txt
IE allows universal Cross Domain Scripting (TL#003)
Thor Larholm, PivX, security advisory TL#003 - By Thor Larholm, Denmark 10 July 2002 HTML format: http://www.PivX.com/larholm/adv/TL003/ Topic: IE allows universal Cross Domain Scripting. Discovery date: 25 June 2002. Severity: High Affected applications: -- Any application that hosts the WebBrowser control. Some of these are: Microsoft Internet Explorer Microsoft Outlook Microsoft Outlook Express Impact: --- Elevating privileges, arbitrary command execution, local file reading, stealing arbitrary cookies, etc. Authors: Patrick Zumstein and Thor Larholm. Introduction: - One of the many elements in HTML 4 is the OBJECT element which is used to embed external objects inside a page. Such objects can be the WebBrowser control and other ActiveX controls, images, applets and more. The object property of embedded WebBrowser controls is not subject to the Cross Domain security checks that embedded HTML documents ordinarily go through, and as such it is possible to escape any sandboxing and security zone restrictions. Discussion: --- Any document can extend the properties exposed by the OBJECT element, and any namespace conflicts are handled by querying the object property which is a duplicate reference to the embedded document. When embedding a document from the same site (same protocol, port and host) it is possible to make a reference to the object property without circumventing any Cross Domain security checks. After having established a reference we will then change the location of the document being embedded. The location changes but the reference stays, and we now have complete access to the DOM of the foreign document. The default object being referenced by the object property in the case of text/html is the document object. The simple proof-of-concept exploit below will read the cookie from passport.com. The OBJECT element is not restricted to embedding HTML documents, but can embed objects of any type. As such, this vulnerability could be extended even further. Exploit: object id=data data=empty.html type=text/html/object script var ref=document.getElementById(data).object; ref.location.href = http://www.passport.com;; setTimeout(alert(ref.cookie),5000); /script Solution: - Disable ActiveX, or Set Script ActiveX controls marked safe for scripting to Prompt or Disable ( URL: http://www.PivX.com/tutorials/disable_activex.html ). Tested on: -- IE6 Win2000, all patches and servicepacks. IE5.5 Win98, all patches and servicepacks. IE5.5 WinNT 4, all patches and servicepacks. Demonstration: -- I have put together some proof-of-concept examples: - Read foreign cookies - Read local (or foreign) file - Execute arbitrary commands These can be found at http://www.PivX.com/larholm/adv/TL003/ Vendor status: -- Microsoft was notified 25 June 2002. Mitigating factors: --- Outlook and OE are not directly affected if they run in the Restricted zone. Postscript: --- On June 25, Patrick Zumstein notified Thor Larholm, Georgi Guninski and PacketStormSecurity about a possible vulnerability. In working together, Patrick and Thor quickly outlined the culprit and prepared this advisory, after which Microsoft were notified immediately. Since this is possibly very publicly known by now I have decided to release this advisory after only 2 weeks times, so that system administrators and end users may possibly apply the provided workaround to temporarily secure themselves until a proper patch has been made. Regards Thor Larholm, Security Researcher PivX Solutions, LLC Unpatched IE security holes - 19 and counting http://www.PivX.com/larholm/unpatched/ Are You Secure? http://www.PivX.com
RE: XSS Hole in Fluid Dynamics Search engine
Hello, Thanks for this bug report. I have released an updated version which includes a fix (FDSE version 2.0.0.0055). For the folks at securitybugware.org and securityfocus.com, would you please include a mention of this update if you issue a report. Thanks, Zoltan Milosevic (360) 944-8387 Fluid Dynamics Search Engine http://www.xav.com/scripts/search/ -Original Message- From: valdeux [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 10, 2002 7:40 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: XSS Hole in Fluid Dynamics Search engine Name : FD Search Engine Vendor :Fluid Dynamics - http://www.xav.com Version : Probably all Demo : http://www.xav.com/search.pl Note : Sorry for my poor english ... - PROBLEM For a multiple result pages search, the script uses the variable Rank wich contains current result number. Anything could be written into, including HTML tags. EXEMPLE http://www.xav.com/search.pl?Realm=AllMatch=0Terms=testnocpp=1maxhit s=10 Rank=brh1XSS/h1 Note : it works because test returns several pages. SOLUTION None yet.
SuSE Security Announcement: Resolver (SuSE-SA:2002:026)
-BEGIN PGP SIGNED MESSAGE- __ SuSE Security Announcement Package:bind, glibc Announcement-ID:SuSE-SA:2002:026 Date: Tue Jul 09 2002 Affected products: 7.0, 7.1, 7.2, 7.3, 8.0 SuSE Linux Enterprise Server for S/390, SuSE Linux Database Server, SuSE eMail Server III, SuSE Linux Enterprise Server, SuSE Linux Firewall on CD Vulnerability Type: buffer overflow Severity (1-10):3 SuSE default package: yes Cross References: CERT CA-2002-19; CVE CAN-2002-0651 Content of this advisory: 1) security vulnerability resolved: buffer overflow in dig, host, and nslookup utilities. problem description, discussion, solution and upgrade information 2) pending vulnerabilities, solutions, workarounds 3) standard appendix (further information) __ 1) problem description, brief discussion, solution, upgrade information A vulnerability has been discovered in some resolver library functions. The affected code goes back to the resolver library shipped as part of BIND4; code derived from it has been included in later BIND releases as well as the GNU libc. The bug itself is a buffer overflow that can be triggered if a DNS server sends multiple CNAME records in a DNS response. This bug has been fixed for the gethostbyXXX class of functions in GNU libc in 1999. Unfortunately, there is similar code in the getnetbyXXX functions in recent glibc implementations, and the code is enabled by default. However, these functions are used by very few applications only, such as ifconfig and ifuser, which makes exploits less likely. We will make updated glibc packages available as they have gone through our build system, but without separate announcements. Until glibc patches are available, we recommend that you disable DNS lookups of network names in nsswitch.conf. Simply replace the line containing the tag networks: with this line: networks: files In the unlikely event that you've configured any name to network mapping via DNS, make sure you copy this information to /etc/networks. The resolver bug is also present in the libbind library included in BIND. This library is used by utilities from the bindutil package. We are therefore providing security updates for bind8 that address this vulnerability. As communicated previously (1), the SuSE security team is not providing fixes for BIND4 anymore. The bind9 packages shipped by SuSE are not vulnerable. Please download the update package for your distribution and verify its integrity by the methods listed in section 3) of this announcement. Apply the updata packages (bindutil, bind8) package using rpm -Fvh bind*.rpm If you are running the BIND name server, you should restart the name server process by issuing rcnamed restart Our maintenance customers are being notified individually. The packages are being offered to install from the maintenance web. References: (1) http://www.suse.de/de/support/security/adv004_ssh.html __ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - There is a format string bug in the nn news reader that can be exploited by a malicious NNTP server to execute arbitrary commands within the client user's account. We will be releasing updated packages. __ 3) standard appendix: authenticity verification, additional information - Package authenticity verification: SuSE update packages are available on many mirror ftp servers all over the world. While this service is being considered valuable and important to the free and open source software community, many users wish to be sure about the origin of the package and its content before installing the package. There are two verification methods that can be used independently from each other to prove the authenticity of a downloaded file or rpm package: 1) md5sums as provided in the (cryptographically signed) announcement. 2) using the internal gpg signatures of the rpm package. 1) execute the command md5sum name-of-the-file.rpm after you downloaded the file from a SuSE ftp server or its mirrors. Then, compare the resulting md5sum with the one that is listed in the
XSS Hole in Fluid Dynamics search Engine
Name : FD Search Engine Vendor :Fluid Dynamics - http://www.xav.com Version : Probably all Demo : http://www.xav.com/search.pl Note : Sorry for my poor english ... - PROBLEM For a multiple result pages search, the script uses the variable Rank wich contains current result number. Anything could be written into, including HTML tags. EXEMPLE http://www.xav.com/search.pl?Realm=AllMatch=0Terms=testnocpp=1maxhits=10; Rank=brh1XSS/h1 Note : it works because test returns several pages. SOLUTION None yet.
Re: iPlanet Remote File Viewing
In-Reply-To: [EMAIL PROTECTED] Well, the release notes for the service packs does mention the vulnerability you're talking about. 6.0 SP 3: http://docs.iplanet.com/docs/manuals/enterprise/60sp3/rn60sp3.html 4.1 SP 10: http://docs.iplanet.com/docs/manuals/enterprise/41/rn41sp10.html Download page: http://wwws.sun.com/software/download/inter_ecom.html#webs Cheers /Hubbel Yo I originally wrote to Sun about this on May 22 2002 and was advised that it would be fixed in the next Service Pack. David Litchfield says that 6.0 SP3/4.1 SP10 is out, but I don't yet see it on their Product Tracker site. I was going to wait to release this information until I had the Service Pack, feeling secure with my Snort sig but decided to go ahead since it pales in comparison to David's buffer overflow advisory.
Re: Linux kernels DoSable by file-max limit
On Mon, Jul 08, 2002 at 09:30:34PM -0400, Michal Zalewski wrote: And they can still most likely bypass your limit by putting something smart in their .procmailrc / .forward / .qmail, or in so many other ways. One could use 'initscript' to plug many of those holes: INITSCRIPT(5) Linux System Administrator's Manual INITSCRIPT(5) NAME initscript - script that executes inittab commands. SYNOPSIS /bin/sh /etc/initscript id runlevels action process When the shell script /etc/initscript is present, init will use it to execute the commands from inittab. This script can be used to set things like ulimit and umask default values for every process.
EEYE: Remote PGP Outlook Encryption Plug-in Vulnerability
Remote PGP Outlook Encryption Plug-in Vulnerability Release Date: July 10, 2002 Severity: High (Remote Code Execution) Systems Affected: NAI PGP Desktop Security 7.0.4 NAI PGP Personal Security 7.0.3 NAI PGP Freeware 7.0.3 Description: The beer is still cold, the days are still long, the exploits still start as jokes (this time over a beer with a three letter agency) and the advisories... we'll just say, All of your SCADA are belong to us. A vulnerability in the NAI PGP Outlook plug-in can be exploited to remotely execute code on any system that uses the NAI PGP Outlook plug-ins. By sending a carefully crafted email the message decoding functionality can be manipulated to overwrite various heap structures pertinent to the PGP plug-in. This vulnerability can be exploited by a user simply selecting a malicious email, the opening of attachments is not required. When the attack is performed against a target system, malicious code will be executed within the context of the user receiving the email. This can lead to the compromise of the targets machine, as well as their PGP encrypted communications. It should also be noted that because of the nature of the SMTP protocol this vulnerability can be exploited anonymously. Technical Description: Exploitation: By creating a malformed email we can overwrite a section of heap memory that contains various data. By overwriting this section of heap with valid addresses of an unused section in the PEB, which is the same across all NT systems, we can walk the email parsing and eventually get to something easily exploitable: CALL DWORD PTR [ecx] This pointer addresses references a function pointer list. At the time of exploitation, an attacker controlled buffer address is the first item on the stack. By overwriting the function pointer list pointer address with the address of an Import table, we can call any imported function. Our current stack will be passed into the function for parameter use. as is. The first item on our stack is an address that points to attacker-controlled data. By overwriting the address, with the address of the SetUnhandledExceptionFilter() IAT entry, execution will redirect into this address when the default exception handler is called, After returning from SetUnhandledExceptionFilter() PGP Outlook will fail as it crawls back down the call stack, after cycling through the exception list it will call the DefaultExceptionFilter, which now contains the address of our code. This of course can also be exploited silently using frame reconstruction. Due to the large size of an example vulnerable email we are not including it in our advisory. We will be updating the research section of our website with a link to an example email. http://www.eEye.com Where do you want your secret key to go today? Vendor Status: NAI has worked quickly to safeguard customers against this vulnerability. They have released a patch, for the latest versions of the PGP Outlook plug-in, to protect systems from this flaw. You may download the patch from: http://www.nai.com/naicommon/download/upgrade/patches/patch-pgphotfix.asp Note: This issue does not affect PGP Corporate Desktop users. Discover: Marc Maiffret Exploitation: Riley Hassell Greetings: Kasia, and the hot photographer from Inc Magazine. Phil Zimmerman, the godfather of personal privacy, much respect. Copyright (c) 1998-2002 eEye Digital Security Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please e-mail [EMAIL PROTECTED] for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. Feedback Please send suggestions, updates, and comments to: eEye Digital Security http://www.eEye.com [EMAIL PROTECTED]
Cisco VPN3000 gateway MTU overflow
Cisco VPN3000 gateway MTU overflow == Bug class: Conceptual/bad protocol implementation Equipments affected: Cisco/VPN 3000 Concentrator with software vpn3000-3.5.Rel-k9.bin FACTS The Cisco VPN3000 gateway lets remote client dictate which maximum MTU to use when sending back ESP frames, regardless of the transmitting capabilities of the physical medium. IMPACT * Oversized frames get silently discarded by equipements linked to the gateway's public interface and retransmissions occur. * Other disturbances or DoS against neighboring equipements may occur, especially as many IP stacks on routers and sniffers etc ... are poorly implemented. DETAILS We have witnessed this phenomena after establishing tunnels with the VPN dialer over a modem connexion: when the target sends back ethernet frames with size close to the max ethernet MTU (1500), the gateway encrypts the frames adding ESP headers and stupidly tries to send a 1580-bytes frame back to the client. RESOLUTION - From the official documentation there is no way to enforce a maximum MTU on the VPN gateway. - Hence: a gateway software patch by Cisco is necessary: if MTU negociation occurs, the gateway should set a max-MTU threshold (the physical medium's !). PSEUDO WORKAROUNDS * client side: For Windows-based OS (likely Unix and Linux-based OS too), Cisco released a tool called setMTU.exe that can prevent ill MTU negociation from happening. * target side: artificially lowering the max MTU on the interfaces. - But such a policy is not acceptable: The VPN client, as well as remote targets, should not have to be aware of the gateway's interface configuration ! The bug does not lie in client software, but in the gateway's software. Master Phi --- Today's statement: Networking software robustness isn't worth the tenth of that of arcade game engines. Let's call it junk software.
[CORE-20020528] Multiple vulnerabilities in ToolTalk Database server
CORE SECURITY TECHNOLOGIES http://www.corest.com Multiple vulnerabilities in Tooltalk database server Date Published: 2002-07-10 Last Update: 2002-07-10 Advisory ID: CORE-20020528 Bugtraq ID: 5082,5083 CVE: CAN-2002-0677, CAN-2002-0678 CERT: VU#975403 VU#299816 Title: Multiple vulnerabilities in Tooltalk database server. Class: Implementation flaws Remotely Exploitable: Yes Locally Exploitable: Yes Vendors contacted: - Sun CORE notification: 2002-06-10 CERT notification: 2002-06-11 4:32pm Status: .Vulnerable (original bug discovery on Solaris) .Acknowledged notification on 2002-06-10 .Research in progress, no confirmation from Sun as of 2002-06-18 .Official statement forwardr by CERT: 2002-07-10 - HP CORE notification: 2002-06-10 CERT notification: 2002-06-11 Status: .Acknowledged notification on 2002-06-10 .Confirmed HP-UX vulnerable on 2002-06-11 and issued high priority lab fix request .Official statement forwarded by CERT: 2002-07-10 - Compaq Computer Corporation CORE notification: 2002-06-10 CERT notification: 2002-06-11 4:32pm Status: .Acknowledged notification on 2002-06-10 .Official statement forwarded by CERT: 2002-07-10 - SGI CORE notification: 2002-06-10 CERT notification: 2002-06-11 Status: .Acknowledged notification on 2002-06-18 - Xi Graphics (CDE for Linux) CERT notification: 2002-06-12 Status: .Confirmed vulnerable, fixes are available at the release date of this advisory .Patches available : 2002-06-20 - IBM CORE notification: 2002-06-10 CERT notification: 2002-06-11 4:32pm EST Status: .Confirmed vulnerable .Official statement forwarded by CERT: 2002-07-10 - Caldera (SCO) CERT notification: 2002-06-12 1:32pm Status: .Confirmed vulnerable .Official statement forwarded by CERT: 2002-07-10 - Cray Inc. CERT notification: 2002-06-12 1:19pm Status: .Acknoledged notification. Cray Inc. ships ToolTAlk wiht the CrayTools product but is not enabled by default or used by any Cray provided application - Data General CERT notification: 2002-06-12 1:19pm Status: N/A - Fujitsu CERT notification: 2002-06-12 1:19pm Status: .Acknowledged notification. Fujitsu's UXP/V is not vulnerable. Does not support any CDE functionalities - The Open Group CERT notification: 2002-06-12 1:31pm Status: N/A Release Mode: USER RELEASE *Vulnerability Description:* The ToolTalk service allows independently developed applications to communicate with each other by exchanging ToolTalk messages. Using ToolTalk, applications can create open protocols which allow different programs to be interchanged, and new programs to be plugged into the system with minimal reconfiguration. The ToolTalk database server (rpc.ttdbserverd) is an ONC RPC service which manages objects needed for the operation of the ToolTalk service. ToolTalk-enabled processes communicate with each other using RPC calls to this program, which runs on each ToolTalk-enabled host. This program is a standard component of the ToolTalk system, which ships as a standard component of many commercial Unix operating systems. The ToolTalk database server runs as root. Several security bugs were discovered in the rpc.ttdbserverd program that allow an attacker to: - Overwrite 4 bytes of memory the running process with a zero (0x0L) value - Remotely delete any file on the vulnerable host - Locally create or overwrite any file on the vulnerable host with arbitrary contents. - Remotely create arbitrary directory entries on the vulnerable host These vulnerabilities by themselves can lead to remote and local compromise of the privilege root account on the vulnerable system. Additionally these vulnerabilities may be used to build more reliable and effective exploit programs for previously published ToolTalk Database server vulnerabilities. Exploit modules for the vulnerabilities described in this advisory are available inmediately for CORE IMPACT customers through the product support channel or as part of CORE IMPACT v1.1 or the July 2002 module update pack. *Vulnerable Packages:* Solaris 2.5.1 2.6 7 8 9 HP-UX 10.10 10.20 11.00 11.11 Tru64 v4.0f, v4.0g, v5.0a, v5.1, v5.1a Xi Graphics deXtop CDE v2.1 IBM AIX 4.3.3 and 5.1.0 Caldera Open UNIX and Caldera UNIXware Not confirmed but suspected vulnerable - SGI IRIX 5.2-6.5.x Not vulnerable - Fujitsu UXP/V - Cray Inc, CrayTools - Caldera OpenLinux - SCO OpenServer *Solution/Vendor Information/Workaround* Caldera, Inc. Caldera Open UNIX and Caldera UnixWare provide the CDE ttdbserverd daemon, and are vulnerable to these issues. We have prepared fixes for those two operating systems, and will make them available as soon as these issues are made public. SCO OpenServer and
Re: Linux kernels DoSable by file-max limit
On Sun, Jul 07, 2002 at 10:54:44PM +0200, Paul Starzetz wrote:
Hi,
the recently mentioned problem in BSD kernels concerning the global
limit of open files seems to be present in the Linux-kernel too. However
as mentioned in the advisory about the BSD specific problem the Linux
kernel keeps some additional file slots reserved for the root user. This
code can be found in the fs/file_table.c source file (2.4.18):
struct file * get_empty_filp(void)
{
static int old_max = 0;
struct file * f;
file_list_lock();
if (files_stat.nr_free_files NR_RESERVED_FILES) {
used_one:
f = list_entry(free_list.next, struct file, f_list);
[...]
/*
* Use a reserved one if we're the superuser
*/
[*] if (files_stat.nr_free_files !current-euid)
goto used_one;
Greping the source code (2.4.18) reveals that the limit is pretty low:
./include/linux/fs.h:#define NR_RESERVED_FILES 10 /* reserved for root */
well, that's not really secure in the first place, I mean there's
nothing to exploit, it's more an hack to try to have more chances to
keep an usable machine as root after you hit the file-max, but it's not
guaranteed to work at all regardless of malicious or non malicious
workloads. Linux never enforce to keep the nr_free_files to a level =
NR_RESERVED_FILES, it just tries to do that lazily, but it's not
guaranteed you will have any nr_free_files when you happen to need them.
For example if you keep only opening files since boot and you never
execute a single close() or exit() syscall, you will never get any
nr_free_file available, so no matter who you are (root or not), you will
never pass this test if (files_stat.nr_free_files !current-euid)
because nr_free_files will be always zero.
Furthmore that part of the vfs file allocation management needs a
rewrite (hope it will happen in 2.5) and the file-max should go away
like the inode-max gone away too in 2.3. At the moment all released
files have no way to be releaed dynamically, and that's not good. There
should be a proper slab cache and the fput should kmem_cache_free,
instead of putting the file into the unshrinkable
file_table.c::free_list. But this is more a linux-kernel topic...
After we make possible to shrink the released files, the file-max limit
can go away (we need it now or we can pin all the ram into this not
shrinkable free_list). Then if you allocate all the ram into files you
will run the machine oom at some point. Which moves the DoS issues
elsewere: in the memory management area, which becomes a generic
problem, not specific to the file allocations anymore. After you hit the
oom point, even if you could allocate the file with a
root-file-reserved-pool, still you may not be able to allocate the
dentry and the inode then.
Anyways regardless of the memory management oom possible DoSes (when
running out of ram resources), removing the file-max is a goodness
because it makes the usability of linux much better, if you need lots of
files in a temporarly spike of load, then you won't be left with an huge
leak of files hanging around the the vm will shrink them as you need
more ram later. And if you hit oom, it's very likely (though not
guaranteed, also considering the different algorithms to handle oom
conditions, some deadlock prone, some not deadlock prone) that the
offending task will be killed too rendering any malicious attack much
less reproducible than now.
[..]
Exploitability to get uid=0 has not been confirmed yet but seems possible.
If that's the case it's an userspace bug in the suid apps that you're
executing, certainly it's not a kernel issue.
Andrea
