thr3ads.net - linux security - [linux-security] Re: IPMASQ and lock-up of all terminals ---- Sum mary and update [Mar 2000]

If this information is useful, please help other people find it:
Share via:
MeriwetherDJ@nswccd.navy.mil
2000-Mar-15 13:12 UTC
[linux-security] Re: IPMASQ and lock-up of all terminals ---- Sum mary and update

Well, last night, my box was hit again.. same symptoms:

All attempts to connect remotely receive a connection, but a login prompt
never comes up.
When I went to the console and turned on the monitor, I had the login
prompt, but written on to the screen was the message 
IPMASQ: Reverse ICMP: Checksum error from xxx.xxx.xxx.xxx

So, on this occasion, I thought I would post a summary of the responses I
got, and ask a few specific lingering questions.

Summary:
Some commented on having the same problem until they switched from one
distribution to another, or from one version to another. (this doesn't help
me too much as the same problem happened in two different versions 6.0 and
6.2 beta)
Some suggested I check my binaries for trojans, and other signs of attack.
I found none.
Some suggested the problem lay with syslogd locking up. Several specific
conditions that have caused this phenomenon in the past were mentioned, but
none of the circumstances fit my case.  (the machine using itself in
resolv.conf, disk full,  etc.)
Another mentioned a similar problem tied to mgetty, although the lock-up is
not as complete as on my machine, so I imagine that they are dealing with a
different phenomenon.
Another mentioned that running out of file descriptors would also lock up a
system, but they also mentioned that this is mainly a problem with web and
mail servers.  My box is running neither.
Another mentioned the possibility that a fork bomb or a DOS attack may have
caused the system to run out of processes (of which they reported the
default to be 512).   I know of no way of verifying this theory, nor do I
know of anyway to defend against such an attack.  Help in this arena would
be appreciated.

Continuing questions:

1) What exactly is a Reverse ICMP?  (That message has been on the terminal
screen 3 out of 3 times I have had this problem.)

2) Is there a way to directly test whether syslogd is the culprit?  Is there
a way I can correct it?

3) Is there a way of directly testing whether I am the victim of an
occasionally fork bomb or DOS attack?  Is there a way I can correct this?


Thank you very much for all your help.. and of course references to helpful,
germane websites is also greatly appreciated!

James Meriwether


From mail@mail.redhat.com Fri Apr 7 08:08:43 2000
Received: (qmail 3377 invoked from network); 7 Apr 2000 12:08:47 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 7 Apr 2000 12:08:47 -0000
Received: from rosie.bitwizard.nl (13dyn134.delft.casema.net [212.64.76.134])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id IAA20764
	for <linux-security@redhat.com>; Fri, 7 Apr 2000 08:08:43 -0400
Received: from cave.bitwizard.nl (root@cave.bitwizard.nl [192.168.234.1])
	by rosie.bitwizard.nl (8.8.8/8.8.8) with ESMTP id OAA24222
	for <linux-security@redhat.com>; Fri, 7 Apr 2000 14:08:39 +0200
Received: (from wolff@localhost)
	by cave.bitwizard.nl (8.9.3/8.9.3) id OAA11233
	for linux-security@redhat.com; Fri, 7 Apr 2000 14:08:37 +0200
Approved: R.E.Wolff@BitWizard.nl
Received: (qmail 26851 invoked by alias); 4 Apr 2000 05:08:28 -0000
Received: (qmail 26848 invoked from network); 4 Apr 2000 05:08:28 -0000
Received: from lists.redhat.com (199.183.24.247)
  by www.bitwizard.nl with SMTP; 4 Apr 2000 05:08:28 -0000
Received: (qmail 13668 invoked by uid 501); 4 Apr 2000 05:08:27 -0000
Received: (qmail 13656 invoked from network); 4 Apr 2000 05:08:27 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 4 Apr 2000 05:08:27 -0000
Received: from sana.furryterror.org (cr934547-a.flfrd1.on.wave.home.com
[24.112.247.163])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id BAA20919
	for <linux-security@redhat.com>; Tue, 4 Apr 2000 01:08:24 -0400
Received: from mngexecu by sana.furryterror.org with local (Exim 3.12 #1
(Debian))
	id 12c8fr-0001G8-00
	for <linux-security@redhat.com>; Mon, 03 Apr 2000 11:21:55 -0400
From: hgtaesml@umail.furryterror.org (Zygo Blaxell)
Subject: [linux-security] Re: IPMASQ and lock-up of all terminals ---- Sum mary
and update
Date: 3 Apr 2000 11:21:53 -0400
Organization: A poorly-maintained Debian GNU/Linux InterNetNews site
Message-ID: <8cacuh$4n1$1@sana.furryterror.org>
References:
<27BC18174C3CD2118F6000A0C99E423E026A17F3@CRPHEX02.NAVSSES.NAVY.MIL>
NNTP-Posting-Host: 127.0.0.1
X-Header-Mangling: Original "From:" was
<zblaxell@sana.furryterror.org>
To: <linux-security@redhat.com>

In article
<27BC18174C3CD2118F6000A0C99E423E026A17F3@CRPHEX02.NAVSSES.NAVY.MIL>,
 <MeriwetherDJ@nswccd.navy.mil> wrote:>Well, last night, my box was hit again.. same symptoms:
>
>All attempts to connect remotely receive a connection, but a login prompt
>never comes up.
What about other servers that this machine is running?  Do they all hang, or
can you get a response from one of the other ports?  Do a 'netstat
-antu'
while the machine is up, then try every listed port next time it's
not feeling well.
>When I went to the console and turned on the monitor, I had the login
>prompt, but written on to the screen was the message 
>IPMASQ: Reverse ICMP: Checksum error from xxx.xxx.xxx.xxx
But could you get another login prompt, or actually log in?  If you can
hit ENTER and/or Ctrl-D and get more login prompts, but as soon as you
enter a user name or password it hangs, then it's probably syslogd
(login (actually PAM) will hang as soon as it tries to syslog the username
you're logging in with).  

If you can't even get further login: prompts, then something more
low-level has failed.

Try enabling Magic-SysRq support in your kernel 
('echo 1 > /proc/sys/kernel/sysrq' may be required) then press
Alt-SysRq-T
to get a list of tasks (you may need Alt-SysRq-8 first, to cause all log
messages to be displayed on the screen instead of intercepted by klogd).

Incidentally, you can also use this feature unmount and sync your disks,
with Alt-SysRq-U and Alt-SysRq-S, respectively.  Sometimes Alt-SysRq-U
unhangs things, particularly swap-related deadlocks.
>So, on this occasion, I thought I would post a summary of the responses I
>got, and ask a few specific lingering questions.
>
>Summary:
>Some commented on having the same problem until they switched from one
>distribution to another, or from one version to another. (this doesn't
help
>me too much as the same problem happened in two different versions 6.0 and
>6.2 beta)
Presumably you're counting two different revisions of Red Hat as changing
distributions?  That's not a big change.  Debian or Slackware will give
you different behavior (although not necessarily different in a good way ;-).
>Some suggested I check my binaries for trojans, and other signs of attack.
>I found none.
>Some suggested the problem lay with syslogd locking up. Several specific
>conditions that have caused this phenomenon in the past were mentioned, but
>none of the circumstances fit my case.  (the machine using itself in
>resolv.conf, disk full,  etc.)
One case that always seemed to hang syslogd for me is syslogging to a
remote server from a Red Hat machine.  If the network between the log
client and log server goes down, syslogd inevitably hangs.  This problem
seems to have gone away in recent (in the last year) versions of Debian's
sysklogd package.  IIUC Debian and Red Hat have had different sysklogd
code bases for some years now.
>Another mentioned the possibility that a fork bomb or a DOS attack may have
>caused the system to run out of processes (of which they reported the
>default to be 512).   I know of no way of verifying this theory, nor do I
>know of anyway to defend against such an attack.  Help in this arena would
>be appreciated.
The defense against DOS attacks is to better control resource usage or
increase capacity until the DOS doesn't consume all of your resources
(though the latter case is more useful for "unintentional" DOS, e.g.
when
your machine is simply crushed by the amount of legitimate work it has
to do).

To verify the theory, try running '(date; ps xaf) >>
/var/log/ps-log'
out of crontab every minute until the next time this problem happens.  
This may give you a clue if the fork bomb occurs slowly enough.

You can get some useful information by simply leaving 'top' running on
a virtual console.  At least you would have a partial process list just
before the crash.
>Continuing questions:
>
>1) What exactly is a Reverse ICMP?  (That message has been on the terminal
>screen 3 out of 3 times I have had this problem.)
Probably an ICMP that isn't a Forward ICMP.  ;-)  Actually an ICMP packet
that is going through the firewall from outside to inside, as opposed to
inside-to-outside (i.e. an ICMP "reply").
>2) Is there a way to directly test whether syslogd is the culprit?  Is there
>a way I can correct it?
If you have a shell prompt on the machine, try "echo boo! | logger". 
If
that hangs, your problem is syslogd.  Note this will require you to leave
an ssh logged in under screen, or some similar thing, because you need to
be already logged in in order to do this.

To correct the problem, '/etc/rc.d/init.d/syslogd restart' (or 
'killall -9 syslogd; syslogd').  

Note that if your machine is unable to schedule any processes
(e.g. because the swap disk died), it can still accept() several hundred
incoming network connections.  
>>From the symptoms described so far, the problem could be nearly anythingfrom deliberate DOS to bad disk controller firmware, particularly if
console log messages are being routed through klogd.  A deadlock caused
by masquerading code isn't outside the realm of possibility.
>3) Is there a way of directly testing whether I am the victim of an
>occasionally fork bomb or DOS attack?  Is there a way I can correct this?
Logging...lots of logging.

You'd probably notice a fork bomb with tools as basic as 'ps' or
'top'--if
you got there fast enough.  If you're too late...well, you can't ask the
machine if it's running a fork bomb because it's too busy forking to
respond to you.  ;-)


From mail@mail.redhat.com Sat Apr 8 12:11:47 2000
Received: (qmail 20652 invoked from network); 8 Apr 2000 16:11:50 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 8 Apr 2000 16:11:50 -0000
Received: from rosie.bitwizard.nl (14dyn150.delft.casema.net [212.64.77.150])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id MAA00428
	for <linux-security@redhat.com>; Sat, 8 Apr 2000 12:11:47 -0400
Received: from cave.bitwizard.nl (root@cave.bitwizard.nl [192.168.234.1])
	by rosie.bitwizard.nl (8.8.8/8.8.8) with ESMTP id SAA00974
	for <linux-security@redhat.com>; Sat, 8 Apr 2000 18:11:44 +0200
Received: (from wolff@localhost)
	by cave.bitwizard.nl (8.9.3/8.9.3) id SAA06185
	for linux-security@redhat.com; Sat, 8 Apr 2000 18:11:43 +0200
Approved: R.E.Wolff@BitWizard.nl
Received: (qmail 24083 invoked by alias); 8 Apr 2000 08:34:13 -0000
Received: (qmail 24080 invoked from network); 8 Apr 2000 08:34:13 -0000
Received: from lists.redhat.com (199.183.24.247)
  by www.bitwizard.nl with SMTP; 8 Apr 2000 08:34:12 -0000
Received: (qmail 14020 invoked by uid 501); 8 Apr 2000 08:28:46 -0000
Received: (qmail 14008 invoked from network); 8 Apr 2000 08:28:46 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 8 Apr 2000 08:28:46 -0000
Received: from electron.upit.ro (qmailr@[193.230.35.20])
	by mail.redhat.com (8.8.7/8.8.7) with SMTP id EAA26724
	for <linux-security@redhat.com>; Sat, 8 Apr 2000 04:28:43 -0400
Received: (qmail 7909 invoked by uid 500); 8 Apr 2000 10:22:45 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 8 Apr 2000 10:22:45 -0000
Date: Sat, 8 Apr 2000 10:22:44 +0000 (UCT)
From: Pantalache Dalis-Adrian <dalis@electron.upit.ro>
To: linux-security@redhat.com
Subject: [linux-security] Re: IPMASQ and lock-up of all terminals ----
 Sum mary and update
In-Reply-To: <8cacuh$4n1$1@sana.furryterror.org>
Message-ID: <Pine.LNX.4.21.0004081013170.7640-100000@electron.upit.ro>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On 3 Apr 2000, Zygo Blaxell wrote:
> >3) Is there a way of directly testing whether I am the victim of an
> >occasionally fork bomb or DOS attack?  Is there a way I can correct
this?
> 
> Logging...lots of logging.
> 
> You'd probably notice a fork bomb with tools as basic as 'ps'
or 'top'--if
> you got there fast enough.  If you're too late...well, you can't
ask the
> machine if it's running a fork bomb because it's too busy forking
to
> respond to you.  ;-)
> 
> A solution is 
put  in 
/etc/pam.d/login
session    required     /lib/security/pam_limits.so
and in other config pam ex.
/etc/pam.d/ssh 
......
then 
in /etc/security/limits.conf
*               hard     nproc            15

read the limits.conf for more 
and try a fork bomb
try before zis
#!/bin/sh
$0&$0&
and after modification 
15 is the number of the proces per user 

-- 
Pantalache Dalis-Adrian
+---------------------------------+
|	 Linux Sysadmin           |
|                                 |
| dalis@electron.upit.ro          |
| dalis@agersystems.ro            |
+---------------------------------+


From mail@mail.redhat.com Apr 11:17:39 2000  -0400
Received: (qmail 6734 invoked from network); 12 Apr 2000 16:06:25 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 12 Apr 2000 16:06:25 -0000
Received: from devserv.devel.redhat.com (root@devserv.devel.redhat.com
[207.175.42.156])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id LAA17236;
	Wed, 12 Apr 2000 11:17:39 -0400
Received: from alien.devel.redhat.com (IDENT:gafton@alien.devel.redhat.com
[207.175.42.9])
	by devserv.devel.redhat.com (8.9.3/8.9.3) with ESMTP id LAA23867;
	Wed, 12 Apr 2000 11:17:39 -0400
Date: Wed, 12 Apr 2000 11:17:32 -0400 (EDT)
From: Cristian Gafton <gafton@redhat.com>
X-Sender: gafton@alien.devel.redhat.com
To: redhat-watch-list@redhat.com
Subject: [SECURITY] RHSA-2000:009-02.text: New gpm packages available
Message-ID:
<Pine.LNX.4.21.0004121114240.27152-100000@alien.devel.redhat.com>
Approved: ewt@redhat.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-----BEGIN PGP SIGNED MESSAGE-----


- ---------------------------------------------------------------------
                   Red Hat, Inc. Security Advisory

Synopsis:          gpm
Advisory ID:       RHSA-2000:009-02
Issue date:        2000-04-07
Updated on:        2000-04-10
Product:           Red Hat Linux
Keywords:          gpm gpm-root gid 0 priviledge
Cross references:  N/A
- ---------------------------------------------------------------------

1. Topic:

gpm-root (part of the gpm packge) fails to drop gid 0 priviledges
when executing user commands.

2. Relevant releases/architectures:

Red Hat Linux 4.2 - alpha i386 sparc
Red Hat Linux 5.2 - i386 alpha sparc
Red Hat Linux 6.0 - alpha i386 sparc
Red Hat Linux 6.1 - i386 alpha sparc
Red Hat Linux 6.2 - alpha i386 sparc


3. Problem description:

gpm is a cut and paste utility and mouse server for virtual
consoles. As part of this package, the gpm-root program allows
people to define menus and actions for display when clicking on
the background of current tty.

The current gpm-root program fails to correctly give up the group
id 0 membership for user defined menus. If you are running
gpm-root on your system then you are at risk.

4. Solution:

For each RPM for your particular architecture, run:

rpm -Fvh [filename]

where filename is the name of the RPM.

5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info):

10340 - Exploit in gpm-root. 
10644 - gpm security problem in gpm-root


6. Obsoleted by:

N/A

7. Conflicts with:

N/A

8. RPMs required:


Red Hat Linux 4.2:

alpha:
ftp://updates.redhat.com/4.2/alpha/gpm-1.19.1-0.4.2.alpha.rpm

intel:
ftp://updates.redhat.com/4.2/i386/gpm-1.19.1-0.4.2.i386.rpm

sparc:
ftp://updates.redhat.com/4.2/sparc/gpm-1.19.1-0.4.2.sparc.rpm

sources:
ftp://updates.redhat.com/4.2/SRPMS/gpm-1.19.1-0.4.2.src.rpm

Red Hat Linux 5.2:

intel:
ftp://updates.redhat.com/5.2/i386/gpm-1.19.1-0.5.2.i386.rpm

alpha:
ftp://updates.redhat.com/5.2/alpha/gpm-1.19.1-0.5.2.alpha.rpm

sparc:
ftp://updates.redhat.com/5.2/sparc/gpm-1.19.1-0.5.2.sparc.rpm

sources:
ftp://updates.redhat.com/5.2/SRPMS/gpm-1.19.1-0.5.2.src.rpm

Red Hat Linux 6.0, 6.1, 6.2:

alpha:
ftp://updates.redhat.com/6.2/alpha/gpm-1.19.1-1.alpha.rpm

intel:
ftp://updates.redhat.com/6.2/i386/gpm-1.19.1-1.i386.rpm

sparc:
ftp://updates.redhat.com/6.2/sparc/gpm-1.19.1-1.sparc.rpm

sources:
ftp://updates.redhat.com/6.2/SRPMS/gpm-1.19.1-1.src.rpm


9. Verification:

MD5 sum                           Package Name
- --------------------------------------------------------------------------
b8278a5d0a867a2fd8e6ac4a927627cb  4.2/alpha/gpm-1.19.1-0.4.2.alpha.rpm
c5075756a0f74c36a94c78ccda496412  4.2/sparc/gpm-1.19.1-0.4.2.sparc.rpm
b3d87c92880a9bf80d0fd3ff944e907b  4.2/SRPMS/gpm-1.19.1-0.4.2.src.rpm
7112c804fd008e137f8d6551460c10d7  4.2/i386/gpm-1.19.1-0.4.2.i386.rpm
79ebec95b2d6e48f60d4e34cfdee6f93  5.2/i386/gpm-1.19.1-0.5.2.i386.rpm
c4cdced5149e773733458c234ede2ac7  5.2/SRPMS/gpm-1.19.1-0.5.2.src.rpm
330e555a09e7b5c85187d348dbf453e6  5.2/alpha/gpm-1.19.1-0.5.2.alpha.rpm
5ceda554f2549c100a88d6370e45e2f6  5.2/sparc/gpm-1.19.1-0.5.2.sparc.rpm
867c4316ec0645fd8e51b674646ef44d  6.2/alpha/gpm-1.19.1-1.alpha.rpm
fbeb89d319776e7eb3af1db15679e93f  6.2/sparc/gpm-1.19.1-1.sparc.rpm
86a800ce94206877edc4f6e88272deee  6.2/i386/gpm-1.19.1-1.i386.rpm
8dedce47f4e6aa7bbfb36d9630561cd4  6.2/SRPMS/gpm-1.19.1-1.src.rpm


These packages are GPG signed by Red Hat, Inc. for security.  Our key
is available at:
    http://www.redhat.com/corp/contact.html

You can verify each package with the following command:
    rpm --checksig  <filename>

If you only wish to verify that each package has not been corrupted or
tampered with, examine only the md5sum with the following command:
    rpm --checksig --nogpg <filename>

10. References:

http://www.securityfocus.com/templates/archive.pike?list=1&msg=20000322182143.4498.qmail@securityfocus.com

Thanks also go to Egmont Koblinger and the members of the Bugtraq list.

Cristian
- --
- ----------------------------------------------------------------------
Cristian Gafton     --     gafton@redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  "How could this be a problem in a country where we have Intel and 
   Microsoft?"  --Al Gore on Y2K

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBOPSTkfGvxKXU9NkBAQFT2wP/Q1CA/zlLy3sii398LoOgW3KCnQNVlSC4
A1QwJXAzLTKTkifgnkKcxMJ1oQ8Xym7LvvsqIUKICrATeL4zEpBVyls/xx/sDp6x
LaMf03yP0ihWnpkKL7/1xqiQ3bq8fAA1FnbpQUvzFZ2uJ+RobiDLQ97G58nLPIn6
MY8sVj6zCks=Lh1D
-----END PGP SIGNATURE-----


From mail@mail.redhat.com Apr 14:29:59 2000  -0400
Received: (qmail 9351 invoked from network); 21 Apr 2000 18:30:00 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 21 Apr 2000 18:30:00 -0000
Received: from devserv.devel.redhat.com (root@devserv.devel.redhat.com
[207.175.42.156])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id OAA03238;
	Fri, 21 Apr 2000 14:29:59 -0400
Received: from alien.devel.redhat.com (IDENT:gafton@alien.devel.redhat.com
[207.175.42.9])
	by devserv.devel.redhat.com (8.9.3/8.9.3) with ESMTP id OAA28227;
	Fri, 21 Apr 2000 14:29:58 -0400
Date: Fri, 21 Apr 2000 14:29:51 -0400 (EDT)
From: Cristian Gafton <gafton@redhat.com>
X-Sender: gafton@alien.devel.redhat.com
To: redhat-watch-list@redhat.com
cc: BUGTRAQ@SECURITYFOCUS.COM, Linux Security <linux-security@redhat.com>
Subject: SECURITY: [RHSA-2000:012] New openldap packages available
Message-ID:
<Pine.LNX.4.21.0004211421540.9127-100000@alien.devel.redhat.com>
Approved: ewt@redhat.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-----BEGIN PGP SIGNED MESSAGE-----

- ---------------------------------------------------------------------
                   Red Hat, Inc. Security Advisory

Synopsis:          New openldap packages.
Advisory ID:       RHSA-2000:012-05
Issue date:        2000-04-13
Updated on:        2000-04-21
Product:           Red Hat Linux
Keywords:          openldap startup symlink overwrite denial
Cross references:  N/A
- ---------------------------------------------------------------------

1. Topic:

New openldap packages are available which fix a security
vulnerability in Red Hat Linux 6.1 and 6.2.

2. Relevant releases/architectures:

Red Hat Linux 6.1 - i386 alpha sparc
Red Hat Linux 6.2 - i386 alpha sparc


3. Problem description:

OpenLDAP follows symbolic links when creating files.  The default location for
these files is /usr/tmp, which is a symlink to /tmp, which in turn is a
world-writable directory.  Local users can destroy the contents of any file on
any
mounted filesystem.

4. Solution:

For each RPM for your particular architecture, run:

rpm -Fvh [filename]

where filename is the name of the RPM.

Administrators with existing databases should also move their NEXTID and *.dbb
files from /usr/tmp to /var/lib/ldap, and verify that the 'directory'
setting in
/etc/openldap/slapd.conf is changed accordingly.

5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info):

10714 - Insecure file creation using static files which follow symlinks.


6. Obsoleted by:

N/A

7. Conflicts with:

N/A

8. RPMs required:


Red Hat Linux 6.1:

intel:
ftp://updates.redhat.com/6.1/i386/openldap-1.2.9-6.i386.rpm

alpha:
ftp://updates.redhat.com/6.1/alpha/openldap-1.2.9-6.alpha.rpm

sparc:
ftp://updates.redhat.com/6.1/sparc/openldap-1.2.9-6.sparc.rpm

sources:
ftp://updates.redhat.com/6.1/SRPMS/openldap-1.2.9-6.src.rpm

Red Hat Linux 6.2:

intel:
ftp://updates.redhat.com/6.2/i386/openldap-1.2.9-6.i386.rpm

alpha:
ftp://updates.redhat.com/6.2/alpha/openldap-1.2.9-6.alpha.rpm

sparc:
ftp://updates.redhat.com/6.2/sparc/openldap-1.2.9-6.sparc.rpm

sources:
ftp://updates.redhat.com/6.2/SRPMS/openldap-1.2.9-6.src.rpm


9. Verification:

MD5 sum                           Package Name
- --------------------------------------------------------------------------
fa79c61565a72407db4695ef8468a482  6.1/alpha/openldap-1.2.9-6.alpha.rpm
058c4aa63710da7490f98da4b3cad53d  6.1/i386/openldap-1.2.9-6.i386.rpm
17fbdb33172a7884f56b4fc746b1b763  6.1/SRPMS/openldap-1.2.9-6.src.rpm
816fccd85990833f7c5dfb7f2dc6e0a1  6.1/sparc/openldap-1.2.9-6.sparc.rpm
fa79c61565a72407db4695ef8468a482  6.2/alpha/openldap-1.2.9-6.alpha.rpm
816fccd85990833f7c5dfb7f2dc6e0a1  6.2/sparc/openldap-1.2.9-6.sparc.rpm
17fbdb33172a7884f56b4fc746b1b763  6.2/SRPMS/openldap-1.2.9-6.src.rpm
058c4aa63710da7490f98da4b3cad53d  6.2/i386/openldap-1.2.9-6.i386.rpm


These packages are GPG signed by Red Hat, Inc. for security.  Our key
is available at:
    http://www.redhat.com/corp/contact.html

You can verify each package with the following command:
    rpm --checksig  <filename>

If you only wish to verify that each package has not been corrupted or
tampered with, examine only the md5sum with the following command:
    rpm --checksig --nogpg <filename>

10. References:

Thanks also go to Stan Bubrouski for reporting this problem.

Cristian
- --
- ----------------------------------------------------------------------
Cristian Gafton     --     gafton@redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  "How could this be a problem in a country where we have Intel and 
   Microsoft?"  --Al Gore on Y2K

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBOQCeJPGvxKXU9NkBAQFIAgP/fBO8WkawNk6qa2/1y3UO0o0t49xbBXPe
KM6qBojNW8yWKdsfGGgVkgvby/1gH+uFxd49mFNMbG8GUNIxOw8r2MfaQXERnnFb
IQ66mYSH5hesXw6wVnw0aIdnOMfd5BRpEZLXUnhrp+wf+IbtaQE6+g3MbmcoRSk4
jmsdnVhD6iQ=Yz4F
-----END PGP SIGNATURE-----


From mail@mail.redhat.com Apr 15:45:19 2000  -0400
Received: (qmail 9782 invoked from network); 21 Apr 2000 19:45:20 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 21 Apr 2000 19:45:19 -0000
Received: from lacrosse.corp.redhat.com (root@lacrosse.corp.redhat.com
[207.175.42.154])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id PAA10421;
	Fri, 21 Apr 2000 15:45:19 -0400
Received: from localhost (porkchop.redhat.com [207.175.42.68])
	by lacrosse.corp.redhat.com (8.9.3/8.9.3) with SMTP id PAA08885;
	Fri, 21 Apr 2000 15:45:18 -0400
Message-Id: <200004211945.PAA08885@lacrosse.corp.redhat.com>
Subject: [RHSA-2000:016-02] imwheel buffer overflow
Content-transfer-encoding: 8bit
Approved: ewt@redhat.com
To: redhat-watch-list@redhat.com
From: bugzilla@redhat.com
Cc: bugtraq@securityfocus.com, linux-security@redhat.com
Content-type: text/plain; charset="iso-8859-1"
Mime-version: 1.0
Date: Fri, 21 Apr 2000 15:45 -0400

---------------------------------------------------------------------
                   Red Hat, Inc. Security Advisory

Synopsis:          imwheel buffer overflow
Advisory ID:       RHSA-2000:016-02
Issue date:        2000-04-20
Updated on:        2000-04-21
Product:           Red Hat Powertools
Keywords:          imwheel buffer imwheel-solo
Cross references:  N/A
---------------------------------------------------------------------

1. Topic:

A buffer overflow exists in imwheel

2. Relevant releases/architectures:

Red Hat Powertools 6.1 - i386 alpha sparc
Red Hat Powertools 6.2 - i386 alpha sparc


3. Problem description:

A vulnerability exists in the imwheel package where local users can execute
arbitrary commands as root.

4. Solution:

For each RPM for your particular architecture, run:

rpm -Fvh [filename]

where filename is the name of the RPM.

5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info):

N/A

6. Obsoleted by:

N/A

7. Conflicts with:

N/A

8. RPMs required:


Red Hat Powertools 6.1:

intel:
ftp://updates.redhat.com/powertools/6.1/i386/imwheel-0.9.8-1.i386.rpm

alpha:
ftp://updates.redhat.com/powertools/6.1/alpha/imwheel-0.9.8-1.alpha.rpm

sparc:
ftp://updates.redhat.com/powertools/6.1/sparc/imwheel-0.9.8-1.sparc.rpm

sources:
ftp://updates.redhat.com/powertools/6.1/SRPMS/imwheel-0.9.8-1.src.rpm

Red Hat Powertools 6.2:

intel:
ftp://updates.redhat.com/powertools/6.2/i386/imwheel-0.9.8-1.i386.rpm

alpha:
ftp://updates.redhat.com/powertools/6.2/alpha/imwheel-0.9.8-1.alpha.rpm

sparc:
ftp://updates.redhat.com/powertools/6.2/sparc/imwheel-0.9.8-1.sparc.rpm

sources:
ftp://updates.redhat.com/powertools/6.2/SRPMS/imwheel-0.9.8-1.src.rpm


9. Verification:

MD5 sum                           Package Name
--------------------------------------------------------------------------
fa97ae01087560b01ef0c08266e097b5  6.1/sparc/imwheel-0.9.8-1.sparc.rpm
921c50608059cd74840d070e5f538202  6.1/SRPMS/imwheel-0.9.8-1.src.rpm
0350d5be826d54f80948f4a4e9de6101  6.1/i386/imwheel-0.9.8-1.i386.rpm
f1cc900d060fec5546a229f0a7a4d48d  6.1/alpha/imwheel-0.9.8-1.alpha.rpm
fa97ae01087560b01ef0c08266e097b5  6.2/sparc/imwheel-0.9.8-1.sparc.rpm
0350d5be826d54f80948f4a4e9de6101  6.2/i386/imwheel-0.9.8-1.i386.rpm
f1cc900d060fec5546a229f0a7a4d48d  6.2/alpha/imwheel-0.9.8-1.alpha.rpm
921c50608059cd74840d070e5f538202  6.2/SRPMS/imwheel-0.9.8-1.src.rpm


These packages are GPG signed by Red Hat, Inc. for security.  Our key
is available at:
    http://www.redhat.com/corp/contact.html

You can verify each package with the following command:
    rpm --checksig  <filename>

If you only wish to verify that each package has not been corrupted or
tampered with, examine only the md5sum with the following command:
    rpm --checksig --nogpg <filename>

10. References:

http://www.securityfocus.com/vdb/bottom.html?vid=1060




From mail@mail.redhat.com Apr 16:33:40 2000  -0400
Received: (qmail 12403 invoked from network); 24 Apr 2000 20:33:41 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 24 Apr 2000 20:33:41 -0000
Received: from devserv.devel.redhat.com (root@devserv.devel.redhat.com
[207.175.42.156])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id QAA20417;
	Mon, 24 Apr 2000 16:33:40 -0400
Received: from alien.devel.redhat.com (IDENT:gafton@alien.devel.redhat.com
[207.175.42.9])
	by devserv.devel.redhat.com (8.9.3/8.9.3) with ESMTP id QAA08577;
	Mon, 24 Apr 2000 16:33:39 -0400
Date: Mon, 24 Apr 2000 16:33:32 -0400 (EDT)
From: Cristian Gafton <gafton@redhat.com>
X-Sender: gafton@alien.devel.redhat.com
To: redhat-watch-list@redhat.com
cc: Linux Security <linux-security@redhat.com>, BUGTRAQ@SECURITYFOCUS.COM
Subject: SECURITY: [RHSA-2000:014-10] Updated piranha packages available
Message-ID:
<Pine.LNX.4.21.0004241630230.20124-100000@alien.devel.redhat.com>
Approved: ewt@redhat.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-----BEGIN PGP SIGNED MESSAGE-----

- ---------------------------------------------------------------------
                   Red Hat, Inc. Security Advisory

Synopsis:          Piranha web GUI exposure
Advisory ID:       RHSA-2000:014-10
Issue date:        2000-04-18
Updated on:        2000-04-24
Product:           Red Hat Linux
Keywords:          piranha remote CGI command
Cross references:  php
- ---------------------------------------------------------------------

1. Topic:

The GUI portion of Piranha may allow any remote attacker to execute
commands on the server. This may lead to remote compromise of the server,
as well as exposure or defacement of the website.

2. Relevant releases/architectures:

Red Hat Linux 6.2 - i386 alpha sparc

3. Problem description:

Piranha when it is installed generates a 'secure' web interface ID using
the HTML .htaccess method. The information for the account is placed in
/home/httpd/html/piranha/secure/passwords which was supposed to be
released with a blank password. In fact the password that is actually on
the CD is either 'q' or 'piranha'. It was intended that when the
administrator loaded the piranha package onto their box, that it was their
resonsibility to change that password. This is not a hidden account. It is
meerly used to protect the web pages from unauthorized access. The
security problem arises from the
/home/httpd/html/piranha/secure/passwd.php3 file from which it is possible
to execute commands by inserting them into the change password option eg
entering 'blah;/bin/command to execute' into the field, and again to
verify, everything after the semicolon is executed with the same privilege
as the webserver. It is possible at this point to compromise the webserver
or do serious damage to the site.

4. Solution:

For each RPM for your particular architecture, run:

rpm -Fvh [filename]

where filename is the name of the RPM.

Temporarily, you should set a password on the web pages as should be done
when you first install the package for the sake of speed you can issue the
following command htpasswd -c -b /home/httpd/html/piranha/secure/passwords
piranha 'password of choice' In theory, this means only you have access
to
that area and you are hardly likely to try and exploit the problem
yourself.

When you install the update for the piranha-gui, please take a moment to
login into the gui frontend and set a password on the account
(http://localhost/piranha)

5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info):

N/A

6. Obsoleted by:

N/A

7. Conflicts with:

N/A

8. RPMs required:


Red Hat Linux 6.2:

intel:
ftp://updates.redhat.com/6.2/i386/piranha-0.4.13-1.i386.rpm
ftp://updates.redhat.com/6.2/i386/piranha-docs-0.4.13-1.i386.rpm
ftp://updates.redhat.com/6.2/i386/piranha-gui-0.4.13-1.i386.rpm

alpha:
ftp://updates.redhat.com/6.2/alpha/piranha-0.4.13-1.alpha.rpm
ftp://updates.redhat.com/6.2/alpha/piranha-docs-0.4.13-1.alpha.rpm
ftp://updates.redhat.com/6.2/alpha/piranha-gui-0.4.13-1.alpha.rpm

sparc:
ftp://updates.redhat.com/6.2/sparc/piranha-0.4.13-1.sparc.rpm
ftp://updates.redhat.com/6.2/sparc/piranha-docs-0.4.13-1.sparc.rpm
ftp://updates.redhat.com/6.2/sparc/piranha-gui-0.4.13-1.sparc.rpm

sources:
ftp://updates.redhat.com/6.2/SRPMS/piranha-0.4.13-1.src.rpm


9. Verification:

MD5 sum                           Package Name
- --------------------------------------------------------------------------
ece87b0ed6f01a87b954b980c115aec0  6.2/SRPMS/piranha-0.4.13-1.src.rpm
985ff7d09172f4bfcc17c8044bee7fe8  6.2/alpha/piranha-0.4.13-1.alpha.rpm
9804348b4dc73ab82a7624c404afb930  6.2/alpha/piranha-docs-0.4.13-1.alpha.rpm
c1e536a9d14422115a89d2d56bf93926  6.2/alpha/piranha-gui-0.4.13-1.alpha.rpm
f2db6f165f21f93e9b724a94cd3fc595  6.2/i386/piranha-0.4.13-1.i386.rpm
bd54eb595f2a535e52486e799715ce00  6.2/i386/piranha-docs-0.4.13-1.i386.rpm
ad9fb552616a221db26b92b668211a30  6.2/i386/piranha-gui-0.4.13-1.i386.rpm
b9cb5cddd6e0cd99fc47eb56a06319a0  6.2/sparc/piranha-0.4.13-1.sparc.rpm
98313aa873dffe9c0520e3ad4862f2f5  6.2/sparc/piranha-docs-0.4.13-1.sparc.rpm
06cdba77a7f128e48a7c3d15c0cf9bcc  6.2/sparc/piranha-gui-0.4.13-1.sparc.rpm


These packages are GPG signed by Red Hat, Inc. for security.  Our key
is available at:
    http://www.redhat.com/corp/contact.html

You can verify each package with the following command:
    rpm --checksig  <filename>

If you only wish to verify that each package has not been corrupted or
tampered with, examine only the md5sum with the following command:
    rpm --checksig --nogpg <filename>

10. References:

This vulnerability was discovered and researched by Allen Wilson and Dan
Ingevaldson of Internet Security Systems. Red Hat would like to thank ISS
for the assistance in getting this problem fixed quickly.

Cristian
- --
- ----------------------------------------------------------------------
Cristian Gafton     --     gafton@redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  "How could this be a problem in a country where we have Intel and 
   Microsoft?"  --Al Gore on Y2K

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBOQSvofGvxKXU9NkBAQHwHQP/efMrg4JQGhU9iBMenU9ldu3bgX+uTNJN
phgVVZ11OsbTYw0OOLHT0uoWtxiTouaE9dYtAHsioOONro1guoSrDkL1aJYn8GdZ
Z4h8iSi+RlfgEFcfvkI5onllcwWkZeevv68qa4GwQBPPXEbNUGiR4KBTlEsuqUjA
2xhGtjqrKd4=EYh9
-----END PGP SIGNATURE-----


From mail@mail.redhat.com Apr 20:46:56 2000  -0400
Received: (qmail 23332 invoked from network); 27 Apr 2000 00:46:57 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 27 Apr 2000 00:46:57 -0000
Received: from devserv.devel.redhat.com (root@devserv.devel.redhat.com
[207.175.42.156])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id UAA27377;
	Wed, 26 Apr 2000 20:46:56 -0400
Received: from alien.devel.redhat.com (IDENT:gafton@alien.devel.redhat.com
[207.175.42.9])
	by devserv.devel.redhat.com (8.9.3/8.9.3) with ESMTP id UAA30466;
	Wed, 26 Apr 2000 20:46:55 -0400
Date: Wed, 26 Apr 2000 20:46:46 -0400 (EDT)
From: Cristian Gafton <gafton@redhat.com>
X-Sender: gafton@alien.devel.redhat.com
To: redhat-watch-list@redhat.com
cc: BUGTRAQ@SECURITYFOCUS.COM, Linux Security <linux-security@redhat.com>
Subject: SECURITY: UPDATED - RHSA-2000:014 New Piranha release available
Message-ID:
<Pine.LNX.4.21.0004262034030.17807-100000@alien.devel.redhat.com>
Approved: ewt@redhat.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-----BEGIN PGP SIGNED MESSAGE-----

- ---------------------------------------------------------------------
                   Red Hat, Inc. Security Advisory

Synopsis:          Piranha web GUI exposure
Advisory ID:       RHSA-2000:014-16
Issue date:        2000-04-18
Updated on:        2000-04-26
Product:           Red Hat Linux
Keywords:          piranha
Cross references:  php
- ---------------------------------------------------------------------

1. Topic:

The GUI portion of Piranha may allow any remote attacker to execute
commands on the server. This may allow a remote attacker to launch
additional exploits against a web site from inside the web server.

This is an updated release that disables Piranha's web GUI interface
unless the site administrator enables it explicitly.

2. Relevant releases/architectures:

Red Hat Linux 6.2 - i386 alpha sparc

3. Problem description:

When Piranha is installed, it generates a 'secure' web interface ID
using
the HTML .htaccess method. The information for the account is placed in
/home/httpd/html/piranha/secure/passwords which was supposed to be
released with a blank password. Unfortunately, the password that is
actually on the CD is 'Q'.

The original intent was that, when the administrator installed Piranha
rpms onto their box, that they would change the default blank password to
a password of their own choosing.

This is not a hidden account. Its only use is to protect the web pages
from unauthorized access.

The security problem arises from the
http://localhost/piranha/secure/passwd.php3 file. It is possible to
execute commands by entering 'blah;some-command' into the password
fields.
Everything after the semicolon is executed with the same privilege as the
webserver.

Because of this, it is possible to compromise the webserver or do serious
damage to files on the site that are owned by the user 'nobody' or to
export a shell using xterm.

Updated piranha packages released as version 0.14.3-1 fixed the security
vulnerability while still require for the default behavior of requiring
the web administrator to reset the password before making the web site
public.

Because of the security concerns from the community and in order to
protect innocent administrators that might not be aware of the need to
change the password for Piranha's interface before going live on the
Internet, Red Hat is releasing a new set of packages that disable the
piranha web interface by default. The site administrator will have to
enable the service from the command line by resetting the password as
detailed on the main page of the piranha utility.

The new packages that include these changes are known as version
piranha-0.4.14-1.

Users of Red Hat Linux 6.2 are strongly encouraged to upgrade to the new
packages if they are actively using piranha on their system (upgrade
instructions follow) or to remove the piranha-gui package altogether by
issuing the following command:

rpm -e piranha-gui

4. Solution:

For each RPM for your particular architecture, run:

rpm -Fvh [filename]

where filename is the name of the RPM.

When you install the update for the piranha-gui, please take a moment to
review the instructions presented on the following URL
(http://localhost/piranha). This should guide you through the process of
installing a password for use with the GUI.

5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info):

N/A

6. Obsoleted by:

N/A

7. Conflicts with:

N/A

8. RPMs required:


Red Hat Linux 6.2:

intel:
ftp://updates.redhat.com/6.2/i386/piranha-0.4.14-1.i386.rpm
ftp://updates.redhat.com/6.2/i386/piranha-docs-0.4.14-1.i386.rpm
ftp://updates.redhat.com/6.2/i386/piranha-gui-0.4.14-1.i386.rpm

alpha:
ftp://updates.redhat.com/6.2/alpha/piranha-0.4.14-1.alpha.rpm
ftp://updates.redhat.com/6.2/alpha/piranha-docs-0.4.14-1.alpha.rpm
ftp://updates.redhat.com/6.2/alpha/piranha-gui-0.4.14-1.alpha.rpm

sparc:
ftp://updates.redhat.com/6.2/sparc/piranha-0.4.14-1.sparc.rpm
ftp://updates.redhat.com/6.2/sparc/piranha-docs-0.4.14-1.sparc.rpm
ftp://updates.redhat.com/6.2/sparc/piranha-gui-0.4.14-1.sparc.rpm

sources:
ftp://updates.redhat.com/6.2/SRPMS/piranha-0.4.14-1.src.rpm


9. Verification:

MD5 sum                           Package Name
- --------------------------------------------------------------------------
7c9cad243857f3e90cb73457619ad3a0  6.2/SRPMS/piranha-0.4.14-1.src.rpm
179e502f88f149fe3bfb285af851a6d3  6.2/alpha/piranha-0.4.14-1.alpha.rpm
881622bc6403c2af38834c0deaf05d44  6.2/alpha/piranha-docs-0.4.14-1.alpha.rpm
7ffc63ec6f236afc0b19298ec29e6774  6.2/alpha/piranha-gui-0.4.14-1.alpha.rpm
1e04357c0ebb004185b834152667c644  6.2/i386/piranha-0.4.14-1.i386.rpm
5b6649f14979e1b2fbdb763d88e9a3ac  6.2/i386/piranha-docs-0.4.14-1.i386.rpm
1a49816f280dc7a9b83ba9bab42a247f  6.2/i386/piranha-gui-0.4.14-1.i386.rpm
4153b861f030a17745463c1749732b58  6.2/sparc/piranha-0.4.14-1.sparc.rpm
dc964993d9a3b6c967e5c4455bc24221  6.2/sparc/piranha-docs-0.4.14-1.sparc.rpm
97071e07e2f34fecf80ba48f61e70ba6  6.2/sparc/piranha-gui-0.4.14-1.sparc.rpm


These packages are GPG signed by Red Hat, Inc. for security.  Our key
is available at:
    http://www.redhat.com/corp/contact.html

You can verify each package with the following command:
    rpm --checksig  <filename>

If you only wish to verify that each package has not been corrupted or
tampered with, examine only the md5sum with the following command:
    rpm --checksig --nogpg <filename>

10. References:

This vulnerability was discovered and researched by Allen Wilson and Dan
Ingevaldson of Internet Security Systems. Red Hat would like to thank ISS
for the assistance in getting this problem fixed quickly.

Cristian
- --
- ----------------------------------------------------------------------
Cristian Gafton     --     gafton@redhat.com      --     Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  "How could this be a problem in a country where we have Intel and 
   Microsoft?"  --Al Gore on Y2K


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBOQeN/fGvxKXU9NkBAQE7LwP/QnZL0RAfs5odNDee0htT3pxp8IxefuzY
jg8aedrbqkbZHzUflaGsFZN1KlXXwpelQ1kO9ro2YAewDvOVRgUFZyEM0gOIRpaJ
mAK3cgQageGG09Gg58X+Ov+3AD64R89ufv30YFakrblRYYCLmvZRn4e2zE97DgZM
Qk5LS0w9ZoM=lrT3
-----END PGP SIGNATURE-----
Possibly Parallel Threads

Search for more apparently analagous threads
linux security - Mar 2000 - Re: IPMASQ and lock-up of all terminals ---- Sum mary and update

[linux-security] Re: IPMASQ and lock-up of all terminals ---- Sum mary and update

Possibly Parallel Threads

Wisdom of the Ancients
