Subject: Core dump security breach

From: "Homer W. Smith" <[email-masked]>
Date: Sun, 20 Oct 1996 14:46:32 -0400 (EDT)

To: [email-masked]

     Anyone have any comments on this?

     We are running beta 11.
 
     Homer
 
------------------------------------------------------------------------------
Homer Wilson Smith     News, Web, Telnet      Art Matrix - Lightlink
(607) 277-0959         SunOS 4.1.4 Sparc 20   Internet Access, Ithaca NY
[email-masked]    [email-masked]     http://www.lightlink.com

On Sun, 20 Oct 1996, john paine wrote:

> There's 2 recent holes in wu-ftpd, and we're potentially suceptible to one
> of them. 
> 
> The problem is that ftpd can't handle more than 100 arguments to a
> command, but lets you make the request anyway.  This results in a
> seg-fault and (if the system allows it) core dump. 
> 
> Because ftpd is running as root, the core can contain shadow file
> information, and is world readable.  Even worse, if you can drop a link in
> where the core will dump, the core will follow the link and overwrite any
> file you choose. 
> 
> The version of ftpd we run does seg-fault with 101 arguments (ie, "get 1 2
> 3 4...101"), but doesn't produce a core dump.  I'm not quite sure why.  If
> someone can figure out how to get the core dump to happen, they can get
> our (crypted) root password or overwrite any file on the system. 
> 
> wu-ftpd is apparently not being officially supported anymore, so there
> won't be any official fixes for it.  There is a wrapper that enforces the
> "no core" rule for ftpd, which looks simple and workable for us.  
> 
> We change the ftp line in /etc/inetd.conf to read 
> 
> ftp     stream  tcp     nowait  root    /usr/sbin/wrap_in.ftpd  in.ftpd
> 
> which calls this wrapper (put into /usr/sbin/wrap_in.ftpd):
> 
> /* ------- start here ------------------------------------------- */
> #include <stdio.h>
> #include <sys/time.h>
> #include <sys/resource.h>
> 
> struct rlimit rlp;
> 
> int
> main( int argc, char **argv, char **env )
> {
> 
>    if ( getrlimit( RLIMIT_CORE , &rlp )!=0 ) {
>       perror("getrlimit(RLIMIT_CORE)");
>    } else {
>       rlp.rlim_cur = 0;
>       if ( setrlimit( RLIMIT_CORE , &rlp )!=0 ) {
>          perror("setrlimit(RLIMIT_CORE)");
>       } else {
>          execve("/usr/sbin/in.ftpd", argv, env);
>          perror("execve(\"/usr/sbin/in.ftpd\")");
>       }
>    }
> 
>    return(1);
> }
> /* ----- end here ----------------------------------------------- */
> 
> Sounds good?  Do we do it?
> 
> -x25
>

---

From: Bob Myers <[email-masked]>
Date: Tue, 22 Oct 1996 14:53:24 -0700

I can't reproduce this problem on wu-ftpd or Solaris 2.5.1 ftpd.

I have seen ftp (the client software, not the server) core dump under
similar circumstances under Solaris 2.5.1, but that's not a server
security
problem.

It does seem like limiting the core size to 0 is a good idea, however,
though
of course we would need a "debug" version that would dump a normal core
as well.
That would prevent unknown bugs from producing a core file containing
shadow
password files.

-- 
Bob Myers                              InteleNet Communications, Inc.
Email: [email-masked]               30 Executive Park, Suite 150
Phone: 714-851-8250 x227               Irvine, CA 92614
Fax:   714-851-1088                    http://www.intelenet.net/

---

From: Marc Slemko <[email-masked]>
Date: Tue, 22 Oct 1996 18:24:12 -0600 (MDT)

> That would prevent unknown bugs from producing a core file containing

The latest academ beta shouldn't core dump anyway, because I think it has
signal handlers installed for all possible signals; at least it has them
for most signals.  The signal handler calls exit(), so no core is
generated.  In old versions, the signal handler called abort(), so it did
dump core.

---

From: Silvia Beltran <[email-masked]>
Date: Fri, 25 Oct 1996 19:20:56 -0600

Sorry,
How can I unsubscribe ??
Silvia