From owner-freebsd-security Sat Dec 14 14:02:21 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA18410 for security-outgoing; Sat, 14 Dec 1996 14:02:21 -0800 (PST) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA18399 for ; Sat, 14 Dec 1996 14:02:18 -0800 (PST) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id OAA01323 for ; Sat, 14 Dec 1996 14:02:41 -0800 (PST) Received: (qmail 6372 invoked by uid 110); 14 Dec 1996 22:01:41 -0000 Message-ID: <19961214220141.6371.qmail@suburbia.net> Subject: Re: questions... In-Reply-To: from John Dowdal at "Dec 14, 96 04:28:36 pm" To: jdowdal@destiny.erols.com (John Dowdal) Date: Sun, 15 Dec 1996 09:01:41 +1100 (EST) Cc: steve@edmweb.com, hackers@freebsd.org, security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Sun, 15 Dec 1996 proff@suburbia.net wrote: > > > Unfortunately this isn't a total cure, because there are 1001 stack overflows > > in NON-suid programs. > > So what. The programs will just core dump if they stack overflow, else > just not work right. Since they are not SUID and not run as root [inetd, > ...], they won't be able to get root if they blow up. > > John > > You miss the point. There are kernel level bugs, and bugs in suid programs often requires executable trigger code. The design goal behind the file system layout I presented is to prevent execution of any attacker designed code. This is not possible due to stack over-write conditions in NON suid programs. Decent mmu's, such is found on alpha cpu's have real PROT_EXEC memory protections, which is turned off for the stack segment. It is still possible to exploit stack over-flows as the pc is usurpable. Finding existing code to point it to that will achieve your ends however is very difficult. Which reminds me. Several mmu changes were introduced with the P6 including 2Mb pages and 36 bit addressing modes. Has anyone verified that real exec protections didn't also make their way in? I don't know much about P5/P6 hardware break-point/watch support, but I can't help wondering if it will take ranges, rather than just fixed locations and for exec instead of r/w. Can someone who knows more about the P5/6 enhancements than myself comment? Note that sunos4.1.x is not vulnerable to noexec subversion by LD_PRELOADing, as mmap's of PROT_EXEC fail on noexec file systems. I haven't examined FreeBSD's vm system in this regard, but clearly the sun behaviour is correct, as is refusing mprotect() changes to fd's on noexec vnodes. btw (dyson?) are union mounts working correctly yet? Seems like the ideal solution for ro file systems with site modifications. -Julian A. (proff@suburbia.net)