On Sat, Jul 21, 2001 at 05:22:22PM -0500, Brent J. Nordquist wrote:
(1) A PHPLIB vulnerability allowed an attacker to provide a value for
the array element $_PHPLIB[libdir], and thus to get scripts from another
server to load and execute. This vulnerability is remotely exploitable.
(Horde
Stephanie Thomas [EMAIL PROTECTED] writes:
A potential remote root exploit has been discovered
in SSH Secure Shell 3.0.0, for Unix only, concerning
accounts with password fields consisting of two or
fewer characters.
A quick glance at the source code suggests that SSH 2.3.0 and 2.4.0
Now that the storm has passed for the most part I will only be approving
a few final messages on this topic. Please, use the incidents mailing
list if you wish to follow up on Core Red. You can find it at
[EMAIL PROTECTED]
--
Elias Levy
SecurityFocus.com
http://www.securityfocus.com/
Si vis
On 2001-07-22 10:03:31 +0200, Florian Weimer wrote:
A quick glance at the source code suggests that SSH 2.3.0 and
2.4.0 have the same problem. Is this true?
I suppose we are talking about this section of ssh 2.4.0's
sshunixuser.c:
940
941/* Authentication is accepted if the
On Fri, 20 Jul 2001, Patrick Medhurst wrote:
The vendor was contacted on 19 June 2001 and responded on 20 June 2001
as follows:
We will take a look at the issue and fix it as soon as possible.
Further correspondence requesting when a fix will be released has been
ignored.
Just because a
Chad Loder [EMAIL PROTECTED] wrote:
Snip
What's even MORE menacing to me is that UNC paths can
include references to file shares on remote computers
(on the local LAN *or* on the Internet) e.g.:
file://\\trojan.evil.com\HACKME
When Windows tries to open UNC paths like that, by
default
On 21 Jul 2001, Dale Southard wrote:
Sshd should probably be constraining its match to the length of the
crypt() output rather than the length of the password file entry. [I
say ``probably'' here because some systems (AIX) seem to produce null
password file hashes when `passwd` is given a
It seems as if the Code Red worm has gone to sleep for now, at least so
far as we can tell. It will be interesting to see what happens when it
re-awakens.
My previous email noted that the ARIS project would be notifying as many
IP's as we could about possible infections of the worm. To that
The following cross-site scripting vulnerability was reported in
cgiwrap. This has just been corrected in version 3.7 which has just been
released.
http://prdownloads.sourceforge.net/cgiwrap/cgiwrap-3.7.tar.gz
All error message output is now html encoded to prevent this problem.
-- Nathan
During the infection phase of Code Red (on the 19th) we wrote a small tool
for research purposes.
This tool read in logs of machines sending the default.ida attack and connected
back to them on port 80, made a GET request and dumped the resulting data.
This tool was run continuously from 3
On Fri, 20 Jul 2001, Stephanie Thomas wrote:
an empty password. This affects SSH Secure Shell 3.0.0
I guess openssh with pam support is not vulnerable??
--
Marcin Zurakowski
InterFirma Administrator
JNJ wrote:
I have to disagree. Microsoft released a patch for this issue on 6/18/2001.
Here we are, a tad over a month later, and the issue is being exploited en
masse. This calls to question the attention of systems administrators to
their networks. The days of selective application of
Michal Zalewski [EMAIL PROTECTED] writes:
On Fri, 20 Jul 2001, Stephanie Thomas wrote:
PLATFORMS IMPACTED: Red Hat Linux 6.1 thru 7.1
RedHat Linux 7.0 ships OpenSSH 2.2.1 (7.0). RedHat Linux 7.1 ships OpenSSH
2.5.2. Previous versions shipped SSH 1.2.xx
Releases of Red Hat Linux earlier
Attached you will find pileup-1.2 which fixes the scanf() buffer overflows,
allowing root access as demonstrated by Charles Stevenson.
The fix was written by Richard Everitt [EMAIL PROTECTED], the
author of pileup.
Regards,
Joop
--
Joop Stakenborg - Debian GNU/Linux developer [EMAIL PROTECTED]
OpenSSH is not vulnerable at all weather or not you use PAM.. this is SSH
the commercial Version.
If you didn't pay for it then you are OK!!
--
Brian Carpio
CSG Systems Inc.
Open Systems Unix System Admin
x3317
--
--- Security is a Process NOT a Product
On
-Original Message-
From: Angelos Karageorgiou [SMTP:[EMAIL PROTECTED]]
Sent: Friday, July 20, 2001 3:37
To: Cole, Timothy D.
Cc: [EMAIL PROTECTED]
Subject: RE: Linux, too, sot of (Windows MS-DOS Device Name DoS
vulnerabil ities)
On Wed, 18 Jul 2001, Cole, Timothy D.
let's not forget, this is only alpha code. it is a good thing
that the vuln was found and reported to ibm. i think the advisory
is more than appropriate given that this is most likely not being
used in production by anyone. i don't know much about alphaworks but
i would presume that all code
e-smith (www.e-smith.com) has a minor fault in its 'administration' part. If
an account is added manually (that is, without using the http interface) it
wont show in the accounts in the http interface. Since most/all
administration is taken care of through the http interface an account would
While working with the commercial version of Arkeia backup software I
noticed it creates most of it's database files with the permissions of
666. This was version 4.2.8-2 of the server, and I had noticed this several
updates ago, so it's been going on for some time. The database files are
A quick glance at the source code suggests that SSH 2.3.0 and
2.4.0 have the same problem. Is this true?
I suppose we are talking about this section of ssh 2.4.0's
sshunixuser.c:
940
941 /* Authentication is accepted if the encrypted passwords are
identical. */
942
Just because a company can't tell you immediately when a bug will be
fixed, you say that you are being ignored and see fit to release an
advisory? Do you have any idea how easy the problem will be to fix?
Probably not, and I bet IBM would have to do some research first, finding
out what
Stephanie Thomas wrote:
A potential remote root exploit has been discovered
in SSH Secure Shell 3.0.0, for Unix only, concerning
accounts with password fields consisting of two or
fewer characters. Unauthorized users could potentially
log in to these accounts using any password,
From: Stephanie Thomas [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Fri, 20 Jul 2001 17:34:02 -0700
Subject: URGENT SECURITY ADVISORY FOR SSH SECURE SHELL 3.0.0
[...]
PLATFORMS IMPACTED:
Red Hat Linux 6.1 thru 7.1
Solaris 2.6 thru 2.8
HP-UX 10.20
HP-UX 11.00
Caldera Linux 2.4
Suse
This was covered in CERT Advisory CA-2001-18, posted
to bugtraq by aleph1 on July 17th. The posting is a
bit miss leading and has Oracle 8i Enterprise Edition
listed rather than Oracle Internet Directory (OiD).
- Dave Lee
In CERTs defense OiD does ship with the Enterprise
Edition, but that is
Both 2.3.0 and 2.4.0 don't appear to be vulnerable on my system (Intel
Solaris 8). 3.0.0 *was* vulnerable, however, and I was able to easily
exploit the system.
-Original Message-
From: Jaime BENJUMEA [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 21, 2001 12:27 PM
To: Stephanie Thomas
Proxomitron Cross-site Scripting Vulnerability
==
Affected versions
=
Proxomitron Naoko-4 BetaFour or earlier
http://spywaresucks.org/prox/
Problem
===
Accessing the following URL with the browser configured to use
26 matches
Mail list logo
