RE: what process is using a port
Or you can use fuser -n tcp 80 Also. Domonkos Czinke -Original Message- From: LeVA [mailto:[EMAIL PROTECTED] Sent: Monday, May 03, 2004 7:15 PM To: debian-security@lists.debian.org Subject: what process is using a port Hi! Is there a way to figure out what program is using a port. For example I want to know which process is using port 80. How can I do this? ps.: and another tiny question: Is it possible to see if a symlink is pointing at a given file? Thanks! Daniel -- LeVA
RE: what process is using a port
Or you can use fuser -n tcp 80 Also. Domonkos Czinke -Original Message- From: LeVA [mailto:[EMAIL PROTECTED] Sent: Monday, May 03, 2004 7:15 PM To: [EMAIL PROTECTED] Subject: what process is using a port Hi! Is there a way to figure out what program is using a port. For example I want to know which process is using port 80. How can I do this? ps.: and another tiny question: Is it possible to see if a symlink is pointing at a given file? Thanks! Daniel -- LeVA
FW: Coreutils 'dir' integer overflow vulnerability.
FYI (Woody is vulnerable) Domonkos Czinke -Original Message- From: Shaun Colley [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 02, 2004 8:35 PM To: bugtraq@securityfocus.com Subject: Coreutils 'dir' integer overflow vulnerability. ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Product: Coreutils 'dir' - versions < 5.2.0 http://www.gnu.org Versions: < 5.2.0 (**see "Vulnerable Versions" for very important info on versions vulnerable!**) Bug: DoS / possible arbitrary code execution. Impact: Attacker's can cause MASS consumption of CPU utilisation and usage of memory, by corrupting the stack. Possible code execution. Date: March 02, 2004 Author: Shaun Colley Email: [EMAIL PROTECTED] WWW: http://www.nettwerked.co.uk ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Introduction # GNU Coreutils is a set of standard utilities included in all Linux distributions, with a set of useful tools. These include: - ls - cat - date - yes - who - wc - dir - vdir - chown - chmod - echo and so on... A while ago, an integer overflow vulnerability was found in 'ls' by Georgi Guninski, allowing an attacker to consume CPU resources due to stack corruption, and *potentially* execute arbitrary code remotely (due to usage of 'ls' by Internet daemons like 'WU-FTPD'). Fixed packages were supplied by major Linux distribution vendors (and other UNIX-like OSes and UNIX variants), which fixed the integer overflow issue. After auditing 'dir' on a slightly older version of Coreutils, 4.1.11, I discovered 'dir' to be vulnerable to an almost identical attack. On the updated Coreutils packages supplied by Linux distribution vendors, and on the latest version of Coreutils (5.2.0), this issue in 'dir' *HAS* been fixed (likely because 'dir' uses some of 'ls's code), but for some reason, the community *WAS NOT* alerted of this vulnerability. The bug This bug occurs in the handling of arguments passed to 'dir' via the '-w' flag (the 'width' flag) at the shell. If an overly long integer is passed to 'dir' with the -w flag, the stack is corrupted, and large amounts of CPU utilisation are consumed. Although unlikely, if programs which invoke 'dir' allow passing of arguments via the '-w' flag, it is possible that arbitrary code execution is possible, although unconfirmed. CPU utilisation mass consumed by 'dir' due to the corruption of the stack can reach close to, or equal to, 100% usage, allowing complete DoS to be performed by a potential attacker. The vulnerability is due to bad handling of command line arguments, causing an integer overflow - causing the program stack and memory to be corrupted. The exploit A proof-of-concept to verify the issue in your version of Coreutils is the command shown below: ## bash$ dir -w 1073741828 ## If the host's version of Coreutils is vulnerable, mass CPU utilisation will be used, and if invoked via a debugging tool such as 'Valgrind', one can see the consequences of the integer overflow taking place. The fix The solution for this issue is to upgrade to the latest GNU Coreutils package. www.gnu.org Optionally, you can use the Coreutils packages supplied by your Linux distribution vendor. Grab the RPMs, and issue the following command: ## root# rpm -Uhv ## Re-invoke the proof-of-concept 'dir' command shown above, and the issue should be resolved. Vulnerable Versions During October 2003, Georgi Guninski discovered a similar (almost identical) integer overflow in 'ls', which led the the release of fixed Coreutils packages, fixing the 'ls' integer overflow, AND THE INTEGER OVERFLOW IN 'dir'. Perhaps it was never realised that 'dir' was vulnerable, but the fact remains is that it is. (The caps below are to ensure that the important information is read, not to imply shouting.) USERS WHO UPGRADED WHEN FIXED Coreutils PACKAGES WERE RELEASED TO FIX THE 'ls' INTEGER OVERFLOW VULNERABILITY ARE IMMUNE TO THIS VULNERABILITY, AND THEREFORE DO NOT NEED TO UPGRADE! Users who did not upgrade are *still* vulnerable to this similar (but different, since 'dir' is a different program) vulnerability. I advise you upgrade, as recommended above. Credit ### This vulnerability was discovered by Shaun Colley / shaun2k2. Thank you for your time. Shaun. ___ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html
FW: Coreutils 'dir' integer overflow vulnerability.
FYI (Woody is vulnerable) Domonkos Czinke -Original Message- From: Shaun Colley [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 02, 2004 8:35 PM To: [EMAIL PROTECTED] Subject: Coreutils 'dir' integer overflow vulnerability. ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Product: Coreutils 'dir' - versions < 5.2.0 http://www.gnu.org Versions: < 5.2.0 (**see "Vulnerable Versions" for very important info on versions vulnerable!**) Bug: DoS / possible arbitrary code execution. Impact: Attacker's can cause MASS consumption of CPU utilisation and usage of memory, by corrupting the stack. Possible code execution. Date: March 02, 2004 Author: Shaun Colley Email: [EMAIL PROTECTED] WWW: http://www.nettwerked.co.uk ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Introduction # GNU Coreutils is a set of standard utilities included in all Linux distributions, with a set of useful tools. These include: - ls - cat - date - yes - who - wc - dir - vdir - chown - chmod - echo and so on... A while ago, an integer overflow vulnerability was found in 'ls' by Georgi Guninski, allowing an attacker to consume CPU resources due to stack corruption, and *potentially* execute arbitrary code remotely (due to usage of 'ls' by Internet daemons like 'WU-FTPD'). Fixed packages were supplied by major Linux distribution vendors (and other UNIX-like OSes and UNIX variants), which fixed the integer overflow issue. After auditing 'dir' on a slightly older version of Coreutils, 4.1.11, I discovered 'dir' to be vulnerable to an almost identical attack. On the updated Coreutils packages supplied by Linux distribution vendors, and on the latest version of Coreutils (5.2.0), this issue in 'dir' *HAS* been fixed (likely because 'dir' uses some of 'ls's code), but for some reason, the community *WAS NOT* alerted of this vulnerability. The bug This bug occurs in the handling of arguments passed to 'dir' via the '-w' flag (the 'width' flag) at the shell. If an overly long integer is passed to 'dir' with the -w flag, the stack is corrupted, and large amounts of CPU utilisation are consumed. Although unlikely, if programs which invoke 'dir' allow passing of arguments via the '-w' flag, it is possible that arbitrary code execution is possible, although unconfirmed. CPU utilisation mass consumed by 'dir' due to the corruption of the stack can reach close to, or equal to, 100% usage, allowing complete DoS to be performed by a potential attacker. The vulnerability is due to bad handling of command line arguments, causing an integer overflow - causing the program stack and memory to be corrupted. The exploit A proof-of-concept to verify the issue in your version of Coreutils is the command shown below: ## bash$ dir -w 1073741828 ## If the host's version of Coreutils is vulnerable, mass CPU utilisation will be used, and if invoked via a debugging tool such as 'Valgrind', one can see the consequences of the integer overflow taking place. The fix The solution for this issue is to upgrade to the latest GNU Coreutils package. www.gnu.org Optionally, you can use the Coreutils packages supplied by your Linux distribution vendor. Grab the RPMs, and issue the following command: ## root# rpm -Uhv ## Re-invoke the proof-of-concept 'dir' command shown above, and the issue should be resolved. Vulnerable Versions During October 2003, Georgi Guninski discovered a similar (almost identical) integer overflow in 'ls', which led the the release of fixed Coreutils packages, fixing the 'ls' integer overflow, AND THE INTEGER OVERFLOW IN 'dir'. Perhaps it was never realised that 'dir' was vulnerable, but the fact remains is that it is. (The caps below are to ensure that the important information is read, not to imply shouting.) USERS WHO UPGRADED WHEN FIXED Coreutils PACKAGES WERE RELEASED TO FIX THE 'ls' INTEGER OVERFLOW VULNERABILITY ARE IMMUNE TO THIS VULNERABILITY, AND THEREFORE DO NOT NEED TO UPGRADE! Users who did not upgrade are *still* vulnerable to this similar (but different, since 'dir' is a different program) vulnerability. I advise you upgrade, as recommended above. Credit ### This vulnerability was discovered by Shaun Colley / shaun2k2. Thank you for your time. Shaun. ___ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Tripwire (clone) which would you prefer?
Hello, Actually Im using Integrit with Coda. I store the binary and the database on a read only coda mount (you can't mount it rw unless you know the coda password), and its really fast and reliable. So my vote is Integrit, btw you should check all of them and then make a decision for you needs. Best regards, Domonkos Czinke -Original Message- From: Jan Lühr [mailto:[EMAIL PROTECTED] Sent: Monday, February 23, 2004 10:42 AM To: debian-security@lists.debian.org Subject: Tripwire (clone) which would you prefer? Greetings, well, I looking for an open source intrusion detection. At first, tripwire caputures my attention, but the last open source version seems to be three years old - is it still in development or badly vulnerable? Then I searched for tripwire in the woody packages and found integrit and bsign - so which would you prefer and why? Are there any interesting other projekt that worth looking for? Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Tripwire (clone) which would you prefer?
Hello, Actually Im using Integrit with Coda. I store the binary and the database on a read only coda mount (you can't mount it rw unless you know the coda password), and its really fast and reliable. So my vote is Integrit, btw you should check all of them and then make a decision for you needs. Best regards, Domonkos Czinke -Original Message- From: Jan Lühr [mailto:[EMAIL PROTECTED] Sent: Monday, February 23, 2004 10:42 AM To: [EMAIL PROTECTED] Subject: Tripwire (clone) which would you prefer? Greetings, well, I looking for an open source intrusion detection. At first, tripwire caputures my attention, but the last open source version seems to be three years old - is it still in development or badly vulnerable? Then I searched for tripwire in the woody packages and found integrit and bsign - so which would you prefer and why? Are there any interesting other projekt that worth looking for? Keep smiling yanosz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Grsecurity, ssh and postfix
Hi, I think you won't have to make a unique jail for ssh, you can use the pam module which is designed especially for this. Unfortunately AFAIK debian does not support that module, so you will have to compile your own packages. Btw you can switch off the double chroot restrictions under Grsec Customize > Filesystem Protections > Chroot jail restrictions (NEW) > [ ]Deny double-chroots Domonkos Czinke -Original Message- From: Arnaud Fontaine [mailto:[EMAIL PROTECTED] Sent: Saturday, December 06, 2003 3:37 PM To: debian-security@lists.debian.org Subject: Re: Grsecurity, ssh and postfix On Fri, 5 Dec 2003 21:45:01 +0100 Florian Weimer <[EMAIL PROTECTED]> wrote: > The privilege separation code invokes chroot(), too. > > Is there a "do not create any new file descriptors" process attribute > in grsecurity? If there is, OpenSSH should toggle instead of calling > chroot() to an empty directory, which is a poor replacement. Hello, Thanks for your explanation but i don't know how to do that with grsecurity. I am looking after this. I have done a chroot environment for ssh to log in for fetch, read and send mails with mutt, procmail, fetchmail and postfix. But i would like to know how i can integrate postfix to this chroot environment. Could you give me some advices about this ? Thanks for your help... Arnaud Fontaine - signature Arnaud Fontaine <[EMAIL PROTECTED]> - http://www.andesi.org/ GnuPG Public Key available at http://www.andesi.org/gpg/dsdebian.asc Fingerprint: 22B6 B676 332E 23BC CA7D 174D 6D41 235A 23A2 500A -- fortune "There are a billion people in China. And I want them to be able to pass notes to each other written in Perl. I want them to be able to write poetry in Perl. That is my vision of the Future. My chosen perspective." -- Larry Wall (Open Sources, 1999 O'Reilly and Associates)
RE: secure file permissions
Hi, I recommend using the chattr program. You should set them immutable chattr +i /etc/passwd /etc/shadow /etc/group /etc/gshadow. Man chattr. Domonkos Czinke -Original Message- From: Lupe Christoph [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 9:56 AM To: mi Cc: debian-security@lists.debian.org Subject: Re: secure file permissions On Sunday, 2003-12-07 at 09:27:04 +0100, mi wrote: > Can you tell me what are the default permissions for /etc/group and > /etc/passwd ? > I restricted them to rw for root only, but some things like exim (and > possibly dpkg ?) seem to need read access there too. > What's recommendet ? You want to change them, so I guess you should know why. BTW, try running ls as a user when /etc/group and /etc/passwd are 600. Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | "Violence is the resort of the violent" Lu Tze | | "Thief of Time", Terry Pratchett | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Grsecurity, ssh and postfix
Hi, I think you won't have to make a unique jail for ssh, you can use the pam module which is designed especially for this. Unfortunately AFAIK debian does not support that module, so you will have to compile your own packages. Btw you can switch off the double chroot restrictions under Grsec Customize > Filesystem Protections > Chroot jail restrictions (NEW) > [ ]Deny double-chroots Domonkos Czinke -Original Message- From: Arnaud Fontaine [mailto:[EMAIL PROTECTED] Sent: Saturday, December 06, 2003 3:37 PM To: [EMAIL PROTECTED] Subject: Re: Grsecurity, ssh and postfix On Fri, 5 Dec 2003 21:45:01 +0100 Florian Weimer <[EMAIL PROTECTED]> wrote: > The privilege separation code invokes chroot(), too. > > Is there a "do not create any new file descriptors" process attribute > in grsecurity? If there is, OpenSSH should toggle instead of calling > chroot() to an empty directory, which is a poor replacement. Hello, Thanks for your explanation but i don't know how to do that with grsecurity. I am looking after this. I have done a chroot environment for ssh to log in for fetch, read and send mails with mutt, procmail, fetchmail and postfix. But i would like to know how i can integrate postfix to this chroot environment. Could you give me some advices about this ? Thanks for your help... Arnaud Fontaine - signature Arnaud Fontaine <[EMAIL PROTECTED]> - http://www.andesi.org/ GnuPG Public Key available at http://www.andesi.org/gpg/dsdebian.asc Fingerprint: 22B6 B676 332E 23BC CA7D 174D 6D41 235A 23A2 500A -- fortune "There are a billion people in China. And I want them to be able to pass notes to each other written in Perl. I want them to be able to write poetry in Perl. That is my vision of the Future. My chosen perspective." -- Larry Wall (Open Sources, 1999 O'Reilly and Associates) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: secure file permissions
Hi, I recommend using the chattr program. You should set them immutable chattr +i /etc/passwd /etc/shadow /etc/group /etc/gshadow. Man chattr. Domonkos Czinke -Original Message- From: Lupe Christoph [mailto:[EMAIL PROTECTED] Sent: Sunday, December 07, 2003 9:56 AM To: mi Cc: [EMAIL PROTECTED] Subject: Re: secure file permissions On Sunday, 2003-12-07 at 09:27:04 +0100, mi wrote: > Can you tell me what are the default permissions for /etc/group and > /etc/passwd ? > I restricted them to rw for root only, but some things like exim (and > possibly dpkg ?) seem to need read access there too. > What's recommendet ? You want to change them, so I guess you should know why. BTW, try running ls as a user when /etc/group and /etc/passwd are 600. Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | "Violence is the resort of the violent" Lu Tze | | "Thief of Time", Terry Pratchett | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Attack using php+apache
I recommend using SuPHP to avoid run-as-apache problems:
http://www.suphp.org/Home.html
"suPHP is a tool for executing PHP scripts with the permissions of their
owners. It consists of an Apache module (mod_suphp) and a setuid root
binary (suphp) that is called by the Apache module to change the uid of
the process executing the PHP interpreter. "
Domonkos Czinke
-Original Message-
From: Adam ENDRODI [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 16, 2003 12:33 PM
To: debian-security
Subject: Re: Attack using php+apache
On Sat, Nov 15, 2003 at 10:43:14PM -0500, Alex J. Avriette wrote:
> On Sat, Nov 15, 2003 at 08:11:34PM -0600, Tom Goulet (UID0) wrote:
>
> > If you have register globals off *or* safe mode on, this particular
> > exploit is useless.
>
> > If you had register globals on and safe mode off then he could run
> > arbitrary programs as your Apache user. It's possible he could run
a
> > local root exploiting program, but that's not as likely.
>
> It really irritates me that people continue to use this when the
> php.ini file repeatedly warns (no, begs) you not to.
FWIW, having register globals off sometimes gives a false sense
of security. Recently, I've discovered that PHP-Nuke just seems
to work well with this setting, because it circumventes it by
calling import_request_variables('GPC'). I'm less than happy
about PHP.
bit,
adam
--
1024D/37B8D989 954B 998A E5F5 BA2A 3622 82DD 54C2 843D 37B8 D989
finger://[EMAIL PROTECTED] | Some days, my soul's confined
http://www.keyserver.net | And out of mind
Sleep forever
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]
RE: Attack using php+apache
I recommend using SuPHP to avoid run-as-apache problems:
http://www.suphp.org/Home.html
"suPHP is a tool for executing PHP scripts with the permissions of their
owners. It consists of an Apache module (mod_suphp) and a setuid root
binary (suphp) that is called by the Apache module to change the uid of
the process executing the PHP interpreter. "
Domonkos Czinke
-Original Message-
From: Adam ENDRODI [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 16, 2003 12:33 PM
To: debian-security
Subject: Re: Attack using php+apache
On Sat, Nov 15, 2003 at 10:43:14PM -0500, Alex J. Avriette wrote:
> On Sat, Nov 15, 2003 at 08:11:34PM -0600, Tom Goulet (UID0) wrote:
>
> > If you have register globals off *or* safe mode on, this particular
> > exploit is useless.
>
> > If you had register globals on and safe mode off then he could run
> > arbitrary programs as your Apache user. It's possible he could run
a
> > local root exploiting program, but that's not as likely.
>
> It really irritates me that people continue to use this when the
> php.ini file repeatedly warns (no, begs) you not to.
FWIW, having register globals off sometimes gives a false sense
of security. Recently, I've discovered that PHP-Nuke just seems
to work well with this setting, because it circumventes it by
calling import_request_variables('GPC'). I'm less than happy
about PHP.
bit,
adam
--
1024D/37B8D989 954B 998A E5F5 BA2A 3622 82DD 54C2 843D 37B8 D989
finger://[EMAIL PROTECTED] | Some days, my soul's confined
http://www.keyserver.net | And out of mind
Sleep forever
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS
FYI
Cheers,
Domonkos Czinke
- Original Message -
From: <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
To: mailto:bugtraq@securityfocus.com>>
Sent: Sunday, January 05, 2003 4:37 AM
Subject: OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS
>
> -BEGIN PGP SIGNED MESSAGE-
>
> *** OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS ***
>
> MICKEY MOUSE HACKING SQUADRON ADVISORY #2
>
> DISCLAIMER
> - --
>
> The nation's zeroth private security intelligence firm, Mickey Mouse
> Hacking Squadron uniquely addresses the challenges faced by both public-
> and private-sector organizations in protecting critical information
> assets.
>
> Our intelligence is timely, delivered 24 x 7, 365 (*) days per year;
> relevant, fully customizable, and actionable intelligence is only
> valuable if it makes a difference.
>
> (*) in the case of a leap year, we of course provide a 24 x 7, 366 days
> premier service.
>
> TECHNICAL BACKGROUND
> -
>
> The following advisory is based on the excellent advisory published by
> Global InterSec LLC *six months ago*:
>
> <http://www.globalintersec.com/adv/openssh-2002062801.txt>
>
> After more than six months of intensive underground research, our ISO
> 31337 certified security department evidenced that the bug (an integer
> overflow, resulting in a heap overflow) described in the aforementioned
> advisory still exists in OpenSSH 3.5p1 and 3.4p1, and remains trivially
> exploitable. All existing PAM enabled versions of OpenSSH (3.5p1, 3.4p1
> and below) are therefore affected.
>
> Due to various advisories posted to various fora by unnamed security
> companies, this bug was supposed to be nonexistent or nonexploitable.
> Fortunately, Global InterSec LLC shed some light on the whole affair and
> revealed the malignant nature of the oversight to the world.
>
> Their results were applied to the latest OpenSSH versions by privately
> trained Mickey Mouse Hacking Squadron security specialists and revealed
> that the exploitation techniques developed by Global InterSec LLC are
> still applicable to the newest OpenSSH.
>
> PROOF OF CONCEPT
> -
>
> The following proof of concept is reproducing Global InterSec LLC
> findings, enhanced with the patented research performed by Mickey Mouse
> Hacking Squadron against OpenSSH 3.5p1.
>
> First of all, the OpenSSH 3.5p1 server has to be built (with PAM support
> enabled):
>
> $ tar xzf openssh-3.5p1.tar.gz
> $ cd openssh-3.5p1
> $ configure --with-pam
> [...]
> $ make sshd
> [...]
>
> Before the SSH server is actually executed, the sshd_config file should
> be modified in order to enable PAM ("PAMAuthenticationViaKbdInt yes").
>
> # sshd
>
> In order to reveal the nature of the OpenSSH vulnerability, the next
> step is to connect to the SSH server:
>
> $ ssh werewolf.research.mmhs.com
> Password:
>
> Thanks to the "Password:" prompt, it is clear that PAM is actually
> enabled (otherwise, the prompt would have been "[EMAIL PROTECTED]'s
> <mailto:[EMAIL PROTECTED]'s> password:").
> This unique fingerprinting technique was investigated by Mickey Mouse
> Hacking Squadron, and is already present in the latest version of the
> Mickey Mouse Hacking Squadron award winning network vulnerability
> assessment tool.
>
> After the previous command was executed, the freshly spawned sshd
> process has to be examined with a debugger, in order to set the correct
> breakpoints within the input_userauth_info_response_pam() function of
> OpenSSH, as demonstrated in the Global InterSec LLC advisory:
>
> # gdb sshd 6552
> (gdb) disassemble input_userauth_info_response_pam
> [...]
> 0x80531bc : push %esi
> 0x80531bd :
> call 0x807306c
> [...]
> (gdb) break *0x80531bd
> Breakpoint 1 at 0x80531bd: file auth2-pam.c, line 158.
> (gdb) continue
> Continuing.
>
> Now that the buggy call to xfree() can be intercepted, the SSH client
> should trigger the integer overlow and the resulting heap overflow:
>
> $ ssh werewolf.research.mmhs.com
> Password:
>
> After that, the xfree() breakpoint is reached, and the next call to
> free() should therefore be intercepted in order to comply with the
> technique developed by Global InterSec LLC:
>
> Breakpoint 1, 0x080531bd in input_userauth_info_response_pam (type=61,
> seqnr=7, ctxt=0x809c050) at auth2-pam.c:158
> 158 xfree(resp);
> (gdb) disassemble xfree
> [...]
> 0x807308e : call 0x804ba14
> [...]
> (gdb) break *0x807308e
> Breakpoint 2 at 0x807308e: file xmalloc.c, line 55.
> (gdb) continue
> Continuing.
>
OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS
FYI
Cheers,
Domonkos Czinke
- Original Message -
From: <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
To: <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
Sent: Sunday, January 05, 2003 4:37 AM
Subject: OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS
>
> -BEGIN PGP SIGNED MESSAGE-
>
> *** OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS ***
>
> MICKEY MOUSE HACKING SQUADRON ADVISORY #2
>
> DISCLAIMER
> - --
>
> The nation's zeroth private security intelligence firm, Mickey Mouse
> Hacking Squadron uniquely addresses the challenges faced by both public-
> and private-sector organizations in protecting critical information
> assets.
>
> Our intelligence is timely, delivered 24 x 7, 365 (*) days per year;
> relevant, fully customizable, and actionable intelligence is only
> valuable if it makes a difference.
>
> (*) in the case of a leap year, we of course provide a 24 x 7, 366 days
> premier service.
>
> TECHNICAL BACKGROUND
> -
>
> The following advisory is based on the excellent advisory published by
> Global InterSec LLC *six months ago*:
>
> <http://www.globalintersec.com/adv/openssh-2002062801.txt>
>
> After more than six months of intensive underground research, our ISO
> 31337 certified security department evidenced that the bug (an integer
> overflow, resulting in a heap overflow) described in the aforementioned
> advisory still exists in OpenSSH 3.5p1 and 3.4p1, and remains trivially
> exploitable. All existing PAM enabled versions of OpenSSH (3.5p1, 3.4p1
> and below) are therefore affected.
>
> Due to various advisories posted to various fora by unnamed security
> companies, this bug was supposed to be nonexistent or nonexploitable.
> Fortunately, Global InterSec LLC shed some light on the whole affair and
> revealed the malignant nature of the oversight to the world.
>
> Their results were applied to the latest OpenSSH versions by privately
> trained Mickey Mouse Hacking Squadron security specialists and revealed
> that the exploitation techniques developed by Global InterSec LLC are
> still applicable to the newest OpenSSH.
>
> PROOF OF CONCEPT
> -
>
> The following proof of concept is reproducing Global InterSec LLC
> findings, enhanced with the patented research performed by Mickey Mouse
> Hacking Squadron against OpenSSH 3.5p1.
>
> First of all, the OpenSSH 3.5p1 server has to be built (with PAM support
> enabled):
>
> $ tar xzf openssh-3.5p1.tar.gz
> $ cd openssh-3.5p1
> $ configure --with-pam
> [...]
> $ make sshd
> [...]
>
> Before the SSH server is actually executed, the sshd_config file should
> be modified in order to enable PAM ("PAMAuthenticationViaKbdInt yes").
>
> # sshd
>
> In order to reveal the nature of the OpenSSH vulnerability, the next
> step is to connect to the SSH server:
>
> $ ssh werewolf.research.mmhs.com
> Password:
>
> Thanks to the "Password:" prompt, it is clear that PAM is actually
> enabled (otherwise, the prompt would have been "user@host's <mailto:user@host's>
>password:").
> This unique fingerprinting technique was investigated by Mickey Mouse
> Hacking Squadron, and is already present in the latest version of the
> Mickey Mouse Hacking Squadron award winning network vulnerability
> assessment tool.
>
> After the previous command was executed, the freshly spawned sshd
> process has to be examined with a debugger, in order to set the correct
> breakpoints within the input_userauth_info_response_pam() function of
> OpenSSH, as demonstrated in the Global InterSec LLC advisory:
>
> # gdb sshd 6552
> (gdb) disassemble input_userauth_info_response_pam
> [...]
> 0x80531bc : push %esi
> 0x80531bd :
> call 0x807306c
> [...]
> (gdb) break *0x80531bd
> Breakpoint 1 at 0x80531bd: file auth2-pam.c, line 158.
> (gdb) continue
> Continuing.
>
> Now that the buggy call to xfree() can be intercepted, the SSH client
> should trigger the integer overlow and the resulting heap overflow:
>
> $ ssh werewolf.research.mmhs.com
> Password:
>
> After that, the xfree() breakpoint is reached, and the next call to
> free() should therefore be intercepted in order to comply with the
> technique developed by Global InterSec LLC:
>
> Breakpoint 1, 0x080531bd in input_userauth_info_response_pam (type=61,
> seqnr=7, ctxt=0x809c050) at auth2-pam.c:158
> 158 xfree(resp);
> (gdb) disassemble xfree
> [...]
> 0x807308e : call 0x804ba14
> [...]
> (gdb) break *0x807308e
> Breakpoint 2 at 0x807308e: file xmalloc.c, line 55.
> (gdb) continue
> Continuing.
>
RE: Bind9 stopped after 34 days of uptime
Hello, I have the same problem recently. I've deleted the needless users and groups from the group and passwd files, but because of some reason the utmp grp is needed by logrotate (why ? :)). Because of this problem, the logrotate didn't run daily and logfiles were bigger and bigger. Some days ago I received an alert from netsaint that my shiny new bind9 stopped running. I started to investigate it and I was surprised that i have 2 megabytes of free ram :/ I figured out that if some of the log files are so big (around 100Mb) syslog-ng ate up all of my 256Mb ram. So i compresssed those log files, restarted syslog-ng and bamm i have 181 Mb of free ram. So you should check this as well :) Best Regards, Domonkos Czinke -Original Message- From: InfoEmergencias - Luis Gomez [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 25, 2002 3:03 PM To: Debian security Subject: Bind9 stopped after 34 days of uptime Hi all I've been running my company's server with Linux in the same computer for about six months. Tonight, when I arrived home (my company is in my house) at about 6 a.m., I noticed I could not browse any website, and noticed that the DNS server (bind 9) was stopped. It was up when I left at 15.30h. I restarted the service and everything is OK now. We currently have an uptime of 34 days, and this had never happened before. The computer is running Woody, upgraded every night (via cron.daily). I've been looking at my logs, trying to determine at what exact time the dns server failed, but I cannot figure out. We never lost connection from the Internet, as we use a secondary name server provided by our name registrant (gandi.net), so as far as I can tell our name did not stop being resolvable from the outside (that explains why I didn't stop receiving mails, I think). Well, if anyone has ever had a problem like this and can lend me a hand or give me some advice, I'll be very happy to hear you :-) TIA Pope -- Luis Gomez Miralles InfoEmergencias - Technical Department Phone (+34) 654 24 01 34 Fax (+34) 963 49 31 80 [EMAIL PROTECTED] PGP Public Key available at http://www.infoemergencias.com/lgomez.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Bind9 stopped after 34 days of uptime
Hello, I have the same problem recently. I've deleted the needless users and groups from the group and passwd files, but because of some reason the utmp grp is needed by logrotate (why ? :)). Because of this problem, the logrotate didn't run daily and logfiles were bigger and bigger. Some days ago I received an alert from netsaint that my shiny new bind9 stopped running. I started to investigate it and I was surprised that i have 2 megabytes of free ram :/ I figured out that if some of the log files are so big (around 100Mb) syslog-ng ate up all of my 256Mb ram. So i compresssed those log files, restarted syslog-ng and bamm i have 181 Mb of free ram. So you should check this as well :) Best Regards, Domonkos Czinke -Original Message- From: InfoEmergencias - Luis Gomez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 25, 2002 3:03 PM To: Debian security Subject: Bind9 stopped after 34 days of uptime Hi all I've been running my company's server with Linux in the same computer for about six months. Tonight, when I arrived home (my company is in my house) at about 6 a.m., I noticed I could not browse any website, and noticed that the DNS server (bind 9) was stopped. It was up when I left at 15.30h. I restarted the service and everything is OK now. We currently have an uptime of 34 days, and this had never happened before. The computer is running Woody, upgraded every night (via cron.daily). I've been looking at my logs, trying to determine at what exact time the dns server failed, but I cannot figure out. We never lost connection from the Internet, as we use a secondary name server provided by our name registrant (gandi.net), so as far as I can tell our name did not stop being resolvable from the outside (that explains why I didn't stop receiving mails, I think). Well, if anyone has ever had a problem like this and can lend me a hand or give me some advice, I'll be very happy to hear you :-) TIA Pope -- Luis Gomez Miralles InfoEmergencias - Technical Department Phone (+34) 654 24 01 34 Fax (+34) 963 49 31 80 [EMAIL PROTECTED] PGP Public Key available at http://www.infoemergencias.com/lgomez.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: File system integrity checkers - comparison?
Hi, I'm using integrit for a while and its working fine here. Fast, small memory usage and good reporting system. I'm using it with CODA (binary, config and databases are on the CODA server), and its working fine :) Cheers, Domonkos Czinke -Original Message- From: Johannes Graumann [mailto:[EMAIL PROTECTED] Sent: Thursday, December 05, 2002 3:44 AM To: debian-security@lists.debian.org Subject: File system integrity checkers - comparison? Hello, I'm looking at this triade: Tripwire Aide Fcheck and was wondering as to what this group is prefering and why or whether there are other more trusted alternatives. My main argument ageinst tripwire is it's pseudo-commercial source. Thankful for any comment, Joh
RE: File system integrity checkers - comparison?
Hi, I'm using integrit for a while and its working fine here. Fast, small memory usage and good reporting system. I'm using it with CODA (binary, config and databases are on the CODA server), and its working fine :) Cheers, Domonkos Czinke -Original Message- From: Johannes Graumann [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 05, 2002 3:44 AM To: [EMAIL PROTECTED] Subject: File system integrity checkers - comparison? Hello, I'm looking at this triade: Tripwire Aide Fcheck and was wondering as to what this group is prefering and why or whether there are other more trusted alternatives. My main argument ageinst tripwire is it's pseudo-commercial source. Thankful for any comment, Joh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Trojan Found in libpcap and tcpdump
FYI Members of The Houston Linux Users Group discovered that the newest sources of libpcap and tcpdump available from tcpdump.org were contaminated with trojan code. HLUG has notified the maintainers of tcpdump.org. Details: The trojan contains modifications to the configure script and gencode.c (in libpcap only). The configure script downloads http://mars.raketti.net/~mash/services which is then sourced with the shell. It contains an embedded shell script that creates a C file, and compiles it. The program connects to 212.146.0.34 (mars.raketti.net) on port 1963 and reads one of three one byte status codes: A - program exits D - forks and spawns a shell and does the needed file descriptor manipulation to redirect it to the existing connection to 212.146.0.34. M - closes connection, sleeps 3600 seconds, and then reconnects It's important to note that it reuses the same outgoing connection for the shell. This gets around firewalls that block incoming connections. Gencode.c is modified to force libpcap to ignore packets to/from the backdoor program, hiding the backdoor program's traffic. This is similar to the OpenSSH trojan a few months ago. URL: http://www.net-security.org/news.php?id=1436 Best Regards, Domonkos Czinke
Trojan Found in libpcap and tcpdump
FYI Members of The Houston Linux Users Group discovered that the newest sources of libpcap and tcpdump available from tcpdump.org were contaminated with trojan code. HLUG has notified the maintainers of tcpdump.org. Details: The trojan contains modifications to the configure script and gencode.c (in libpcap only). The configure script downloads http://mars.raketti.net/~mash/services which is then sourced with the shell. It contains an embedded shell script that creates a C file, and compiles it. The program connects to 212.146.0.34 (mars.raketti.net) on port 1963 and reads one of three one byte status codes: A - program exits D - forks and spawns a shell and does the needed file descriptor manipulation to redirect it to the existing connection to 212.146.0.34. M - closes connection, sleeps 3600 seconds, and then reconnects It's important to note that it reuses the same outgoing connection for the shell. This gets around firewalls that block incoming connections. Gencode.c is modified to force libpcap to ignore packets to/from the backdoor program, hiding the backdoor program's traffic. This is similar to the OpenSSH trojan a few months ago. URL: http://www.net-security.org/news.php?id=1436 Best Regards, Domonkos Czinke -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Encrypting/emailing logs and configs
How about setting up loghost server with syslog-ng ? You should send these logs via stunnel (secure way), sort them, compress/gpg them :) Config files problem: set up a Coda server (reliable and secure) on this loghost and write a script to daily copy your config files. Cheers, Domonkos Czinke -Original Message- From: Sean McAvoy [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 30, 2002 7:08 PM To: debian-security@lists.debian.org Subject: Encrypting/emailing logs and configs Hello, I was looking at configuring a few of my VPN/Firewall systems to send me daily backups of vital config files, and selected log files. I was wondering what would be the easiest method of accomplishing this? I was thinking something along the lines of just tar/bzip and then gpg to encrypt. What other possibilities are there? And has anyone else setup something similar? -- Sean McAvoy Network Analyst Megawheels Technologies Inc. Phone: 416.360.8211 Fax: 416.360.1403 Cell: 416.616.6599
RE: Encrypting/emailing logs and configs
How about setting up loghost server with syslog-ng ? You should send these logs via stunnel (secure way), sort them, compress/gpg them :) Config files problem: set up a Coda server (reliable and secure) on this loghost and write a script to daily copy your config files. Cheers, Domonkos Czinke -Original Message- From: Sean McAvoy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 30, 2002 7:08 PM To: [EMAIL PROTECTED] Subject: Encrypting/emailing logs and configs Hello, I was looking at configuring a few of my VPN/Firewall systems to send me daily backups of vital config files, and selected log files. I was wondering what would be the easiest method of accomplishing this? I was thinking something along the lines of just tar/bzip and then gpg to encrypt. What other possibilities are there? And has anyone else setup something similar? -- Sean McAvoy Network Analyst Megawheels Technologies Inc. Phone: 416.360.8211 Fax: 416.360.1403 Cell: 416.616.6599 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Chrooted mysqld sock file problem
Hi ppl :) My question is related to a chrooted Apache(+php) and Mysql. They live in two different chrooted environment and the problem is that I have several php programs which wanna use the mysql, but they can't use it since they can't find the mysql.sock file (because it in another chroot), any idea to use apache+mysql in different chroot ? :) Cheers, Domonkos Czinke
Chrooted mysqld sock file problem
Hi ppl :) My question is related to a chrooted Apache(+php) and Mysql. They live in two different chrooted environment and the problem is that I have several php programs which wanna use the mysql, but they can't use it since they can't find the mysql.sock file (because it in another chroot), any idea to use apache+mysql in different chroot ? :) Cheers, Domonkos Czinke -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Apache 1.3.x shared memory scoreboard vulnerabilities
Title: Apache 1.3.x shared memory scoreboard vulnerabilities Damn :/ Domonkos Czinke -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 iDEFENSE Security Advisory 10.03.2002 Apache 1.3.x shared memory scoreboard vulnerabilities 16:00 GMT, October 3, 2002 I. BACKGROUND The Apache Software Foundation's HTTP Server is an effort to develop and maintain an open-source HTTP server for modern operating systems including Unix and Windows NT. The goal of this project is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards. More details about it are available at <http://httpd.apache.org> . II. DESCRIPTION Apache HTTP Server contains a vulnerability in its shared memory scoreboard. Attackers who can execute commands under the Apache UID can either send a (SIGUSR1) signal to any process as root, in most cases killing the process, or launch a local denial of service (DoS) attack. III. ANALYSIS Exploitation requires execute permission under the Apache UID. This can be obtained by any local user with a legitimate Apache scripting resource (ie: PHP, Perl), exploiting a vulnerability in web-based applications written in the above example languages, or through the use of some other local/remote Apache exploit. Once such a status is attained, the attacker can then attach to the httpd daemon's 'scoreboard', which is stored in a shared memory segment owned by Apache. The attacker can then cause a DoS condition on the system by continuously filling the table with null values and causing the server to spawn new children. The attacker also has the ability to send any process a SIGUSR1 signal as root. This is accomplished by continuously overwriting the parent[].pid and parent[].last_rtime segments within the scoreboard to the pid of the target process and a time in the past. When the target pid receives the signal SIGUSR1, it will react according to how it is designed to manage the signal. According to the man page (man 7 signal), if the signal is un-handled then the default action is to terminate: ... SIGUSR1 30,10,16 A User-defined signal 1 ... The letters in the "Action" column have the following meanings: A Default action is to terminate the process. ... iDEFENSE successfully terminated arbitrary processes, including those that "kicked" people off the system. IV. DETECTION Apache HTTP Server 1.3.x, running on all applicable Unix platforms, is affected. V. VENDOR FIX/RESPONSE Apache HTTP Server 1.3.27 fixes this problem. It should be available on October 3 at <http://www.apache.org/dist/httpd/> . VI. CVE INFORMATION The Mitre Corp.'s Common Vulnerabilities and Exposures (CVE) Project has assigned the identification number CAN-2002-0839 to this issue. VII. DISCLOSURE TIMELINE 8/27/2002 Issue disclosed to iDEFENSE 9/18/2002 Vendor notified at [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 9/18/2002 iDEFENSE clients notified 9/19/2002 Response received from Mark J Cox ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>) 10/3/2002 Coordinated public disclosure VIII. CREDIT zen-parse ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>) disclosed this issue to iDEFENSE. Get paid for security research <http://www.idefense.com/contributor.html> Subscribe to iDEFENSE Advisories: send email to [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>, subject line: "subscribe" About iDEFENSE: iDEFENSE is a global security intelligence company that proactively monitors sources throughout the world — from technical vulnerabilities and hacker profiling to the global spread of viruses and other malicious code. iALERT, our security intelligence service, provides decision-makers, frontline security professionals and network administrators with timely access to actionable intelligence and decision support on cyber-related threats. For more information, visit <http://www.idefense.com>. - -dave David Endler, CISSP Director, Technical Intelligence iDEFENSE, Inc. 14151 Newbrook Drive Suite 100 Chantilly, VA 20151 voice: 703-344-2632 fax: 703-961-1071 [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> www.idefense.com <http://www.idefense.com> -BEGIN PGP SIGNATURE- Version: PGP 7.1.2 Comment: <http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4B0ACC2A> iQA/AwUBPZx0I0rdNYRLCswqEQIowQCfQT+FYR1FLTEzlf49SpJXwDnie8wAn3Kr CncduGV6EYHqVayQE90b7Yij =4T8j -END PGP SIGNATURE-
Apache 1.3.x shared memory scoreboard vulnerabilities
Title: Apache 1.3.x shared memory scoreboard vulnerabilities Damn :/ Domonkos Czinke -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 iDEFENSE Security Advisory 10.03.2002 Apache 1.3.x shared memory scoreboard vulnerabilities 16:00 GMT, October 3, 2002 I. BACKGROUND The Apache Software Foundation's HTTP Server is an effort to develop and maintain an open-source HTTP server for modern operating systems including Unix and Windows NT. The goal of this project is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards. More details about it are available at <http://httpd.apache.org> . II. DESCRIPTION Apache HTTP Server contains a vulnerability in its shared memory scoreboard. Attackers who can execute commands under the Apache UID can either send a (SIGUSR1) signal to any process as root, in most cases killing the process, or launch a local denial of service (DoS) attack. III. ANALYSIS Exploitation requires execute permission under the Apache UID. This can be obtained by any local user with a legitimate Apache scripting resource (ie: PHP, Perl), exploiting a vulnerability in web-based applications written in the above example languages, or through the use of some other local/remote Apache exploit. Once such a status is attained, the attacker can then attach to the httpd daemon's 'scoreboard', which is stored in a shared memory segment owned by Apache. The attacker can then cause a DoS condition on the system by continuously filling the table with null values and causing the server to spawn new children. The attacker also has the ability to send any process a SIGUSR1 signal as root. This is accomplished by continuously overwriting the parent[].pid and parent[].last_rtime segments within the scoreboard to the pid of the target process and a time in the past. When the target pid receives the signal SIGUSR1, it will react according to how it is designed to manage the signal. According to the man page (man 7 signal), if the signal is un-handled then the default action is to terminate: ... SIGUSR1 30,10,16 A User-defined signal 1 ... The letters in the "Action" column have the following meanings: A Default action is to terminate the process. ... iDEFENSE successfully terminated arbitrary processes, including those that "kicked" people off the system. IV. DETECTION Apache HTTP Server 1.3.x, running on all applicable Unix platforms, is affected. V. VENDOR FIX/RESPONSE Apache HTTP Server 1.3.27 fixes this problem. It should be available on October 3 at <http://www.apache.org/dist/httpd/> . VI. CVE INFORMATION The Mitre Corp.'s Common Vulnerabilities and Exposures (CVE) Project has assigned the identification number CAN-2002-0839 to this issue. VII. DISCLOSURE TIMELINE 8/27/2002 Issue disclosed to iDEFENSE 9/18/2002 Vendor notified at [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 9/18/2002 iDEFENSE clients notified 9/19/2002 Response received from Mark J Cox ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>) 10/3/2002 Coordinated public disclosure VIII. CREDIT zen-parse ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>) disclosed this issue to iDEFENSE. Get paid for security research <http://www.idefense.com/contributor.html> Subscribe to iDEFENSE Advisories: send email to [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>, subject line: "subscribe" About iDEFENSE: iDEFENSE is a global security intelligence company that proactively monitors sources throughout the world — from technical vulnerabilities and hacker profiling to the global spread of viruses and other malicious code. iALERT, our security intelligence service, provides decision-makers, frontline security professionals and network administrators with timely access to actionable intelligence and decision support on cyber-related threats. For more information, visit <http://www.idefense.com>. - -dave David Endler, CISSP Director, Technical Intelligence iDEFENSE, Inc. 14151 Newbrook Drive Suite 100 Chantilly, VA 20151 voice: 703-344-2632 fax: 703-961-1071 [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> www.idefense.com <http://www.idefense.com> -BEGIN PGP SIGNATURE- Version: PGP 7.1.2 Comment: <http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4B0ACC2A> iQA/AwUBPZx0I0rdNYRLCswqEQIowQCfQT+FYR1FLTEzlf49SpJXwDnie8wAn3Kr CncduGV6EYHqVayQE90b7Yij =4T8j -END PGP SIGNATURE-
RE: 2seks
pleased to meet you ;)
Domonkos Czinke
-Original Message-
From: Nutty Baba [mailto:[EMAIL PROTECTED]
Sent: Friday, August 16, 2002 1:26 AM
To: debian-security@lists.debian.org
Subject: Re: 2seks
Hic bir yerde bulup izleyemeyeceginiz icerigi size http://www.2seks.com sunuyor.
TURK VE AVRUPALI AMATOR KIZLAR
BULGAR KIZLARI
ROMEN HATUNLAR
TURK TECAVUZ FILMLERI
KIZLAR YURDU
ALMANYA'NIN SAPIK HATUNLARI
OTELDEKI GIZLI KAMERALAR
VE DAHASI...
Hepsi orjinal ve kaliteli kayitlar. Hemen giris yapin ve tadini cikartin
http://www.2seks.com
N.I@éS[uæj{rê·*ªç¶X¶Çn&¢¸SزæyË~é¹»®&NºnW¢{rٲٲ×-+±×?©
