Re: [Full-disclosure] [WEB SECURITY] Universal XSS with PDF files: highly dangerous
On 1/3/07, Jim Manico [EMAIL PROTECTED] wrote: I'm most worried about the CSRF vector. how come? this is client-side stuff. -- Marcio Barbado, Jr. == == ___ 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] Perforce client: security hole by design
Ben Bucksch wrote: Anders B Jansson wrote: I'd say that it's a design decition, not sure that it's a design flaw. It's all down to what you try to protect. ... connecting any device not 100% controlled by the company to a company network is strictly forbidden, doing so would be regarded as intended sabotage. OK, so this bug is not a problem in your company or some Perforce setups. That's fine. However, I hope it was clear from my description that it's *not* fine in other cases: I think it's a bad enough design flaw to call a bug, or at any rate a wide-open security hole. The client should not alter anything that is not *below* the current working directory where it's invoked from. This is exactly the same bug as path traversal on webservers or in (un)archiving programs, all of which have been fixed to prevent ../.. and absolute paths from being allowed; exactly the same reasoning applies to p4. I understand the reasoning of Perforce's design, and I understand that most companies think that their *own* servers are fine and never pose a problem to *anybody*, why *would* they, but that's just not a valid assumption for the rest of the world. This is always an *assumption*, and for that reason it's bad. Defense-in-depth says neither end should just trust the other. I don't use p4 myself, but wouldn't running the client in a chroot'd sandbox be the quickest way to use it safely in these circumstances? cheers, DaveK -- Can't think of a witty .sigline today ___ 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] code release: cryptographic attack tool
Slythers Bro [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] this is a mathematic tool where all bits of a double word have 3 states : one , zero and unknow i implemented the addition , multiplication (with an integer), a new concept fusion (equivalent to = ) , and all basic booleean functions (binary version of xor, or, no , and) there are some utilities like error detection, error depth etc ... What axioms did you define? There is more than one way of describing notions analagous to addition, multiplication etc. with three-valued logic. Does your system form a ring or group? i used this lib for coding fuckmd5.cpp You did? I can't see any sign of tri-state logic in the final source code. if you want to use multithreading the code need modification i think this tool is good for easy recomputation and error detection in the case of a cryptographic attack How? In what way? cheers, DaveK -- Can't think of a witty .sigline today ___ 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 1246-1] New OpenOffice.org packages fix arbitrary code execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 1246-1[EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze January 8th, 2007 http://www.debian.org/security/faq - -- Package: openoffice.org Vulnerability : buffer overflow Problem type : local (remote) Debian-specific: no CVE ID : CVE-2006-5870 Debian Bug : 405679 405986 John Heasman from Next Generation Security Software discovered a heap overflow in the handling of Windows Metafiles in OpenOffice.org, the free office suite, which could lead to a denial of service and potentially execution of arbitrary code. For the stable distribution (sarge) this problem has been fixed in version 1.1.3-9sarge4. For the unstable distribution (sid) this problem has been fixed in version 2.0.4-1. We recommend that you upgrade your openofffice.org package. 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 at the end of this advisory: 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.1 alias sarge - Source archives: http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org_1.1.3-9sarge4.dsc Size/MD5 checksum: 2878 3adfe8b09c20248767fe9d995b3f184c http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org_1.1.3-9sarge4.diff.gz Size/MD5 checksum: 4623655 108120f3b365317fa9c47b25a5445fce http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org_1.1.3.orig.tar.gz Size/MD5 checksum: 166568714 5250574bad9906b38ce032d04b765772 Architecture independent components: http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-af_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2647376 8704f95d7e844e302abcae4d403f7818 http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-ar_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2694806 89cc4671d9d38ff05e5a361a06e02098 http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-ca_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2690164 45db102838292106429d06f2c9d4a77f http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-cs_1.1.3-9sarge4_all.deb Size/MD5 checksum: 3586142 03e0e6ba4d7abc4954fb7ffe4e04ced6 http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-cy_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2662654 ff77cf34ec2cfc0d8deaa49edf5ed00f http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-da_1.1.3-9sarge4_all.deb Size/MD5 checksum: 3581922 7f69ac15b11613a649a2a08ff1501fd8 http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-de_1.1.3-9sarge4_all.deb Size/MD5 checksum: 3453208 fcd76abbb9df7cd707e36903e9db1f17 http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-el_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2741468 ab08c03a0f0d78c3db9c99bd80fe12f1 http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-en_1.1.3-9sarge4_all.deb Size/MD5 checksum: 3525792 12c71a26f9512295ab442fb63e8711a3 http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-es_1.1.3-9sarge4_all.deb Size/MD5 checksum: 3560792 9965231fb1b0c3956ddb09255b91c86b http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-et_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2645014 baa0a0c809a740273d8dfd87b946d81b http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-eu_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2667748 740c781dd55cad46fdc52c1926d5854e http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-fi_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2673164 f8b2c8d335490dcaaf3f1bcb63eb72ec http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-fr_1.1.3-9sarge4_all.deb Size/MD5 checksum: 3494058 674365c474453cf6590a82c2b2d3d631 http://security.debian.org/pool/updates/main/o/openoffice.org/openoffice.org-l10n-gl_1.1.3-9sarge4_all.deb Size/MD5 checksum: 2657584 7ce93bcb8f34a3f05f7560b5631a5ed8
Re: [Full-disclosure] Flog 1.1.2 Remote Admin Password Disclosure
On Sun, 07 Jan 2007 16:08:23 +0100, endrazine said: yes that's correct but don't forget that hashes can collide it could be the case that: can ? could ? might ? Do you have any mathematical prouve or are you just guessing ? It's a pretty easy proof actually. If your password input routine allows more different passwords than there are possible hashes, you *will* have collisions. For instance, if you use a 64-bit hash, and reasonable-length passwords, you can create more than 2**64 of them, and 2 *have* to collide. xhash($Up3$tr0n9 # [EMAIL PROTECTED]) == xhash(1234) and you don't even need the original strong one ;) what hashing algorithm is being use ? Is a collision realistic ? How much time would it take to actually break a given hash ? If you're using anything resembling a sane hash (such as MD5 or similar), what happens is that you basically ignore the hash collisions - because rather than 1234, your colliding password/phrase is probably a 32-byte or so string, which is likely not even enterable at the keyboard (it ends up being A # ctl-b 9 e alt-control-meta-$ etcetc - of the 32, likely only 10 or so of the characters are from the 96-char printable ASCII set, and there's a good chance that at least several of the bytes are ones you can't enter from the keyboard at all) pgpFFTCM60HKV.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] [SECURITY] [DSA 1247-1] New libapache-mod-auth-kerb packages fix remote denial of service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-1247-1[EMAIL PROTECTED] http://www.debian.org/security/ Noah Meyerhans January 08, 2007 - Package: libapache-mod-auth-kerb Vulnerability : heap overflow Problem type : remote Debian-specific: no CVE Id(s) : CVE-2006-5989 BugTraq ID : 21214 Debian Bug : 400589 An off-by-one error leading to a heap-based buffer overflow has been identified in libapache-mod-auth-kerb, an Apache module for Kerberos authentication. The error could allow an attacker to trigger an application crash or potentially execute arbitrary code by sending a specially crafted kerberos message. For the stable distribution (sarge), this problem has been fixed in version 4.996-5.0-rc6-1sarge1. For the unstable version (sid) and the forthcoming stable version (etch), this problem has been fixed in version 5.3-1. We recommend that you upgrade your libapache-mod-auth-kerb package. 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 3.1 (stable) - --- Stable updates are available for alpha, amd64, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390 and sparc. Source archives: http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6-1sarge1.dsc Size/MD5 checksum: 744 5e045be08755cab316754a7f214eeaae http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6-1sarge1.diff.gz Size/MD5 checksum:49849 3ebbb5101629ddd8917159c1cbdf20ab http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6.orig.tar.gz Size/MD5 checksum:68787 b6a6c80b25b362eb7394f69cdc91f76d amd64 architecture (AMD x86_64 (AMD64)) http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache2-mod-auth-kerb_4.996-5.0-rc6-1sarge1_amd64.deb Size/MD5 checksum:28574 65078aa7e78f2728499849047eaf2fbb http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6-1sarge1_amd64.deb Size/MD5 checksum:27148 60ce4d39ac022335bd98ea7ed412f24d arm architecture (ARM) http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6-1sarge1_arm.deb Size/MD5 checksum:24078 053e0b54c348251be97c7708d43b5542 http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache2-mod-auth-kerb_4.996-5.0-rc6-1sarge1_arm.deb Size/MD5 checksum:25498 e1882b8b0e408cb2339ef4d43c800bd7 hppa architecture (HP PA RISC) http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache2-mod-auth-kerb_4.996-5.0-rc6-1sarge1_hppa.deb Size/MD5 checksum:28796 e29c79c55af53fc66cc1ea9084c63403 http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6-1sarge1_hppa.deb Size/MD5 checksum:27246 4d2394e0fc2a429c03ad6063c9ea2cce i386 architecture (Intel ia32) http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6-1sarge1_i386.deb Size/MD5 checksum:25014 20666ea4edbce196ba0b4ea120425af5 http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache2-mod-auth-kerb_4.996-5.0-rc6-1sarge1_i386.deb Size/MD5 checksum:27176 6e7e40781f4beadec9226a918c8d4591 ia64 architecture (Intel ia64) http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6-1sarge1_ia64.deb Size/MD5 checksum:31886 8146de1df6e65b32e213bfdc9b1320d2 http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache2-mod-auth-kerb_4.996-5.0-rc6-1sarge1_ia64.deb Size/MD5 checksum:33946 a2f93809df0703311c64ab28bc71a435 m68k architecture (Motorola Mc680x0) http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache-mod-auth-kerb_4.996-5.0-rc6-1sarge1_m68k.deb Size/MD5 checksum:24592 111a715b11307ad90a8c3c72d144067d http://security.debian.org/pool/updates/main/liba/libapache-mod-auth-kerb/libapache2-mod-auth-kerb_4.996-5.0-rc6-1sarge1_m68k.deb Size/MD5 checksum:24904 058b9470f905b33b7db5c1b7c82b704c mips architecture (MIPS (Big Endian))
Re: [Full-disclosure] Flog 1.1.2 Remote Admin Password Disclosure
Hi Vladis, Hi dear list, [EMAIL PROTECTED] a écrit : It's a pretty easy proof actually. If your password input routine allows more different passwords than there are possible hashes, you *will* have collisions. For instance, if you use a 64-bit hash, and reasonable-length passwords, you can create more than 2**64 of them, and 2 *have* to collide. Agreed, good sense helps in some cases ;) If you're using anything resembling a sane hash (such as MD5 or similar), what happens is that you basically ignore the hash collisions - because rather than 1234, your colliding password/phrase is probably a 32-byte or so string, which is likely not even enterable at the keyboard (it ends up being A # ctl-b 9 e alt-control-meta-$ etcetc - of the 32, likely only 10 or so of the characters are from the 96-char printable ASCII set, and there's a good chance that at least several of the bytes are ones you can't enter from the keyboard at all) Here again, I agree. Now, if one needs to exhaustively try every possible 32b hashes with the largest possible charset (or even bigger hashes with a smaller - like those alphanumerical keys you just mentionned), to break a password hash, the it's not a *BIG* security issue like mentionned earlier imho. Cheers, endrazine- ___ 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] Flog 1.1.2 Remote Admin Password Disclosure
typos : endrazine a écrit : Here again, I agree. Now, if one needs to exhaustively try every possible 32b hashes with the largest possible charset (or even bigger hashes with a smaller - like those alphanumerical keys you just mentionned), to break a password hash, the it's not a *BIG* security issue like mentionned earlier imho. s/hashes/passwords/ indeed Cheers, endrazine- ___ 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] rPSA-2007-0001-1 openoffice.org
rPath Security Advisory: 2007-0001-1 Published: 2007-01-08 Products: rPath Linux 1 Rating: Major Exposure Level Classification: Indirect User Deterministic Unauthorized Access Updated Versions: openoffice.org=/[EMAIL PROTECTED]:devel//1/2.0.3-1.7-1 References: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5870 https://issues.rpath.com/browse/RPL-905 Description: Previous versions of the openoffice.org package are vulnerable to an arbitrary code execution attack. When OpenOffice.org opens an intentionally-malformed .wmf or .emf file, it executes arbitrary code provided by the attacker. ___ 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] Universal XSS with PDF files: highly dangerous
Anyone knows how this affects opensource PDF viewers like gpdf or evince? As I understand this vulnerability, it's only effective against embeded PDF readers, right? A. signature.asc Description: 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/
Re: [Full-disclosure] Universal XSS with PDF files: highly dangerous
The Anarcat wrote: Anyone knows how this affects opensource PDF viewers like gpdf or evince? As I understand this vulnerability, it's only effective against embeded PDF readers, right? I don't know what you mean embedded. It only affects Adobe Reader 7. Matthew Flaschen 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] Fwd: Flog 1.1.2 Remote Admin Password Disclosure
-- Forwarded message -- From: T Biehn [EMAIL PROTECTED] Date: Jan 8, 2007 3:06 PM Subject: Re: [Full-disclosure] Flog 1.1.2 Remote Admin Password Disclosure To: endrazine [EMAIL PROTECTED] How are you guys still arguing about this? It wasn't even a troll. It's called a one-way-hash for a reason. Oh and if someone comes out with quantum computers tomorrow we could factor RSA, so we better start putting out SSL advisories. Slippery slope indeed. On 1/8/07, endrazine [EMAIL PROTECTED] wrote: typos : endrazine a écrit : Here again, I agree. Now, if one needs to exhaustively try every possible 32b hashes with the largest possible charset (or even bigger hashes with a smaller - like those alphanumerical keys you just mentionned), to break a password hash, the it's not a *BIG* security issue like mentionned earlier imho. s/hashes/passwords/ indeed Cheers, endrazine- ___ 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] [ MDKSA-2007:003 ] - Updated avahi packages fix DoS vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2007:003 http://www.mandriva.com/security/ ___ Package : avahi Date: January 8, 2007 Affected: 2007.0 ___ Problem Description: The consume_labels function in avahi-core/dns.c in Avahi before 0.6.16 allows remote attackers to cause a denial of service (infinite loop) via a crafted compressed DNS response with a label that points to itself. Updated packages are patched to address this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6870 ___ Updated Packages: Mandriva Linux 2007.0: 3d85bef8519f2b3bc87fa4689c9f1c3c 2007.0/i586/avahi-0.6.13-4.2mdv2007.0.i586.rpm 4d3917128ec852b8f2bc87c5b5d8666a 2007.0/i586/avahi-dnsconfd-0.6.13-4.2mdv2007.0.i586.rpm 4edbbf9d64e96b142568b053f04c6616 2007.0/i586/avahi-python-0.6.13-4.2mdv2007.0.i586.rpm 4d712e30c2fbd4418f3fcf5b6d1b4c0c 2007.0/i586/avahi-sharp-0.6.13-4.2mdv2007.0.i586.rpm 880684acb045144595581fb339136930 2007.0/i586/avahi-x11-0.6.13-4.2mdv2007.0.i586.rpm 652be4f82f97c1524a6d0f2986b2cdeb 2007.0/i586/libavahi-client3-0.6.13-4.2mdv2007.0.i586.rpm 0cda97099767a99a24bfa7055ce2c841 2007.0/i586/libavahi-client3-devel-0.6.13-4.2mdv2007.0.i586.rpm aa8c01ebe391edb965ec3ef278601bb1 2007.0/i586/libavahi-common3-0.6.13-4.2mdv2007.0.i586.rpm 23fec0b43f0d2f287023cc8262034488 2007.0/i586/libavahi-common3-devel-0.6.13-4.2mdv2007.0.i586.rpm 0bf0ec7072425a530a426b117d625845 2007.0/i586/libavahi-compat-howl0-0.6.13-4.2mdv2007.0.i586.rpm 2d4aca55b435b5b586c8157bd00e298c 2007.0/i586/libavahi-compat-howl0-devel-0.6.13-4.2mdv2007.0.i586.rpm 491e90b47e58faa7f1136756c2eb56b1 2007.0/i586/libavahi-compat-libdns_sd1-0.6.13-4.2mdv2007.0.i586.rpm 821a9132a8b03b05a5efab32be3addd5 2007.0/i586/libavahi-compat-libdns_sd1-devel-0.6.13-4.2mdv2007.0.i586.rpm 7f602260a514a21a2211cabd22c1e6aa 2007.0/i586/libavahi-core4-0.6.13-4.2mdv2007.0.i586.rpm ffa377ad89f47e07112d94400698bbae 2007.0/i586/libavahi-core4-devel-0.6.13-4.2mdv2007.0.i586.rpm 01dc5e308f1e94f8fda051511ba470b1 2007.0/i586/libavahi-glib1-0.6.13-4.2mdv2007.0.i586.rpm 4a90fb91f7a5ff1ca36cbdb9375dd2b2 2007.0/i586/libavahi-glib1-devel-0.6.13-4.2mdv2007.0.i586.rpm 00e29620a63da300e1032c8f37c7837f 2007.0/i586/libavahi-qt3_1-0.6.13-4.2mdv2007.0.i586.rpm 01a5534cccae9a70a1ba915a38a82952 2007.0/i586/libavahi-qt3_1-devel-0.6.13-4.2mdv2007.0.i586.rpm acfec3f7a3d07f6dc07a449f4d1387a3 2007.0/i586/libavahi-qt4_1-0.6.13-4.2mdv2007.0.i586.rpm d1b583ff8eda500d3058da1138ab8407 2007.0/i586/libavahi-qt4_1-devel-0.6.13-4.2mdv2007.0.i586.rpm 40e5ad83bf3a3064c1bccf229a5c6bbf 2007.0/SRPMS/avahi-0.6.13-4.2mdv2007.0.src.rpm Mandriva Linux 2007.0/X86_64: 75a40fbced632bdc8babb3709f01f294 2007.0/x86_64/avahi-0.6.13-4.2mdv2007.0.x86_64.rpm e17b41b7649c696a747ec06b430e688a 2007.0/x86_64/avahi-dnsconfd-0.6.13-4.2mdv2007.0.x86_64.rpm 6186acf41ae8f0466158c9baeb46b688 2007.0/x86_64/avahi-python-0.6.13-4.2mdv2007.0.x86_64.rpm a810ca0d5eefc79882a2922c4d2b1819 2007.0/x86_64/avahi-sharp-0.6.13-4.2mdv2007.0.x86_64.rpm ad25b467a05edd773045c4710dfe3802 2007.0/x86_64/avahi-x11-0.6.13-4.2mdv2007.0.x86_64.rpm 8ca2ef2791379beec855af78a4c9ddc6 2007.0/x86_64/lib64avahi-client3-0.6.13-4.2mdv2007.0.x86_64.rpm 45217f18c88ce547cb1a7376e97e3567 2007.0/x86_64/lib64avahi-client3-devel-0.6.13-4.2mdv2007.0.x86_64.rpm 453dbcd08a1fe2413e32cac3b5cb2f11 2007.0/x86_64/lib64avahi-common3-0.6.13-4.2mdv2007.0.x86_64.rpm fadf1a660490adcf1c47f4ea3d42ba33 2007.0/x86_64/lib64avahi-common3-devel-0.6.13-4.2mdv2007.0.x86_64.rpm 4247e04c65d855d36e5273bed281b463 2007.0/x86_64/lib64avahi-compat-howl0-0.6.13-4.2mdv2007.0.x86_64.rpm f0cb08bf33d91165d5298223de11f026 2007.0/x86_64/lib64avahi-compat-howl0-devel-0.6.13-4.2mdv2007.0.x86_64.rpm 6652bacf267ea46b4d06a6bed7d504b8 2007.0/x86_64/lib64avahi-compat-libdns_sd1-0.6.13-4.2mdv2007.0.x86_64.rpm 69600fd816780de31621c4b5e86a4644 2007.0/x86_64/lib64avahi-compat-libdns_sd1-devel-0.6.13-4.2mdv2007.0.x86_64.rpm 587258202393cd826826a94af80cbe17 2007.0/x86_64/lib64avahi-core4-0.6.13-4.2mdv2007.0.x86_64.rpm 9b048c8a6dfbc0c42bc088fa6983fe7b 2007.0/x86_64/lib64avahi-core4-devel-0.6.13-4.2mdv2007.0.x86_64.rpm 332e5e3e44ac035cef0d03b26b5d1d6c 2007.0/x86_64/lib64avahi-glib1-0.6.13-4.2mdv2007.0.x86_64.rpm cfeda3f7394c4cd28074cc393cdb140d 2007.0/x86_64/lib64avahi-glib1-devel-0.6.13-4.2mdv2007.0.x86_64.rpm b95bec83a950e8ac19ab9d10b24052cd 2007.0/x86_64/lib64avahi-qt3_1-0.6.13-4.2mdv2007.0.x86_64.rpm be3469df6e708ee450de14911c60d617
Re: [Full-disclosure] 0trace - traceroute on established connections
Michal Zalewski wrote:
I'd like to announce the availability of a free security reconnaissance /
firewall bypassing tool called 0trace.
Good work. Are you going to put it under a free license?
Enough chatter - the tool is available here (Linux version):
http://lcamtuf.coredump.cx/soft/0trace.tgz
Note: this is a 30-minute hack that involves C code coupled with a cheesy
shellscript. It may not work on non-Linux systems, and may fail on some
Linuxes, too. It could be improved in a number of ways - so if you like
it, rewrite it.
I've been trying to get it to work on Ubuntu Edgy. That system doesn't
have usleep, so I made the following kludge:
-
if [[ ! -x /bin/usleep ! -x /bin/sleep ]]; then
echo [-] Neither /bin/sleep nor /bin/usleep are found on this system,
sorry. 12
exit 1
fi
usleep()
{
if [ -x /bin/usleep ]; then
/bin/usleep $1
elif [ -x /bin/sleep ]; then
/bin/sleep $(echo .01 * $1 | bc)
fi
}
-
However, that leaves me with other problems:
[+] Waiting for traffic from target on eth0...
[+] Traffic acquired, waiting for a gap...
./0trace.sh: line 85: printf: 0x: invalid number
./0trace.sh: line 86: printf: 0x: invalid number
[+] Target acquired: : - : (0/0).
[+] Setting up a sniffer...
[+] Sending probes...
Usage: ./sendprobe src_ip dst_ip sport dport seq ack
I'm using Kubuntu Edgy. The bash version is 3.1.17(1)-release
(i486-pc-linux-gnu). Anyone have tips?
Thanks,
Matthew Flaschen
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] [ MDKSA-2007:004 ] - Updated geoip packages fix geoipupdate vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2007:004 http://www.mandriva.com/security/ ___ Package : geoip Date: January 8, 2007 Affected: Corporate 4.0 ___ Problem Description: Dean Gaudet discovered the geoipupdate utility fails to do sanity checking on the filename returned by GET /app/update_getfilename?product_id=%s. Updated packages are patched to address this issue. ___ References: http://arctic.org/~dean/patches/GeoIP-1.4.0-update-vulnerability.patch ___ Updated Packages: Corporate 4.0: fa1f121647c2537c612bd06cb696bf45 corporate/4.0/i586/geoip-1.4.0-2.1.20060mlcs4.i586.rpm b7121479dd6061d651e1596d6d088742 corporate/4.0/i586/libgeoip1-1.4.0-2.1.20060mlcs4.i586.rpm 4672680cd19c237b0972c31428b5643d corporate/4.0/i586/libgeoip1-devel-1.4.0-2.1.20060mlcs4.i586.rpm e5df2bdfcdcf1da47ff30756fe6515cb corporate/4.0/i586/libgeoipupdate0-1.4.0-2.1.20060mlcs4.i586.rpm 2ebfd111dd8511dc3cec4ade7ce39f73 corporate/4.0/SRPMS/geoip-1.4.0-2.1.20060mlcs4.src.rpm Corporate 4.0/X86_64: fee7fd2c73be1c3a8b86c83e9b614192 corporate/4.0/x86_64/geoip-1.4.0-2.1.20060mlcs4.x86_64.rpm 0232c0ff1b9463ccddb155de4095fd47 corporate/4.0/x86_64/lib64geoip1-1.4.0-2.1.20060mlcs4.x86_64.rpm a29ebe06132643a78ae9948fff1eb0bd corporate/4.0/x86_64/lib64geoip1-devel-1.4.0-2.1.20060mlcs4.x86_64.rpm 97ef3b059e9771b7c0783c66f0106f29 corporate/4.0/x86_64/lib64geoipupdate0-1.4.0-2.1.20060mlcs4.x86_64.rpm 2ebfd111dd8511dc3cec4ade7ce39f73 corporate/4.0/SRPMS/geoip-1.4.0-2.1.20060mlcs4.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/security/advisories If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team security*mandriva.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFor7NmqjQ0CJFipgRApAZAKCLDkSuruaD63NgUa0pea3XDipthACgrAzC CXwcpZmSUfcLoJTYUBffvkA= =knVQ -END 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] VMware ESX server security updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - --- VMware Security Advisory Advisory ID: VMSA-2007-0001 Synopsis: VMware ESX server security updates Issue date:2007-01-08 Updated on:2007-01-08 CVE: CVE-2006-3589 CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 CVE-2006-4343 CVE-2006-4980 - --- 1. Summary: Updated ESX Patches address several security issues. 2. Relevant releases: VMware ESX 3.0.1 without patch ESX-9986131 VMware ESX 3.0.0 without patch ESX-3069097 VMware ESX 2.5.4 prior to upgrade patch 3 VMware ESX 2.5.3 prior to upgrade patch 6 VMware ESX 2.1.3 prior to upgrade patch 4 VMware ESX 2.0.2 prior to upgrade patch 4 3. Problem description: Problems addressed by these patches: a. Incorrect permissions on SSL key files generated by vmware-config (CVE-2006-3589): ESX 3.0.1: does not have this problem ESX 3.0.0: does not have this problem ESX 2.5.4: corrected by ESX 2.5.4 Upgrade Patch 3 (Build# 36502) ESX 2.5.3: corrected by ESX 2.5.3 Upgrade Patch 6 (Build# 35703) ESX 2.1.3: corrected by ESX 2.1.3 Upgrade Patch 4 (Build# 35803) ESX 2.0.2: corrected by ESX 2.0.2 Upgrade Patch 4 (Build# 35801) A possible security issue with the configuration program vmware-config which could set incorrect permissions on SSL key files. Local users may be able to obtain access to the SSL key files. The Common Vulnerabilities and Exposures project (cve.mitre.org) assigned the name CVE-2006-3589 to this issue. b. OpenSSL library vulnerabilities: ESX 3.0.1: corrected by ESX 3.0.1 Patch ESX-9986131 ESX 3.0.0: corrected by ESX 3.0.0 Patch ESX-3069097 ESX 2.5.4: corrected by ESX 2.5.4 Upgrade Patch 3 (Build# 36502) ESX 2.5.3: corrected by ESX 2.5.3 Upgrade Patch 6 (Build# 35703) ESX 2.1.3: corrected by ESX 2.1.3 Upgrade Patch 4 (Build# 35803) ESX 2.0.2: corrected by ESX 2.0.2 Upgrade Patch 4 (Build# 35801) (CVE-2006-2937) OpenSSL 0.9.7 before 0.9.7l and 0.9.8 before 0.9.8d allows remote attackers to cause a denial of service (infinite loop and memory consumption) via malformed ASN.1 structures that trigger an improperly handled error condition. (CVE-2006-2940) OpenSSL 0.9.7 before 0.9.7l, 0.9.8 before 0.9.8d, and earlier versions allows attackers to cause a denial of service (CPU consumption) via parasitic public keys with large (1) public exponent or (2) public modulus values in X.509 certificates that require extra time to process when using RSA signature verification. (CVE-2006-4339) OpenSSL before 0.9.7, 0.9.7 before 0.9.7k, and 0.9.8 before 0.9.8c, when using an RSA key with exponent 3, removes PKCS-1 padding before generating a hash, which allows remote attackers to forge a PKCS #1 v1.5 signature that is signed by that RSA key and prevents OpenSSL from correctly verifying X.509 and other certificates that use PKCS #1. (CVE-2006-4343) The get_server_hello function in the SSLv2 client code in OpenSSL 0.9.7 before 0.9.7l, 0.9.8 before 0.9.8d, and earlier versions allows remote servers to cause a denial of service (client crash) via unknown vectors that trigger a null pointer dereference. The Common Vulnerabilities and Exposures project (cve.mitre.org) assigned the names CVE-2006-2937, CVE-2006-2940, CVE-2006-3738, CVE-2006-4339, and CVE-2006-4343 to these issues. c. Updated OpenSSH package addresses the following possible security issues: ESX 3.0.1: corrected by Patch ESX-9986131 ESX 3.0.0: corrected by Patch ESX-3069097 ESX 2.5.4: does not have these problems ESX 2.5.3: does not have these problems ESX 2.1.3: does not have these problems ESX 2.0.2: does not have these problems (CVE-2004-2069) sshd.c in OpenSSH 3.6.1p2 and 3.7.1p2 and possibly other versions, when using privilege separation, does not properly signal the non-privileged process when a session has been terminated after exceeding the LoginGraceTime setting, which leaves the connection open and allows remote attackers to cause a denial of service (connection consumption). (CVE-2006-0225) scp in OpenSSH 4.2p1 allows attackers to execute arbitrary commands via filenames that contain shell metacharacters or spaces, which are expanded twice. (CVE-2003-0386) OpenSSH 3.6.1 and earlier, when restricting host access by numeric IP addresses and with VerifyReverseMapping disabled, allows remote attackers to bypass from= and [EMAIL PROTECTED] address restrictions by connecting to a host from a system whose reverse DNS hostname contains the numeric IP address. (CVE-2006-4924) sshd in OpenSSH before 4.4, when using the version 1 SSH protocol, allows remote attackers
Re: [Full-disclosure] 0trace - traceroute on established connections
A much easier way is to write your own usleep and drop it in /bin:
---usleep.c---
#include stdio.h
#include stdlib.h
#include unistd.h
int main (int argc, char **argv) {
usleep(atoi(argv[1]));
return 0;
}
---usleep.c---
[note: doesn't check error conditions]
0trace worked brilliantly on my debian system after putting this
usleep in place, so Kubuntu should be basically the same.
On 1/8/07, Matthew Flaschen [EMAIL PROTECTED] wrote:
Michal Zalewski wrote:
I'd like to announce the availability of a free security reconnaissance /
firewall bypassing tool called 0trace.
Good work. Are you going to put it under a free license?
Enough chatter - the tool is available here (Linux version):
http://lcamtuf.coredump.cx/soft/0trace.tgz
Note: this is a 30-minute hack that involves C code coupled with a cheesy
shellscript. It may not work on non-Linux systems, and may fail on some
Linuxes, too. It could be improved in a number of ways - so if you like
it, rewrite it.
I've been trying to get it to work on Ubuntu Edgy. That system doesn't
have usleep, so I made the following kludge:
-
if [[ ! -x /bin/usleep ! -x /bin/sleep ]]; then
echo [-] Neither /bin/sleep nor /bin/usleep are found on this system,
sorry. 12
exit 1
fi
usleep()
{
if [ -x /bin/usleep ]; then
/bin/usleep $1
elif [ -x /bin/sleep ]; then
/bin/sleep $(echo .01 * $1 | bc)
fi
}
-
However, that leaves me with other problems:
[+] Waiting for traffic from target on eth0...
[+] Traffic acquired, waiting for a gap...
./0trace.sh: line 85: printf: 0x: invalid number
./0trace.sh: line 86: printf: 0x: invalid number
[+] Target acquired: : - : (0/0).
[+] Setting up a sniffer...
[+] Sending probes...
Usage: ./sendprobe src_ip dst_ip sport dport seq ack
I'm using Kubuntu Edgy. The bash version is 3.1.17(1)-release
(i486-pc-linux-gnu). Anyone have tips?
Thanks,
Matthew Flaschen
___
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/
