From owner-freebsd-security Sun Jul 19 15:28:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA03357 for freebsd-security-outgoing; Sun, 19 Jul 1998 15:28:31 -0700 (PDT) (envelope-from owner-freebsd-security@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 PAA03351 for ; Sun, 19 Jul 1998 15:28:29 -0700 (PDT) (envelope-from brett@lariat.org) Received: (from brett@localhost) by lariat.lariat.org (8.8.8/8.8.8) id QAA03712; Sun, 19 Jul 1998 16:28:03 -0600 (MDT) Message-Id: <199807192228.QAA03712@lariat.lariat.org> X-Sender: brett@mail.lariat.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Sun, 19 Jul 1998 16:28:00 -0600 To: dg@root.com From: Brett Glass Subject: Re: The 99,999-bug question: Why can you execute from the stack? Cc: security@FreeBSD.ORG In-Reply-To: <199807192155.OAA18816@implode.root.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Putting the code on the user's stack is an interesting notion, but does not seem to me that executing code from the stack is the only way to clean up after a signal. The code could be in a runtime library, in a specially-created segment, or on a special read-only page mapped into the user space for that purpose. This would be cleaner. In fact, the page might be shared among processes returning from signals. I'd much rather see this technique revised than leave a hole open for buffer overflow attacks. We don't want to get a reputation for lax security. --Brett At 02:55 PM 7/19/98 -0700, David Greenman wrote: >>We're going to be spending about a man-month rebuilding a complex system >>that was hacked due to a buffer overflow exploit. Looking back at our >>system log files, I can see exactly how the hack was done and how the >>perpetrator was able to get root. >> >>What I CAN'T understand is why FreeBSD allows the hack to occur. Why on >>Earth would one want to allow code to be executed from the stack? The Intel >>segmentation model normally prevents this, and there's additional hardware >>in the MMU that's supposed to be able to preclude it. Why does the OS leave >>this gigantic hole open? Why not just close it? > > Two words: Signal Trampoline. For an explaination, see the mailing list >archives for -hackers, search for 'signal trampoline'. > >-DG > >David Greenman >Co-founder/Principal Architect, The FreeBSD Project > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message