From owner-freebsd-security Fri Feb 14 03:55:16 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA28167 for security-outgoing; Fri, 14 Feb 1997 03:55:16 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA28143 for ; Fri, 14 Feb 1997 03:55:12 -0800 (PST) Received: from rover.village.org by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0vvHXz-000924C; Thu, 13 Feb 97 22:55 PST Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vvHTv-000254-00; Thu, 13 Feb 1997 23:50:51 -0700 To: Vadim Kolontsov Subject: Re: new bugs with strcpy() Cc: freebsd-security@freebsd.org In-reply-to: Your message of "Wed, 12 Feb 1997 12:51:56 +0300." References: Date: Thu, 13 Feb 1997 23:50:51 -0700 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message Vadim Kolontsov writes: : For example, : static char pathname[MAXPATHLEN]; : sprintf(pathname, "%s/%s", dirp->name, filename); : } : : (of course, tftpd runs as nobody by default, but when you'll get : access to the system you can use another exploit...) And you are overflowing a static buffer which is *MUCH* harder to exploit than the stack overflows that we've read so much about. None the less, I'll be committing a fix for this at some point soon. Can't be too careful :-) : It looks that we need to check whole source tree carefully.. : Or at least apply patches to libc's strcpy() that checks stack frame. Yes. That's true. Such an effort is going on. Thanks for pointing out possible problems... Warner