ExoPHPdesk user profile XSS / profile SQL injection
ExoPHPdesk user profile XSS / profile SQL injection http://exoscripts.com/exohelpdesk You can inject script code into the website area where you create profile. Cookies are in place making an XSS more than possible. http://example.com/helpdesk/index.php?fn=profile&s=&user=admin' sql here SQL injection in the profile area is possible if you choose a bad input.
[USN-541-1] Emacs vulnerability
=== Ubuntu Security Notice USN-541-1 November 13, 2007 emacs22 vulnerability CVE-2007-5795 === A security issue affects the following Ubuntu releases: Ubuntu 7.10 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 7.10: emacs22 22.1-0ubuntu5.1 In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: Drake Wilson discovered that Emacs did not correctly handle the safe mode of "enable-local-variables". If a user were tricked into opening a specially crafted file while "enable-local-variables" was set to the non-default ":safe", a remote attacker could execute arbitrary commands with the user's privileges. Updated packages for Ubuntu 7.10: Source archives: http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs22_22.1-0ubuntu5.1.diff.gz Size/MD5:31839 daac7632708045145dff688900b7627e http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs22_22.1-0ubuntu5.1.dsc Size/MD5: 1094 9ee2aec99e8c5e084e8fba2830548e5a http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs22_22.1.orig.tar.gz Size/MD5: 38172226 6949df37caec2d7a2e0eee3f1b422726 Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs22-common_22.1-0ubuntu5.1_all.deb Size/MD5: 18577010 5e070efae1ad5f584b4c9c058b7f8d71 http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs22-el_22.1-0ubuntu5.1_all.deb Size/MD5: 11170894 9c2d1be2028e707396f51e1eec6ef5a6 http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs_22.1-0ubuntu5.1_all.deb Size/MD5: 4476 6bff7051ee8d52bb742fea7103f1c7d9 amd64 architecture (Athlon64, Opteron, EM64T Xeon): http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs22-bin-common_22.1-0ubuntu5.1_amd64.deb Size/MD5: 179578 ba931e56ad03653a16b4adc1438e16f1 http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs22-nox_22.1-0ubuntu5.1_amd64.deb Size/MD5: 1933100 bc50b9ed6bb4b8dcd3f9d40edb3b2eb8 http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs22_22.1-0ubuntu5.1_amd64.deb Size/MD5: 2215464 c2c7e4f3ed03834ed5ede1560bbc2049 http://security.ubuntu.com/ubuntu/pool/universe/e/emacs22/emacs22-gtk_22.1-0ubuntu5.1_amd64.deb Size/MD5: 2208806 20dc6aab6d12d9c28280855a558f8f19 i386 architecture (x86 compatible Intel/AMD): http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs22-bin-common_22.1-0ubuntu5.1_i386.deb Size/MD5: 160860 c5b3eb523d873c1a58c4ecb9ace72ce7 http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs22-nox_22.1-0ubuntu5.1_i386.deb Size/MD5: 1704948 ba3f0d7c81e80c47bd1c3bd2e823742a http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs22_22.1-0ubuntu5.1_i386.deb Size/MD5: 1953414 b00fe8d866f6c20f0b204dcbfd68ca4c http://security.ubuntu.com/ubuntu/pool/universe/e/emacs22/emacs22-gtk_22.1-0ubuntu5.1_i386.deb Size/MD5: 1946230 48b0afc1dadaa29637411c77939f40fc powerpc architecture (Apple Macintosh G3/G4/G5): http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs22-bin-common_22.1-0ubuntu5.1_powerpc.deb Size/MD5: 178814 81f619f2744e31d2ada82515284f4d03 http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs22-nox_22.1-0ubuntu5.1_powerpc.deb Size/MD5: 1844778 491dc3cba5b629a84bb91dc8e6c2352d http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs22_22.1-0ubuntu5.1_powerpc.deb Size/MD5: 2117490 9dd0eb9b7476ac3822b477982af4f1c0 http://security.ubuntu.com/ubuntu/pool/universe/e/emacs22/emacs22-gtk_22.1-0ubuntu5.1_powerpc.deb Size/MD5: 2108164 5e605eae9a9909e07f9129850e5fae99 sparc architecture (Sun SPARC/UltraSPARC): http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs22-bin-common_22.1-0ubuntu5.1_sparc.deb Size/MD5: 166048 6e9af301ebe03290c461ee1727038606 http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs22-nox_22.1-0ubuntu5.1_sparc.deb Size/MD5: 1803268 20d302817fe0176d00d809847ebfa5e0 http://security.ubuntu.com/ubuntu/pool/main/e/emacs22/emacs22_22.1-0ubuntu5.1_sparc.deb Size/MD5: 2053664 f36a010a7926f2f52539f70aed9002e7 http://security.ubuntu.com/ubuntu/pool/universe/e/emacs22/emacs22-gtk_22.1-0ubuntu5.1_sparc.deb Size/MD5: 2048642 123992bee7c6d627f1b556dc3d5668f5 signature.asc Description: Digital signature
Re: Standing Up Against German Laws - Project HayNeedle
Florian Echtler wrote: > As a native German speaker, allow me to clarify: with respect to IP > communication, the law mandates saving the following information for 6 > months: > > - which customer was assigned which IP for what timespan > - sender mail address, receiver mail address and sender IP for each mail > - in case of VOIP: caller and callee phone number and IP address This data was required in Italy as well, and indeed was the core of a EU-wide "data retention" spree. Stefano
Re: Standing Up Against German Laws - Project HayNeedle
On Tue, 13 Nov 2007 13:07:02 PST, johan beisser said: > Actually, that's not really part of the issue. The logs don't contain > context, just who/where/when. While encryption will prevent (one > hopes) the capability of recovering context, who you talked to is not > kept private or otherwise secret. It's probably a good idea to deploy encryption *now*, and use it for *everything*, and be ready for when (not if) they decide to be more draconian in their logging requirements. And yes, encrypt *everything* - that way you make it a lot harder to do traffic analysis. If only the "interesting" 10% is encrypted, they know which 10% are interesting connections, which may be as important as the actual content. pgpmjl5zB318D.pgp Description: PGP signature
Re: Standing Up Against German Laws - Project HayNeedle
On Nov 13, 2007, at 12:39 PM, Paul Wouters wrote: Instead of creating noise, one should fix the problem of sending out plaintext email, and encourage people to use email encryption such as Enigma for Thunderbird. Encrypt IM conversations with OTR, and via other ways pro-actively protect ones own privacy. That is a real structural solution. Don't blame others for not using an envelope around your own communication. Actually, that's not really part of the issue. The logs don't contain context, just who/where/when. While encryption will prevent (one hopes) the capability of recovering context, who you talked to is not kept private or otherwise secret.
Re: [Full-disclosure] Standing Up Against German Laws - Project HayNeedle
On Nov 11, 2007, at 1:26 PM, Duncan Simpson wrote: The signal-to-noise logic probably does work, but I am not sure the legal angle does. If you were *deliberately* ran the software that acidently downloaded that kiddie porn the suggested angle might not work. That's been an ongoing question for me with regards to things like TOR gateways. As has been recently posted on Risky Business[1] and The Age[2], TOR doesn't prevent sniffing of the traffic leaving its gateway. If a running gateway connects to a server with "information of interest" - child porn, bomb making information, a known criminal forum - that brings authorities investigating to your house, it isn't a very good way to cover ones own tracks with noise. On a similar note, randomly connecting and pushing network data may create noise that obscures important data, but it may be easily filtered out from the logs during analysis. A law requiring log data to be retained for 6 momths should be a major problem to enforce. Last time I think the UK mooted this it did not happen (disclaimer: this might have been a trial balloon designed to generate flak). My reaction at the ISP end was "OK, will you buy us the extra hardware required?" with the intention the answer would be "no" and the plan quietly killed. (Thinking that plain daft things will not be enacted is not always reliable, unfortunately). That's been my first question as well. Storage, at least for compliance purposes, has gotten cheaper. 6 months of log data for most ISPs will still be under the 500GB range of disk. The harder part of the stored logs is making it easily analyzed and relevant. There are, of course, several companies in the data retention compliance arena already, most have offerings for PCI, SOx and HIPAA. It's not a stretch to think there are smaller offerings to handle this German laws lighter retention requirement for logs. [1] http://www.itradio.com.au/security/?p=48 [2] http://www.theage.com.au/news/security/the-hack-of-the-year/ 2007/11/12/1194766589522.html
[ MDKSA-2007:217 ] - Updated libpng packages fix multiple vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2007:217 http://www.mandriva.com/security/ ___ Package : libpng Date: November 13, 2007 Affected: 2007.0, 2007.1, 2008.0, Corporate 3.0, Corporate 4.0, Multi Network Firewall 2.0 ___ Problem Description: Multiple vulnerabilities were discovered in libpng: An off-by-one error when handling ICC profile chunks in the png_set_iCCP() function (CVE-2007-5266; only affects Mandriva Linux 2008.0). George Cook and Jeff Phillips reported several errors in pngrtran.c, such as the use of logical instead of bitwise functions and incorrect comparisons (CVE-2007-5268; only affects Mandriva Linux 2008.0). Tavis Ormandy reported out-of-bounds read errors in several PNG chunk handling functions (CVE-2007-5269). Updated packages have been patched to correct these issues. For Mandriva Linux 2008.0, libpng 1.2.22 is being provided which corrects all three issues. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5266 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5268 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5269 ___ Updated Packages: Mandriva Linux 2007.0: 6e6a1a752c3323210b7873d9050cc2d1 2007.0/i586/libpng3-1.2.12-2.4mdv2007.0.i586.rpm 44c4d399df519a3774a470cf819fb396 2007.0/i586/libpng3-devel-1.2.12-2.4mdv2007.0.i586.rpm a1933a55e7ee2fc3a250c6c429dfce93 2007.0/i586/libpng3-static-devel-1.2.12-2.4mdv2007.0.i586.rpm 4a1f620d405d0bc92c24912f5d109726 2007.0/SRPMS/libpng-1.2.12-2.4mdv2007.0.src.rpm Mandriva Linux 2007.0/X86_64: d367cc02889fa90498a8d0daa03cb89b 2007.0/x86_64/lib64png3-1.2.12-2.4mdv2007.0.x86_64.rpm 17216e150ba6841c0f1101f2f254a26b 2007.0/x86_64/lib64png3-devel-1.2.12-2.4mdv2007.0.x86_64.rpm 890f7e25640ed0d140304bd84e05a8f4 2007.0/x86_64/lib64png3-static-devel-1.2.12-2.4mdv2007.0.x86_64.rpm 4a1f620d405d0bc92c24912f5d109726 2007.0/SRPMS/libpng-1.2.12-2.4mdv2007.0.src.rpm Mandriva Linux 2007.1: 6a9c7d8f81e83eb36247ff0490a6e282 2007.1/i586/libpng3-1.2.13-2.2mdv2007.1.i586.rpm 1f78dea1216514f421f406672ddbc27e 2007.1/i586/libpng3-devel-1.2.13-2.2mdv2007.1.i586.rpm 49d4946c5b4555a757472dc2267ab7ca 2007.1/i586/libpng3-static-devel-1.2.13-2.2mdv2007.1.i586.rpm bd23b5b93b5f4e196c098d451ba61740 2007.1/SRPMS/libpng-1.2.13-2.2mdv2007.1.src.rpm Mandriva Linux 2007.1/X86_64: eaa4631b4186ecfa64f7d5e5618e8ed6 2007.1/x86_64/lib64png3-1.2.13-2.2mdv2007.1.x86_64.rpm a7ea7e725848d8f9b2064b5c8f6af2a4 2007.1/x86_64/lib64png3-devel-1.2.13-2.2mdv2007.1.x86_64.rpm 0886fd8b11d64a9104b145bd6a80dabd 2007.1/x86_64/lib64png3-static-devel-1.2.13-2.2mdv2007.1.x86_64.rpm bd23b5b93b5f4e196c098d451ba61740 2007.1/SRPMS/libpng-1.2.13-2.2mdv2007.1.src.rpm Mandriva Linux 2008.0: 60aeee7c6232797cbb019b847354a1ee 2008.0/i586/libpng-devel-1.2.22-0.1mdv2008.0.i586.rpm 945c51dca471b3e85417fd98ee75d6a5 2008.0/i586/libpng-source-1.2.22-0.1mdv2008.0.i586.rpm d4a9f587e93f29844db3ffbb8e2ad5c8 2008.0/i586/libpng-static-devel-1.2.22-0.1mdv2008.0.i586.rpm 5971dd0615c2c41e1e8501e24b80fc35 2008.0/i586/libpng3-1.2.22-0.1mdv2008.0.i586.rpm 57077fbd7202ada302d435df35eb0b3f 2008.0/SRPMS/libpng-1.2.22-0.1mdv2008.0.src.rpm Mandriva Linux 2008.0/X86_64: 9ec7f1e81514c27a0c3e818157cb9ac9 2008.0/x86_64/lib64png-devel-1.2.22-0.1mdv2008.0.x86_64.rpm f5db16ab9f528476d1ce5835a5686af1 2008.0/x86_64/lib64png-static-devel-1.2.22-0.1mdv2008.0.x86_64.rpm 989081716cb746497bcde8b846c7cae7 2008.0/x86_64/lib64png3-1.2.22-0.1mdv2008.0.x86_64.rpm 31a6c01ff31fec291b6906852d0e8b29 2008.0/x86_64/libpng-source-1.2.22-0.1mdv2008.0.x86_64.rpm 57077fbd7202ada302d435df35eb0b3f 2008.0/SRPMS/libpng-1.2.22-0.1mdv2008.0.src.rpm Corporate 3.0: 0e5f7e4d91eb46712cdfaff8abf8bd9f corporate/3.0/i586/libpng3-1.2.5-10.9.C30mdk.i586.rpm 3a90decd4088b6a49691c147d65bb7b0 corporate/3.0/i586/libpng3-devel-1.2.5-10.9.C30mdk.i586.rpm bba0383eecdebceffbfbba57db77af78 corporate/3.0/i586/libpng3-static-devel-1.2.5-10.9.C30mdk.i586.rpm 3c2af2ec7c62f0cab6175036b96645de corporate/3.0/SRPMS/libpng-1.2.5-10.9.C30mdk.src.rpm Corporate 3.0/X86_64: 825654d8659640d47bd35f31ece3d34c corporate/3.0/x86_64/lib64png3-1.2.5-10.9.C30mdk.x86_64.rpm e016ff95747174902fc7008ea87daa6e corporate/3.0/x86_64/lib64png3-devel-1.2.5-10.9.C30mdk.x86_64.rpm eb52ed562b56248b3fc1c1b52f333d30 corporate/3.0/x86_64/lib64png3-static-devel-1.2.5-10.9.C30mdk.x86_64.rpm 0e5f7e4d91eb46712cdfaff8abf8bd9f corporate/3.0/x86_64/libpng3-1.2.5-10.9.C30mdk.i586.rpm 3c2af2ec7c62f0cab6175036
Re: Standing Up Against German Laws - Project HayNeedle
On Tue, 13 Nov 2007, Florian Echtler wrote: As a native German speaker, allow me to clarify: with respect to IP communication, the law mandates saving the following information for 6 months: - which customer was assigned which IP for what timespan - sender mail address, receiver mail address and sender IP for each mail - in case of VOIP: caller and callee phone number and IP address It's all in the ETSI version of the Transport of Intercepted IP Traffic (http://www.opentap.org/documents/TIIT-v1.0.0.pdf) and the "FuncSpec" document (http://www.opentap.org/documents/101WAI-GT-FuncspecV1.0.1.doc) They might have updated it by now. It used to treat email different from other traffic, but with IM now, I am sure that has changed. See http://www.opentap.org/documents/ for other documents So it wouldn't make much sense to create connection noise on a TCP or HTTP basis, as this stuff isn't logged. I think one should rather concentrate on generating email noise in this regard. Instead of creating noise, one should fix the problem of sending out plaintext email, and encourage people to use email encryption such as Enigma for Thunderbird. Encrypt IM conversations with OTR, and via other ways pro-actively protect ones own privacy. That is a real structural solution. Don't blame others for not using an envelope around your own communication. For pointers on how to obtain more privacy via userfriendly software, see: http://chameleon.spaink.net/PTT.pdf Paul
iDefense Security Advisory 11.12.07: Novell NetWare Client Local Privilege Escalation Vulnerability
iDefense Security Advisory 11.12.07 http://labs.idefense.com/intelligence/vulnerabilities/ Nov 12, 2007 I. BACKGROUND The Novell Client software provides a workstation with access to Novell NetWare networks as well as Novell Open Enterprise Server (OES) services. Novell Clients can access the full range of Novell services such as authentication via Novell eDirectory, network browsing and service resolution, and secure and reliable file system access. More information about the Novel Client can be found on the vendor's site at the following URL. http://www.novell.com/products/clients/ II. DESCRIPTION Local exploitation of an input validation error vulnerability within Novell NetWare Client could allow an unprivileged attacker to execute arbitrary code within the kernel. When the Novell NetWare Client is installed on a Windows based operating system, the driver nwfilter.sys will be loaded at system startup. This driver allows any user to open the device "\.\nwfilter" and issue IOCTLs with a buffering mode of METHOD_NEITHER. The problem specifically exists because the driver allows untrusted user mode code to pass kernel addresses as arguments to the driver. With specially constructed input, a malicious user can use functionality within the driver to patch kernel addresses and execute arbitrary code within kernel mode. III. ANALYSIS Exploitation of this vulnerability allows an unprivileged local user to patch and execute arbitrary code within the kernel. In order to exploit the vulnerability, an attacker needs to be able to log in to the target machine and execute a specially crafted executable. IV. DETECTION iDefense has confirmed the existence of this vulnerability in nwfilter.sys, file version 4.91.1.1, as included with Novell's NetWare Client 4.91 SP4. Other versions are suspected vulnerable as well. V. WORKAROUND iDefense is currently unaware of any workaround for this issue. VI. VENDOR RESPONSE Novell has addressed this vulnerability by releasing patches that remove the "nwfilter.sys" driver. For more information, consult Novell's advisory at the following URL. https://secure-support.novell.com/KanisaPlatform/Publishing/98/3260263_f.SAL_Public.html VII. CVE INFORMATION The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2007-5667 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org/), which standardizes names for security problems. VIII. DISCLOSURE TIMELINE 09/25/2007 Initial vendor notification 09/25/2007 Initial vendor response 11/12/2007 Coordinated public disclosure IX. CREDIT This vulnerability was reported to iDefense by Stephen Fewer of Harmony Security (www.harmonysecurity.com). Get paid for vulnerability research http://labs.idefense.com/methodology/vulnerability/vcp.php Free tools, research and upcoming events http://labs.idefense.com/ X. LEGAL NOTICES Copyright © 2007 iDefense, Inc. Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDefense. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please e-mail [EMAIL PROTECTED] for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.
[USN-540-1] flac vulnerability
=== Ubuntu Security Notice USN-540-1 November 13, 2007 flac vulnerability CVE-2007-4619 === A security issue affects the following Ubuntu releases: Ubuntu 6.06 LTS Ubuntu 6.10 Ubuntu 7.04 Ubuntu 7.10 This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu. The problem can be corrected by upgrading your system to the following package versions: Ubuntu 6.06 LTS: libflac71.1.2-3ubuntu1.1 Ubuntu 6.10: libflac71.1.2-5ubuntu1.1 Ubuntu 7.04: libflac71.1.2-5ubuntu2.1 Ubuntu 7.10: libflac81.1.4-3ubuntu1.1 In general, a standard system upgrade is sufficient to affect the necessary changes. Details follow: Sean de Regge discovered that flac did not properly perform bounds checking in many situations. An attacker could send a specially crafted FLAC audio file and execute arbitrary code as the user or cause a denial of service in flac or applications that link against flac. Updated packages for Ubuntu 6.06 LTS: Source archives: http://security.ubuntu.com/ubuntu/pool/main/f/flac/flac_1.1.2-3ubuntu1.1.diff.gz Size/MD5: 284604 feb27a6426a007bc2a0a78eeec6de3d0 http://security.ubuntu.com/ubuntu/pool/main/f/flac/flac_1.1.2-3ubuntu1.1.dsc Size/MD5: 824 be82d3e74ad75f0b2c4dbb9fad7f http://security.ubuntu.com/ubuntu/pool/main/f/flac/flac_1.1.2.orig.tar.gz Size/MD5: 1516235 2bfc127cdda02834d0491ab531a20960 Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/universe/f/flac/libflac-doc_1.1.2-3ubuntu1.1_all.deb Size/MD5: 447440 4df3d8f2205048b72f0d39a497877e27 amd64 architecture (Athlon64, Opteron, EM64T Xeon): http://security.ubuntu.com/ubuntu/pool/main/f/flac/flac_1.1.2-3ubuntu1.1_amd64.deb Size/MD5: 131746 ee4d910c7d5cea96a798e0d02aac5724 http://security.ubuntu.com/ubuntu/pool/main/f/flac/libflac++-dev_1.1.2-3ubuntu1.1_amd64.deb Size/MD5:49854 e258e0a74ba286ee63bc671060460435 http://security.ubuntu.com/ubuntu/pool/main/f/flac/libflac++5c2_1.1.2-3ubuntu1.1_amd64.deb Size/MD5:40408 575f2f769a13bcaf7a5dcb8d1276 http://security.ubuntu.com/ubuntu/pool/main/f/flac/libflac-dev_1.1.2-3ubuntu1.1_amd64.deb Size/MD5: 185820 393768563f38beaabd141d80d636b2eb http://security.ubuntu.com/ubuntu/pool/main/f/flac/libflac7_1.1.2-3ubuntu1.1_amd64.deb Size/MD5: 109282 6d80dec0f38582e76dd8b6f97381301e http://security.ubuntu.com/ubuntu/pool/main/f/flac/liboggflac++-dev_1.1.2-3ubuntu1.1_amd64.deb Size/MD5:25946 18aa0a2036736e38b3ff087e78e61634 http://security.ubuntu.com/ubuntu/pool/main/f/flac/liboggflac++2c2_1.1.2-3ubuntu1.1_amd64.deb Size/MD5:26048 d2d30fb06edfc4896952e6d5b56f816c http://security.ubuntu.com/ubuntu/pool/main/f/flac/liboggflac-dev_1.1.2-3ubuntu1.1_amd64.deb Size/MD5:59634 772e0c11b01ec18347b60cdc1f9b79a7 http://security.ubuntu.com/ubuntu/pool/main/f/flac/liboggflac3_1.1.2-3ubuntu1.1_amd64.deb Size/MD5:32890 925d6b56f26faea749e53eea3abcd69d http://security.ubuntu.com/ubuntu/pool/universe/f/flac/xmms-flac_1.1.2-3ubuntu1.1_amd64.deb Size/MD5:61752 f6bf71d6a117216999192fbb79d90e37 i386 architecture (x86 compatible Intel/AMD): http://security.ubuntu.com/ubuntu/pool/main/f/flac/flac_1.1.2-3ubuntu1.1_i386.deb Size/MD5: 126982 76d4a39d95baebdb6578613a63168c1a http://security.ubuntu.com/ubuntu/pool/main/f/flac/libflac++-dev_1.1.2-3ubuntu1.1_i386.deb Size/MD5:47036 b39a5d2f1f77a23786b3a1aca62046d8 http://security.ubuntu.com/ubuntu/pool/main/f/flac/libflac++5c2_1.1.2-3ubuntu1.1_i386.deb Size/MD5:41566 7085dd7d3b9123e9e213e8e111ccdc94 http://security.ubuntu.com/ubuntu/pool/main/f/flac/libflac-dev_1.1.2-3ubuntu1.1_i386.deb Size/MD5: 181756 4188bdddc96d69f9d21e626004a12086 http://security.ubuntu.com/ubuntu/pool/main/f/flac/libflac7_1.1.2-3ubuntu1.1_i386.deb Size/MD5: 109146 f12d216b63902992c081e9ab05f1a455 http://security.ubuntu.com/ubuntu/pool/main/f/flac/liboggflac++-dev_1.1.2-3ubuntu1.1_i386.deb Size/MD5:25328 db56e68ca44d17f83ee16ac472c322ea http://security.ubuntu.com/ubuntu/pool/main/f/flac/liboggflac++2c2_1.1.2-3ubuntu1.1_i386.deb Size/MD5:27500 6bb49b501639aa1d80a61c94936f151b http://security.ubuntu.com/ubuntu/pool/main/f/flac/liboggflac-dev_1.1.2-3ubuntu1.1_i386.deb Size/MD5:55842 0ea5ffbec66b2279f382d54b57bacda9 http://security.ubuntu.com/ubuntu/pool/main/f/flac/liboggflac3_1.1.2-3ubuntu1.1_i386.deb Size/MD5:31064 7e95e6171191d77c49dbbca70124bfb9 http://security.ubuntu.com/ubuntu/pool/universe/f/flac/xmms-flac_1.1.2-3ubuntu1.1_i386.deb Size/MD5:57524 65b57d4b9c02895de44e7bd7b4252383 powerp
Re: [Full-disclosure] Standing Up Against German Laws - Project HayNeedle
I know this is obvious to everyone on bugtraq, but nobody seems to that told P.S.Ziegler yet. (He might or might not be aware of these facts). If the report is right and logs recoriding you connecting and obtaining an IP address are a concern then you should be terrified already. I suspect that I could reconstruct much of what you did online given access to all the asssociated logs. Getting an IP address from a DHCP server and using almost any other service whatsoever usually generates at least an IP address and timestamp. Bind 9 has logs, and they are on by default, so big brother might be able to deduce a lot just using your ISP's DNS logs. When I say that I got this spam from IP address X at time Y, and give full headers to back this up, most ISPs work out who was responsible and nuke their account. I do not think the "a virus sent that spam not me" or "nobody told me not to send spam" line is very effective. If you allowed a virus to send spam then the internet does not need your box. Period. The signal-to-noise logic probably does work, but I am not sure the legal angle does. If you were *deliberately* ran the software that acidently downloaded that kiddie porn the suggested angle might not work. A law requiring log data to be retained for 6 momths should be a major problem to enforce. Last time I think the UK mooted this it did not happen (disclaimer: this might have been a trial balloon designed to generate flak). My reaction at the ISP end was "OK, will you buy us the extra hardware required?" with the intention the answer would be "no" and the plan quietly killed. (Thinking that plain daft things will not be enacted is not always reliable, unfortunately). Of course the "hand over your keys" law is a lot less effective tbat the government thinks. If an hour has passed they can have my host private key then I no longer have one of the keys required. -- Duncan (-: "software industry, the: unique industry where selling substandard goods is legal and you can charge extra for fixing the problems."
Re: Standing Up Against German Laws - Project HayNeedle
> If I read the law correctly, it requires retention of "what IP > connected to another IP" and "which phone number called where." It > doesn't bother retaining the URL called (my German is rusty, so I may > be a little off in my interpretation). Connecting to a random IP on a > random open port (80 and 443, for example) would be a good start to > accomplish the goal creating chatter. The issue is that the search > terms to find those ports could lead to connecting to a site that > increases your profile against general background chatter, even as it > is raised with random connection traffic. As a native German speaker, allow me to clarify: with respect to IP communication, the law mandates saving the following information for 6 months: - which customer was assigned which IP for what timespan - sender mail address, receiver mail address and sender IP for each mail - in case of VOIP: caller and callee phone number and IP address So it wouldn't make much sense to create connection noise on a TCP or HTTP basis, as this stuff isn't logged. I think one should rather concentrate on generating email noise in this regard. Yours, Florian signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Oracle 11g/10g Installation Vulnerability
Hey all, After investigating 11g the other day I came across an interesting issue. During the installation of Oracle 11g and 10g all accounts, including the SYS and SYSTEM accounts, have their default passwords and only at the end of the install are the passwords changed. This means that there is a window of opportunity for an attacker to log into the database server during the install process. Depending upon "which" install options you choose determines the size of the window. Full details for those that are interested can be found here: http://www.davidlitchfield.com/blog/archives/0030.htm - since I reported this to Oracle on the 3rd of November they've updated their security checklist document: http://www.oracle.com/technology/deploy/security/pdf/twp_security_checklist_ db_database_20071108.pdf Cheers, David Litchfield -- E-MAIL DISCLAIMER The information contained in this email and any subsequent correspondence is private, is solely for the intended recipient(s) and may contain confidential or privileged information. For those other than the intended recipient(s), any disclosure, copying, distribution, or any other action taken, or omitted to be taken, in reliance on such information is prohibited and may be unlawful. If you are not the intended recipient and have received this message in error, please inform the sender and delete this mail and any attachments. The views expressed in this email do not necessarily reflect NGS policy. NGS accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the NGS domain. NGS and NGSSoftware are trading names of Next Generation Security Software Ltd. Registered office address: 52 Throwley Way, Sutton, SM1 4BF with Company Number 04225835 and VAT Number 783096402
Re: [Full-disclosure] Standing Up Against German Laws - Project HayNeedle
Hi, Am Samstag, 10. November 2007 19:53 schrieb Jan Newger: > > NO! This is totally WRONG! The only thing which is logged, in the case > of internet connectivity, is your IP you got from the ISP. Not even > connections are logged! This is important to understand since many > people are misinformed this way. Read > http://www.vorratsdatenspeicherung.de/content/view/78/86/lang,de/#Umsetzung >_in_Deutschland 1. That document is not quite up-to-date. I don't think there were any improvements in the actually passed law, though. 2. The IP is not "the only thing which is logged". Besides telephone and SMS/MMS connections the following is logged: - for internet connections (i. e. dial-in or equivalent): - IP number - connecting user (i. e. the calling phone number, ppp userid or equivalent) - Timestamp - for email - sender and recipient address of every email (logged on sending as well as receiving servers) - IP address(es) accessing a mailbox - timestamps for both of the above - for anonymizing services (!): - original and anonymized identifiers (e. g. IP or email address) - timestamps So much for "Einigkeit und Recht und Freiheit". Bye, Peter -- Peter ConradTel: +49 6102 / 80 99 072 [ t]ivano Software GmbH Fax: +49 6102 / 80 99 071 Bahnhofstr. 18 http://www.tivano.de/ 63263 Neu-Isenburg Germany
PHP <= 5.2.5 Gettext Lib Multiple Denial of service
Application: PHP <= 5.2.5
Web Site: http://php.net
Platform: Unix
Bug: Multiple Denial of service
fonction: Gettext Lib multiple Denial of service
special condition: Default php-memory-limit
Tested on : Debian 4.0 , Ubuntu , Freebsd with Suhosin 0.9.6.2
---
1) Introduction
2) Bug
3) Proof of concept
4) Greets
5) Credits
===
1) Introduction
===
"PHP is a widely-used general-purpose scripting language that
is especially suited for Web development and can be embedded into HTML."
==
2) Bug
==
dgettext(),dcgettext(),dngettext(),gettext(),ngettext(),dcgettext() are
vulnerable to a Denial of service
=
3)Proof of concept
=
Proof of concept example :
[EMAIL PROTECTED]:/# uname -a
Linux unsafebox 2.6.20-16-generic #2 SMP Sun Sep 23 19:50:39 UTC 2007 i686
GNU/Linux
[EMAIL PROTECTED]:/# php -v
PHP 5.2.5 (cli) (built: Nov 11 2007 07:56:04)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
[EMAIL PROTECTED]:/# php -r 'dgettext(str_repeat("A",8476509),"hi");'
Erreur de segmentation (core dumped)
[EMAIL PROTECTED]:/# php -r 'dcgettext(LC_CTYPE,str_repeat("A",8476509),"hi");'
Erreur de segmentation (core dumped)
[EMAIL PROTECTED]:/# php -r 'dngettext("hi",str_repeat("A",8476509),"hi",-1);'
Erreur de segmentation (core dumped)
[EMAIL PROTECTED]:/# php -r 'gettext(str_repeat("A",8476509));'
Erreur de segmentation (core dumped)
[EMAIL PROTECTED]:/# php -r 'ngettext(str_repeat("A",8476509),"hi",-1);'
Erreur de segmentation (core dumped)
[EMAIL PROTECTED]:/# php -r 'dcgettext(LC_CTYPE,str_repeat("A",8476509),"hi");'
Erreur de segmentation (core dumped)
4)Greets
Benjilenoob,team soh, #futurezone, #soh
=
5)Credits
=
laurent gaffié
PHP <= 5.2.5 stream_wrapper_register() denial of service
Application: PHP <= 5.2.5 Web Site: http://php.net Platform: unix Bug: Denial of service fonction: stream_wrapper_register() special condition: default php-memory-limit --- 1) Introduction 2) Bug 3) Proof of concept 4) Greets 5) Credits === 1) Introduction === "PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML." == 2) Bug == stream_wrapper_register() is vulnerable to a denial of service = 3)Proof of concept = Proof of concept example : result: [EMAIL PROTECTED]:~/Desktop# php shot.php Erreur de segmentation (core dumped) [EMAIL PROTECTED]:~/Desktop# 4)Greets Benjilenoob, Ivanlef0u, la team soh, #futurezone, #soh = 5)Credits = laurent gaffié
After 6 months - fix available for Microsoft DNS cache poisoning attack
After 6 months - fix available for Microsoft DNS cache poisoning attack On April this year I discovered a new vulnerability that enables DNS cache poisoning attack against the Windows DNS server. Today (November 13th, 2007) - six and a half months after being informed - Microsoft released a fix for this vulnerability. As the fix is now publicly available, I can finally share my research finding with you. For those of you who read my research papers on BIND 8 and 9 (http://www.trusteer.com/docs/research.html) - it is the same type of attack but a different vulnerability and a different DNS server. It's interesting that both BIND and Microsoft had different, and at the same time fundamentally flawed implementations of DNS (with Microsoft's implementation being more easily predictable than those of BIND). Using this attack an attacker can remotely poison the cache of any Windows DNS server (when run in caching mode) and force users who use this DNS server to reach fraudulent websites each time they try to access real websites. Windows DNS Server (part of Windows 2003 Server and Windows 2000 Server) is a popular DNS server (especially in Microsoft-based sites). The concept of DNS cache poisoning was discussed many times before. However, this attack was considered impractical for the leading industrial DNS servers due to the transaction ID mechanism that DNS servers implement today. The transaction ID is supposed to be a secure, random number that the attacker must guess in order to poison the DNS cache. There are 65,536 possible transaction ID values which make enumeration impractical in the current network conditions. The weakness I found is in the transaction ID generation algorithm of Windows DNS Server. By observing a few consecutive transaction IDs from the same DNS server an attacker can predict its next value. This weakness can be turned into a mass attack in the following way: (1) the attacker lures a single user that uses the target DNS server to click on a link. No further action other than clicking the link is required; (2) by clicking the link the user starts a chain reaction that eventually poisons the DNS server's cache (subject to some standard conditions) and associates fraudulent IP addresses with real website domains; (3) All users that use this DNS server will now reach the fraudulent website each time they try to reach the real website. The algorithm for predicting the transaction ID is very simple. It was coded in Perl and was demonstrated to work well (and fast!). The algorithm, as well as the paper, are available on Trusteer's website: http://www.trusteer.com/docs/windowsdns.html Microsoft were informed on April 30th, and patched versions of Windows DNS Server are now available on their website (see Microsoft Security Bulletin MS07-062 and Microsoft Knowledge Base Article 941672). Thanks, Amit Klein CTO Trusteer PS - as a side note, this vulnerability was originally scheduled for the October patch Tuesday, but due to some implementation issues, it was postponed by one month.
[ MDKSA-2007:216 ] - Updated kernel packages fix multiple vulnerabilities and bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2007:216 http://www.mandriva.com/security/ ___ Package : kernel Date: November 13, 2007 Affected: Corporate 3.0, Multi Network Firewall 2.0 ___ Problem Description: Some vulnerabilities were discovered and corrected in the Linux 2.6 kernel: A typo in the Linux kernel caused RTA_MAX to be used as an array size instead of RTN_MAX, which lead to an out of bounds access by certain functions (CVE-2007-2172). The IPv6 protocol allowed remote attackers to cause a denial of service via crafted IPv6 type 0 route headers that create network amplification between two routers (CVE-2007-2242). The random number feature did not properly seed pools when there was no entropy, or used an incorrect cast when extracting entropy, which could cause the random number generator to provide the same values after reboots on systems without an entropy source (CVE-2007-2453). A memory leak in the PPPoE socket implementation allowed local users to cause a denial of service (memory consumption) by creating a socket using connect, and releasing it before the PPPIOCGCHAN ioctl is initialized (CVE-2007-2525). A stack-based buffer overflow in the random number generator could allow local root users to cause a denial of service or gain privileges by setting the default wakeup threshold to a value greater than the output pool size (CVE-2007-3105). The hugetlb_vmtruncate_list() and hugetlb_vmtruncate() functions in the Linux kernel perform certain pio_tree calculations using HPAGE_SIZE intead of PAGE_SIZE units, which may allow local users to cause a denial of service (panic) via unspecified vectors (CVE-2007-4133). To update your kernel, please follow the directions located at: http://www.mandriva.com/en/security/kernelupdate ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2172 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2242 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2453 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2525 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3105 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4133 ___ Updated Packages: Corporate 3.0: 951b74d57e994b4628145efacc37222c corporate/3.0/i586/kernel-2.6.3.37mdk-1-1mdk.i586.rpm 86de2411fb8c3d140849b8acdb2ddf6e corporate/3.0/i586/kernel-BOOT-2.6.3.37mdk-1-1mdk.i586.rpm cdf5a2817b915da2da45f9437ec8d38f corporate/3.0/i586/kernel-doc-2.6.3-37mdk.i586.rpm 59d21423ef81ff35dddad9001fda3642 corporate/3.0/i586/kernel-enterprise-2.6.3.37mdk-1-1mdk.i586.rpm 9d1434bd62398cf5dcaab7415f147277 corporate/3.0/i586/kernel-i686-up-4GB-2.6.3.37mdk-1-1mdk.i586.rpm a529c6992a35891bc520d3ad890cbf12 corporate/3.0/i586/kernel-p3-smp-64GB-2.6.3.37mdk-1-1mdk.i586.rpm 3d2a8f68700537c645640f5306ca8960 corporate/3.0/i586/kernel-secure-2.6.3.37mdk-1-1mdk.i586.rpm be4214847382dc6f0d5643f22ddf8f39 corporate/3.0/i586/kernel-smp-2.6.3.37mdk-1-1mdk.i586.rpm e2689b9b306664d765d862c0daede5d5 corporate/3.0/i586/kernel-source-2.6.3-37mdk.i586.rpm 008504eda8fed1c67454cd60c027d028 corporate/3.0/i586/kernel-source-stripped-2.6.3-37mdk.i586.rpm b9d3ea705a1bef93599196cc49b82542 corporate/3.0/SRPMS/kernel-2.6.3.37mdk-1-1mdk.src.rpm Corporate 3.0/X86_64: 8169fd11e477ca0b8632c08a7117917e corporate/3.0/x86_64/kernel-2.6.3.37mdk-1-1mdk.x86_64.rpm cf8eb0161a4546fa607b0d929a1aa0f4 corporate/3.0/x86_64/kernel-BOOT-2.6.3.37mdk-1-1mdk.x86_64.rpm 872f9663d73566764008dd809eec01cf corporate/3.0/x86_64/kernel-doc-2.6.3-37mdk.x86_64.rpm 324a6126fae141784d37ee9d9225d89a corporate/3.0/x86_64/kernel-secure-2.6.3.37mdk-1-1mdk.x86_64.rpm c91f757553e380aafc8188e7639b6f55 corporate/3.0/x86_64/kernel-smp-2.6.3.37mdk-1-1mdk.x86_64.rpm 7b7ef3e6dcd36a7148f582c22c62640c corporate/3.0/x86_64/kernel-source-2.6.3-37mdk.x86_64.rpm ff5dbcddb882758fd0f6f74c90b9281a corporate/3.0/x86_64/kernel-source-stripped-2.6.3-37mdk.x86_64.rpm b9d3ea705a1bef93599196cc49b82542 corporate/3.0/SRPMS/kernel-2.6.3.37mdk-1-1mdk.src.rpm Multi Network Firewall 2.0: a5c867fd3c793d8322dc1b126316851f mnf/2.0/i586/kernel-2.6.3.37mdk-1-1mdk.i586.rpm 86082110e7d82931a415bfeae71a1d26 mnf/2.0/i586/kernel-i686-up-4GB-2.6.3.37mdk-1-1mdk.i586.rpm bb8cd008ed4dce886eef632c2e21fe87 mnf/2.0/i586/kernel-p3-smp-64GB-2.6.3.37mdk-1-1mdk.i586.rpm 998a08ace2f127df5421122ddb3fa66f mnf/2.0/i586/kernel-secure-2.6.3.37mdk-1-1mdk.i586.rpm 14607a9531ab4b2a39ea92290138f2a2 mnf/2.0/i586/kernel-smp-2.6.3.37mdk-1-1mdk.i586.rpm
Re: Bosdev Multiple vulnerabilities
Actually, you've never emailed us. HTML is stripped from posts, with the exception of admin allowed tags. The username XSS issue is already being dealt with in the 6.1 release. Install.php won't do anything, unless you know the username/password/db name for the system. Admins are told to remove the file specifically for the reason listed above. Next time you say you have emailed someone, you might actually try doing it.
ATC-08 Call for papers (repost)
ATC-08 Call For Papers The 5th International Conference on Autonomic and Trusted Computing, Oslo, Norway, June 23-25 2008 "Bring Safe, Self-x and Organic Computing Systems into Reality" Topics include but are not limited to the following: - Trust Models and Specifications Models and semantics of trust, distrust, mistrust, over-trust, cheat, risk, reputation, reliability, etc. - Trust-related Security and Privacy Trust-related secure architecture, framework, policy, intrusion detection/awareness, protocols, etc. - Trusted Reliable and Dependable Systems Fault-tolerant systems, hardware redundancy, robustness, survivable systems, failure recovery, etc. - Trustworthy Services and Applications Trustworthy Internet/web/grid/P2P e-services, secured mobile services, novel applications, etc. - Trust Standards and Non-Technical Issues Trust standards and issues related to personality, ethics, sociology, culture, psychology, economy, etc. See full call for papers at: http://www.ux.uis.no/atc08/
[ISecAuditors Security Advisories] VTLS.web.gateway cgi is vulnerable to XSS
= INTERNET SECURITY AUDITORS ALERT 2006-004 - Original release date: April 18, 2006 - Last revised: November 13, 2007 - Discovered by: Jesus Olmos Gonzalez - Severity: 1/5 = I. VULNERABILITY - VTLS.web.gateway cgi is vulnerable to XSS II. BACKGROUND - vtls.web.gateway cgi is a product from Visionary Technology in Library Solutions. VTLS Inc. is a leading global company that creates and provides visionary technology in library solutions. The company provide these solutions to a diverse customer base of more than 900 libraries in over 32 countries. III. DESCRIPTION - VTLS is vulnerable to a cross site scripting attack, it is possible to execue html and javascript code in the browser of who cliks in a malicious crafted link. Here is a simple proof of concept that change html page as example. An attacker could intercept the keyboard, or make CSRF to submit a form of other page. IV. PROOF OF CONCEPT - http://somevtlsweb.net/cgi-bin/vtls/vtls.web.gateway?authority=1&searchtype=subject%22%3E%3Ch1%3E%3Cmarquee%3EXSS%20bug%3C/marquee%3E%3C/h1%3E%3C!--&kind=ns&conf=080104+++ VI. SYSTEMS AFFECTED - All with this solution up to 48.1.0 VII. SOLUTION - Update to Version 48.1.1 VII. SOLUTION - Update to Version 48.1.1 VIII. REFERENCES - www.vtls.com IX. CREDITS - This vulnerability has been discovered and reported by Jesus Olmos Gonzalez (jolmos (at) isecauditors (dot) com). X. REVISION HISTORY - April 18, 2006: Initial release. November 13, 2007: Last revision. XI. DISCLOSURE TIMELINE - February 27, 2006: The vulnerability discovered by Internet Security Auditors. April 18, 2006: Initial vendor notification sent. No response April 26, 2006: Second vendor notification sent. Ping pong responses. September 14, 2006: Third vendor notification sent. No response. December 01, 2006: Fourth vendor notification sent. No response. December 04, 2006: New patch coming. No schedule. January 02, 2007: Fifth vendor contact to ask for planning. No response. January 22, 2007: Sixth vendor contact to ask for planning. Scheduled. March 23, 2007: Seventh vendor contact to ask for planning. Re-Scheduled. May 22, 2007: Eigth vendor contact to ask for planning. Re-Scheduled. October 01, 2007: Nineth vendor contact to ask for planning. Patch will be published in October. November 09, 2007: Tenth. Version 48.1.1 has been approved for general release and published. November 13, 2007: Advisory Published. XII. LEGAL NOTICES - The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors, S.L. accepts no responsibility for any damage caused by the use or misuse of this information.
