[Full-disclosure] Advisory 03/2006: KisMAC Cisco Vendor Tag Encapsulated SSID Overflow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Happy PPC Hacking Project
www.hardened-php.net
-= Security Advisory =-
Advisory: KisMAC Cisco Vendor Tag Encapsulated SSID Overflow
Release Date: 2006/03/23
Last Modified: 2006/03/23
Author: Stefan Esser [EMAIL PROTECTED]
Application: KisMAC dev version 113
KisMAC 73p
Severity: Special crafted 80211 management frames may cause
a stackoverflow that eventually leads to remote
code execution
Risk: Critical
Vendor Status: Vendor has a released an updated version
References: http://www.hardened-php.net/advisory_032006.115.html
Overview:
Quote from www.kismac.de:
KisMAC is a free stumbler application for MacOS X, that puts
your card into the monitor mode. Unlike most other applications
for OS X it has the ability to run completely invisible and
send no probe requests.
While playing around with wifi, raw packets, MacOS X, ppc and
KisMAC a quick audit revealed a remotely triggerable buffer
overflow in KisMAC's parser for tagged data in 80211 management
frames, that can lead to execution of arbitrary code.
To exploit this vulnerability an attacker must either trick the
victim in opening a pcap file containing the special crafted
management frames OR the attacker must send such raw frames
while the victim is performing a passive network scan.
Details:
When KisMAC receives a 80211 management frame (or finds one in
a imported pcap file) it parses the attached tagged data with
the function WavePacket:parseTaggedData. With the help of this
method the SSID, the channel and the rates get extracted from
the management packet.
The function in question also supports a special Cisco vendor tag,
which is scanned by KisMAC for additional SSIDs. Unfortunately it
then copies the SSIDs found into a 33 bytes big stackbuffer
without any kind of size check.
slen = (*(ssidl + 5)); // -- reading SSID length (UINT8)
ssidl += 6;
if ((len -= slen) 0) break;
@try {
memcpy(ssid, ssidl, slen); // -- copying without check into 33
// bytes big stackbuffer
ssid[slen]=0;
[_SSIDs addObject:[NSString stringWithUTF8String:ssid]];
}
@catch (NSException *exception) {
[_SSIDs addObject:[NSString stringWithCString:(char*)(ssidl)
length:slen]];
}
Due to the try/catch block around the memcpy() the stacklayout
allows to overwrite the jump_buf for setjmp/longjump which are
used for the exception handling. This actually means it is not
only possible to control the execution flow by manipulating the
program counter (pc) but also to have control over the content
of all registers once the execution flow has been manipulated.
It should be obvious that this eventually leads to the execution
of arbitrary code.
Proof of Concept:
The Happy PPC Hacking Project is not going to release exploits
for this vulnerability to the public.
Disclosure Timeline:
22. March 2006 - Contacted KisMAC developers by email
22. March 2006 - Vendor releases KisMAC update
23. March 2006 - Public Disclosure
Recommendation:
It is strongly recommended to upgrade to the newest version of
KisMAC which you can download at:
http://trac.kismac.de
GPG-Key:
http://www.hardened-php.net/hardened-php-signature-key.asc
pub 1024D/0A864AA1 2004-04-17 Hardened-PHP Signature Key
Key fingerprint = 066F A6D0 E57E 9936 9082 7E52 4439 14CC 0A86 4AA1
Copyright 2006 Stefan Esser. All rights reserved.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQFEIlt4RDkUzAqGSqERAk9kAJ96iwq93+EeDAMlk5JmRTUUxgkP1gCeKY1v
WZy/+ASNSsw9PqRGLFb1FZs=
=zmaa
-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] Secunia Research: Microsoft Internet Explorer createTextRange() Code Execution
== Secunia Research 23/03/2006 - Microsoft Internet Explorer createTextRange() Code Execution - == Table of Contents Affected Software1 Severity.2 Description of Vulnerability.3 Solution.4 Time Table...5 Credits..6 References...7 About Secunia8 Verification.9 == 1) Affected Software * Microsoft Internet Explorer 6 * Microsoft Internet Explorer 7 Beta 2 Preview (January edition) Other versions may also be affected. == 2) Severity Rating: Highly critical Impact: System access Where: Remote == 3) Description of Vulnerability Secunia Research has discovered a vulnerability in Microsoft Internet Explorer, which can be exploited by malicious people to compromise a user's system. The vulnerability is caused due to an error in the processing of the createTextRange() method call applied on a radio button control. This can be exploited by e.g. a malicious web site to corrupt memory in a way, which allows the program flow to be redirected to the heap. Successful exploitation allows execution of arbitrary code. == 4) Solution Disable Active Scripting support. NOTE: The vendor is currently working on a patch. == 5) Time Table 10/02/2006 - Vulnerability discovered. 13/02/2006 - Vendor notified. 21/02/2006 - Vendor confirms vulnerability. 22/03/2006 - Vulnerability reported to public mailing lists by third-party. 23/03/2006 - Public disclosure. == 6) Credits Discovered by Andreas Sandblad, Secunia Research. == 7) References US-CERT VU#876678: http://www.kb.cert.org/vuls/id/876678 == 8) About Secunia Secunia collects, validates, assesses, and writes advisories regarding all the latest software vulnerabilities disclosed to the public. These advisories are gathered in a publicly available database at the Secunia website: http://secunia.com/ Secunia offers services to our customers enabling them to receive all relevant vulnerability information to their specific system configuration. Secunia offers a FREE mailing list called Secunia Security Advisories: http://secunia.com/secunia_security_advisories/ == 9) Verification Please verify this advisory by visiting the Secunia website: http://secunia.com/secunia_research/2006-7/advisory/ Complete list of vulnerability reports published by Secunia Research: http://secunia.com/secunia_research/ == ___ 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] Secunia Research: Orion Application Server JSP Source Disclosure Vulnerability
== Secunia Research 23/03/2006 - Orion Application Server JSP Source Disclosure Vulnerability - == Table of Contents Affected Software1 Severity.2 Description of Vulnerability.3 Solution.4 Time Table...5 Credits..6 References...7 About Secunia8 Verification.9 == 1) Affected Software * Orion Application Server version 2.0.5 and 2.0.6. Prior versions may also be affected. == 2) Severity Rating: Moderately Critical Impact: Exposure of sensitive information Where: Remote == 3) Description of Vulnerability Secunia Research has discovered a vulnerability in Orion Application Server, which can be exploited by malicious people to disclose potentially sensitive information. The vulnerability is caused due to a validation error of the filename extension supplied by the user in the URL. This can be exploited to retrieve the source code of JSP files from the server via specially-crafted requests containing dot and space characters. The vulnerability affects only the Windows platform. == 4) Solution Update to version 2.0.7 or contact the vendor for a patch. == 5) Time Table 17/02/2006 - Initial vendor notification. 17/02/2006 - Initial vendor reply. 23/03/2006 - Public disclosure. == 6) Credits Discovered by Tan Chew Keong, Secunia Research. == 7) References The Common Vulnerabilities and Exposures (CVE) project has assigned CVE-2006-0816 for the vulnerability. == 8) About Secunia Secunia collects, validates, assesses, and writes advisories regarding all the latest software vulnerabilities disclosed to the public. These advisories are gathered in a publicly available database at the Secunia website: http://secunia.com/ Secunia offers services to our customers enabling them to receive all relevant vulnerability information to their specific system configuration. Secunia offers a FREE mailing list called Secunia Security Advisories: http://secunia.com/secunia_security_advisories/ == 9) Verification Please verify this advisory by visiting the Secunia website: http://secunia.com/secunia_research/2006-11/advisory/ Complete list of vulnerability reports published by Secunia Research: http://secunia.com/secunia_research/ == ___ 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 1015-1] New sendmail packages fix arbitrary code execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 1015-1[EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze March 23rd, 2006http://www.debian.org/security/faq - -- Package: sendmail Vulnerability : programming error Problem type : remote Debian-specific: no CVE ID : CVE-2006-0058 CERT advisory : VU#834865 Mark Dowd discovered a flaw in the handling of asynchronous signals in sendmail, a powerful, efficient, and scalable mail transport agent. This allows a remote attacker may to exploit a race condition to execute arbitrary code as root. For the old stable distribution (woody) this problem has been fixed in version 8.12.3-7.2. For the stable distribution (sarge) this problem has been fixed in version 8.13.4-3sarge1. For the unstable distribution (sid) this problem has been fixed in version 8.13.6-1. We recommend that you upgrade your sendmail package immediately. 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/s/sendmail/sendmail_8.12.3-7.2.dsc Size/MD5 checksum: 753 e88f300c970924d33b8ba8ea2b3eae6b http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-7.2.diff.gz Size/MD5 checksum: 277212 96008f9276955cd69add11424604e8e4 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3.orig.tar.gz Size/MD5 checksum: 1840401 b198b346b10b3b5afc8cb4e12c07ff4d Architecture independent components: http://security.debian.org/pool/updates/main/s/sendmail/sendmail-doc_8.12.3-7.2_all.deb Size/MD5 checksum: 747982 c253bf2db4f202a880396249318df054 Alpha architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-7.2_alpha.deb Size/MD5 checksum: 267946 5cc2f292308e753286150b9f5f0dc598 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-7.2_alpha.deb Size/MD5 checksum: 1107346 cee76bc87880b6d986337cb758bdd9e6 ARM architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-7.2_arm.deb Size/MD5 checksum: 247798 b47e73e4eb91410308ff3d7772986c9b http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-7.2_arm.deb Size/MD5 checksum: 979674 d03f90f8d57fa4bbe2f90776a487680e Intel IA-32 architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-7.2_i386.deb Size/MD5 checksum: 237492 75116396559388f01e199773e2dda2a3 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-7.2_i386.deb Size/MD5 checksum: 917446 0fd30312a872b9a3d1ba7c3e6c3d46b5 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-7.2_ia64.deb Size/MD5 checksum: 282384 4ce505c68a5434df2a6d196b87884e78 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-7.2_ia64.deb Size/MD5 checksum: 1332476 863dd30db60027d3efe5028c09b12805 HP Precision architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-7.2_hppa.deb Size/MD5 checksum: 261800 b7d14fc3ef6fc0b07068970659c4916a http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-7.2_hppa.deb Size/MD5 checksum: 1081594 8c154a46eb55b2c65399ced49674fcac Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-7.2_m68k.deb Size/MD5 checksum: 231320 e8bcfb54013b87753ddf6f146a38ed1d http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-7.2_m68k.deb Size/MD5 checksum: 865750 0d10292b121fcaee2ec8e7362528ac45 Big endian MIPS architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-7.2_mips.deb Size/MD5 checksum: 255544 f64577662a0d9385b2e451696f9d4d71 http://security.debian.org/pool/updates/main/s/sendmail/sendmail_8.12.3-7.2_mips.deb Size/MD5 checksum: 1024626 68dd1d411341a29cec916d081c78653f Little endian MIPS architecture: http://security.debian.org/pool/updates/main/s/sendmail/libmilter-dev_8.12.3-7.2_mipsel.deb Size/MD5 checksum: 255318
[Full-disclosure] SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
Tech details: Sendmail vulnerabilities were released yesterday. No real public announcements to speak of to the security community. SecuriTeam released some data: Improper timeout calculation, usage of memory jumps and integer overflows allow attackers to perfom a race condition DoS on sendmail, and may also execute arbitrary code. More here: http://www.securiteam.com/unixfocus/5RP0L0UI0S.html ISS only reported the Race Condition (DoS?). The Sendmail Advisory reported the Race Condition DoS, the Memory Jumps and a theoretical Integer Overflow. To begin with, anyone noticed the memory leak they (Sendmail) silently patched? I wonder how many other unreported silently-patched vulnerabilities are out there? Second, the Integer Overflow is practical, not theoretical. ISS reported the Race Condition last mounth. There is NO data available on when the other vulnerabilities were discovered. Any guesses? They also patched many non-security related bugs, added checks and more informative error messages, etc. Sendmail is, as we know, the most used daemon for SMTP in the world. This is an International Infrastructure vulnerability and should have been treated that way. It wasn't. It was handled not only poorly, but irresponsibly. Here's what ISS releasing the Race Condition vulnerability has to say: http://xforce.iss.net/xforce/alerts/id/216 They say it's a remote code execution. They say it's a race condition. No real data available to speak of. I can't see how it's remotely exploitable, but well, no details, remember? From what we can see it seems like a DoS. Bottom line --- What they did behind the smoke-screen is replace a lot of setjmp() and longjmp() functions (not very secure ones at that) with goto's (interesting choice). They changed the logic of the code, replaced everything that calculated timeout. Anything that calculated something and returned a value now returns a boolean result, when previously they just returned void. They used to look at the content rather than success. The int overflow is possibly exploitable, not very sure about the jumps. No idea why ISS says the Race Condition is, would love insight. Public announcement --- FreeBSD were the only ones who released a public announcement of a patch and emailed it to bugtraq so far. The patches --- The FreeBSD patch much like the sendmail.org patch is very long, complicated and obscure. The release was made along with a ton of other patches for FreeBSD. Go figure what's in there. Sendmail.com's patch is so big they may as well have re-released the whole program. There are also patches available for other *nix systems, no distributions released updates yet. Sendmail's announcement --- Obscure. Not worth any other comments other than the ones above. CVE information --- CVE-2006-0058 (reserved) Commentary -- One could say ISS and Sendmail did good, obscuring the information so that the vulnerability-to-exploit time will be longer. That proved wrong, useless and pointless. They failed. After looking at the available data for 30 minutes (more or less), we know exactly what the vulnerabilities are. Exploiting them may not be that trivial if indeed possible, but there are most likely already exploits out there if it is. When will the first public POC be released? Your guess is as good as mine. Not to mention the silently patched memory leak. SMTP and Sendmail by extension are critical for the Internet as an International Infrastructure. If this ends up being exploitable (no details, remember?) both ISS and Sendmail should look good and hard at the coming massive exploitation of Sendmail servers. With issues relating to the Internet Infrastructure I'd be willing to go even with the evil of non-disclosure, as long as something gets done and then reported publically when it finally scaled down in a roll-back after a couple of years. If not, and you are going to make it public, make the effort and fix it as soon as you can, and give information to help the process of healing. Don't do it a mounth late and obscure data. It took Sendmail a mounth to fix this. A mounth. A mounth! With such Vendor Responsibility, perhaps it is indeed a Good Thing to go Full Disclosure. It seems like history is repeating itself and Full Disclosure is once again not only a choice, but necessary to make vendors become responsible. I wish we could somehow avoid all the guys who will inevitably shout in the press end of the world. The Internet is, was and will stay havoc. There will be exploitation. Those who care about security will be patched, those that don't will hopefully finally learn a lesson. The Internet won't die because of this, although email may suffer ? but we are used to that by now, even when losing money. I am so very angry the details are obscure and hidden in the way they are, especially as that is useless in this case. Why did they do it, to claim they are ?responsible??
[Full-disclosure] trusting SMTP [was: SendGate: Sendmail Multiple Vulnerabilities]
Oh, sorry for not mentioning earlier - Operators that want to patch Sendmail, I'd suggest doing it soon. Now we not only do we face risk to our mail servers, but rather trusting other servers as well. This may sound as a joke as SMTP is a not trusted service with no trust in it, but servers that employ different trust models can potentially be compromised now. Gadi. On Thu, 23 Mar 2006, Gadi Evron wrote: Tech details: Sendmail vulnerabilities were released yesterday. No real public announcements to speak of to the security community. SecuriTeam released some data: Improper timeout calculation, usage of memory jumps and integer overflows allow attackers to perfom a race condition DoS on sendmail, and may also execute arbitrary code. More here: http://www.securiteam.com/unixfocus/5RP0L0UI0S.html ISS only reported the Race Condition (DoS?). The Sendmail Advisory reported the Race Condition DoS, the Memory Jumps and a theoretical Integer Overflow. To begin with, anyone noticed the memory leak they (Sendmail) silently patched? I wonder how many other unreported silently-patched vulnerabilities are out there? Second, the Integer Overflow is practical, not theoretical. ISS reported the Race Condition last mounth. There is NO data available on when the other vulnerabilities were discovered. Any guesses? They also patched many non-security related bugs, added checks and more informative error messages, etc. Sendmail is, as we know, the most used daemon for SMTP in the world. This is an International Infrastructure vulnerability and should have been treated that way. It wasn't. It was handled not only poorly, but irresponsibly. Here's what ISS releasing the Race Condition vulnerability has to say: http://xforce.iss.net/xforce/alerts/id/216 They say it's a remote code execution. They say it's a race condition. No real data available to speak of. I can't see how it's remotely exploitable, but well, no details, remember? From what we can see it seems like a DoS. Bottom line --- What they did behind the smoke-screen is replace a lot of setjmp() and longjmp() functions (not very secure ones at that) with goto's (interesting choice). They changed the logic of the code, replaced everything that calculated timeout. Anything that calculated something and returned a value now returns a boolean result, when previously they just returned void. They used to look at the content rather than success. The int overflow is possibly exploitable, not very sure about the jumps. No idea why ISS says the Race Condition is, would love insight. Public announcement --- FreeBSD were the only ones who released a public announcement of a patch and emailed it to bugtraq so far. The patches --- The FreeBSD patch much like the sendmail.org patch is very long, complicated and obscure. The release was made along with a ton of other patches for FreeBSD. Go figure what's in there. Sendmail.com's patch is so big they may as well have re-released the whole program. There are also patches available for other *nix systems, no distributions released updates yet. Sendmail's announcement --- Obscure. Not worth any other comments other than the ones above. CVE information --- CVE-2006-0058 (reserved) Commentary -- One could say ISS and Sendmail did good, obscuring the information so that the vulnerability-to-exploit time will be longer. That proved wrong, useless and pointless. They failed. After looking at the available data for 30 minutes (more or less), we know exactly what the vulnerabilities are. Exploiting them may not be that trivial if indeed possible, but there are most likely already exploits out there if it is. When will the first public POC be released? Your guess is as good as mine. Not to mention the silently patched memory leak. SMTP and Sendmail by extension are critical for the Internet as an International Infrastructure. If this ends up being exploitable (no details, remember?) both ISS and Sendmail should look good and hard at the coming massive exploitation of Sendmail servers. With issues relating to the Internet Infrastructure I'd be willing to go even with the evil of non-disclosure, as long as something gets done and then reported publically when it finally scaled down in a roll-back after a couple of years. If not, and you are going to make it public, make the effort and fix it as soon as you can, and give information to help the process of healing. Don't do it a mounth late and obscure data. It took Sendmail a mounth to fix this. A mounth. A mounth! With such Vendor Responsibility, perhaps it is indeed a Good Thing to go Full Disclosure. It seems like history is repeating itself and Full Disclosure is once again not only a choice, but necessary to make vendors become responsible. I wish we could somehow avoid all
[Full-disclosure] Interesting PDF about Skype
FYA: http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdf Thanks, Dan ___ 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] SUSE Security Announcement: RealPlayer security problems (SUSE-SA:2006:018)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 __ SUSE Security Announcement Package:RealPlayer Announcement ID:SUSE-SA:2006:018 Date: Thu, 23 Mar 2006 12:00:00 + Affected Products: Novell Linux Desktop 9 SUSE LINUX 10.0 SUSE LINUX 9.3 SUSE LINUX 9.2 Vulnerability Type: remote code execution Severity (1-10):8 SUSE Default Package: yes Cross-References: CVE-2005-2922, CVE-2006-0323 Content of This Advisory: 1) Security Vulnerability Resolved: realplayer security problems Problem Description 2) Solution or Work-Around 3) Special Instructions and Notes 4) Package Location and Checksums 5) Pending Vulnerabilities, Solutions, and Work-Arounds: See SUSE Security Summary Report. 6) Authenticity Verification and Additional Information __ 1) Problem Description and Brief Discussion This update fixes the following security problems in Realplayer: - Specially crafted SWF files could cause a buffer overflow and crash RealPlayer (CVE-2006-0323). - Specially crafted web sites could cause heap overflow and lead to executing arbitrary code (CVE-2005-2922). This was already fixed with the previously released 1.0.6 version, but not announced on request of Real. The advisory for these problems is on this page at Real: http://service.real.com/realplayer/security/03162006_player/en/ SUSE Linux 9.2 up to 10.0 and Novell Linux Desktop 9 are affected by this problem and receive fixed packages. If you are still using Realplayer on SUSE Linux 9.1 or SUSE Linux Desktop 1, we again wish to remind you that the Real player on these products cannot be updated and recommend to deinstall it. 2) Solution or Work-Around There is no known workaround, please install the update packages. 3) Special Instructions and Notes None. 4) Package Location and Checksums The preferred method for installing security updates is to use the YaST Online Update (YOU) tool. YOU detects which updates are required and automatically performs the necessary steps to verify and install them. Alternatively, download the update packages for your distribution manually and verify their integrity by the methods listed in Section 6 of this announcement. Then install the packages using the command rpm -Fhv file.rpm to apply the update, replacing file.rpm with the filename of the downloaded RPM package. x86 Platform: SUSE LINUX 10.0: ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/i586/RealPlayer-10.0.7-0.1.i586.rpm eaf09598db97183bdb25478dc5266edf SUSE LINUX 9.3: ftp://ftp.suse.com/pub/suse/i386/update/9.3/rpm/i586/RealPlayer-10.0.7-0.1.i586.rpm 427de6f3af871dca3d9c6c4f42d14793 SUSE LINUX 9.2: ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/RealPlayer-10.0.7-0.1.i586.rpm e84dd17634bcb046ade69fcdc8d67468 Sources: SUSE LINUX 10.0: ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/src/RealPlayer-10.0.7-0.1.nosrc.rpm d686f982312d06ff76ad786c29c94f5a SUSE LINUX 9.3: ftp://ftp.suse.com/pub/suse/i386/update/9.3/rpm/src/RealPlayer-10.0.7-0.1.src.rpm 5355bf3f17801d07f9a004711622dc8e SUSE LINUX 9.2: ftp://ftp.suse.com/pub/suse/i386/update/9.2/rpm/src/RealPlayer-10.0.7-0.1.src.rpm 0a7e783c563c24107b04b7f7f4e0b697 Our maintenance customers are notified individually. The packages are offered for installation from the maintenance web: http://support.novell.com/cgi-bin/search/searchtid.cgi?psdb/3ad7b20395a03f666b8f4ffe14e9276d.html __ 5) Pending Vulnerabilities, Solutions, and Work-Arounds: See SUSE Security Summary Report. __ 6) Authenticity Verification and Additional Information - Announcement authenticity verification: SUSE security announcements are published via mailing lists and on Web sites. The authenticity and integrity of a SUSE security announcement is guaranteed by a cryptographic signature in each announcement. All SUSE security announcements are published with a valid signature. To verify the signature of the announcement, save it as text into a file and run the command gpg --verify file replacing file with the name of the file where you saved the announcement. The output for a valid signature looks like: gpg: Signature made DATE using RSA key ID
[Full-disclosure] [USN-265-1] cairo/Evolution library vulnerability
=== Ubuntu Security Notice USN-265-1 March 23, 2006 libcairo vulnerability CVE-2006-0528 === A security issue affects the following Ubuntu releases: Ubuntu 5.10 (Breezy Badger) The following packages are affected: libcairo2 The problem can be corrected by upgrading the affected package to version 1.0.2-0ubuntu1.1. In general, a standard system upgrade is sufficient to effect the necessary changes. Details follow: When rendering glyphs, the cairo graphics rendering library did not check the maximum length of character strings. A request to display an excessively long string with cairo caused a program crash due to an X library error. Mike Davis discovered that this could be turned into a Denial of Service attack in Evolution. An email with an attachment with very long lines caused Evolution to crash repeatedly until that email was manually removed from the mail folder. This only affects Ubuntu 5.10. Previous Ubuntu releases did not use libcairo for text rendering. Source archives: http://security.ubuntu.com/ubuntu/pool/main/libc/libcairo/libcairo_1.0.2-0ubuntu1.1.diff.gz Size/MD5:14177 884cd3ad27785ac78aab5deb8cd31d9a http://security.ubuntu.com/ubuntu/pool/main/libc/libcairo/libcairo_1.0.2-0ubuntu1.1.dsc Size/MD5: 748 70fa6ff25b4fffe105a47a51cda5fc33 http://security.ubuntu.com/ubuntu/pool/main/libc/libcairo/libcairo_1.0.2.orig.tar.gz Size/MD5: 1458903 d0b7111a14f90ec3afa777ec40c44984 Architecture independent packages: http://security.ubuntu.com/ubuntu/pool/main/libc/libcairo/libcairo2-doc_1.0.2-0ubuntu1.1_all.deb Size/MD5: 212994 e7c990a09f1c808dfd748602c276145e amd64 architecture (Athlon64, Opteron, EM64T Xeon) http://security.ubuntu.com/ubuntu/pool/main/libc/libcairo/libcairo2-dev_1.0.2-0ubuntu1.1_amd64.deb Size/MD5: 339828 b973ef52a7cf03ccb9ce33b3a5f20ce6 http://security.ubuntu.com/ubuntu/pool/main/libc/libcairo/libcairo2_1.0.2-0ubuntu1.1_amd64.deb Size/MD5: 286302 faf2bb5520043b2e42f0fbd4aef74e83 i386 architecture (x86 compatible Intel/AMD) http://security.ubuntu.com/ubuntu/pool/main/libc/libcairo/libcairo2-dev_1.0.2-0ubuntu1.1_i386.deb Size/MD5: 312730 fd04bdd0a75954bd77da98d0c5e4a0b3 http://security.ubuntu.com/ubuntu/pool/main/libc/libcairo/libcairo2_1.0.2-0ubuntu1.1_i386.deb Size/MD5: 269248 efbcf5f0a02cc3a1fbd8d48fd3adeed9 powerpc architecture (Apple Macintosh G3/G4/G5) http://security.ubuntu.com/ubuntu/pool/main/libc/libcairo/libcairo2-dev_1.0.2-0ubuntu1.1_powerpc.deb Size/MD5: 321256 cbaabdb16a7e2ee6dfc099ef388dfd78 http://security.ubuntu.com/ubuntu/pool/main/libc/libcairo/libcairo2_1.0.2-0ubuntu1.1_powerpc.deb Size/MD5: 272914 6a67ee450397d760b607470d5d749bde 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/
[Full-disclosure] [SECURITY] [DSA 1016-1] New evolution packages fix arbitrary code execution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 1016-1[EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze March 23rd, 2006http://www.debian.org/security/faq - -- Package: evolution Vulnerability : format string vulnerabilities Problem type : remote Debian-specific: no CVE IDs: CVE-2005-2549 CVE-2005-2550 BugTraq ID : 14532 Debian Bug : 322535 Ulf Härnhammar discovered several format string vulnerabilities in Evolution, a free groupware suite, that could lead to crashes of the application or the execution of arbitrary code. For the old stable distribution (woody) these problems have been fixed in version 1.0.5-1woody3. For the stable distribution (sarge) these problems have been fixed in version 2.0.4-2sarge1. For the unstable distribution (sid) these problems have been fixed in version 2.2.3-3. We recommend that you upgrade your evolution 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 GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/e/evolution/evolution_1.0.5-1woody3.dsc Size/MD5 checksum: 992 4bafc18ff115d57baa3ecd24feaea244 http://security.debian.org/pool/updates/main/e/evolution/evolution_1.0.5-1woody3.diff.gz Size/MD5 checksum:16997 91088d27d6ae64632db5d8fd8eb38f68 http://security.debian.org/pool/updates/main/e/evolution/evolution_1.0.5.orig.tar.gz Size/MD5 checksum: 15010672 d2ffe374b453d28f5456db5af0a7983c Alpha architecture: http://security.debian.org/pool/updates/main/e/evolution/evolution_1.0.5-1woody3_alpha.deb Size/MD5 checksum: 10271404 abcc13e804daccea7e21031124bc60ce http://security.debian.org/pool/updates/main/e/evolution/libcamel-dev_1.0.5-1woody3_alpha.deb Size/MD5 checksum: 947970 1112c848840fe6148d8694510674c764 http://security.debian.org/pool/updates/main/e/evolution/libcamel0_1.0.5-1woody3_alpha.deb Size/MD5 checksum: 623132 42a240c46a0c166eb57040e01b403650 ARM architecture: http://security.debian.org/pool/updates/main/e/evolution/evolution_1.0.5-1woody3_arm.deb Size/MD5 checksum: 9282474 3d0f1299d60f5b54e278049870611a46 http://security.debian.org/pool/updates/main/e/evolution/libcamel-dev_1.0.5-1woody3_arm.deb Size/MD5 checksum: 663998 22ebfac4576408d91642d119b4220a4d http://security.debian.org/pool/updates/main/e/evolution/libcamel0_1.0.5-1woody3_arm.deb Size/MD5 checksum: 492764 2d41ff6e38e21dad80e5bc51b7e2fc86 Intel IA-32 architecture: http://security.debian.org/pool/updates/main/e/evolution/evolution_1.0.5-1woody3_i386.deb Size/MD5 checksum: 8905760 cbb89adf1743d7b74c25b90a872e5181 http://security.debian.org/pool/updates/main/e/evolution/libcamel-dev_1.0.5-1woody3_i386.deb Size/MD5 checksum: 586138 7311e70c22a6649808bea31000f1d7ff http://security.debian.org/pool/updates/main/e/evolution/libcamel0_1.0.5-1woody3_i386.deb Size/MD5 checksum: 470798 6b32f968b3d825d71b236801a16b0567 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/e/evolution/evolution_1.0.5-1woody3_ia64.deb Size/MD5 checksum: 11454846 2cb22139d0cac3722c34c48df0bf9af8 http://security.debian.org/pool/updates/main/e/evolution/libcamel-dev_1.0.5-1woody3_ia64.deb Size/MD5 checksum: 948336 7552edb843b53caf53d3224508a0189f http://security.debian.org/pool/updates/main/e/evolution/libcamel0_1.0.5-1woody3_ia64.deb Size/MD5 checksum: 771248 98ee08a95db9f16bef5eb7a8751859d1 Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/e/evolution/evolution_1.0.5-1woody3_m68k.deb Size/MD5 checksum: 8876524 30ac372fbf54049e1228ae4ca608c8b0 http://security.debian.org/pool/updates/main/e/evolution/libcamel-dev_1.0.5-1woody3_m68k.deb Size/MD5 checksum: 578502 bc44d6ff350f6af098c60ad997ad67f8 http://security.debian.org/pool/updates/main/e/evolution/libcamel0_1.0.5-1woody3_m68k.deb Size/MD5 checksum: 484064 34381b70ae3c9279c406b6f79030e79f PowerPC architecture: http://security.debian.org/pool/updates/main/e/evolution/evolution_1.0.5-1woody3_powerpc.deb Size/MD5 checksum: 9339960 1c1fa119eadff662c3073a6e1ee48913
[Full-disclosure] Secure HTTP
Hey, Are their any open source proxy/tunneling software that makes it possible to surf both HTTP/HTTPS over an SSL/HTTPS connection. In other words I want all my http traffic to be encrypted... Thx Q Beukes ___ 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] Secure HTTP
Le jeudi 23 mars 2006 à 15:55 +0200, Q Beukes a écrit : Are their any open source proxy/tunneling software that makes it possible to surf both HTTP/HTTPS over an SSL/HTTPS connection. Use PPP over stunnel, with a patch to support CONNECT method through proxies : http://www.stunnel.org/examples/pppvpn.html You can use OpenVPN as well, that supports both CONNECT and HTTP AUTH. Or you can use any HTTPS proxying service, such as anonymizer.com... -- http://sid.rstack.org/ PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE Hi! I'm your friendly neighbourhood signature virus. Copy me to your signature file and help me spread! ___ 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: Re: Re: Links to Google's cache of626FrSIRTexploits
nocfed wrote: Really, do you ``hackers'' really not know howto at least read the manpage for wget? There is no need for any script, only a few switches to wget. Hint: -e robots=off Wow! j00 R so 1337! Hint: -e clue=on Seriously, I truly phj33r your 4w3s0Me!!!one!1 man-page reading skills, but how could you imagine that switch could possibly make the slightest difference? robots.txt is enforced (or ignored) by the client. If a server returns a 403 or doesn't, depending on what UserAgent you specified, then how could making the client ignore robots.txt somehow magically make the server not return a 403 when you try to fetch a page? If you think that a switch that makes no difference to the data going over the wire could affect the response given to an otherwise identical protocol request sent back by the server, you must think they're using IP over ESP as a transport layer. Which rfc was that again? Or perhaps you just don't understand the first thing about the client-server model of system architecture. In which case you're in no position to go around calling other people hackers in sarcastic quote marks[*]. Anyway, this is a great illustration of the dangers of posting smartarse replies without actually having TRIED what you claim will work. Let me *prove* it: here's what happens if you try and wget the list of cached page, first with no switches, then with -e but no -U, then with -U but no -e. ---no options--- [EMAIL PROTECTED] /artimi/haxx0r/frsirt/test wget -i list.txt --14:53:56-- http://72.14.203.104/search?q=cache:HG1c4HzNGuYJ:www.frsirt.com/exploits/20050621.p33r-b33r.c.php+site:frsirt.com+p33rhl=enct=clnkcd=2 = [EMAIL PROTECTED]hl=enct=clnkcd=2' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:53:57 ERROR 403: Forbidden. --14:53:57-- http://72.14.203.104/search?q=cache:mI8fMz47MSQJ:www.frsirt.com/exploits/20060226.sco-root-exploit.c.php+site:frsirt.com+prdelkahl=enct=clnkcd=1 = [EMAIL PROTECTED]hl=enct=clnkcd=1' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:53:59 ERROR 403: Forbidden. --14:53:59-- http://72.14.203.104/search?q=cache:http://www.frsirt.com/exploits/20060307.revilloc.pl.php = [EMAIL PROTECTED]' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:54:00 ERROR 403: Forbidden. --14:54:00-- http://72.14.203.104/search?q=cache:http://www.frsirt.com/exploits/20060305.ms-visual-dbp.c.php = [EMAIL PROTECTED]' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:54:01 ERROR 403: Forbidden. ^C e--- [EMAIL PROTECTED] /artimi/haxx0r/frsirt/test wget -i list.txt -e robots=off --14:54:12-- http://72.14.203.104/search?q=cache:HG1c4HzNGuYJ:www.frsirt.com/exploits/20050621.p33r-b33r.c.php+site:frsirt.com+p33rhl=enct=clnkcd=2 = [EMAIL PROTECTED]hl=enct=clnkcd=2' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:54:13 ERROR 403: Forbidden. --14:54:13-- http://72.14.203.104/search?q=cache:mI8fMz47MSQJ:www.frsirt.com/exploits/20060226.sco-root-exploit.c.php+site:frsirt.com+prdelkahl=enct=clnkcd=1 = [EMAIL PROTECTED]hl=enct=clnkcd=1' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:54:15 ERROR 403: Forbidden. --14:54:15-- http://72.14.203.104/search?q=cache:http://www.frsirt.com/exploits/20060307.revilloc.pl.php = [EMAIL PROTECTED]' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:54:16 ERROR 403: Forbidden. --14:54:16-- http://72.14.203.104/search?q=cache:http://www.frsirt.com/exploits/20060305.ms-visual-dbp.c.php = [EMAIL PROTECTED]' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:54:17 ERROR 403: Forbidden. --14:54:17-- http://72.14.203.104/search?q=cache:http://www.frsirt.com/exploits/20060305.libtiff_exploit.c.php = [EMAIL PROTECTED]' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:54:18 ERROR 403: Forbidden. ^C U--- [EMAIL PROTECTED] /artimi/haxx0r/frsirt/test wget -i list.txt -U 'nocfed is talking a steaming great heap of n3td3v LOL LOL LOL' --15:04:32-- http://72.14.203.104/search?q=cache:HG1c4HzNGuYJ:www.frsirt.com/exploits/20050621.p33r-b33r.c.php+site:frsirt.com+p33rhl=enct=clnkcd=2 = [EMAIL PROTECTED]hl=enct=clnkcd=2' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 200 OK Length:
Re: [Full-disclosure] Re: Re: Re: Links to Google's cache of626FrSIRTexploits
Is it possible we can get this wget'ing artwork incorporated with the korn shell? /str0ke On 3/23/06, Dave Korn [EMAIL PROTECTED] wrote: nocfed wrote: Really, do you ``hackers'' really not know howto at least read the manpage for wget? There is no need for any script, only a few switches to wget. Hint: -e robots=off Wow! j00 R so 1337! Hint: -e clue=on Seriously, I truly phj33r your 4w3s0Me!!!one!1 man-page reading skills, but how could you imagine that switch could possibly make the slightest difference? robots.txt is enforced (or ignored) by the client. If a server returns a 403 or doesn't, depending on what UserAgent you specified, then how could making the client ignore robots.txt somehow magically make the server not return a 403 when you try to fetch a page? If you think that a switch that makes no difference to the data going over the wire could affect the response given to an otherwise identical protocol request sent back by the server, you must think they're using IP over ESP as a transport layer. Which rfc was that again? Or perhaps you just don't understand the first thing about the client-server model of system architecture. In which case you're in no position to go around calling other people hackers in sarcastic quote marks[*]. Anyway, this is a great illustration of the dangers of posting smartarse replies without actually having TRIED what you claim will work. Let me *prove* it: here's what happens if you try and wget the list of cached page, first with no switches, then with -e but no -U, then with -U but no -e. ---no options--- [EMAIL PROTECTED] /artimi/haxx0r/frsirt/test wget -i list.txt --14:53:56-- http://72.14.203.104/search?q=cache:HG1c4HzNGuYJ:www.frsirt.com/exploits/20050621.p33r-b33r.c.php+site:frsirt.com+p33rhl=enct=clnkcd=2 = [EMAIL PROTECTED]hl=enct=clnkcd=2' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:53:57 ERROR 403: Forbidden. --14:53:57-- http://72.14.203.104/search?q=cache:mI8fMz47MSQJ:www.frsirt.com/exploits/20060226.sco-root-exploit.c.php+site:frsirt.com+prdelkahl=enct=clnkcd=1 = [EMAIL PROTECTED]hl=enct=clnkcd=1' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:53:59 ERROR 403: Forbidden. --14:53:59-- http://72.14.203.104/search?q=cache:http://www.frsirt.com/exploits/20060307.revilloc.pl.php = [EMAIL PROTECTED]' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:54:00 ERROR 403: Forbidden. --14:54:00-- http://72.14.203.104/search?q=cache:http://www.frsirt.com/exploits/20060305.ms-visual-dbp.c.php = [EMAIL PROTECTED]' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:54:01 ERROR 403: Forbidden. ^C e--- [EMAIL PROTECTED] /artimi/haxx0r/frsirt/test wget -i list.txt -e robots=off --14:54:12-- http://72.14.203.104/search?q=cache:HG1c4HzNGuYJ:www.frsirt.com/exploits/20050621.p33r-b33r.c.php+site:frsirt.com+p33rhl=enct=clnkcd=2 = [EMAIL PROTECTED]hl=enct=clnkcd=2' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:54:13 ERROR 403: Forbidden. --14:54:13-- http://72.14.203.104/search?q=cache:mI8fMz47MSQJ:www.frsirt.com/exploits/20060226.sco-root-exploit.c.php+site:frsirt.com+prdelkahl=enct=clnkcd=1 = [EMAIL PROTECTED]hl=enct=clnkcd=1' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:54:15 ERROR 403: Forbidden. --14:54:15-- http://72.14.203.104/search?q=cache:http://www.frsirt.com/exploits/20060307.revilloc.pl.php = [EMAIL PROTECTED]' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:54:16 ERROR 403: Forbidden. --14:54:16-- http://72.14.203.104/search?q=cache:http://www.frsirt.com/exploits/20060305.ms-visual-dbp.c.php = [EMAIL PROTECTED]' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:54:17 ERROR 403: Forbidden. --14:54:17-- http://72.14.203.104/search?q=cache:http://www.frsirt.com/exploits/20060305.libtiff_exploit.c.php = [EMAIL PROTECTED]' Connecting to 72.14.203.104:80... connected. HTTP request sent, awaiting response... 403 Forbidden 14:54:18 ERROR 403: Forbidden. ^C U--- [EMAIL PROTECTED] /artimi/haxx0r/frsirt/test wget -i list.txt -U 'nocfed is talking a steaming great heap of n3td3v LOL LOL LOL' --15:04:32--
Re: [Full-disclosure] Secure HTTP
Ok, but all his traffic on his network will be encrypted... no ? If the sites you are visiting don't support encryption, you are still going to end up with data in clear-text on the wire. ___ 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: Re: Re: Re: Links to Google's cacheof626FrSIRTexploits
str0ke wrote: Is it possible we can get this wget'ing artwork incorporated with the korn shell? /str0ke You'll have to ask Dave Korn that question ;-P~~~ 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] VoIP Security whitepaper : a layered approach
Hi Fred, nice paper btw, what about H.323? Regards /JA https://www.securinfos.info - Original Message - From: Frederic Charpentier [EMAIL PROTECTED] Cc: full-disclosure@lists.grok.org.uk Sent: Thursday, March 23, 2006 3:43 PM Subject: [Full-disclosure] VoIP Security whitepaper : a layered approach Hi FD, Our team is pleased to release a whitepaper about VoIP. This whitepaper propose a security analysis of the Voice Over IP protocols with a layered approach. Link : http://www.xmcopartners.com/whitepapers/voip-security-layered-approach.pdf Chapters : 1 VOICE OVER IP SECURITY 1.1 A GENERAL OVERVIEW OF VOICE OVER IP 1.2 VOICE OVER IP PARTICULARITIES 1.3 VOICE OVER IP ARCHITECTURES 1.4 VOICE OVER IP THREATS 1.4.1 Signaling Protocols Layer 1.4.1.1SIP based Denials of Service 1.4.1.2SIP based Man in the Middle/Call Hijacking 1.4.1.3Possible solutions for SIP based attacks 1.4.2 Transport Protocols Layer 1.4.2.1Eavesdropping 1.4.2.2RTP Insertion attacks 1.4.2.3RTCP insertion attacks 1.4.2.4Possible solutions for RTP based attacks 1.4.3Application Layer 1.5 FUTURE THREATS TO VOICE OVER IP SECURITY 2 CONCLUSIONS -- Xmco Partners Security Consulting / Pentest web : http://www.xmcopartners.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 - 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] Secure HTTP
On 3/23/06, Julien GROSJEAN - Proxiad [EMAIL PROTECTED] wrote: Ok, but all his traffic on his network will be encrypted... no ? If the sites you are visiting don't support encryption, you are still going to end up with data in clear-text on the wire. Sure. It depends on who and what he is worried about. - Brian ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
FW: [Full-disclosure] Secure HTTP
I did a simelar thing and used it to get around my school's filtering system. I'd wager he's trying to do something like this ;) Unfortuatly, what Julian says is correct, you'll need to bounce the connection through another server with stunnel forwarding the (now encrypted) connections back to your gateway. Which isn't too bad, all you need a halfway decent shell account (or just get a damn server) that'll allow backgroup procs. Just my 2 pence. Ed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Eaton Sent: 23 March 2006 15:40 To: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Secure HTTP On 3/23/06, Julien GROSJEAN - Proxiad [EMAIL PROTECTED] wrote: Ok, but all his traffic on his network will be encrypted... no ? If the sites you are visiting don't support encryption, you are still going to end up with data in clear-text on the wire. Sure. It depends on who and what he is worried about. - Brian ___ 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] Microsoft MSN Hotmail : Cross-Site Scripting Vulnerability
Microsoft MSN Hotmail : Cross-Site Scripting Vulnerability //- Advisory Program : Microsoft MSN Hotmail Homepage : http://www.hotmail.com Discovery: 2006/01/28 Author Contacted : 2006/03/21 Found by : crashfr at sysdream dot com This Advisory: nono2357 at sysdream dot com //- Application description Hotmail is one of the most popular free webmail email services, which are accessible from anywhere on the planet via a standard web browser. Hotmail is developed by Microsoft. //- Description of vulnerability Hotmail's filtering engine insufficiently filters javascript scripts. It is possible to write javascript in the BGCOLOR attribute of the BODY tag, using CSS. This leads to execution when the email is viewed. Javascript must be unicode encoded in order to fool the filter. This encoding is recognized with IE = 6. //- Proof Of Concept When the user sends the following email : html body bgcolor=#CC; background-image: url\0028'\006a\0061\0076\0061\0073\0063\0072\0069\0070\0074\003a\0061\006c\0065\0072\0074\0028\0064\006f\0063\0075\006d\0065\006e\0074\002e\0063\006f\006f\006b\0069\0065\0029'\0029 pFound by http://www.sysdream.com !!!/p /body /html The victim receives the following email : div style=background-color:#CC;background-image:url\0028'\006a\0061\0076\0061\0073\0063\0072\0069\0070\0074\003a\0061\006c\0065\0072\0074\0028\0064\006f\0063\0075\006d\0065\006e\0074\002e\0063\006f\006f\006b\0069\0065\0029'\0029 pFound by http://www.sysdream.com !!!/p /div //- Impact This vulnerability can be used to modify the webmail display, to gather the victim's cookies, and to steal his session. One is able to download all the victim's emails and address book entries and to send emails from the stolen account. //- Solution Hotmail should filter javascript in CSS attributes. //- Credits http://www.sysdream.com http://www.nuitduhack.com/accueil_en-nuit-du-hack-2006.htm crashfr at sysdream dot com //- Greetings nono2357 ___ 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] Re: Noise on the list
funny example and i totally agree on this. if you subscribe to an unmoderated list you have to expect that you may have to config your mail filter if you want to get rid of certain crap. procmail is great for that. ___ 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] SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
On 3/23/06, Gadi Evron [EMAIL PROTECTED] wrote: Tech details: Sendmail vulnerabilities were released yesterday. No real public announcements to speak of to the security community. snip Public announcement --- FreeBSD were the only ones who released a public announcement of a patch and emailed it to bugtraq so far. snip Not sure what you mean by no advisories from the major distros. The CERT advisory went out at about 1700GMT. At the same time, RedHat sent out their notices, Mandrake, SUSE and Gentoo were within a few hours. Debian and Sun had updates within 24 hours. I'd say that covers the major players, and all of them were sent out by the time you sent your email. If you mean specifically Bugtraq (tm) postings, then you're right, they haven't been released by the moderators of that list yet. Bugtraq is what a moderated FD would look like, which is why it's not anywhere near as popular or useful as it was back in the Aleph1 netspace.org days. While I agree with you that this vulnerability should have more publicity then it does, I don't think everything is quite as gloomy as you're making it sound. Mike ___ 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] Re: Re: Re: Links to Google's cache of626FrSIRTexploits
On Thu, 23 Mar 2006 15:15:00 GMT, Dave Korn said: difference? robots.txt is enforced (or ignored) by the client. If a server returns a 403 or doesn't, depending on what UserAgent you specified, then how could making the client ignore robots.txt somehow magically make the server not return a 403 when you try to fetch a page? It *can*, however, make the client *issue* a request it would otherwise not have. If the client had snarfed a robots.txt, and it said don't snarf anything under /dontlook/here/, and a link pointed there. it wouldn't follow the link. If you tell it 'robots=off', then it *would* follow the link. Remember - robots.txt *isn't* for the pages that would 403. It's for the pages that *would* work, that you don't want automatically snarfed by things like wget and googlebots pgpszdCYLl3Ol.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] recommendations ??
Is anyone aware of a good open source proxy type launch box I wanted to force all my network admins(router jockeys) to connect to this box in order to connect to my infrastructure the box in turn must be capable of logging (tacacs type keystrokes), enforce access control etc . Something with the functionality of command broker from Nakina Systems Regards, Paul ___ 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] Fun with DHTML
On Wed, Mar 22, 2006 at 04:22:27PM -0600, H D Moore wrote: PS. If you find something easily exploitable, at least give the vendor a heads-up. Some of the new folks on the MS IE team are the same people who posted bugs to this list a couple years ago, so cut them some slack :-) a triple more reasons to send all of your 0days to m$: 1. only you can save mankind (they still need you, so it is not clear if several years old tru$tworthy computing can save mankind) 2. help bill get richer 3. help m$ security engineers get bigger bonus/salary for handling the incident properly -- where do you want bill gates to go today? EOM junk ___ 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] recommendations ??
On Thu, Mar 23, 2006 at 02:42:51PM -0500, Paul A Ryan wrote: Is anyone aware of a good open source proxy type launch box - I wanted to force all my network admins(router jockeys) to connect to this box in order to connect to my infrastructure - the box in turn must be capable of logging (tacacs type keystrokes), enforce access control etc .. Something with the functionality of command broker from Nakina Systems . Not open source(sorry) but I have to give props to OpsWare Network Automation System, which also does this, and very well...config diffs pop up in web pages side-by-side (new/old), along with who did what. John ___ 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: Re: Re: Re: Links to Google's cacheof626FrSIRTexploits
[EMAIL PROTECTED] wrote: On Thu, 23 Mar 2006 15:15:00 GMT, Dave Korn said: difference? robots.txt is enforced (or ignored) by the client. If a server returns a 403 or doesn't, depending on what UserAgent you specified, then how could making the client ignore robots.txt somehow magically make the server not return a 403 when you try to fetch a page? It *can*, however, make the client *issue* a request it would otherwise not have. If the client had snarfed a robots.txt, and it said don't snarf anything under /dontlook/here/, and a link pointed there. it wouldn't follow the link. If you tell it 'robots=off', then it *would* follow the link. Yes, these are all extremely obvious truisms, but I think now you need to go back and read the thread, because you haven't noticed that they're utterly irrelevant to the matter at hand. Remember - robots.txt *isn't* for the pages that would 403. See, thing is, pages that would 403 is /exactly/ what we were talking about. So saying switch off robots.txt is a completely irrelevant response. And the fact that doing so _would_ have /an/ effect in /other/ circumstances doesn't make it any less irrelevant, at least not according to any definition of the word relevant that I've ever seen! 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] Fun with DHTML
On Thursday 23 March 2006 13:44, Georgi Guninski wrote: a triple more reasons to send all of your 0days to m$: Can always count on you Georgi :-) 1. only you can save mankind (they still need you, so it is not clear if several years old tru$tworthy computing can save mankind) You are the ONE! 2. help bill get richer Hell yeah, can't let that IKEA guy take the title for richest man! 3. help m$ security engineers get bigger bonus/salary for handling the incident properly If that means they pay for drinks next time I am in Seattle, more power to them. Would you prefer that money to go to the security engineer or to the anti-ODF marketing campaign? The way I see it, the more cash Microsoft diverts into the security, the less they will be spending on efforts I disagree with :-) -HD ___ 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] SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
On March 23, 2006 01:41 am, Gadi Evron wrote: Here's what ISS releasing the Race Condition vulnerability has to say: http://xforce.iss.net/xforce/alerts/id/216 They say it's a remote code execution. They say it's a race condition. No real data available to speak of. I can't see how it's remotely exploitable, but well, no details, remember? From what we can see it seems like a DoS. ISS's Mark Dowd is very clever guy. And if duke says it's exploitable I would believe him :-). It's an interesting new vector anyway. But like all timing related attacks, the question is reliability. Though gossip has it, this one is repeatable with sub-100 attempts and you get infinite shots at it because even if the process does die it's a child of the parent listener. (So it is not really a DoS per se in any case.) Bottom line --- What they did behind the smoke-screen is replace a lot of setjmp() and longjmp() functions (not very secure ones at that) with goto's (interesting choice). Smoke screen seems like unfarily loaded terminology to use. OpenBSD fixed (removed) many setjmp/longjmp functions in their tree a long time ago as a class of bugs. (Though this sendmail exploitable collecttimeout() longjmp one is new and they patched it yesterday with everyone else, because as you noted, replacing it was kinda hairy...) I don't think its fair to bitch about people fixing bugs and then not having the time to send out advisories for every little tweak. The important thing is to fix the bug. And often times the developer won't understand the real impact of fixing a bug until someone clever like Mark comes up with some innovative way to exploit an unexploitable bug like this one. What will be interesting to see when the PoC exploits are finally released, is if any of the memory/stack protection schemes mitigate it. humor Besides, there is only one true mailer to mail them all, and its name is Postfix. /humor Now if we could only convince Mr. Venema to switch to a BSD license _everyone_ would switch to Postfix and everything would be much better. If it weren't for that poison pill clause in its license, I'm sure most OSes and commercial systems would have swapped out Sendmail for Postfix long ago. cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Vancouver, CanadaApril 3-7 2006 http://cansecwest.com pgpkey http://dragos.com/ kyxpgp ___ 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] Fun with DHTML
On Thu, Mar 23, 2006 at 02:03:33PM -0600, H D Moore wrote: 3. help m$ security engineers get bigger bonus/salary for handling the incident properly If that means they pay for drinks next time I am in Seattle, more power to them. Would you prefer that money to go to the security engineer or to 0days for drinks in Seattle - an irresistible offer how could you have paid your drinks so long if they are not on m$? -- where do you want bill gates to go today? EOM junk ___ 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] Secure HTTP
Brian Eaton wrote: On 3/23/06, Julien GROSJEAN - Proxiad [EMAIL PROTECTED] wrote: Ok, but all his traffic on his network will be encrypted... no ? If the sites you are visiting don't support encryption, you are still going to end up with data in clear-text on the wire. Sure. It depends on who and what he is worried about. - Brian Maybe a valid scenario might be surfing Pr0n from work? ___ 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: FW: [Full-disclosure] Secure HTTP
And to think you were the guy who started the 'noise on the list' thread. My mailing list filter has your spelling mistakes written all over it. You're the weakest link, good bye! On 3/23/06, Edward Pearson [EMAIL PROTECTED] wrote: I did a simelar thing and used it to get around my school's filteringsystem. I'd wager he's trying to do something like this ;) Unfortuatly, what Julian says is correct, you'll need to bounce theconnection through another server with stunnel forwarding the (nowencrypted) connections back to your gateway. Which isn't too bad, all you need a halfway decent shell account (or just get a damn server)that'll allow backgroup procs.Just my 2 pence.Ed ___ 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] Phun! Search
I have exploit code for this issue, which the list won't be getting hold of. The disclosure was to show that I can ask the slurp robot to cache an account on the public index, so I can retrieve account information. I ask the code to cache a copy of 'x user', when 'x' is at critical information page to obtain access to the yahoo users account. Of course with such a good 0-day, I use it seldom and only on specific targets like yahoo users with 'paid' services and or Yahoo employees. On 3/22/06, Stan Bubrouski [EMAIL PROTECTED] wrote:How old are you?Seriously.I don't know whether you realize just how completely stupid you come off as to even people new in thesecurity field.You are a joke.Quit filling this list with crap.BTW did you even check to see if you Yahoo! will let you view OTHERpeople's account stuff?Otherwise it seems pretty useless. -sb ___ 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] PasswordSafe 3.0 weak random number generator allows key recovery attack
I wonder why havent anyone posted this one here yet?!? Concidering the fact that Password Safe is used to create and store users secure passphrases in one database, the compromise of this database could be horrible...therefore I see this attack/bug also as horrible. http://www.securityfocus.com/archive/1/428552/30/0/threaded Title : PasswordSafe 3.0 weak random number generator allows key recovery attack Date : March 23, 2006 Product : PasswordSafe 3.0 Discovered by : ElcomSoft Co.Ltd. ... PasswordSafe 3.0 utilizes two different random number generator (RNG) functions: Win32 API RtlGenRandom() and standart Visual C++ rand(). RtlGenRandom() is not available on Windows prior to Windows XP (i.e. Windows 2000, Windows NT, Windows Me) so rand() is used instead. Specifically, rand() is used to generate 256-bit database encryption key. It is widely known that using rand() in cryptographic applications is not secure due to its predictbility and small internal state. ... It is possible to mount guaranteed decryption attack on PasswordSafe 3.0 databases created under OS prior to Windows XP. The attack is very simple: 1. Generate 256-bit key for every possible seed value 2. Decrypt first database record (the structure is documented, so we have known plaintext attack) 3) Check decrypted value against the known plaintext ... The total number of all possible seed values is limited by 2^32, so it is quite feasible. Our experiments show that the key can be recovered in less than 6 hours on the single PC (Pentium 4). Can anyone confirm 1) Is version 2.xx also vulnerable (either on XP or other OS)? 2) Password Safe has ability to create secure passphrases, are they too insecure because PRNG is insecure in PSv3? 3) Is there a fix available? 4) Is there a more secure password manager solution available? ;) -- My computer security privacy related homepage http://www.markusjansson.net Use HushTools or GnuPG/PGP to encrypt any email before sending it to me to protect our privacy. ___ 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: Vulnerability Alert Services - Independent List
To answer your question, My mailing list caches all the lists you've suggested below, and offers a great interface. If you're worried about spam, trolls or running out of disk space, the n3td3v public news group is for you! http://groups.google.com/group/n3td3v-- Forwarded message --From: Andy CuffDate: Thu, 23 Mar 2006 15:17:41 -Subject: Vulnerability Alert Services - Independent ListTo: [EMAIL PROTECTED]HelloLove them or loathe them, commercial vulnerability alert services whichreport salient detail from lists such as Bugtraq and Full Disclosurefulfila valuable security function to many organisations. We would like some help in updating the vendor agnostic view of allvulnerability alert services (good, bad ugly) athttp://www.securitywizardry.com/alert.htm as we are now looking for analertservice ourselves we need to update the page, if you know of any otherservices that we don't have (below) please contact us off list.One kind hearted supplier was providing us a free feed with which we verified the information on our vulnerability radarhttp://securitywizardry.com/radar.htm However, following the publicisedvisit to the NSA by President Bush http://www.securitywizardry.com/about.htmthe feed was withdrawn.Thus far we have details on:Symantec Deepsight Alert ServicesSecurityMobFrCIRT iAlert WebTraceAlertSecurityTrackerCybertrust Vulnerability/Threat ManagementVulnerability Tracking ServiceX-Force Threat Analysis Servicehttp://www.securitywizardry.com/alert.htm As mentioned please reply off list if you wish to add to the list ofproviders, if there is sufficient value in the changes I will post asummary, otherwise the page will remain availableRegards Andy CuffChief Technology OfficerComputer Network Defence Ltdhttp://www.securitywizardry.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] [ GLSA 200603-23 ] NetHack, Slash'EM, Falcon's Eye: Local privilege escalation
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory GLSA 200603-23 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Severity: Normal Title: NetHack, Slash'EM, Falcon's Eye: Local privilege escalation Date: March 23, 2006 Bugs: #125902, #122376, #127167, #127319 ID: 200603-23 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis NetHack, Slash'EM and Falcon's Eye are vulnerable to local privilege escalation vulnerabilities that could potentially allow the execution of arbitrary code as other users. Background == NetHack is the classic single player dungeon exploration game. Slash'EM and Falcon's Eye are NetHack variants. Affected packages = --- Package / Vulnerable / Unaffected --- 1 games-roguelike/nethack = 3.4.3-r1 Vulnerable! 2 games-roguelike/falconseye = 1.9.4aVulnerable! 3 games-roguelike/slashem = 0.0.760Vulnerable! --- NOTE: Certain packages are still vulnerable. Users should migrate to another package if one is available or wait for the existing packages to be marked stable by their architecture maintainers. --- 3 affected packages on all of their supported architectures. --- Description === NetHack, Slash'EM and Falcon's Eye have been found to be incompatible with the system used for managing games on Gentoo Linux. As a result, they cannot be played securely on systems with multiple users. Impact == A local user who is a member of group games may be able to modify the state data used by NetHack, Slash'EM or Falcon's Eye to trigger the execution of arbitrary code with the privileges of other players. Additionally, the games may create save game files in a manner not suitable for use on Gentoo Linux, potentially allowing a local user to create or overwrite files with the permissions of other players. Workaround == Do not add untrusted users to the games group. Resolution == NetHack has been masked in Portage pending the resolution of these issues. Vulnerable NetHack users are advised to uninstall the package until further notice. # emerge --ask --verbose --unmerge games-roguelike/nethack Slash'EM has been masked in Portage pending the resolution of these issues. Vulnerable Slash'EM users are advised to uninstall the package until further notice. # emerge --ask --verbose --unmerge games-roguelike/slashem Falcon's Eye has been masked in Portage pending the resolution of these issues. Vulnerable Falcon's Eye users are advised to uninstall the package until further notice. # emerge --ask --verbose --unmerge games-roguelike/falconseye Availability This GLSA and any updates to it are available for viewing at the Gentoo Security Website: http://security.gentoo.org/glsa/glsa-200603-23.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 pgpCVtIu7NKTz.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] iDefense Security Advisory 03.23.05: ISS Multiple Products Local Privilege Escalation Vulnerability
ISS Multiple Products Local Privilege Escalation Vulnerability iDefense Security Advisory 03.23.05 http://www.idefense.com/intelligence/vulnerabilities/display.php?id=403 March 23, 2006 I. BACKGROUND Internet Security Systems (ISS) has developed a suite of tools aimed at securing server and desktop systems. A flaw exists within a central module to these components that can allow unprivileged users to obtain complete control of the machine. http://www.iss.net/products_services/products.php II. DESCRIPTION Local exploitation of a design error in the multiple Internet Security Systems (ISS) products may allow a user to gain System level privileges. Exploitation of this issue is trival and can be done manually. This exploit has been confirmed in ISS BlackIce 3.6 product and is reportedly also found in the following products: - BlackICE PC Protection (Consumer) - BlackICE Server Protection (Consumer) - BlackICE Agent for Server (Corporate) - RealSecure Desktop 3.6 and 7.0 (Corporate) To exploit this condition you must first trigger an action that would initiate the Application Protection Module to display a warning. For the BlackIce product, this can be initiated by launching any executable moved or installed after the product itselft was first installed. From the Application Protection dialog press the More Info button with will bring up a secondary form. With this form active, pressing the F1 key will bring up the standard Windows Open File dialog prompting the user to manually locate the help file for the application. The problem arises when the BlackIce process fails to drop permissions before launching the help dialog. If a user resets the dialog file mask by entering *.exe [enter] they can then launch any executable on the system from the dialog by right clicking on it and choosing open. Applications run in this manner will be executed with System level rights. III. ANALYSIS Successful exploitation allows a local attacker to execute arbitrary commands as the System Administrator user. This allows complete system compromise including the installation and removal of applications, and ability to read and write any file on the system. IV. DETECTION iDefense has confirmed this vulnerability exists in version 3.6 of ISS BlackIce PC Desktop for Windows with all current updates applied. V. WORKAROUND There is currently no known work around for this issue. VI. VENDOR RESPONSE This issue does not affect Proventia Desktop, which is a replacement product for and a free upgrade from RealSecure Desktop 3.6 and 7.0. Nor does this issue affect Proventia Server, which is a replacement product for and a free upgrade from BlackICE Agent for Server. There are no other ISS products that use the components described. VII. CVE INFORMATION The Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-2005-2711 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 08/23/2005 Initial vendor notification 08/24/2005 Initial vendor response 03/23/2005 Public disclosure IX. CREDIT The discoverer of this vulnerability wishes to remain anonymous. Get paid for vulnerability research http://www.idefense.com/poi/teams/vcp.jsp Free tools, research and upcoming events http://labs.idefense.com X. LEGAL NOTICES Copyright © 2006 iDefense, Inc. Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDefense. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please email [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. ___ 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] iDefense Security Advisory 03.23.06: RealNetworks RealPlayer and Helix Player Invalid Chunk Size Heap Overflow Vulnerability
RealNetworks RealPlayer and Helix Player Invalid Chunk Size Heap Overflow Vulnerability iDefense Security Advisory 03.23.06 http://www.idefense.com/intelligence/vulnerabilities/display.php?id=404 March 23, 2006 I. BACKGROUND RealPlayer is an application for playing various media formats, developed by RealNetworks Inc. For more information, visit http://www.real.com/. II. DESCRIPTION Remote exploitation of a heap-based buffer overflow in RealNetwork Inc's RealPlayer could allow the execution of arbitrary code in the context of the currently logged in user. The vulnerability specifically exists in the handling of the 'chunked' Transfer-Encoding method. This method breaks the file the server is sending up into 'chunks'. For each chunk, the server first sends the length of the chunk in hexadecimal, followed by the chunk data. This is repeated until there are no more chunks. The server then sends a chunk length of 0 indicating the end of the transfer. There are multiple ways of triggering this vulnerability. * Sending a well-formed chunk header with a length of -1 () followed by malicious data. * Sending a well-formed chunk header with a length specified which is less than the amount of data that will be sent, followed by malicious data. * Not sending a chunk header before sending malicious data. Each of these cases result in a heap overflow. Depending on the versions used, certain of these cases will not cause exploitable issues. However, the last case appears to be reliable in triggering a crash. III. ANALYSIS Successful exploitation allows a remote attacker to execute arbitrary code with the privileges of the currently logged in user. In order to exploit this vulnerability, an attacker would need to entice a user to follow a link to a malicious server. Once the user visits a website under the control of an attacker, it is possible in a default install of RealPlayer to force a web-browser to use RealPlayer to connect to an arbitrary server, even when it is not the default application for handling those types, by the use of embedded object tags in a webpage. This may allow automated exploitation when the page is viewed. As the client sends its version information as part of the request, it would be possible for an attacker to create a malicious server which uses the appropriate offsets and shellcode for each version and platform of the client. IV. DETECTION iDefense has confirmed the existence of this vulnerability in RealPlayer Version 10.4 and 10.5 for Windows and Both RealPlayer 10.4 and Helix Player 1.4 for Linux. The vendor has stated that the following versions are vulnerable: * RealPlayer 10.5 (6.0.12.1040-1348) * RealPlayer 10 * RealOne Player v2 * RealOne Player v1 * RealPlayer 8 It is suspected that previous versions of RealPlayer and Helix Player are affected by this vulnerability. V. WORKAROUND Although there is no way to completely protect yourself from this vulnerability, aside from removing the RealPlayer software, the following actions may be taken to minimize the risk of automated exploitation. Disable ActiveX controls and plugins, if not necessary for daily operations, using the following steps: 1. In IE, click on Tools and select Internet Options from the drop-down menu. 2. Click the Security tab and the Custom Level button. 3. Under ActiveX Controls and Plugins, then Run Activex Controls and Plugins, click the Disable radio button. In general, exploitation requires that a targeted user be socially engineered into visiting a link to a server controlled by an attacker. As such, do not visit unknown/untrusted website and do not follow suspicious links. When possible, run client software, especially applications such as IM clients, web browsers and e-mail clients, from regular user accounts with limited access to system resources. This may limit the immediate consequences of client-side vulnerabilities such as this. VI. VENDOR RESPONSE Information from the vendor about this vulnerability is available at to following URL: http://service.real.com/realplayer/security/03162006_player/en/ VII. CVE INFORMATION The Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-2005-2922 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/08/2005 Initial vendor notification 09/09/2005 Initial vendor response 03/23/2006 Public disclosure IX. CREDIT This vulnerability was found internally by Greg MacManus of iDefense Labs. Get paid for vulnerability research http://www.idefense.com/poi/teams/vcp.jsp Free tools, research and upcoming events http://labs.idefense.com X. LEGAL NOTICES Copyright (c) 2006 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
Re: [Full-disclosure] Phun! Search
Hello, n3td3v wrote: I have exploit code for this issue, which the list won't be getting hold of. The disclosure was to show that I can ask the slurp robot to cache an account on the public index,... bla,... There's no need at all to cache anything at all. http://mtf.news.yahoo.com/mailto?prop=mycstorelocale=ush2=n3td3v will give you the same result as http://66.218.69.11/search/cache?ei=UTF-8p=n3td3vfr=sfpu=mtf.news.yahoo.com/mailto%3Furl%3Dhttp%253A//e.my.yahoo.com/config/cstore%253F.opt%3Dcontent%2526.node%3D1%2526.sid%3D171771%26title%3DChoose+Content%26prop%3Dmycstore%26locale%3Dus%26h1%3Dymessenger+at+Yahoo%21+Groups%26h2%3Dn3td3v%26h3%3Dhttp%253A//my.yahoo.comw=n3td3vd=U5wy1m1aMbOeicp=1.intl=us (your Concept). Sorry to tell you, but there is no vulnerability involved here (except maybe a lame XSS, didn't try that though). -- Bernhard ___ 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] Phun! Search
The document is cached on Yahoo Slurp, you explain that, smart guy ;-) On 3/23/06, Bernhard Mueller [EMAIL PROTECTED] wrote: Hello, There's no need at all to cache anything at all.Sorry to tell you, but there is no vulnerability involved here --Bernhard___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/
Re: [Full-disclosure] Phun! Search
Lol, and even with your idea, that would open up a great Yahoo phishing vector. You mean anyone can edit a legitimate Yahoo webpage with the name n3td3v on it and have it cached on Yahoo servers. I believe thats called DEFACEMENT of a corporate webpage. Even with your idea, thats still headline news. Now wheres Robert Lemos and Joris Evers, or are they too scared to mention the 'n3td3v' alias on public news sites, yes they are. On 3/23/06, n3td3v [EMAIL PROTECTED] wrote: The document is cached on Yahoo Slurp, you explain that, smart guy ;-) On 3/23/06, Bernhard Mueller [EMAIL PROTECTED] wrote: Hello, There's no need at all to cache anything at all. Sorry to tell you, but there is no vulnerability involved here --Bernhard___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/
Re: [Full-disclosure] Phun! Search
Im wondering when will u grow up and stop writing shits on FD ? On 3/24/06, n3td3v [EMAIL PROTECTED] wrote: Lol, and even with your idea, that would open up a great Yahoo phishing vector. You mean anyone can edit a legitimate Yahoo webpage with the name n3td3v on it and have it cached on Yahoo servers. I believe thats called DEFACEMENT of a corporate webpage. Even with your idea, thats still headline news. Now wheres Robert Lemos and Joris Evers, or are they too scared to mention the 'n3td3v' alias on public news sites, yes they are. On 3/23/06, n3td3v [EMAIL PROTECTED] wrote: The document is cached on Yahoo Slurp, you explain that, smart guy ;-) On 3/23/06, Bernhard Mueller [EMAIL PROTECTED] wrote: Hello, There's no need at all to cache anything at all. Sorry to tell you, but there is no vulnerability involved here -- Bernhard ___ 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/ -- Best Regards, Aleksander Hristov root at securitydot.net http://securitydot.net -- Best Regards, Aleksander Hristov root at securitydot.net http://securitydot.net ___ 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] Phun! Search
Read http://en.wikipedia.org/wiki/Hacktivismlearn ;-) On 3/24/06, Alexander Hristov [EMAIL PROTECTED] wrote: Im wondering when will u grow up and stop writing shits on FD ? ___ 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] Phun! Search
LOL jajajajajajOn 3/21/06, Javor Ninov [EMAIL PROTECTED] wrote:
i hope you soon reach 18 and start thinking about sex... you will likeit i am suren3td3v wrote: \/\/3 53nd j00 m4d c0d35 ch3x j00r 1nb0x3r ph0r Xpl01t c0d3 2 m4n1pul4t3 phUN! s34rch h0h0h0
On 3/21/06, *teh kids* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
G00d W0Rk, i7 533m5 tHaT u ArE pu77ing Y0Ur 3x7r@ ChR0M050M3 70 g00D u53 XxX On 3/21/06, n3td3v [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:Vendor: Yahoo! Inc. Service: Yahoo! Search.
Description: Phun! Search indexes millions of documents, including its own user accounts. Concept:
http://66.218.69.11/search/cache?ei=UTF-8p=n3td3vfr=sfpu=mtf.news.yahoo.com/mailto%3Furl%3Dhttp%253A//e.my.yahoo.com/config/cstore%253F.opt%3Dcontent%2526.node%3D1%2526.sid%3D171771%26title%3DChoose+Content%26prop%3Dmycstore%26locale%3Dus%26h1%3Dymessenger+at+Yahoo%21+Groups%26h2%3Dn3td3v%26h3%3Dhttp%253A//my.yahoo.comw=n3td3vd=U5wy1m1aMbOeicp=1.intl=us
http://66.218.69.11/search/cache?ei=UTF-8p=n3td3vfr=sfpu=mtf.news.yahoo.com/mailto%3Furl%3Dhttp%253A//e.my.yahoo.com/config/cstore%253F.opt%3Dcontent%2526.node%3D1%2526.sid%3D171771%26title%3DChoose+Content%26prop%3Dmycstore%26locale%3Dus%26h1%3Dymessenger+at+Yahoo%21+Groups%26h2%3Dn3td3v%26h3%3Dhttp%253A//my.yahoo.comw=n3td3vd=U5wy1m1aMbOeicp=1.intl=us
Remark: Yahoo! is not affiliated with the authors of this page or responsible for its content. :-) Thank: n3td3v.
Greet: Yahoo! core security team. ___ Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ 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 - 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-2006:060 ] - Updated FreeRADIUS packages fix EAP-MSCHAPv2 module vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2006:060 http://www.mandriva.com/security/ ___ Package : freeradius Date: March 23, 2006 Affected: 2006.0 ___ Problem Description: An unspecified vulnerability in FreeRADIUS 1.0.0 up to 1.1.0 allows remote attackers to bypass authentication or cause a denial of service (server crash) via Insufficient input validation in the EAP-MSCHAPv2 state machine module. Updated packages have been patched to correct this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1354 ___ Updated Packages: Mandriva Linux 2006.0: f5694e70f14cbd19b83fd27b2486206c 2006.0/RPMS/freeradius-1.0.4-2.1.20060mdk.i586.rpm 9659a4da82f833ad9f981ea7227868b2 2006.0/RPMS/libfreeradius1-1.0.4-2.1.20060mdk.i586.rpm f9a3447563fef1dfb6340999b1d826de 2006.0/RPMS/libfreeradius1-devel-1.0.4-2.1.20060mdk.i586.rpm bf2f92256eaa0ce809d792e8e24611a1 2006.0/RPMS/libfreeradius1-krb5-1.0.4-2.1.20060mdk.i586.rpm 044cc3fbaa56104318ba267cdab184f9 2006.0/RPMS/libfreeradius1-ldap-1.0.4-2.1.20060mdk.i586.rpm 4b8c8e812804df23e9f6596d905621be 2006.0/RPMS/libfreeradius1-mysql-1.0.4-2.1.20060mdk.i586.rpm c2623a903a88573a3b768f2ebe7eacbb 2006.0/RPMS/libfreeradius1-postgresql-1.0.4-2.1.20060mdk.i586.rpm 28c6de397354d35ee9df21d8e191ebbe 2006.0/RPMS/libfreeradius1-unixODBC-1.0.4-2.1.20060mdk.i586.rpm 085c52e42b5cc7fc22837abd0f9c5139 2006.0/SRPMS/freeradius-1.0.4-2.1.20060mdk.src.rpm Mandriva Linux 2006.0/X86_64: bfce7c3070118389bfb438cf21172339 x86_64/2006.0/RPMS/freeradius-1.0.4-2.1.20060mdk.x86_64.rpm 16da145b1daefdb21ddf948840e5080d x86_64/2006.0/RPMS/lib64freeradius1-1.0.4-2.1.20060mdk.x86_64.rpm 8a31178431515a527b098eba3cae4d24 x86_64/2006.0/RPMS/lib64freeradius1-devel-1.0.4-2.1.20060mdk.x86_64.rpm ea2fac845a7de5897fc5a8cfc10aa567 x86_64/2006.0/RPMS/lib64freeradius1-krb5-1.0.4-2.1.20060mdk.x86_64.rpm df111b875358584ec03dc45c16a18cb5 x86_64/2006.0/RPMS/lib64freeradius1-ldap-1.0.4-2.1.20060mdk.x86_64.rpm a8b1ab60450cae42203318941f32a596 x86_64/2006.0/RPMS/lib64freeradius1-mysql-1.0.4-2.1.20060mdk.x86_64.rpm dad9cba86a4bbe8dd30d052853989094 x86_64/2006.0/RPMS/lib64freeradius1-postgresql-1.0.4-2.1.20060mdk.x86_64.rpm c058e7e6d30729aefa60dd7cf3fe3ab3 x86_64/2006.0/RPMS/lib64freeradius1-unixODBC-1.0.4-2.1.20060mdk.x86_64.rpm 085c52e42b5cc7fc22837abd0f9c5139 x86_64/2006.0/SRPMS/freeradius-1.0.4-2.1.20060mdk.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.2.2 (GNU/Linux) iD8DBQFEIyNkmqjQ0CJFipgRAqX7AKDlD7ZrED1MAZDU8zXs/JOq6wk2VwCffGiU ZMogegmLH8UXUd2dlOmdwh8= =BcHF -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] Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
Sendmail is, as we know, the most used daemon for SMTP in the world. This is an International Infrastructure vulnerability and should have been treated that way. It wasn't. It was handled not only poorly, but irresponsibly. You would probably expect me to the be last person to say that Sendmail is perfectly within their rights. I have had a lot of problems with what they are doing. But what did you pay for Sendmail? Was it a dollar, or was it more? Let me guess. It was much less than a dollar. I bet you paid nothing. So does anyone owe you anything, let alone a particular process which you demand with such length? Now, the same holds true with OpenSSH. I'll tell you what. If there is ever a security problem (again :) in OpenSSH we will disclose it exactly like we want, and in no other way, and quite frankly since noone has ever paid a cent for it's development they have nothing they can say about it. Dear non-paying user -- please remember your place. Or run something else. OK? Luckily within a few months you will be able to tell Sendmail how to disclose their bugs because their next version is going to come out with a much more commercial licence. Then you can pay for it, and then you can complain too. ___ 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] [FLSA-2006:186277] Updated sendmail packages fix security issues
- Fedora Legacy Update Advisory Synopsis: Updated sendmail packages fix security issues Advisory ID: FLSA:186277 Issue date:2006-03-23 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2006-0058 - - 1. Topic: Updated sendmail packages that fix a security issue are now available. The sendmail package provides A widely used Mail Transport Agent (MTA). 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 Fedora Core 3 - i386, x86_64 3. Problem description: A flaw in the handling of asynchronous signals was discovered in Sendmail. A remote attacker may be able to exploit a race condition to execute arbitrary code as root. The Common Vulnerabilities and Exposures project assigned the name CVE-2006-0058 to this issue. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. In order to correct this issue for RHL 7.3 users, it was necessary to upgrade the version of Sendmail from 8.11 as originally shipped to Sendmail 8.12.11 with the addition of the security patch supplied by Sendmail Inc. This erratum provides updated packages based on Sendmail 8.12 with a compatibility mode enabled as provided by Red Hat for RHEL 2.1. After updating to these packages, users should pay close attention to their sendmail logs to ensure that the upgrade completed successfully. In order to correct this issue for RHL 9 and FC1 users, it was necessary to upgrade the version of Sendmail from 8.12.8 and 8.12.10 respectively to 8.12.11 with the addition of the security patch supplied by Sendmail Inc. After updating to these packages, users should pay close attention to their sendmail logs to ensure that the upgrade completed successfully. For Fedora Core 3 users, the patch supplied by Sendmail Inc. applies cleanly to the latest sendmail package previously released for Fedora Core 3. Users updating to these packages are urged to review their sendmail.cf file after updating. rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via yum and apt. Many people find this an easier way to apply updates. To use yum issue: yum update or to use apt: apt-get update; apt-get upgrade This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. This assumes that you have yum or apt-get configured for obtaining Fedora Legacy content. Please visit http://www.fedoralegacy.org/docs for directions on how to configure yum and apt-get. 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186277 6. RPMs required: Red Hat Linux 7.3: SRPM: http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/sendmail-8.12.11-4.22.9.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/7.3/updates/i386/sendmail-8.12.11-4.22.9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/sendmail-cf-8.12.11-4.22.9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/sendmail-devel-8.12.11-4.22.9.legacy.i386.rpm http://download.fedoralegacy.org/redhat/7.3/updates/i386/sendmail-doc-8.12.11-4.22.9.legacy.i386.rpm Red Hat Linux 9: SRPM: http://download.fedoralegacy.org/redhat/9/updates/SRPMS/sendmail-8.12.11-4.24.1.legacy.src.rpm i386: http://download.fedoralegacy.org/redhat/9/updates/i386/sendmail-8.12.11-4.24.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/sendmail-cf-8.12.11-4.24.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/sendmail-devel-8.12.11-4.24.1.legacy.i386.rpm http://download.fedoralegacy.org/redhat/9/updates/i386/sendmail-doc-8.12.11-4.24.1.legacy.i386.rpm Fedora Core 1: SRPM: http://download.fedoralegacy.org/fedora/1/updates/SRPMS/sendmail-8.12.11-4.25.1.legacy.src.rpm i386: http://download.fedoralegacy.org/fedora/1/updates/i386/sendmail-8.12.11-4.25.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/sendmail-cf-8.12.11-4.25.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/sendmail-devel-8.12.11-4.25.1.legacy.i386.rpm http://download.fedoralegacy.org/fedora/1/updates/i386/sendmail-doc-8.12.11-4.25.1.legacy.i386.rpm Fedora Core 2: SRPM: http://download.fedoralegacy.org/fedora/2/updates/SRPMS/sendmail-8.12.11-4.26.legacy.src.rpm i386:
Re: [Full-disclosure] Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
On 3/23/06, Theo de Raadt [EMAIL PROTECTED] wrote: Sendmail is, as we know, the most used daemon for SMTP in the world. This is an International Infrastructure vulnerability and should have been treated that way. It wasn't. It was handled not only poorly, but irresponsibly. You would probably expect me to the be last person to say that Sendmail is perfectly within their rights. I have had a lot of problems with what they are doing. I think people expect you to be as you are. But what did you pay for Sendmail? Was it a dollar, or was it more? Let me guess. It was much less than a dollar. I bet you paid nothing. So does anyone owe you anything, let alone a particular process which you demand with such length? Now, the same holds true with OpenSSH. I'll tell you what. If there is ever a security problem (again :) in OpenSSH we will disclose it exactly like we want, and in no other way, and quite frankly since noone has ever paid a cent for it's development they have nothing they can say about it. Dear non-paying user -- please remember your place. I seem to recall that DARPA funded a good bit of your work. I also seem to recall that I and many others funded DARPA. Kindly submit to the will of us all. Or run something else. OK? Or simply cut off funding. The game can be played both ways. Luckily within a few months you will be able to tell Sendmail how to disclose their bugs because their next version is going to come out with a much more commercial licence. Then you can pay for it, and then you can complain too. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- Purple Bag Society of the Crown ___ 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] Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
Theo de Raadt wrote: But what did you pay for Sendmail? Was it a dollar, or was it more? Let me guess. It was much less than a dollar. I bet you paid nothing. Hey Theo, what did you pay for all the software you started with and/or still use in your project? How much did YOU pay for Sendmail? And you guys essentially resell it, right? So does anyone owe you anything, let alone a particular process which you demand with such length? I don't know... I seem to see a lot of criticism and demands coming from your direction: http://en.wikiquote.org/wiki/Theo_de_Raadt Now, the same holds true with OpenSSH. I'll tell you what. If there is ever a security problem (again :) in OpenSSH we will disclose it exactly like we want, and in no other way, and quite frankly since noone has ever paid a cent for it's development they have nothing they can say about it. Really? No one? You wrote it by yourself with no support of any kind? And are you saying that you plan to slipstream your fixes? Dear non-paying user -- please remember your place. I seem to recall having donated some money, purchased shirts... I think I've got a number of OpenBSD CDs sets around the house that I purchased. Now I realize that you consider those donations, ever though most people would consider that some degree of having paid. But I'd be willing to bet that even if we worked out some contract that had the word paid in it, that you would still not confer upon me any right to complain. That I would still need to remember my place. So I think we can eliminate payment as a variable. This simplifies your argument from Don't criticize me if you haven't paid to simply Don't criticize me. Sucks to be held accountable, even when you give stuff away for free, doesn't it? Or run something else. OK? I don't know why they don't put you in charge of the fundraising efforts more often! http://undeadly.org/cgi?action=articlesid=20060321034114 And your timing is impeccable! Buy up! http://undeadly.org/cgi?action=articlesid=20060323091020 My order is on its way. BB ___ 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] Phun! Search
How come when people make comments off-list you re-add FD to the replies? You are cancer. On 3/23/06, n3td3v [EMAIL PROTECTED] wrote: I have exploit code for this issue, which the list won't be getting hold of. The disclosure was to show that I can ask the slurp robot to cache an account on the public index, so I can retrieve account information. I ask the code to cache a copy of 'x user', when 'x' is at critical information page to obtain access to the yahoo users account. Of course with such a good 0-day, I use it seldom and only on specific targets like yahoo users with 'paid' services and or Yahoo employees. On 3/22/06, Stan Bubrouski [EMAIL PROTECTED] wrote: How old are you? Seriously. I don't know whether you realize just how completely stupid you come off as to even people new in the security field. You are a joke. Quit filling this list with crap. BTW did you even check to see if you Yahoo! will let you view OTHER people's account stuff? Otherwise it seems pretty useless. -sb ___ 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 1019-1] New kpdf packages fix several vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 1019-1[EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze March 24th, 2006http://www.debian.org/security/faq - -- Package: koffice Vulnerability : several Problem type : local (remote) Debian-specific: no CVE ID : CVE-2006-1244 Bugtraq ID : 16748 Derek Noonburg has fixed several potential vulnerabilities in xpdf, the Portable Document Format (PDF) suite, which is also present in koffice, the KDE Office Suite. The old stable distribution (woody) does not contain kpdf packages. For the stable distribution (sarge) these problems have been fixed in version 1.3.5-4.sarge.3. For the unstable distribution (sid) these problems will be fixed soon. We recommend that you upgrade your kpdf 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 GNU/Linux 3.1 alias sarge - Source archives: http://security.debian.org/pool/updates/main/k/koffice/koffice_1.3.5-4.sarge.3.dsc Size/MD5 checksum: 975 5968b7cf5d069e98ba8fe6512b6f656c http://security.debian.org/pool/updates/main/k/koffice/koffice_1.3.5-4.sarge.3.diff.gz Size/MD5 checksum:21789 52604c90cca5685c2cecba3e418066d1 http://security.debian.org/pool/updates/main/k/koffice/koffice_1.3.5.orig.tar.gz Size/MD5 checksum: 13154501 2c9b45ecbf16a8c5d16ce9d2f51c2571 Architecture independent components: http://security.debian.org/pool/updates/main/k/koffice/kivio-data_1.3.5-4.sarge.3_all.deb Size/MD5 checksum: 623568 c53b00698e81328e5526fe40cbd4522e http://security.debian.org/pool/updates/main/k/koffice/koffice-data_1.3.5-4.sarge.3_all.deb Size/MD5 checksum: 692792 a8e0f9cbb192c88a23f42bd3e62836d4 http://security.debian.org/pool/updates/main/k/koffice/koffice-doc-html_1.3.5-4.sarge.3_all.deb Size/MD5 checksum: 295700 5cb99cee3874acbd20344315c2fc8dc7 http://security.debian.org/pool/updates/main/k/koffice/koffice_1.3.5-4.sarge.3_all.deb Size/MD5 checksum:21672 b27effec8464b005b354072a612365a9 Alpha architecture: http://security.debian.org/pool/updates/main/k/koffice/karbon_1.3.5-4.sarge.3_alpha.deb Size/MD5 checksum: 923332 f45bb0425f6f39ecc521f6bf10484374 http://security.debian.org/pool/updates/main/k/koffice/kchart_1.3.5-4.sarge.3_alpha.deb Size/MD5 checksum: 715538 e6bcecf6bea0bcda1c2728e1b2a7495d http://security.debian.org/pool/updates/main/k/koffice/kformula_1.3.5-4.sarge.3_alpha.deb Size/MD5 checksum: 703440 346bf50fda8dfaec02a90a8e0d0e54c3 http://security.debian.org/pool/updates/main/k/koffice/kivio_1.3.5-4.sarge.3_alpha.deb Size/MD5 checksum: 633042 7a824bf8ff0108fcadc4b249e2c3eea3 http://security.debian.org/pool/updates/main/k/koffice/koffice-dev_1.3.5-4.sarge.3_alpha.deb Size/MD5 checksum: 154722 ef84303285cfe0e1f529bbf8d19178d2 http://security.debian.org/pool/updates/main/k/koffice/koffice-libs_1.3.5-4.sarge.3_alpha.deb Size/MD5 checksum: 2307112 be91472dd188946a10b8893794825aa5 http://security.debian.org/pool/updates/main/k/koffice/koshell_1.3.5-4.sarge.3_alpha.deb Size/MD5 checksum:59784 2ac5aa0b6ee6103347717c7e0bf1bced http://security.debian.org/pool/updates/main/k/koffice/kpresenter_1.3.5-4.sarge.3_alpha.deb Size/MD5 checksum: 2603222 3cf494f98a30f24ad5bad6c64cc8d730 http://security.debian.org/pool/updates/main/k/koffice/kspread_1.3.5-4.sarge.3_alpha.deb Size/MD5 checksum: 1851030 1603d191a1c8d7f35909830c4c7cd78e http://security.debian.org/pool/updates/main/k/koffice/kugar_1.3.5-4.sarge.3_alpha.deb Size/MD5 checksum: 566634 b739c228f6ae2e03b5c205858425b3d2 http://security.debian.org/pool/updates/main/k/koffice/kword_1.3.5-4.sarge.3_alpha.deb Size/MD5 checksum: 3768746 ce22e335fb911f30c4175c4fcd43095a AMD64 architecture: http://security.debian.org/pool/updates/main/k/koffice/karbon_1.3.5-4.sarge.3_amd64.deb Size/MD5 checksum: 860396 a2a44915558aaa5a69548d6b6cffea73 http://security.debian.org/pool/updates/main/k/koffice/kchart_1.3.5-4.sarge.3_amd64.deb Size/MD5 checksum: 681242 a789c3a842ae8e777dacac43eba7284e http://security.debian.org/pool/updates/main/k/koffice/kformula_1.3.5-4.sarge.3_amd64.deb
[Full-disclosure] [SECURITY] [DSA 1018-1] New Linux kernel 2.4.27 packages fix several vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 1018-1[EMAIL PROTECTED] http://www.debian.org/security/ Dann Frazier, Simon Horman March 26th, 2006http://www.debian.org/security/faq - -- Package: kernel-source-2.4.27 Vulnerability : several Problem-Type : local/remote Debian-specific: no CVE IDs: CVE-2004-0887 CVE-2004-1058 CVE-2004-2607 CVE-2005-0449 CVE-2005-1761 CVE-2005-2457 CVE-2005-2555 CVE-2005-2709 CVE-2005-2973 CVE-2005-3257 CVE-2005-3783 CVE-2005-3806 CVE-2005-3848 CVE-2005-3857 CVE-2005-3858 CVE-2005-4618 Several local and remote vulnerabilities have been discovered in the Linux kernel that may lead to a denial of service or the execution of arbitrary code. The Common Vulnerabilities and Exposures project identifies the following problems: CVE-2004-0887 Martin Schwidefsky discovered that the privileged instruction SACF (Set Address Space Control Fast) on the S/390 platform is not handled properly, allowing for a local user to gain root privileges. CVE-2004-1058 A race condition allows for a local user to read the environment variables of another process that is still spawning through /proc/.../cmdline. CVE-2004-2607 A numeric casting discrepancy in sdla_xfer allows local users to read portions of kernel memory via a large len argument which is received as an int but cast to a short, preventing read loop from filling a buffer. CVE-2005-0449 An error in the skb_checksum_help() function from the netfilter framework has been discovered that allows the bypass of packet filter rules or a denial of service attack. CVE-2005-1761 A vulnerability in the ptrace subsystem of the IA-64 architecture can allow local attackers to overwrite kernel memory and crash the kernel. CVE-2005-2457 Tim Yamin discovered that insufficient input validation in the compressed ISO file system (zisofs) allows a denial of service attack through maliciously crafted ISO images. CVE-2005-2555 Herbert Xu discovered that the setsockopt() function was not restricted to users/processes with the CAP_NET_ADMIN capability. This allows attackers to manipulate IPSEC policies or initiate a denial of service attack. CVE-2005-2709 Al Viro discovered a race condition in the /proc handling of network devices. A (local) attacker could exploit the stale reference after interface shutdown to cause a denial of service or possibly execute code in kernel mode. CVE-2005-2973 Tetsuo Handa discovered that the udp_v6_get_port() function from the IPv6 code can be forced into an endless loop, which allows a denial of service attack. CVE-2005-3257 Rudolf Polzer discovered that the kernel improperly restricts access to the KDSKBSENT ioctl, which can possibly lead to privilege escalation. CVE-2005-3783 The ptrace code using CLONE_THREAD didn't use the thread group ID to determine whether the caller is attaching to itself, which allows a denial of service attack. CVE-2005-3806 Yen Zheng discovered that the IPv6 flow label code modified an incorrect variable, which could lead to memory corruption and denial of service. CVE-2005-3848 Ollie Wild discovered a memory leak in the icmp_push_reply() function, which allows denial of service through memory consumption. CVE-2005-3857 Chris Wright discovered that excessive allocation of broken file lock leases in the VFS layer can exhaust memory and fill up the system logging, which allows denial of service. CVE-2005-3858 Patrick McHardy discovered a memory leak in the ip6_input_finish() function from the IPv6 code, which allows denial of service. CVE-2005-4618 Yi Ying discovered that sysctl does not properly enforce the size of a buffer, which allows a denial of service attack. The following matrix explains which kernel version for which architecture fix the problems mentioned above: Debian 3.1 (sarge) Source 2.4.27-10sarge2 Alpha architecture 2.4.27-10sarge2 ARM architecture2.4.27-2sarge2 Intel IA-32 architecture2.4.27-10sarge2 Intel IA-64 architecture2.4.27-10sarge2 Motorola 680x0 architecture 2.4.27-3sarge2 Big endian MIPS architecture2.4.27-10.sarge1.040815-2 Little endian MIPS architecture 2.4.27-10.sarge1.040815-2 PowerPC architecture2.4.27-10sarge2 IBM S/390 architecture 2.4.27-2sarge2 Sun Sparc architecture 2.4.27-9sarge2 The following matrix lists additional packages that were rebuilt for compatability with or to take advantage of this update:
Re: [Full-disclosure] Phun! Search
On could hope that the two of you will get cancer and die and soon. On Thu, 23 Mar 2006 21:56:13 -0800 Stan Bubrouski [EMAIL PROTECTED] wrote: How come when people make comments off-list you re-add FD to the replies? You are cancer. On 3/23/06, n3td3v [EMAIL PROTECTED] wrote: I have exploit code for this issue, which the list won't be getting hold of. The disclosure was to show that I can ask the slurp robot to cache an account on the public index, so I can retrieve account information. I ask the code to cache a copy of 'x user', when 'x' is at critical information page to obtain access to the yahoo users account. Of course with such a good 0-day, I use it seldom and only on specific targets like yahoo users with 'paid' services and or Yahoo employees. On 3/22/06, Stan Bubrouski [EMAIL PROTECTED] wrote: How old are you? Seriously. I don't know whether you realize just how completely stupid you come off as to even people new in the security field. You are a joke. Quit filling this list with crap. BTW did you even check to see if you Yahoo! will let you view OTHER people's account stuff? Otherwise it seems pretty useless. -sb ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ 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/
Re: [Full-disclosure] Phun! Search
Hmm,.. No, I can't figure out how this works. You must have used zero day exploit code. n3td3v wrote: The document is cached on Yahoo Slurp, you explain that, smart guy ;-) On 3/23/06, *Bernhard Mueller* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello, There's no need at all to cache anything at all. Sorry to tell you, but there is no vulnerability involved here -- Bernhard ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html 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] sendmail stuff
if anyone is playing with the sendmail bug stuff , here is what ive gotten thus far. http://rapturesecurity.org/jack/exploiting_sendmail.html if anyone has any luck i would like to hear about it :] -- Jack - [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
Theo de Raadt wrote: (who are you again?) Your customer. That does not make it right for our user community to attack developers for their freely given efforts. People who get attacked might stop trying to improve the code. Attacking commercial software developers makes them write better code, attacking free software developers makes them feel bad and quit. Got it. You could run other software, you know. And you could write your software without bitching at the people who help you pay your bills. I can't see that changing real soon either. But hey, you keep being you, and I'll keep buying your stuff in spite of your attitude, because it's good software. I use DJB's software under the same circumstances, so I'm used to it. BB ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
