From owner-freebsd-security  Wed Oct 16 14:33:51 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id OAA07900
          for security-outgoing; Wed, 16 Oct 1996 14:33:51 -0700 (PDT)
Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA07887
          for <freebsd-security@FreeBSD.org>; Wed, 16 Oct 1996 14:33:38 -0700 (PDT)
Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.7.5/8.7.3) with UUCP id PAA14994; Wed, 16 Oct 1996 15:33:11 -0600 (MDT)
Received: from localhost (marcs@localhost) by alive.ampr.ab.ca (8.7.5/8.7.3) with SMTP id PAA19407; Wed, 16 Oct 1996 15:15:22 -0600 (MDT)
Date: Wed, 16 Oct 1996 15:15:22 -0600 (MDT)
From: Marc Slemko <marcs@znep.com>
X-Sender: marcs@alive.ampr.ab.ca
To: "az.com" <yankee@lucy.az.com>
cc: freebsd-security@FreeBSD.org
Subject: Re: BUG IN FTPD
In-Reply-To: <Pine.BSF.3.91.961016100637.4979A-100000@lucy.az.com>
Message-ID: <Pine.BSF.3.95.961016151102.19361B-100000@alive.ampr.ab.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-security@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

No.  Things like login and ftpd are not started from a shell generally, so
all thaat would do is stop coredumps for things started from csh, when csh
read /etc/csh.cshrc, and if the user didn't override it.

Stopping programs from core dumping (by something similar to the patch I
suggested) does seem to fix the obvious ways of exploiting the problem,
since you can't attach a debugger to a process that has changed UIDs, but
a better solution is to have the appropriate buffers zeroed so the
information just isn't there.... 

On Wed, 16 Oct 1996, az.com wrote:

> 
> 
> would 
> 
> limit coredumpsize 0
> 
> in /etc/csh.cshrc
> 
> also offer any relief?
> 
> 
> Dan
>