Non-exec stack now in snapshots

Contributed by jose on 2002-07-24 from the smash-and-spolit dept.

"As theo announced on misc@, non-executable stack support is available in the most recent snapshots for most platforms. In other words, say goodbye to the vast majority of buffer overflow attacks against OpenBSD machines :-) "

The text of the message is here:




To: misc@openbsd.org 
Subject: non-exec stack 
From: Theo de Raadt

Date: Tue, 23 Jul 2002 20:44:32 -0600 

non-executable stacks can now be found on the following architectures:

        i386
        sparc
        sparc64
        alpha
        macppc

and also on the hppa, which is not a real release yet.

the snapshots that are up contain this code.

Note that none of the other non-exec stacks out there (Solaris, OpenWall, Pax, etc) are immune to all problems, but this does raise the bar for attackers.

(Comments are closed)

Comments

By Anonymous Coward () on 2002-07-24 14:42
Comments
1. By Anonymous Coward () on 2002-07-24 23:17
  
  Non-executable stacks are a great idea and a great improvement. I'm very excited about OpenBSD 3.2, and I'll pre-order it ASAP. I commend OpenBSD for switching from the "no bugs in our code" mentality to the "layers of security" mentality. This is a major shift and it is the next step in OpenBSD security. Non-exec stack is a great layer of security to add. So is privsep. So is systrace. And so is using safer languages, such as Java. Every one of these layers adds something to security. If one of them fails, the system is still secure. This is the best approach to achieving the highest levels of security.
  So... I'm still working on coding some of the daemons in Java (particularly BIND and SSH). BIND is almost done....
  C gives programmers an unlimited supply of rope to hang themselves with. As we can see, even the world's most security-consious programmers (ie, the OpenBSD team) still make memory safety mistakes sometimes. With Java you would have to work very hard to make a memory safety mistake. It's nearly impossible.
  There are still other mistakes you can make, but again, Java has features that make these mistakes more difficult.
  Comments
  1. By Anonymous Coward () on 2002-07-25 00:16
    
    We wish you luck with your Javix operating system. Maybe someone will use it and a legend will be born. Maybe not. Good luck regardless.
  2. By jose () on 2002-07-25 00:37 http://www.monkey.org/~jose/
    
    java needs a jvm and a runtime environment. these need to be encoded in C unless you're running one of Sun's Java stations and you interpret it raw (i think thats how they ran).
    C is still the language of choice for hardcore OS development. you're right that the standard C library is a lot of rope to easily hang yourself. as such, i suggest you come back to the world of C and play with cyclone a typesafe C dialect. you can learn a lot from it.
    
    Comments
    
    By Anonymous Coward () on 2002-07-25 00:47
    
    That is a good idea. You can argue all you want about the merits of C, but regular C with the standard lib is just not the right tool for secure programming. If the OpenBSD team can't write C code that is free of memory safety problems, then no one can. I'll look into Cyclone.
    
    Comments
    
    By W () on 2002-07-25 07:14
    
    Maybe DJB (http://cr.yp.to/) can. I don't know, his software seems very secure.
  3. By Anonymous Coward () on 2002-07-25 08:41
    
    Umm, you really don't have to work that hard at all. In Java the toughest problem is keeping track of what is pointing to what object (If I have a Vector and Hashtable pointing to the same object, modifying one modifies the other). Far to easy to change something without realizing that it's actually changing something else as well.
    
    Java is not designed for OS development. Good luck with your Java kernel. I can imagine the blazing speed already.
    
    Comments
    
    By Peter Schuller () peter.schuller@infidyne.com on 2002-07-29 12:53 mailto:peter.schuller@infidyne.com
    
    What are you talking about?
    
    First of all, you cannot have objects "pointing" to other objects. You can have *references*.
    
    Even so, you cannot have a reference declared to referr to a Vector actually referr to a Hashtable because attempting to perform such an assignment will result in a ClassCastException (or a compile time error if you forget to cast).
    
    As for keeping track of which reference points to which - you have that problem in ANY language that allows you to manipulate data. It's no more difficult than any other form av variable; and *certainly* not more difficult than pointers in C...
    
    If you're having trouble with *that* you either don't know Java or don't know fundamental principles of programming.
    
    By Peter Schuller () peter.schuller@infidyne.com on 2002-07-29 14:12 mailto:peter.schuller@infidyne.com
    
    What are you talking about?
    
    First of all, you cannot have objects "pointing" to other objects. You can have *references*.
    
    Even so, you cannot have a reference declared to referr to a Vector actually referr to a Hashtable because attempting to perform such an assignment will result in a ClassCastException (or a compile time error if you forget to cast).
    
    As for keeping track of which reference points to which - you have that problem in ANY language that allows you to manipulate data. It's no more difficult than any other form av variable; and *certainly* not more difficult than pointers in C...
    
    If you're having trouble with *that* you either don't know Java or don't know fundamental principles of programming.
    
    By Peter Schuller () peter.schuller@infidyne.com on 2002-07-29 16:43 mailto:peter.schuller@infidyne.com
    
    What are you talking about?
    
    First of all, you cannot have objects "pointing" to other objects. You can have *references*.
    
    Even so, you cannot have a reference declared to referr to a Vector actually referr to a Hashtable because attempting to perform such an assignment will result in a ClassCastException (or a compile time error if you forget to cast).
    
    As for keeping track of which reference points to which - you have that problem in ANY language that allows you to manipulate data. It's no more difficult than any other form av variable; and *certainly* not more difficult than pointers in C...
    
    If you're having trouble with *that* you either don't know Java or don't know fundamental principles of programming.
  4. By Marwan Burelle () mb@feanor.org on 2002-07-25 11:05 mailto:mb@feanor.org
    
    Well, I'm totaly agree with you when you said that it's hard to write safe C code, but I don't think Java is the solution (even with their abstract interpretation of the bytecode for stack preservation...).
    
    Their's lot of other langages that can be use for safe programming without the performance cost of the java's models. In fact, with a good strongly typed functionnal langage, almost memory problems are solved. This is because strong typing insure correct executions (the famous Curry-Howard isomorphism between typing and proof) seen as existance of fix point in functionnal langages.
    
    For examples, it is impossible to make overflows and other segfault (or runtime error) with an ocaml code.
    
    The reason to use such a language and not Java, is that it is prooved to work and it can be compiled to native binaries without loosing its property. Native compilations of ocaml give good performances nearly the same as C code.
    
    In fact the main probleme is not only the language used to code, but the incredible mass of code that do the same thing (with different programming style...) and that must be audited individualy. A better approch is too write good libraries (that have to be verified one time) that give high level functions to be used with safe programming languages.
  5. By Anonymous Coward () on 2002-07-26 01:02
    
    I work for a US Military contractor and we write the software for most major US/Nato fighter jets and helicopters. All mission critical software we write is done in Ada95 and will NEVER be done in anything close to java. Now I love c, but military standards make ada a mandatory on many of our contracts. So with languages that can be compiled into binaries like ada (which has an excellent error record for development and maintenance).. why have a slug like java running bind/ssh/* ??
    
    There are more than TWO computer languages!! C rocks and I'm all for keeping bind and ssh in C but I hate to see this two sided debate when it should have several more suggestions.
    
    Take this case study for example on the cost/error ratios with c versus ada.
    http://www.adaic.com/whyada/ada-vs-c/cada_art.html
  6. By Anonymous Coward () on 2002-07-26 01:03
    
    I work for a US Military contractor and we write the software for most major US/Nato fighter jets and helicopters. All mission critical software we write is done in Ada95 and will NEVER be done in anything close to java. Now I love c, but military standards make ada a mandatory on many of our contracts. So with languages that can be compiled into binaries like ada (which has an excellent error record for development and maintenance).. why have a slug like java running bind/ssh/* ??
    
    There are more than TWO computer languages!! C rocks and I'm all for keeping bind and ssh in C but I hate to see this two sided debate when it should have several more suggestions.
    
    Take this case study for example on the cost/error ratios with c versus ada.
    http://www.adaic.com/whyada/ada-vs-c/cada_art.html
    
    Comments
    
    By Anonymous Coward () on 2002-07-25 17:47
    
    I work for a US Military contractor and we write the software for most major US/Nato fighter jets and helicopters.
    that explains the double post - you're used to redundancy ;-)
    
    Comments
    
    By Anonymous Coward () on 2002-07-25 18:23
    
    shit, if the # of posts was directly correlated with the amount of redundant shit i have to do / put up with.... we'd be here all day just reading my post. :( then reread it, retest it, change it up and start all over.
    
    By George () on 2002-07-27 02:07
    
    I'm quite interested in Ada. I haven't done any coding with it, but this will encourage me to look into it. Thanks for sharing your experience.
  7. By Anonymous Coward () on 2002-07-25 15:10
    
    Cool, please let me know when I can test your Java implementation of BIND. I have this 486 133Mhz box with 64 MB RAM running BIND 4. Performance is pretty good now, but I guess I could sacrifice a little performance to get real security. It will work with any of the jdks in the ports tree, and I don't have to worry about bugs inside the jdk, since Java doesn't have pointers, right?
    
    Comments
    
    By Anonymous Coward () on 2002-07-25 18:08
    
    133MHz 486 ?
    
    Comments
    
    By Anonymous Coward () on 2002-07-25 19:26
    
    Yes, one of those nice little soekris boxes. Filters 100mbps on three interfaces statefully with the CPU not going below 95% idle. Runs sshd, named, dhcpd and whatnot, too. So it should handle a Java implementation of bind without a problem, either, no? :)
  8. By Anonymous Coward () on 2002-07-26 04:39
    
    Java sucks the big one. Not useful for OS development at all. Let's not even talk about performance!
  9. By Igor M Podlesny () on 2002-08-04 01:38 www.morning.ru/~poige
    
    I suggest using C++ (STL), this way you can feel safe AND quick enough...
By Anonymous Coward () on 2002-07-24 16:09

Does this mean I have to install a binary
snapshot before I upgrade? I have read I
had to do this on some other platform, but
I am on i386 here.
Comments
1. By Peter Hessler () spambox@theapt.org on 2002-07-24 17:24 http://www.sfobug.org
  
  Rebuilding every program is nessasary only for sparc. Not nessasary for i386 and macppc. Not sure about the others.
2. By Peter Valchev () pvalchev@openbsd.org on 2002-07-24 20:59 mailto:pvalchev@openbsd.org
  
  It is necessary only for sparc.
By Anonymous Coward () on 2002-07-24 18:58

"Note that none of the other non-exec stacks out there (Solaris, OpenWall, StackGuard, etc) are immune to all problems, but this does raise the bar for attackers."
Is this to be read that the OpenBSD-non-exec stack is immune to all problems, or should it really be "Note that none of the other non-exec stacks out there (Solaris, OpenWall, StackGuard, etc) are immune to all problems either , but this does raise the bar for attackers."
Comments
1. By Anonymous Coward () on 2002-07-24 19:42
  
  Give them a break, dude. They need a new catch phrase ;-)
2. By Anonymous Coward () on 2002-07-24 19:48
  
  It is quite clear that nobody claimed the non-exec stack was completely immune. This is a simple comparison.
3. By jose () on 2002-07-24 21:21 http://www.monkey.org/~jose/
  
  so i said that because on all of those architectures if people see it they simply exploit around it. the same will undoubtedly occur for openbsd. since openbsd will have a non-exc stack in the install (dunno if its enabled or not), once someone has techniques to get past it (as they do for stackguard, openwall, etc ...) they will simply take that into account. its not a save all option, but it certinaly does raise the bar for an attacker.
  
  dont forget that plenty of exploits are not buffer overflows but stupid things like configuration bugs. systrace is a great tool to use in conjunction here with the non-exec stack.
  Comments
  1. By none () on 2002-07-30 20:55
    
    especially when systrace race conditions are in the (private) air...
By Anonymous Coward () on 2002-07-24 21:15

If only this had come before Gobbles sploit.
Comments
1. By Anonymous Coward () on 2002-07-24 23:12
  
  Gobbles are a bunch of fags anyways.
  Comments
  1. By Anonymous Coward () on 2002-07-25 00:15
    
    Fags? Grow up. Homophobia isn't "cool"
    
    Comments
    
    By Anonymous Coward () on 2002-07-25 00:19
    
    I would say it is. Some of us don't get our viewpoints from MTV.
    
    Comments
    
    By Anonymous Coward () on 2002-07-25 13:13
    
    oh yeah, i learned to be tolerent of other sexualities on MTV.
    
    once you leave your homophobe lair, you'll realize most of the rest of the world has caught up and could careless if someone is gay.
    
    Comments
    
    By Anonymous Coward () on 2002-07-25 13:52
    
    most of the rest of the world has caught up and could careless if someone is gay
    huh? where is this world that doesnt care?
    
    Comments
    
    By Not Really Anonymous () on 2002-07-25 05:47
    
    Eventhough I can careless about sexual orientation, your right. The majority (99.9%) of the planet cares about anything that strays from our/their perceived norm.
    
    Comments
    
    By W () on 2002-07-25 07:22
    
    Homosexuality is natural for "them," and it is for all of us. It's normal to be tempted to do things that are wrong. In the same way, pedophiles and adulterers don't make a conscious decision to "choose" that self-destructive lifestyle; they simply give in to their sinful desires.
    
    Comments
    
    By Anonymous Coward () on 2002-07-25 19:37
    
    Homosexuals don't have 'sinful desires'. I used to be homophobic as well and curse with words like 'fag' and 'homo' as well when i were young. I changed my attitude. Same counts for cursing against God which my father tends to do every day.
    
    Comments
    
    By W () on 2002-07-26 19:19
    
    As an eariler individual said, some of us don't get our views from MTV (exaggerated, but there is a little bit of truth in it). It's simply not normal, man.
    
    I would not call myself homophobic. I do not call them 'fags' and use other insults and I treat them as everyone else.
    
    It's nothing wrong with the homosexual, it's his homosexuality there's something severely wrong with.
    
    By Anonymous Coward () on 2002-07-25 15:29
    
    Ya big fag.
By Anonymous Coward () on 2002-07-24 23:42

Can this be done for the heap as well? If not, what would it break?
Comments
1. By Jedi/Sector One () j@pureftpd.org on 2002-07-26 14:14 http://www.pureftpd.org/
  
  It can. On Linux, PAX does it.
2. By Sarah () on 2002-08-01 02:15
  
  I know it's not terribly popular with the kids, but I don't think we want to totally leave out an area for polymorphic code. That isn't going to come until vnodes aren't executable, which probably isn't going to happen, but I think we should just leave it at the stack. As compiliers get more and more interesting and processors have things like branch prediction bits i think it would be nicer to have the option of puting code on the heap as well as under a bunch of kernel and pagers and such.
  
  If anyone can think of an easy way to, given a read-only text and non-executable stack, change execution to whatever they want, maybe I'll think my comment over.
  
  Just to clearify, can someone tell me if this effects both kernel and user stack?
By RC () on 2002-07-25 02:18

I've figured it out! Most ideas given to the OpenBSD team (even if good) will never see the light of day. Obviously, the solution is to do something that publicly embarasses them (as with Apache and OpenSSH), and they will do the stuff that is *not fun*.

Or, maybe they've just finally come to their senses that there will never be secure software, and started implimenting things like this.

Hey, I'm still waiting to see them impliment my suggestion for giving each user their own /tmp folder (to prevent race conditions). And still waiting for TCP/UDP port ACLs (yes, there is a patch that worked with an old snapshot). Port ACLs would allow everything (except SSH) to be run as a user, not Root.
Comments
1. By Anonymous Coward () on 2002-07-25 03:17
  
  > my suggestion for giving each user their own /tmp folder (to prevent race conditions)
  
  ??? You obviously don't know what you talking about...
2. By skull () a on 2002-07-25 03:28 a
  
  there is some merit to this comment. I could have *swore* I've seen some executable-stack-is-crap comments on misc@ from the developers, but what the hey...
  
  and there are other areas where obsd can be improved. so perhaps people could just create their own distributions of obsd just like all the crazy linux distros.
3. By W () on 2002-07-25 07:25
  
  > Port ACLs would allow everything (except SSH)
  > to be run as a user, not Root.
  
  Why don't you put
  
  rdr on if proto tcp from any to any port 80 -> 1.2.3.4 port 8080
  
  in /etc/nat.conf?
  Comments
  1. By W () on 2002-07-25 07:27
    
    > in /etc/nat.conf?
    
    in /etc/nat.conf and configure your software to listen to another port?, that is.
  2. By michael anuzis () on 2002-07-25 16:54 http://www.anuzisnetworking.com
    
    you won't catch apache running as root long enough to exploit it anyway. if you'd look, you'd find the apache children that actually serve people normally run as either "www" or "nobody".
    
    better example would have been ssh, but now with priv sep it's not quite so relevant anymore.
    
    Comments
    
    By W () on 2002-07-26 19:22
    
    That is true. I'm no expert or anything, but I've been told that it's (at least theoretically) possible to "get back to" root. I run all my all my httpd processes as a normal user.
    
    Comments
    
    By jolan () on 2002-07-26 19:59
    
    Not really anymore, since the parent process doesn't even run as root anymore in -current. And it runs inside of a chroot chail a la BIND.
    
    Comments
    
    By W () on 2002-07-26 21:20
    
    Not my httpd. I don't use the OpenBSD httpd; I compile my own from scratch.
4. By Anonymous Coward () on 2002-07-25 07:45
  
  I'm still waiting
  stop waiting, start coding.
  allow everything (except SSH)
  or anything else requiring authentication. and there are already methods to deal w/ this (port redirection, though it's prone to error (race condition))
  Comments
  1. By W () on 2002-07-25 09:41
    
    > there are already methods to deal w/ this (port
    > redirection, though it's prone to error (race
    > condition))
    
    Could you explain the "prone to errer, race condition" part. Thank you! :-)
    
    Comments
    
    By Anonymous Coward () on 2002-07-25 14:08
    
    Could you explain the "prone to errer, race condition" part
    let's say you redirect 8000 to 80 and run apache on port 8000. if apache dies or you restart it, there will exist a period of time while apache is down that a local user may run a version of apache on that port.
    not likely to happen, but possible.
    
    Comments
    
    By W () on 2002-07-25 14:19
    
    I see. Of course. Well, thank you! :-)
5. By Anonymous Coward () on 2002-07-25 15:32
  
  Seriously.
By jose () on 2002-07-25 19:44 http://www.monkey.org/

browsing my OWC today (from earlier in the week), i saw this: ~ freebsd_machdep.c ~ linux_machdep.c ~ machdep.c ~ svr4_machdep.c > Instead of copying out the signal trampoline on top of the stack, create > an uvm aobj, copy out the signal trampoline into it and share that page > among all processes for the same emulation. > This also requires us to actually be able to tell signal code where the > trampoline is located, so introduce a new field in struct proc - p_sigcode > that is a pointer to sigcode. This allows us to remove all the ugly > calculations of the signal trampoline address done in every sendsig > function in the tree (that's why so many files are changed). > Tested by various people. ok deraadt@ the cool thing is this also affects linux, freebsd and sysVr4 emulation binaries :)
By Lamont Granquist () lamont@scriptkiddie.org on 2002-07-26 04:00 http://www.scriptkiddie.org/

This produces no security on x86. Since you pass arguments on the stack in the x86 architecture you can execute arbitrary code, particularly copying shellcode to excutable pages and jumping there. What you will see is just exploits recoded for non-exec exploits on x86. For every exploit out there I'm confident that it can be recrafted into a non-exec exploit.

On the sparc64 and alpha architectures this is a welcome improvement. In those architectures function calls pass their values in registers and that makes exploiting non-exec stacks much more difficult.
Comments
1. By Anonymous Coward () on 2002-07-26 10:50
  
  I'm not sure about the technical merit of your point on the x86 in particular, as I haven't ever had to use it. However, regardless of the platform's merits, all the canned exploits that affect someserver-v.4.3.2 COULD be rewritten, but who's going to rewrite the code for such a small target audience (x86 on obsd?) Like all security, it's just another hoop to pass through, even on x86. If a script kiddie wants to attack my machine, he's SOL, and he's unable to recode the exploit. As for the professional black hat, I have no doubt that he will find a way in to my system, most likely through social engineering.
  Comments
  1. By ChatLog.txt () on 2002-07-26 19:29
    
    SystemAdmin342 :
    
    *** THIS IS AN AUTOMATED MESSAGE ***
    IT HAS COME TO THE ATTENTION OF NETWORK MAINT. STAFF THAT YOUR ACCOUNT IS INCLEDED IN A SMALL TARGET AUDIENCE OF ACCOUNT OWNERS WHOS AUTHORIZATION INFORMATION MAY HAVE BEEN COMPRIMISED. PLEASE VERIFY OWNERSHIP OF THIS ACCOUNT WITH YOUR USERNAME AND PASSWORD
    THANK YOU FOR YOUR COOPERATION IN THIS MATTER YOU HAVE 45 SECONDS TO VERIFY BEFORE ACCOUNT DELETION & REINITIALIZATION.
    PopRoachKid17 : dud fuck off fagot
    SystemAdmin342 :
    
    *** THIS IS AN AUTOMATED MESSAGE ***
    IT HAS COME TO THE ATTENTION OF NETWORK MAINT. STAFF THAT YOUR ACCOUNT IS INCLEDED IN A SMALL TARGET AUDIENCE OF ACCOUNT OWNERS WHOS AUTHORIZATION INFORMATION MAY HAVE BEEN COMPRIMISED. PLEASE VERIFY OWNERSHIP OF THIS ACCOUNT WITH YOUR USERNAME AND PASSWORD
    THANK YOU FOR YOUR COOPERATION IN THIS MATTER YOU HAVE 30 SECONDS TO VERIFY BEFORE ACCOUNT DELETION & REINITIALIZATION.
    PopRoachKid17 : lisen fuckeing queer stop being gay leave me aloen
    SystemAdmin342 :
    
    *** THIS IS AN AUTOMATED MESSAGE ***
    IT HAS COME TO THE ATTENTION OF NETWORK MAINT. STAFF THAT YOUR ACCOUNT IS INCLEDED IN A SMALL TARGET AUDIENCE OF ACCOUNT OWNERS WHOS AUTHORIZATION INFORMATION MAY HAVE BEEN COMPRIMISED. PLEASE VERIFY OWNERSHIP OF THIS ACCOUNT WITH YOUR USERNAME AND PASSWORD
    THANK YOU FOR YOUR COOPERATION IN THIS MATTER YOU HAVE 15 SECONDS TO VERIFY BEFORE ACCOUNT DELETION & REINITIALIZATION.
    PopRoachKid17 : dude okay jesus it's PopRoachKid17/marlbrlsmkr
  2. By I Too, just learned about security () newbie@aol.com on 2002-07-26 19:33 mailto:newbie@aol.com
    
    > for such a small target audience (x86 on obsd?)
    
    HAHA. Riiite. Why don't you go back to your Fortune magazine article where you read up on security theroy and leave this thread alone.
    
    Comments
    
    By Anonymous Coward () on 2002-07-29 17:08
    
    hey, fuck you. there it is.
2. By Sergey Smitienko () hunter@dg.net.ua on 2002-08-29 07:54 www.sergey-smitienko.com.ua
  
  It is posible on x86 to make executable pages marked as read only.

Latest Articles

Sat, Nov 30
- 18:42 Initial list of 21 EuroBSDcon 2024 videos released (0)
- 18:39 Rafael Sadowski on dpb(1) (1)
Fri, Nov 29
- 09:31 -current now has more flexible performance policy (0)
Mon, Nov 25
- 07:13 unwind: wildcard in blacklist (0)
Fri, Nov 22
- 07:33 Game of Trees 0.106 released (0)
Fri, Nov 15
- 06:51 Game of Trees 0.105 released (0)
Wed, Oct 23
- 07:12 Game of Trees 0.104 released (0)
Tue, Oct 15
- 08:46 LibreSSL 4.0.0 Released (0)
Mon, Oct 14
- 07:05 sshd(8) splitting continues (1)

Credits

Copyright © 2004-2008 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 April 2nd 2004 as well as images and HTML templates were copied from the fabulous original deadly.org 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.]