You probably know this already, but the following notice appeared to bugtraq. As a side note the protocol on bugtraq seems to be designed to make a fix available before the announcement by providing one yourself or giving the maintainer a week's advance warning (M$ gets a lot longer warning and *still* fails to fix the bugs before bugtraq knows). Having said that M$ insists on allowing me to source route that packet from 127.0.0.1 via my (evil) machine in Australia (which forged the packet and gets a chance to forge a reply, despite the fact that the NT server should know about the forgery) and this has been the case for several years (no fix yet, someone might get around to doing something by NT 9 with a following wind). Before you ask M$ "tech support" can be clueless enough never to have heard of IP source routing... (which also has other cool features, like falsification of recipients to bypass firewalls). Naturally there is no CERT announcement due the lack of any action. Duncan (-: ------- Forwarded Message>From owner-bugtraq@NETSPACE.ORG Sun Jul 19 13:08:00 1998Received: from io.stargate.co.uk (root@io.stargate.co.uk [192.168.1.1]) by io.stargate.co.uk (8.8.8/8.7.3) with ESMTP id NAA26050 for <dps@IO.STARGATE.CO.UK>; Sun, 19 Jul 1998 13:07:59 +0100 Received: from mail1.astra.co.uk by io.stargate.co.uk (fetchmail-4.3.7 IMAP) for <dps@IO.STARGATE.CO.UK@io.stargate.co.uk> (multi-drop); Sun, 19 Jul 1998 13:07:59 BST Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143]) by mail1.astra.co.uk (8.8.8/8.8.8) with ESMTP id UAA13568 for <dps@IO.STARGATE.CO.UK>; Sat, 18 Jul 1998 20:18:33 GMT Received: from unknown@netspace.org (port 9824 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <96620-2227>; Sat, 18 Jul 1998 16:13:52 -0400 Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 1878416 for BUGTRAQ@NETSPACE.ORG; Sat, 18 Jul 1998 16:01:02 -0400 Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143]) by netspace.org (8.8.7/8.8.7) with ESMTP id QAA07416 for <BUGTRAQ@NETSPACE.ORG>; Sat, 18 Jul 1998 16:00:10 -0400 Received: from unknown@netspace.org (port 9824 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <81164-2225>; Sat, 18 Jul 1998 16:02:16 -0400 Approved-By: aleph1@DFW.NET Received: from ANARCHY.MAXHO.COM (ANARCHY.MAXHO.COM [206.20.110.150]) by netspace.org (8.8.7/8.8.7) with ESMTP id XAA25501 for <bugtraq@netspace.org>; Thu, 16 Jul 1998 23:26:59 -0400 Received: from localhost (twiztah@localhost) by ANARCHY.MAXHO.COM (8.9.0/8.8.7) with SMTP id XAA00531 for <bugtraq@netspace.org>; Thu, 16 Jul 1998 23:25:45 -0400 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <Pine.LNX.3.96.980716232434.414A-100000@ANARCHY.MAXHO.COM> Date: Thu, 16 Jul 1998 23:25:45 -0400 Reply-To: twiztah <twiztah@ANARCHY.MAXHO.COM> Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG> From: twiztah <twiztah@ANARCHY.MAXHO.COM> Subject: SECURITY: imap-4.1.final now available To: BUGTRAQ@NETSPACE.ORG - ---[another forward from redhat.com's security mailing list]--- Serious security problems have been found in all versions of IMAP shipped with Red Hat Linux. If you have enable the IMAP server on your workstation (you have to edit /etc/inetd.conf to do this; if you have never done this, you are not vulnerable to these problems), please upgrade to these new IMAP releases immediately. Thanks to everyone who helped find these problem, Olaf Kirch in particular. Red Hat 5.0 and 5.1 - - ------------------- i386: rpm -Uvh ftp://ftp.redhat.com/updates/5.0/i386/imap-4.1.final-1.i386.rpm alpha: rpm -Uvh ftp://ftp.redhat.com/updates/5.0/alpha/imap-4.1.final-1.alpha.rpm SPARC: rpm -Uvh ftp://ftp.redhat.com/updates/5.0/sparc/imap-4.1.final-1.sparc.rpm Red Hat 4.2 - - ------------- i386: rpm -Uvh ftp://ftp.redhat.com/updates/4.2/i386/imap-4.1.final-0.i386.rpm alpha: rpm -Uvh ftp://ftp.redhat.com/updates/4.2/alpha/imap-4.1.final-0.alpha.rpm SPARC: rpm -Uvh ftp://ftp.redhat.com/updates/4.2/sparc/imap-4.1.final-0.sparc.rpm ------- End of Forwarded Message -- Duncan (-: "software industry, the: unique industry where selling substandard goods is legal and you can charge extra for fixing the problems."
Please take note that the security announcement below has been amended. You *are* vulnerable if you simply have "imap" installed. You do not need to have edited /etc/inetd.conf. That is, the stock /etc/inetd.conf *does* have imap support turned on by default. If you have "imap" installed you should uninstall it or upgrade to the update IMMEDIATELY.> You probably know this already, but the following notice appeared to bugtraq. > > ------- Forwarded Message > > Date: Thu, 16 Jul 1998 23:25:45 -0400 > Reply-To: twiztah <twiztah@ANARCHY.MAXHO.COM> > Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG> > From: twiztah <twiztah@ANARCHY.MAXHO.COM> > Subject: SECURITY: imap-4.1.final now available > To: BUGTRAQ@NETSPACE.ORG > > - ---[another forward from redhat.com's security mailing list]--- > > Serious security problems have been found in all versions of IMAP shipped > with Red Hat Linux. If you have enable the IMAP server on your workstation > (you have to edit /etc/inetd.conf to do this; if you have never done this, > you are not vulnerable to these problems), please upgrade to these > new IMAP releases immediately. > > Thanks to everyone who helped find these problem, Olaf Kirch in particular. > > Red Hat 5.0 and 5.1 > - - ------------------- > > i386: > rpm -Uvh ftp://ftp.redhat.com/updates/5.0/i386/imap-4.1.final-1.i386.rpm > > alpha: > rpm -Uvh ftp://ftp.redhat.com/updates/5.0/alpha/imap-4.1.final-1.alpha.rpm > > SPARC: > rpm -Uvh ftp://ftp.redhat.com/updates/5.0/sparc/imap-4.1.final-1.sparc.rpm > > Red Hat 4.2 > - - ------------- > > i386: > rpm -Uvh ftp://ftp.redhat.com/updates/4.2/i386/imap-4.1.final-0.i386.rpm > > alpha: > rpm -Uvh ftp://ftp.redhat.com/updates/4.2/alpha/imap-4.1.final-0.alpha.rpm > > SPARC: > rpm -Uvh ftp://ftp.redhat.com/updates/4.2/sparc/imap-4.1.final-0.sparc.rpm > > > ------- End of Forwarded Message > > > -- > Duncan (-: > "software industry, the: unique industry where selling substandard goods is > legal and you can charge extra for fixing the problems." > > -- > ---------------------------------------------------------------------- > Please refer to the information about this list as well as general > information about Linux security at http://www.aoy.com/Linux/Security. > ---------------------------------------------------------------------- > > To unsubscribe: > mail -s unsubscribe linux-security-request@redhat.com < /dev/null >-- Donnie Barnes http://www.redhat.com/~djb djb@redhat.com "Bah." Challenge Diversity. Ignore People. Live Life. Use Linux. 879. My Dad used to say I have deceptive quickness. I'm slower than I look.
> It appears that uninstalling the imap rpm uninstalls the pop mail service as > well, or at least disables it. Is this uncool? Is it safe to leave it > installed (but removed from inetd.conf) for the sake of keeping pop service in > place?I'm not sure, actually. The POP code comes from the imap package, so presumably you need to updated it *all* if you use any of it to make sure you are safe from attack. I'd just update the package to the latest one and leave imap enabled. --Donnie -- Donnie Barnes http://www.redhat.com/~djb djb@redhat.com "Bah." Challenge Diversity. Ignore People. Live Life. Use Linux. 879. My Dad used to say I have deceptive quickness. I'm slower than I look.
On 20 Jul 98, at 23:26, djb@redhat.com said this about [linux-security] Re: IMAPD fix for RH:> > It appears that uninstalling the imap rpm uninstalls the pop mail service as > > well, or at least disables it. Is this uncool? Is it safe to leave it > > installed (but removed from inetd.conf) for the sake of keeping pop service in > > place? > > I'm not sure, actually. The POP code comes from the imap package, so > presumably you need to updated it *all* if you use any of it to make > sure you are safe from attack.The overflow in this case appears to be in an IMAP-specific authentication mechanism, and so shouldn't affect the POP daemons. I upgraded the lot anyway :-)) Cheers Richard -- Richard Stevenson richard@al.pmail.gen.nz PGP Key ID 0x0E5A2DD5 fingerprint = 7B DD 1C 51 76 05 A1 42 44 2E DD 61 78 DB 2D 07
>> It appears that uninstalling the imap rpm uninstalls the pop mail serviceas>> well, or at least disables it. Is this uncool? Is it safe to leave it >> installed (but removed from inetd.conf) for the sake of keeping popservice in>> place? > >I'm not sure, actually. The POP code comes from the imap package, so >presumably you need to updated it *all* if you use any of it to make >sure you are safe from attack. > >I'd just update the package to the latest one and leave imap enabled.Better yet, do some packet filtering in addition to updating -- after all, who _really_ needs access to your imap/pop server but usually a select few.... Guys, people are already trying to exploit this hole -- I have packet filter logs to prove it. My philosophy is simply this -- if they don't need access to a port, don't give it. Deny by default -- permit only when there is a demonstrated need. Permit access at the finest granularity possible -- even if that means a fifty line packet filter. Use multiple filters -- tcp wrappers plus cisco ACLs, etc. Log access to exposed ports -- even if it means a large partition dedicated to /var/log. Protect your logs. Etc, etc, etc,.... Yes, I know it's alot of (often thankless) work. However, the crackers attacking your system are going to be diligent -- it behooves you to be just as diligent. I know I'd rather be chewed out by my boss for spending too much time on security than to have him really chew me out for the embarrassment of not spending enough time. Lamar Owen WGCR Internet Radio