OpenBSD creator Theo de Raadt [interview] announced that propolice, the "stack-smashing protector" has been merged into the OpenBSD kernel. Miod Vallat went on to explain, "We have choosen to enable propolice by default to ensure that it will get widely tested, in the hope that this will prove a worthy addition for our next releases. Expect some breakage in ports, though, that will get fixed as time permits."
You can read Hiroaki Etoh's original propolice announcement here. It is now simply referred to as the "stack-smashing protector", being a highly portable GCC extension that 1) reorders variables to prevent pointer corruption, and 2) inserts protection code into an application at compilation time to detect buffer overflows, preventing such bugs from being exploited. The buffer overflow protection portion of Hiroaki's GCC extension is based on StackGuard. Complete details into how this works can be found on the project's homepage.
From: Theo de Raadt To: misc Subject: propolice Date: Sun, 01 Dec 2002 22:15:48 -0700 the new snapshots leaking out contain propolice in the compiler. this means that binaries compiled upon these snapshots will NOT run on older systems; there is an upcoming half-flag day for this. miod will be providing more information within a day when this goes into the tree, but I just wanted to give an early alert. if you want to find out what propolice is, and are too dense to use google, please go back in kindergarden.
From: Peter Fairbrother Subject: Re: propolice Date: Mon, 02 Dec 2002 09:43:09 +0000 Theo de Raadt wrote: > the new snapshots leaking out contain propolice in the compiler. this > means that binaries compiled upon these snapshots will NOT run on > older systems; there is an upcoming half-flag day for this. miod will > be providing more information within a day when this goes into the > tree, but I just wanted to give an early alert. > > if you want to find out what propolice is, and are too dense to use > google, please go back in kindergarden. Propolice relies on a random guard variable that is unknown to an attacker, and which cannot be determined without local root privileges. However, an attacker could load a compiled package on a machine on which he does have root and determine the value. So any protection would not apply to pre-compiled packages. I may be wrong here, if so would someone please let me know how. -- Peter Fairbrother (I guess my antipathy to "bolt-on" security is well known. Didn't we have an argument about this about a year ago? At the time you rejected putting buffer-overflow protection into a compiler because "it would break too much". Fine, but why add an insecure/ineffective feature if you've changed your mind?) (dons flameproof suit)
From: Theo de Raadt Subject: Re: propolice Date: Mon, 02 Dec 2002 02:47:04 -0700 > > the new snapshots leaking out contain propolice in the compiler. this > > means that binaries compiled upon these snapshots will NOT run on > > older systems; there is an upcoming half-flag day for this. miod will > > be providing more information within a day when this goes into the > > tree, but I just wanted to give an early alert. > > > > if you want to find out what propolice is, and are too dense to use > > google, please go back in kindergarden. > > Propolice relies on a random guard variable that is unknown to an attacker, > and which cannot be determined without local root privileges. > > However, an attacker could load a compiled package on a machine on which he > does have root and determine the value. > > So any protection would not apply to pre-compiled packages. > > I may be wrong here, if so would someone please let me know how. If a user can break into his own programs, why would he not in the first place upload one that gives him privs without him having to go through the bother? Come on. Rational thought can't be that difficult.
From: Theo de Raadt Subject: Re: propolice Date: Mon, 02 Dec 2002 02:47:38 -0700 > (I guess my antipathy to "bolt-on" security is well known. Didn't we have an > argument about this about a year ago? At the time you rejected putting > buffer-overflow protection into a compiler because "it would break too > much". Fine, but why add an insecure/ineffective feature if you've changed > your mind?) Nothing at the time was sufficient to the task. Go read the damn propolice paper, and see what existed at the time. I'll give you a hint:All the world is an i386.
From: Peter Varga
Subject: Re: propolice
Date: Mon, 2 Dec 2002 14:28:35 -0500On Mon, Dec 02, 2002 at 02:47:38AM -0700, Theo de Raadt wrote:
> > (I guess my antipathy to "bolt-on" security is well known. Didn't we have an
> > argument about this about a year ago? At the time you rejected putting
> > buffer-overflow protection into a compiler because "it would break too
> > much". Fine, but why add an insecure/ineffective feature if you've changed
> > your mind?)
>
> Nothing at the time was sufficient to the task.
>
> Go read the damn propolice paper, and see what existed at the time.
>
> I'll give you a hint:
>
> All the world is an i386.Another hint: does the hardware know what is executable and what is
data? Is there any way to tell the hardware this page/segment/bank is
executable?Thanks for all the work to have propolice.
Asap i'll try it.
From: Dries Schellekens
Subject: Re: propolice
Date: Mon, 2 Dec 2002 20:42:49 +0100 (CET)On Mon, 2 Dec 2002, Peter Varga wrote:
> On Mon, Dec 02, 2002 at 02:47:38AM -0700, Theo de Raadt wrote:
> > > (I guess my antipathy to "bolt-on" security is well known. Didn't we have an
> > > argument about this about a year ago? At the time you rejected putting
> > > buffer-overflow protection into a compiler because "it would break too
> > > much". Fine, but why add an insecure/ineffective feature if you've changed
> > > your mind?)
> >
> > Nothing at the time was sufficient to the task.
> >
> > Go read the damn propolice paper, and see what existed at the time.
> >
> > I'll give you a hint:
> >
> > All the world is an i386.
>
> Another hint: does the hardware know what is executable and what is
> data? Is there any way to tell the hardware this page/segment/bank is
> executable?Yes, since 3.2 OpenBSD has a non-executable stack on i386, sparc, sparc64,
alpha, powerpc and no-exec heap and bss on sparc, sparc64, and alpha.Cheers,
Dries
--
Dries Schellekens
From: Peter Varga
Subject: Re: propolice
Date: Mon, 2 Dec 2002 15:02:44 -0500On Mon, Dec 02, 2002 at 08:42:49PM +0100, Dries Schellekens wrote:
> On Mon, 2 Dec 2002, Peter Varga wrote:
>
> > On Mon, Dec 02, 2002 at 02:47:38AM -0700, Theo de Raadt wrote:
> > > > (I guess my antipathy to "bolt-on" security is well known. Didn't we have an
> > > > argument about this about a year ago? At the time you rejected putting
> > > > buffer-overflow protection into a compiler because "it would break too
> > > > much". Fine, but why add an insecure/ineffective feature if you've changed
> > > > your mind?)
> > >
> > > Nothing at the time was sufficient to the task.
> > >
> > > Go read the damn propolice paper, and see what existed at the time.
> > >
> > > I'll give you a hint:
> > >
> > > All the world is an i386.
> >
> > Another hint: does the hardware know what is executable and what is
> > data? Is there any way to tell the hardware this page/segment/bank is
> > executable?
>
> Yes, since 3.2 OpenBSD has a non-executable stack on i386, sparc, sparc64,
> alpha, powerpc and no-exec heap and bss on sparc, sparc64, and alpha.I am fondly aware of that. Let me be more clear.
Is there any way to tell the hardware what is executable and will it
cause a sigsegv?
From: Theo de Raadt
Subject: ha ha
Date: Mon, 02 Dec 2002 02:22:57 -0700And it goes further: we've got stack smash protected install floppies!
I find that pretty hilarious.
Not just by making the stack non-executable (and data and bss on some
architectures), but also by having the compiler generate checking
code.
From: Miod Vallat
Subject: Propolice stack protector merged in -current
Date: Mon, 2 Dec 2002 09:12:21 +0000Hello folks,
as hinted by Theo a few hours ago, the propolice stack protection gcc
mods have been merged in the tree.We have choosen to enable propolice by default to ensure that it will
get widely tested, in the hope that this will prove a worthy addition
for our next releases. Expect some breakage in ports, though, that will
get fixed as time permits.If you are updating your system by source, please be sure to compile
and install an updated ld.so (libexec/ld.so on ELF platforms,
gnu/usr.bin/ld/rtld on a.out platforms) before you start a make build.
The make build phase will also build and install a new libc first, that
provides some code needed by propolice-enabled binaries.Miod
From: Miod Vallat
To: source-changes
Subject: CVS: cvs.openbsd.org: src
Date: Mon, 2 Dec 2002 09:01:36 GMTCVSROOT: /cvs
Module name: src
Changes by: miod@cvs.openbsd.org 2002/12/02 02:00:26Modified files:
gnu/egcs/gcc : Makefile.in combine.c cse.c explow.c expr.c
flags.h function.c gcse.c optabs.c reload1.c
toplev.c
gnu/usr.bin/ld/rtld: rtld.c
lib/libc : shlib_version
lib/libc/sys : Makefile.inc
lib/libc_r : shlib_version
libexec/ld.so : util.c
sys/arch/alpha/conf: Makefile.alpha
sys/arch/alpha/stand: Makefile.inc
sys/arch/amiga/conf: Makefile.amiga
sys/arch/amiga/stand/binpatch: Makefile
sys/arch/amiga/stand/boot: Makefile
sys/arch/amiga/stand/loadbsd: Makefile
sys/arch/amiga/stand/loadkmap: Makefile
sys/arch/hp300/conf: Makefile.hp300
sys/arch/hp300/stand: Makefile.inc
sys/arch/hppa/conf: Makefile.hppa
sys/arch/hppa/stand: Makefile.inc
sys/arch/i386/conf: Makefile.i386
sys/arch/i386/stand: Makefile.inc
sys/arch/mac68k/conf: Makefile.mac68k
sys/arch/macppc/conf: Makefile.macppc
sys/arch/macppc/stand: Makefile.inc
sys/arch/mvme68k/conf: Makefile.mvme68k
sys/arch/mvme68k/stand: Makefile.inc
sys/arch/mvme88k/conf: Makefile.mvme88k
sys/arch/mvme88k/stand: Makefile.inc
sys/arch/mvmeppc/conf: Makefile.mvmeppc
sys/arch/mvmeppc/stand: Makefile.inc
sys/arch/sparc/conf: Makefile.sparc
sys/arch/sparc/stand: Makefile.inc
sys/arch/sparc64/conf: Makefile.sparc64
sys/arch/sparc64/stand: Makefile.inc
sys/arch/sun3/conf: Makefile.sun3
sys/arch/sun3/stand: Makefile.inc
sys/arch/vax/boot: Makefile.inc
sys/arch/vax/conf: Makefile.vax
Added files:
gnu/egcs/gcc : protector.c protector.h
lib/libc/sys : stack_protector.cLog message:
Import propolice (http://www.trl.ibm.com/projects/security/ssp), a stack
attack protection scheme, into gcc.This protection is enabled by default. It can be turned off by using the
-fno-stack-protector flag.Code by Hiroaki Etoh (etoh at jp dot ibm dot com); work on openbsd-specific
integration by fgsch@, deraadt@ and myself; tests by fgsch@, naddy@ and
myself; beer drinking by myself.Please note that system upgrades with this new code will require a new
libc and ld.so to be build and installed before the propolice-enabled
compiler can be installed.
C gotta die
sorry folks, but why use tools to fix a broken language? I don't understand why people use C for something else than helloworld.c.
cheers
WTF?
C is hardly broken - I've seen many good things written in C - I think *you* are the one with a broken brain :P
Cheers,
Michael (Your non-expert C++ Programmer :) )
good luck
I wish you good luck writing an OS kernel in say... perl.
Fact is that C is widely used and well tested.
Personally I started my programming journey with C++, and I like it a lot - but I certainly wouldn't use it for everything... use the right tools for the job and all.
Because...
There are many better languages out there than C. Why still use it? C has one big advantage over other languages: acceptance. Everyone can program in C. Every system has a C compiler.
C is just too entrenched. What we really need is a bigger push for incremental improvements to C. Getting an entire industry to make a big change is hard. Getting an entire industry to make lots of little changes is a lot easier.
because the alternatives are worse
ever try doing a security audit of C++ or java? it takes _far_ longer than C. Hmm. does + really mean addition on this object, gotta go check. Which version of the ->foo() method does this object use? it really sucks. C is straight forward and well understood. OO languages are great for programming. But they suck two nuts (and a third if you got one) for verifiable security.
Why use C? Because it is the
Why use C? Because it is the 2nd most efficient language (assembler being number 1). It is also very human readable, even much more so than C++ (which does a great job of mixing structured and object oriented languages together but gets very messy quickly). I personally would use C for anything to do with the kernel or guts of any software, and Java for the fluff such as user interface.
the case against C
I'm the first poster - the one with a broken brain ;(
Why is C efficent? because it does no runtime checks. the results are overflows. You, the programmer has to take care of eveything and insert here and there additional code - that must be up to the compiler and well designed languages take care of that.
another guy mentioned that perl is not an alternativ for writing an OS? it's sad that computer folks nowadays just know java, c, c++, perl and php.
verification of c programs? I have never heard that you can verify C smoothly - typecasts and all the pointer are a nightmare for verification.if you want to verify programs you might want to look out for languages that explicitely support that. euclid and turing come to my mind.
yes, everybody can program in C. yes, C is widespread. yes, everybody is using windows. ops? maybe that's not a quality ...
the big problem is that the programming interface to the OS is in C. if you want to do cool thinks that are beyond the scope of your language (say fork or sockets), then you need to use the kernel interface and your natural choice is C.
I like to program over 2 weekends smaller programs ( ~2000 LOC). My choice is typically C because you can simply start typing - you don't need to design the program from the start. But I'm simply sick of it. I'm currently looking around for Ada add-ons. I found a socket interface as well as a gtk interface. I know Ada from school but have never used some interfaces. My next weekend's project will be in Ada.
Yes, I'm still looking for a cool language - but for sure it's not C.
Why C?
The tools available to C programmers have been in development for
decades. GCC is highly optimised and I've only once encountered a bug
in it[1].
I enjoy learning language (and learning about them).
Perl has too much magic (for me, others love it).
Python is a hack, designed to be simple and constantly getting new
syntax added.
C++ is bloated, there's way too much syntax. It's cross-platform
capabilities were vapourware too.
Ada, well, the FSF have a Free Ada compiler and still no one uses
it. There must be a reason.
Scheme is a really nice language. It has it's quirks though. I wish
more people knew scheme.
C: great tools, readable code, no magic, simple syntax. Perfect for
good programmers writing serious software[2]. Mickey Mouse software
can be written in BASIC. You don't hear Alan Cox or Marcus
Brinkmann saying C is too hard, do you?
Ciaran O'Riordan
[1] In a pre-release of 2.95.4 I found that declaring a twenty-nine
dimensional array made it crash. I forgive them.
[2] I'm not claiming to be a hardcore C programmer
re
I agree 100% C is very usable, and you can write an object system in it (Glib). Which makes C++ have fewer advantage. Scheme is a great scripting language; more programmers should be aware of it. A program called scheme shell makes a better replacement for all those things that aren't quite full-fledged programming languages, like Perl, shell programming, and sed; it lets you do kernel calls as well
What can you suggest?
What can you suggest for writing an OS?
java
i really don't (want to) understand why people want to use a language like JAVA. JAVA is big en slow (they call it stable) and it's it very, very fqqd up programming.
and i am talking about JAVA applications. applets sux as well, but can be handy, i admit. if you need a GUI why don't use Borland's Kylix? It worx (as far as i know) on almost every UNIX platform, and it's easy and light.
i just started c-programming, and it's a very straight language. and all UNIX is built in it and with it and within it. UNIX == C and C == UNIX, so the people here that don't like C, actually don't like unix.
kind regards