Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 15 Feb 2001 10:05:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 15 Feb 2001 10:05:26 -0500 Received: from slc573.modem.xmission.com ([166.70.7.65]:28935 "EHLO flinx.biederman.org") by vger.kernel.org with ESMTP id ; Thu, 15 Feb 2001 10:05:17 -0500 To: Jeremy Jackson Cc: linux-kernel@vger.kernel.org Subject: Re: Is this the ultimate stack-smash fix? In-Reply-To: <3A899FEB.D54ABBC7@sympatico.ca> <3A8ADA30.2936D3B1@sympatico.ca> From: ebiederm@xmission.com (Eric W. Biederman) Date: 14 Feb 2001 22:30:05 -0700 In-Reply-To: Jeremy Jackson's message of "Wed, 14 Feb 2001 14:19:12 -0500" Message-ID: Lines: 48 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Jeremy Jackson writes: > "Eric W. Biederman" wrote: > > > Jeremy Jackson writes: > > (about non-executable stack) > > > > There is another much more effective solution in the works. The C > > standard allows bounds checking of arrays. So it is quite possible > > for the compiler itself to check this in a combination of run-time and > > compile-time checks. I haven't followed up but not too long ago > > there was an effort to add this as an option to gcc. If you really > > want this fixed that is the direction to go. Then buffer overflow > > exploits become virtually impossible. > > > > I've thought some more, and yes someone else has already done this. Problems > are with compilers that > put code on stack (g++ trampolines for local functions i think). There is > the gcc-mod (Stack-guard?) that checks for > corrupt stack frame using magic number containing zeros before returning... > this will take away some > performance though... No. I'm not talking about stack-guard patches. I'm talking about bounds checking. The difference here is that if correct code is generated you won't overflow any buffer at all period. The compiler will either prove at compile time that it can't happen (The efficient case). Or it will generate pointers as tuples into chunks of memory. And it will do runtime checks that will that will kill your program if it overflows the stack. I think the gcc options is -fcheck or something like that. I haven't had a chance to follow up, since I saw that someone was actually working on it. Since compilers bugs happen buffer overflow exploits are still possible but it means two separate programmers must mess up in complimentary ways. As for fine grain privileges they can help, but the real fix is to keep the programs that need raised privileges down to one function. Letting you look at the program and see if it is obviously correct with no security bugs. But the gcc bounds checking work is the ultimate buffer overflow fix. You can recompile all of your trusted applications, and libraries with it and be safe from one source of bugs. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/