OpenBSD Journal

Propolice Support Added

Contributed by jose on from the stack-smashing-protection dept.

Numer Six was the first to write:


"Log message:
Import propolice (, 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 to be build and installed before the propolice-enabled compiler can be installed."

Wow, I had mentioned this previously for GCC 3.2, but this is the base system. Hurray! Check out the link about ProPolice and see how it works, it's some cool stuff!

(Comments are closed)

  1. By Will () on

    Sounds great, but the excerpt doesn't make it clear that the author of the mail was miod@. Good work all (that beer drinking sounds like hard work ;-)

  2. By zil0g () on

    Well that sounds pretty schweet to me!

  3. By Anonymous Coward () on

    Well, that's one swell extension. I hope more extensions like that follow: I don't like C because I suck at coding and I would make tons of security errors (so I use safer languages). This kind of stuff helps people like me.

  4. By grey () on

    "this does nothing to help against you writing shitty code full of security holes. all of these x86 stack smashing protections have been broken in the past, this one will too. they don't help protect heap attacks either."

    Indeed, you're quite right - propolice, non-exec stacks, etc. don't solve the root problem, namely buggy & incorrect code. However, I think you're mistaken in the intent behind such measures. Not all protections are designed to be infallable, in fact the best designed ones are usually engineered with failure in mind. It then becomes a matter of how the protection is defeated, and how difficult it is which determines the success of the measure. (For a a different industry, but similar issue, Gavin Todd's "Keeping Pirates at Bay" provides a great discourse on what successful copy protection entails, with relation to cracking videogame protections. [it requires a login, so I'll only link it here: ]

    I can't google up the interview where Theo talks about this more directly, but here's a quote from Aleph One referring to Theo (and others) opinion on the matter of such tools (or at least a previous thinking):

    (lifted from: )

    "As mentioned by Theo de Raadt, Michael Shields, Tim Newsham, and others the only real solution to buffer overflows is fixing the defective programs. Anything else is a stopgap measure."

    However, Aleph goes on to say:

    "This by no means implies you should not use one or more of the alternatives as fall back methods. The more defenses the better. Just don't depend on them."


    As evidenced by many changes in the OpenBSD tree over the past year - there has been a shift in how certain forms of security are handled.

    Understanding that true security derives from "correctness" is a fundamental stumbling block that a lot of people never understand, they layer cryptography, ACL's, and other forms of complexity in repeatedly failed efforts to promote real security. Greatfully, I've never seen OpenBSD have this problem, the developers have a keen eye for snakeoil and bullshit. The fundamental nature of computers as discrete machines hasn't been glazed over, there is an understanding that if a program fails unexpectedly, that there's something that needs fixing - putting more duct tape around it doesn't mean the pipe doesn't need replacing just because the symptoms have gone away.

    However, I think the past year and a half of OpenBSD development have really evolved. There at times when OpenBSD developers have been known to simply write things off as ineffective or not solving the real issues, and discard them; just look at SMP development for one - you'll hear a lot of folks going on about how other OS's only do multiprocessing, not symetric multiprocessing, how this and that processor locking structure should be used, etc. Or take the failover support for pf & discussions over VRRP. Often OpenBSD will hold back on certain technical leaps because the ideal way to accomplish that goal isn't within grasp. From what I've seen, there are extremely limited developer resources, so wasting resources on inferior solutions which will need to be overhauled isn't just wasted effort - it can really impact other areas.

    Sorry about that slight tangent. But getting back on topic, I feel that development really has been evolving a bit. In the past, such things as propolice might have been written off as inneffective, or not the way to procede, it's clear that these don't really add features (in the way that SMP or pf failover do) so much as they add robustness to situations where OpenBSD fails. While it's still true that fixing bugs and encouraging correct code is the work that allows for a higher level of quality, nothing is 100%. People will always make mistakes, so there need to be alternate measures to reduce the damage which can be wreaked by such problems. Since 3.0-current we've seen such additions as privelege separation to OpenSSH, systrace, non-exec stacks, and now propolice. These are primarily engineering choices rather than feature additions, which will ultimately reduce the scope of damage when something bad happens. None of them prevent the bugs from occurring, nor eliminate the need for those bugs to get fixed; but the systems will fail less catastrophically, often or easily. Additionally, the bar will be raised against those who develop malicious code. -Of course- this doesn't make developing exploits impossible, but there will be fewer people out there who have the skill, care, time, dedication or malintent to actually be arsed to do anything. Maybe only one or two fewer people, who knows or cares, it should be pretty obvious that the effort required to implement these sorts of fallback measures isn't overtaxing; and hopefully it will be reciprocated by a marked (even if only minimal) increase in effort on the part of a vulnerability developer.

    The root problems of incorrect code won't go away, nor will OpenBSD developers turn a blind eye to them. Not to sound too much like Schneier, but this step (as well as other improvements in recent releases) simply adds some more robustness to how the OpenBSD fails - in a climate where it has already had great successes.


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]