[31297] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Buffer overflow prevention

daemon@ATHENA.MIT.EDU (Anil Madhavapeddy)
Wed Aug 20 23:22:04 2003

Date: Tue, 19 Aug 2003 17:17:46 +0100
From: Anil Madhavapeddy <anil@recoil.org>
To: Crispin Cowan <crispin@immunix.com>
Cc: Theo de Raadt <deraadt@cvs.openbsd.org>, mtinberg@securepipe.com,
        bugtraq@securityfocus.com, peter@trusteddebian.org, etoh@openbsd.org
Message-ID: <20030819161746.GA26259@quick.recoil.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F41C5F6.6020305@immunix.com>

On Mon, Aug 18, 2003 at 11:38:46PM -0700, Crispin Cowan wrote:
> 
> ProPolice does not protect functions containing arrays of length 7 or 
> less. We don't know what other cases exist in which ProPolice fails to 
> protect. This kind of risk exists precisely because of the design choice 
> that gives ProPolice its multi-architecture capability: putting the 
> protection way up high in the compiler. This creates the potential for 
> later stages of GCC to optimize away the security checks, or move them 
> so far away from relevant code that they are no longer effective. When 
> you choose ProPolice, you choose CPU portability over security.

You're correct that OpenBSD/ProPolice does not protect buffers of length 7
or less, but your analysis appears to be completely wrong.

It's just a simple #define SUSPICIOUS_BUF_SIZE, and looks to be there for
performance reasons.  If you run with -Wstack-protector, PP will warn
explicitly when it skips a too-small buffer.  If you are feeling particularly
paranoid and don't mind the performance hit, just crank the define down
and recompile GCC.

It certainly isn't gcc optimising away the checks, or anything to do with
architecture.

-- 
Anil Madhavapeddy                                   http://anil.recoil.org
University of Cambridge                            http://www.cl.cam.ac.uk

home help back first fref pref prev next nref lref last post