wulfman wrote:
> After the recent attacks on the major servers on the web my ISP has
> decided to stop all ICMP messages from his ISP.
>
> I have red the RFCs and it seems that he cant do that... As a result
> pings and traceroutes will not work.
Having ping's and traceroutes not working isn't all that horrible.
Stopping the destination unreachable (fragmentation need) ICMP message is
as it will break MTU discovery.
To a network I want relatively secure I've blocked:
echo-requests inbound (ping)
time-exceeded outbound (traceroute)
redirect inbound (could be nasty)
Everything else comes through. I did the first two to stop people learning
more then they need to about the network and the last to stop someone
fooling a machine in to routing packets somewhere it shouldn't.
If anyone out there knows better then I and can suggest other things I
should be blocking or give good reason why I shouldn't block some of these
I'm always willing to learn more.
Jon
[mod: P.S. in a previous message I noted that UUNET-NL was filtering
ICMP. I was wrong: From the discussion that followed I learned that it
was the other end of the pipe, my ISP, that was recklessly filtering
ICMP. -- REW]
--
Jonathan Benson
Systems Administrator
Ocean Internet
http://www.ocean.com.au/
From mail@mail.redhat.com Thu Mar 2 10:29:17 2000
Received: (qmail 1215 invoked from network); 2 Mar 2000 15:29:25 -0000
Received: from mail.redhat.com (199.183.24.239)
by lists.redhat.com with SMTP; 2 Mar 2000 15:29:25 -0000
Received: from rosie.bitwizard.nl (14dyn97.delft.casema.net [212.64.77.97])
by mail.redhat.com (8.8.7/8.8.7) with ESMTP id KAA03972
for <linux-security@redhat.com>; Thu, 2 Mar 2000 10:29:17 -0500
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 QAA08249
for <linux-security@redhat.com>; Thu, 2 Mar 2000 16:29:14 +0100
Received: (from wolff@localhost)
by cave.bitwizard.nl (8.9.3/8.9.3) id QAA00574
for linux-security@redhat.com; Thu, 2 Mar 2000 16:29:12 +0100
Approved: R.E.Wolff@BitWizard.nl
Received: (qmail 31830 invoked by alias); 2 Mar 2000 11:56:22 -0000
Received: (qmail 31827 invoked from network); 2 Mar 2000 11:56:21 -0000
Received: from lists.redhat.com (199.183.24.247)
by www.bitwizard.nl with SMTP; 2 Mar 2000 11:56:21 -0000
Received: (qmail 7385 invoked by uid 501); 2 Mar 2000 11:56:20 -0000
Received: (qmail 7372 invoked from network); 2 Mar 2000 11:56:20 -0000
Received: from mail.redhat.com (199.183.24.239)
by lists.redhat.com with SMTP; 2 Mar 2000 11:56:20 -0000
Received: from janeway.cistron.net (root@janeway.cistron.net [195.64.65.23])
by mail.redhat.com (8.8.7/8.8.7) with ESMTP id GAA24883
for <linux-security@redhat.com>; Thu, 2 Mar 2000 06:56:19 -0500
Received: from subspace.cistron-internet.nl (root@subspace.cistron-internet.nl
[195.64.65.200])
by janeway.cistron.net (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id MAA03588
for <linux-security@redhat.com>; Thu, 2 Mar 2000 12:56:18 +0100
Received: (from miquels@localhost)
by subspace.cistron-internet.nl (8.9.3/8.9.3/Debian 8.9.3-6) id MAA32200
for linux-security@redhat.com; Thu, 2 Mar 2000 12:56:18 +0100
Date: Thu, 2 Mar 2000 12:56:17 +0100
From: Miquel van Smoorenburg <miquels@cistron.nl>
To: "linux-security@redhat.com" <linux-security@redhat.com>
Subject: [linux-security] Re: ICMP
Message-ID: <20000302125617.A32178@cistron.nl>
References: <38BB4867.3770A005@wulfman.com>
<Pine.LNX.4.10.10002290823130.6383-100000@bastion.hugo.vanderkooij.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To:
<Pine.LNX.4.10.10002290823130.6383-100000@bastion.hugo.vanderkooij.org>;
from Hugo.van.der.Kooij@caiw.nl on Tue, Feb 29, 2000 at 08:30:45AM +0100
X-NCC-RegID: nl.cistron
> breaking e.g. path MTU discovery. -- REW]
This is a good URL to refer clueless administrators to:
Path MTU Discovery and Filtering ICMP
http://www.worldgate.com/~marcs/mtu/
Mike.
--
"dhbgr zr ba guvf bar - biretnna bc Rkpunatr vf rra jvwf orfyhvg" --
ZnepbU.
(punatrq gb ebg13 nsgre frireny frevbhfyl fbhaqvat guerngf).
From mail@mail.redhat.com Fri Mar 3 02:38:57 2000
Received: (qmail 16767 invoked from network); 3 Mar 2000 07:39:03 -0000
Received: from mail.redhat.com (199.183.24.239)
by lists.redhat.com with SMTP; 3 Mar 2000 07:39:03 -0000
Received: from rosie.bitwizard.nl (14dyn65.delft.casema.net [212.64.77.65])
by mail.redhat.com (8.8.7/8.8.7) with ESMTP id CAA06168
for <linux-security@redhat.com>; Fri, 3 Mar 2000 02:38:57 -0500
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 IAA13752
for <linux-security@redhat.com>; Fri, 3 Mar 2000 08:38:55 +0100
Received: (from wolff@localhost)
by cave.bitwizard.nl (8.9.3/8.9.3) id IAA26099
for linux-security@redhat.com; Fri, 3 Mar 2000 08:38:54 +0100
Approved: R.E.Wolff@BitWizard.nl
Received: (qmail 7927 invoked by alias); 3 Mar 2000 00:31:42 -0000
Received: (qmail 7924 invoked from network); 3 Mar 2000 00:31:42 -0000
Received: from lists.redhat.com (199.183.24.247)
by www.bitwizard.nl with SMTP; 3 Mar 2000 00:31:42 -0000
Received: (qmail 51 invoked by uid 501); 3 Mar 2000 00:05:06 -0000
Received: (qmail 36 invoked from network); 3 Mar 2000 00:05:05 -0000
Received: from mail.redhat.com (199.183.24.239)
by lists.redhat.com with SMTP; 3 Mar 2000 00:05:05 -0000
Received: from mail.ocean.com.au (mail.ocean.com.au [203.12.234.40])
by mail.redhat.com (8.8.7/8.8.7) with ESMTP id TAA17514
for <linux-security@redhat.com>; Thu, 2 Mar 2000 19:05:03 -0500
Received: from ocean.com.au (orpheus.ocean.com.au [203.12.234.232])
by mail.ocean.com.au (8.9.3/8.9.3) with ESMTP id LAA24043;
Fri, 3 Mar 2000 11:04:53 +1100
Sender: hardware@mail.ocean.com.au
Message-ID: <38BF01A5.88F8B4AD@ocean.com.au>
Date: Fri, 03 Mar 2000 11:04:53 +1100
From: Jonathan Benson <sysadmin@ocean.com.au>
Organization: Ocean Internet
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-security@redhat.com
CC: shawn.m@microcore.net
Subject: ICMP & IPCHAINS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To all those that wanted to know how I was filtering particular
ICMP packets here is a few snippets from my firewall script which is
based on one by Ian Hall-Beyer. I hope this helps you get started.
Also note the output of the command:
ipchains -h icmp
Shawn Mitchell mentioned blocking all ICMP echos and especially
broadcast echos. Perhaps he'd care to elaborate with a similar
example? I believe he means inbound replys to stop someone spoofing
your IP and then flooding your network with ICMP replies?
Whilst I'm mentioning these sorts of things, one thing you should ALL be
doing at your firewalls is dropping packets that can't have originated
from inside your network or shouldn't be allowed out (eg the 10.0.0.0/8
subnet, etc) to stop spoofing and indeed inbound packets that could only
have originated from inside your network.
If all routers/firewalls did this spoofing would be a thing of the
past. A nice thought but not likely to happen.
Anyway, here's the bits of my script:
#!/bin/sh
# ----------------------------------------------------------------
Interfaces -
# External Interface
# This is the interface that is your link to the world
EXTERNIF="eth0"
# Internal Interface
# This is the interface to your LAN
INTERNIF="eth1"
# Secured Interface
# This is the interface you want secured
SECUREIF="eth2"
# ------------------------------------------------------- Variable
definition -
#
# Set the location of ipchains.
IPCHAINS="/sbin/ipchains"
IFCONFIG="/sbin/ifconfig"
# You shouldn't need to change anything in the rest of this section
EXTERNIP=`$IFCONFIG $EXTERNIF | grep inet | cut -d : -f 2 | cut -d \ -f
1`
EXTERNMASK=`$IFCONFIG $EXTERNIF | grep Mask | cut -d : -f 4`
EXTERNNET="$EXTERNIP/$EXTERNMASK"
echo "Extern NET: $EXTERNNET"
INTERNIP=`$IFCONFIG $INTERNIF | grep inet | cut -d : -f 2 | cut -d \ -f
1`
INTERNMASK=`$IFCONFIG $INTERNIF | grep Mask | cut -d : -f 4`
INTERNNET="$INTERNIP/$INTERNMASK"
echo "Intern NET: $INTERNNET"
SECUREIP=`$IFCONFIG $SECUREIF | grep inet | cut -d : -f 2 | cut -d \ -f
1`
SECUREMASK=`$IFCONFIG $SECUREIF | grep Mask | cut -d : -f 4`
SECURENET="$SECUREIP/$SECUREMASK"
echo "Secure NET: $SECURENET"
ANYNET="0.0.0.0/0"
# -------------------------------------- Flush everything, start from
scratch -
echo -n "Flushing rulesets.."
# Incoming packets from the outside network
$IPCHAINS -F input
echo -n "."
# Outgoing packets from the internal network
$IPCHAINS -F output
echo -n "."
echo "Done!"
# -------------------------------------------------- Allow loopback
interface -
echo -n "Loopback.."
$IPCHAINS -A input -i lo -s $ANYNET -d $ANYNET -j ACCEPT
$IPCHAINS -A output -i lo -s $ANYNET -d $ANYNET -j ACCEPT
echo -n ".."
echo "Done!"
# ----------------------------------------------------------------------
ICMP -
echo -n "ICMP Rules.."
# Use this to deny ICMP attacks from specific addresses
# $IPCHAINS -A input -b -i $EXTERNALIF -p icmp -s <address> -d $ANYNET
-j DENY
# echo -n "."
# Only allows certain ICMP to the Secure network
$IPCHAINS -A input -p icmp -s $INTERNNET -d $SECURENET -j ACCEPT
# Blocks 'pings' from external sources
$IPCHAINS -A input -p icmp -s $EXTERNNET echo-request -d $SECURENET -j
DENY
# Blocks traceroutes (or the response to them)
$IPCHAINS -A output -p icmp -s $SECURENET time-exceeded -d $INTERNNET -j
ACCEPT
$IPCHAINS -A output -p icmp -s $SECURENET time-exceeded -d $EXTERNNET -j
DENY
# Block redirects from entering the Secure network
$IPCHAINS -A input -p icmp -s $EXTERNNET redirect -d $SECURENET -j DENY
# Allow all ICMP
$IPCHAINS -A input -p icmp -s $ANYNET -d $ANYNET -j ACCEPT
echo -n ".."
echo "Done!"
--
Jonathan Benson
Systems Administrator
Ocean Internet
http://www.ocean.com.au/
From mail@mail.redhat.com Fri Mar 3 02:53:54 2000
Received: (qmail 472 invoked from network); 3 Mar 2000 07:53:58 -0000
Received: from mail.redhat.com (199.183.24.239)
by lists.redhat.com with SMTP; 3 Mar 2000 07:53:58 -0000
Received: from rosie.bitwizard.nl (14dyn65.delft.casema.net [212.64.77.65])
by mail.redhat.com (8.8.7/8.8.7) with ESMTP id CAA06761
for <linux-security@redhat.com>; Fri, 3 Mar 2000 02:53:54 -0500
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 IAA13843
for <linux-security@redhat.com>; Fri, 3 Mar 2000 08:53:52 +0100
Received: (from wolff@localhost)
by cave.bitwizard.nl (8.9.3/8.9.3) id IAA26497
for linux-security@redhat.com; Fri, 3 Mar 2000 08:53:51 +0100
Approved: R.E.Wolff@BitWizard.nl
Received: (qmail 8660 invoked by alias); 3 Mar 2000 01:40:00 -0000
Received: (qmail 8656 invoked from network); 3 Mar 2000 01:39:59 -0000
Received: from lists.redhat.com (199.183.24.247)
by www.bitwizard.nl with SMTP; 3 Mar 2000 01:39:59 -0000
Received: (qmail 6822 invoked by uid 501); 3 Mar 2000 01:36:36 -0000
Received: (qmail 6800 invoked from network); 3 Mar 2000 01:36:35 -0000
Received: from mail.redhat.com (199.183.24.239)
by lists.redhat.com with SMTP; 3 Mar 2000 01:36:35 -0000
Received: from washu.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 UAA24371
for <linux-security@redhat.com>; Thu, 2 Mar 2000 20:36:34 -0500
Received: from zblaxell by washu.furryterror.org with local (Exim 3.12 #1
(Debian))
id 12Qh0m-0006h9-00; Thu, 02 Mar 2000 20:36:12 -0500
To: sysadmin@ocean.com.au, wulfman <wulfman@wulfman.com>
Cc: "linux-security@redhat.com" <linux-security@redhat.com>
Subject: [linux-security] Re: ICMP
In-Reply-To: <38BC7B4C.832F9841@ocean.com.au>
References: <38BB4867.3770A005@wulfman.com>
<38BC7B4C.832F9841@ocean.com.au>
Message-Id: <E12Qh0m-0006h9-00@washu.furryterror.org>
From: Zygo Blaxell <zblaxell@washu.furryterror.org>
Date: Thu, 02 Mar 2000 20:36:12 -0500
In security.redhat.linux-security, you wrote:>To a network I want relatively secure I've blocked:
>echo-requests inbound (ping)
>time-exceeded outbound (traceroute)
>redirect inbound (could be nasty)
>
>Everything else comes through. I did the first two to stop people learning
>more then they need to about the network and the last to stop someone
>fooling a machine in to routing packets somewhere it shouldn't.
I've used ISP's that have somewhat haphazard router configurations
where ICMP redirects are necessary. In this case the ISP is configuring
client machines to use an "advertised" router as the default gateway,
when in fact multiple routes separated by subnet are necessary. The ISP
configures routing properly on the "advertised" router, and relies on
the router to send every client machine ICMP redirects to the "real"
routers that will actually forward the traffic to the right places.
If you block ICMP redirect from this particular ISP, you will lose
Internet access unless you phone them often to keep up with their network
configuration of the month.
Try to avoid this sort of ISP if you can. ;-)
In Linux 2.2, the ICMP redirect messages create entries in the route
cache. From a security point of view, it's similar to ARP cache for
Ethernet, except for a few minor differences--packet format, timeouts,
and sequence of events in the protocol--the semantics are similar enough
to consider one to be a superset of the other for security purposes.
If you're in a situation where you're on Ethernet (switched or not)
shared
with someone you don't trust, don't worry about ICMP redirect spoofing
until you've first solved the MAC/ARP spoofing problem. Once you've
done
that, then you can meaningfully block incoming ICMP redirects. As ugly
as it sounds, more and more Internet feeds (even commercial ones) are
popping up with wide-area switched Ethernet somewhere at the ISP's site
due to the popularity and resulting cheapness of *DSL and cable modems.
ICMP redirect can only be effectively used to redirect traffic to a
different gateway on the same subnet, or to a different subnet attached
to your machine (and that might be subject to some sanity checking in
the kernel to prevent exactly that kind of abuse). IIRC (I apologize
if I get this wrong, but I'm waiting for my Internet feed to come back
up as I write this so I can't easily consult an RFC near me ;-) ICMP
redirects are not supposed to be forwarded, and even if they were,
they don't make a lot of sense when they are.
ICMP redirect to a different interface on your machine can be contained
by using ipchains on output rules to block packets with the wrong source
or destination addresses. I configure ipchains to block source or
destination addresses that I use on my private networks on all network
interfaces connected to the Internet. If, for any reason, packets are
redirected from the private side interface to the public Internet, they
won't get past the firewall. This converts a potential confidentiality
breach or IP spoofing attack into a simple denial of service.
Here's some common configurations and what an attacker can get if
the attacker can cause your machine to send data to the wrong host on
a subnet:
1. ISP gives you a router and a subnet. The router has one IP in that
subnet, and all the other IP's are yours. Here, ICMP redirect can only
be used to direct traffic from one of your hosts to another...and the
other host will just send an ICMP redirect back to correct the error. ;-)
2. ISP gives you a router and a single point-to-point address (e.g. a
PPP-based connection). ICMP redirect here is useless, since all possible
outgoing routes will go to your point-to-point peer, which will consult
its own routing table to process them.
3. ISP gives you a box that emulates switched Ethernet. Attacker can
redirect packets to any IP address on the switched Ethernet, possibly
including machines controlled by your attacker. See above about MAC/ARP
spoofing.
--
OpenPGP email preferred at <zblaxell@feedme.hungrycats.org>.
OpenPGP key available on www.keyserver.net and other fine keyservers.
OpenPGP fingerprint: 2B32 546D 21A5 0DB2 20C8 AF10 1D4A 610E 6972 2DEE
From mail@mail.redhat.com Mar 21:01:39 2000 -0500
Received: (qmail 10083 invoked from network); 7 Mar 2000 02:01:39 -0000
Received: from mail.redhat.com (199.183.24.239)
by lists.redhat.com with SMTP; 7 Mar 2000 02:01:39 -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 VAA30816;
Mon, 6 Mar 2000 21:01:39 -0500
Received: from localhost (porkchop.redhat.com [207.175.42.68])
by lacrosse.corp.redhat.com (8.9.3/8.9.3) with SMTP id VAA04220;
Mon, 6 Mar 2000 21:01:39 -0500
Message-Id: <200003070201.VAA04220@lacrosse.corp.redhat.com>
Subject: [RHSA-2000:006-01] New nmh packages available
Content-transfer-encoding: 8bit
Approved: gafton@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: Mon, 6 Mar 2000 20:59 -0500
---------------------------------------------------------------------
Red Hat, Inc. Security Advisory
Synopsis: New nmh packages available
Advisory ID: RHSA-2000:006-01
Issue date: 2000-03-06
Updated on: 2000-03-06
Product: Red Hat Linux
Keywords: nmh mime mhshow
Cross references: N/A
---------------------------------------------------------------------
1. Topic:
New nmh packages are available to fix a security problem in
mime header parsing.
2. Relevant releases/architectures:
Red Hat Linux 5.2 - i386 alpha sparc
Red Hat Linux 6.0 - i386 alpha sparc
Red Hat Linux 6.1 - i386 alpha sparc
3. Problem description:
By creating specially formed MIME headers, it was possible
to have nmh's 'mhshow' utility execute arbitrary shell code.
It is recommended that all users of nmh upgrade to the fixed
packages.
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):
9921 - security bug in nmh
6. Obsoleted by:
N/A
7. Conflicts with:
N/A
8. RPMs required:
Red Hat Linux 5.2:
intel:
ftp://updates.redhat.com/5.2/i386/nmh-1.0.3-5x.i386.rpm
alpha:
ftp://updates.redhat.com/5.2/alpha/nmh-1.0.3-5x.alpha.rpm
sparc:
ftp://updates.redhat.com/5.2/sparc/nmh-1.0.3-5x.sparc.rpm
sources:
ftp://updates.redhat.com/5.2/SRPMS/nmh-1.0.3-5x.src.rpm
Red Hat Linux 6.0:
intel:
ftp://updates.redhat.com/6.0/i386/nmh-1.0.3-6x.i386.rpm
alpha:
ftp://updates.redhat.com/6.0/alpha/nmh-1.0.3-6x.alpha.rpm
sparc:
ftp://updates.redhat.com/6.0/sparc/nmh-1.0.3-6x.sparc.rpm
sources:
ftp://updates.redhat.com/6.0/SRPMS/nmh-1.0.3-6x.src.rpm
Red Hat Linux 6.1:
intel:
ftp://updates.redhat.com/6.1/i386/nmh-1.0.3-6x.i386.rpm
alpha:
ftp://updates.redhat.com/6.1/alpha/nmh-1.0.3-6x.alpha.rpm
sparc:
ftp://updates.redhat.com/6.1/sparc/nmh-1.0.3-6x.sparc.rpm
sources:
ftp://updates.redhat.com/6.1/SRPMS/nmh-1.0.3-6x.src.rpm
9. Verification:
MD5 sum Package Name
--------------------------------------------------------------------------
158d9ce6bcbc130fdcc069218440c14e 6.0/alpha/nmh-1.0.3-6x.alpha.rpm
34ff509708a6878e9b58b5ed98cb27df 5.2/alpha/nmh-1.0.3-5x.alpha.rpm
158d9ce6bcbc130fdcc069218440c14e 6.1/alpha/nmh-1.0.3-6x.alpha.rpm
829927f436bab62a4a6b3e9ba0b8ab36 6.0/SRPMS/nmh-1.0.3-6x.src.rpm
383e55c58bea25d6fa73216e86fc27ba 5.2/SRPMS/nmh-1.0.3-5x.src.rpm
829927f436bab62a4a6b3e9ba0b8ab36 6.1/SRPMS/nmh-1.0.3-6x.src.rpm
ca6a19156b88516362e9404b8ac8fd06 5.2/sparc/nmh-1.0.3-5x.sparc.rpm
59a31706a3747717e6aaec9c5f1b3122 6.0/sparc/nmh-1.0.3-6x.sparc.rpm
59a31706a3747717e6aaec9c5f1b3122 6.1/sparc/nmh-1.0.3-6x.sparc.rpm
5633c3097e0f6503615957778d572b52 5.2/i386/nmh-1.0.3-5x.i386.rpm
272c5a8bbdd1c6b7ed60595cf4521d01 6.0/i386/nmh-1.0.3-6x.i386.rpm
272c5a8bbdd1c6b7ed60595cf4521d01 6.1/i386/nmh-1.0.3-6x.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:
N/A
From mail@mail.redhat.com Mar 11:41:44 2000 -0500
Received: (qmail 12127 invoked from network); 30 Mar 2000 16:41:44 -0000
Received: from mail.redhat.com (199.183.24.239)
by lists.redhat.com with SMTP; 30 Mar 2000 16:41:44 -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 LAA19301;
Thu, 30 Mar 2000 11:41:44 -0500
Received: from localhost (porkchop.redhat.com [207.175.42.68])
by lacrosse.corp.redhat.com (8.9.3/8.9.3) with SMTP id LAA30849;
Thu, 30 Mar 2000 11:41:44 -0500
Message-Id: <200003301641.LAA30849@lacrosse.corp.redhat.com>
Subject: [RHSA-2000:008-01] ircii buffer overflow
Content-transfer-encoding: 8bit
Approved: ewt@redhat.com
To: redhat-watch-list@redhat.com
From: bugzilla@redhat.com
Cc: linux-security@redhat.com, bugtraq@securityfocus.com
Content-type: text/plain; charset="iso-8859-1"
Mime-version: 1.0
Date: Thu, 30 Mar 2000 11:41 -0500
---------------------------------------------------------------------
Red Hat, Inc. Security Advisory
Synopsis: ircii buffer overflow
Advisory ID: RHSA-2000:008-01
Issue date: 2000-03-29
Updated on: 2000-03-29
Product: Red Hat Linux
Keywords: N/A
Cross references: ircii 4.4M buffer dcc
---------------------------------------------------------------------
1. Topic:
A buffer overflow exists in ircii,
2. Relevant releases/architectures:
Red Hat Linux 4.2 - i386 alpha sparc
Red Hat Linux 5.2 - i386 alpha sparc
Red Hat Linux 6.0 - i386 alpha sparc
Red Hat Linux 6.1 - i386 alpha sparc
Red Hat Linux 6.2 - i386 sparc
3. Problem description:
A buffer overflow exists in ircii's dcc chat capability.
An attacker could use this overflow to execute code
as the user of ircii.
It is recommended that users of ircii update to the
fixed pacakges:
Compatibility note: ircii's library directory has
moved from /usr/lib/irc to /usr/share/irc.
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):
10339 - ircii overflow bug. please upgrade ircii. again.
6. Obsoleted by:
N/A
7. Conflicts with:
N/A
8. RPMs required:
Red Hat Linux 4.2:
intel:
ftp://updates.redhat.com/4.2/i386/ircii-4.4M-0.4.2.i386.rpm
alpha:
ftp://updates.redhat.com/4.2/alpha/ircii-4.4M-0.4.2.alpha.rpm
sparc:
ftp://updates.redhat.com/4.2/sparc/ircii-4.4M-0.4.2.sparc.rpm
sources:
ftp://updates.redhat.com/4.2/SRPMS/ircii-4.4M-0.4.2.src.rpm
Red Hat Linux 5.2:
intel:
ftp://updates.redhat.com/5.2/i386/ircii-4.4M-0.5.2.i386.rpm
alpha:
ftp://updates.redhat.com/5.2/alpha/ircii-4.4M-0.5.2.alpha.rpm
sparc:
ftp://updates.redhat.com/5.2/sparc/ircii-4.4M-0.5.2.sparc.rpm
sources:
ftp://updates.redhat.com/5.2/SRPMS/ircii-4.4M-0.5.2.src.rpm
Red Hat Linux 6.2:
intel:
ftp://updates.redhat.com/6.2/i386/ircii-4.4M-1.i386.rpm
sparc:
ftp://updates.redhat.com/6.2/sparc/ircii-4.4M-1.sparc.rpm
sources:
ftp://updates.redhat.com/6.2/SRPMS/ircii-4.4M-1.src.rpm
9. Verification:
MD5 sum Package Name
--------------------------------------------------------------------------
e9cb2195648bf1cc55e00b28f98b090e 5.2/sparc/ircii-4.4M-0.5.2.sparc.rpm
73c9eb162c48a162c2f5ef8c625fba53 4.2/i386/ircii-4.4M-0.4.2.i386.rpm
e44491fe29858c1884196a0cd40fc60d 6.2/i386/ircii-4.4M-1.i386.rpm
324779062a29903f3c2fff581c620425 5.2/i386/ircii-4.4M-0.5.2.i386.rpm
dfed6e42c23064d6b6af88b83c45d67d 4.2/alpha/ircii-4.4M-0.4.2.alpha.rpm
122d90adde4e18db9f7c69143a4334e1 4.2/SRPMS/ircii-4.4M-0.4.2.src.rpm
95c765b3fb7c76dc7d2de1fe1853e3ca 6.2/SRPMS/ircii-4.4M-1.src.rpm
ca748c0df16cda0de83c21b53eb48351 5.2/alpha/ircii-4.4M-0.5.2.alpha.rpm
a14830ab1d939150e7cb38ab57eecfed 5.2/SRPMS/ircii-4.4M-0.5.2.src.rpm
be7db62bbab9c34801f7c1e08983f34e 4.2/sparc/ircii-4.4M-0.4.2.sparc.rpm
a759d5ea66514b4e12e59a8c173d65d9 6.2/sparc/ircii-4.4M-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:
http://www.securityfocus.com/vdb/bottom.html?vid=1046