From owner-freebsd-chat Fri Jul 17 12:48:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA07451 for freebsd-chat-outgoing; Fri, 17 Jul 1998 12:48:55 -0700 (PDT) (envelope-from owner-freebsd-chat@FreeBSD.ORG) Received: from lariat.lariat.org (ppp1000.lariat.org@[206.100.185.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA07440 for ; Fri, 17 Jul 1998 12:48:53 -0700 (PDT) (envelope-from brett@lariat.org) Received: (from brett@localhost) by lariat.lariat.org (8.8.8/8.8.8) id NAA19746; Fri, 17 Jul 1998 13:48:39 -0600 (MDT) Message-Id: <199807171948.NAA19746@lariat.lariat.org> X-Sender: brett@mail.lariat.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 17 Jul 1998 13:47:34 -0600 To: chat@FreeBSD.ORG From: Brett Glass Subject: Let's close the door to "stack hacks" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm in the process of orchestrating a long, painstaking cleanup after a cracker rooted our system via a buffer overflow exploit in Qualcomm's POP server. We're going to reinstall the entire OS, recompile every utility from known good source, and go over every script line by line -- about 3 man months of effort. Worse, the exploit did more than just give the cracker root access; it also trashed our disk. (The corruption must have extended into memory used by the disk cache or file system code.) Now, I realize that buffer overflows are a fundamental problem of the C language -- and are, in fact, one of the reasons why I avoid programming in it when I can. Nonetheless, a weakness in a language and/or its libraries shouldn't spark an endless war against OS security holes. I'd therefore like to initiate a discussion of ways to make it impossible for a buffer overflow to allow the sort of "root canal" we experienced. Can it be made difficult or impossible to execute code from the stack? Alternatively, is there a way to prevent code inserted into the stack from being position-independent enough to run there? Is there a good way to check stack integrity after a call that might compromise it? Is it possible to remove library routines that allow uncounted strings to trash memory? FreeBSD has a lot to gain by coming up with good safeguards against such attacks, since it could then claim that it's light years ahead of Linux vis-a-vis security. --Brett Glass To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message