Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security Operating Systems BSD

Stack-Smashing Protection Added To OpenBSD gcc 44

DieNadel writes "As posted here, support to ProPolice was added to OpenBSD. You can check the announcement. Note that THERE ARE dependencies that should be taken care of before building a new kernel, even on -stable."
This discussion has been archived. No new comments can be posted.

Stack-Smashing Protection Added To OpenBSD gcc

Comments Filter:
  • Performance? (Score:3, Interesting)

    by Dan Ost ( 415913 ) on Monday December 02, 2002 @06:33PM (#4796978)
    Does anyone know how this impacts the performance
    of the generated executables?
  • by stab ( 26928 ) on Monday December 02, 2002 @06:55PM (#4797149) Homepage
    Note that THERE ARE dependencies that should be taken care of before
    building a new kernel, even on -stable.


    No, no, no - propolice has only been added into the -current tree, so if you are tracking -stable, continue as before. Only critical fixes go into -stable, certainly nothing as huge as a big GCC patch.
  • by F2F ( 11474 ) on Monday December 02, 2002 @09:24PM (#4798134)
    damn it, why not make the stack grow downwards, like Plan 9 has done? ain't no stack smashing there! hell, no superuser either! (plus private namespaces take care of everything else)

    Spaf: You can't secure a machine with a privileged user.

    • on which platforms do stacks NOT already grow downward?
    • On many architectures, intel included, you can grow the stack in either direction. However, the thing here is that Plan 9 always uses stack-grow-down, and it omits frame pointers. They aren't strictly necessary on Intel either (-fomit-frame-pointers) but it can make code undebuggable. Furthermore, this doesn't fix the problem. If you know how far up the stack to manipulate, by overwriting into the next stack frame, you can still cause Plan 9 to jump to malicious code on return. But then, it probably won't do anything interesting without superuser. ^_^
    • damn it, why not make the stack grow downwards, like Plan 9 has done? ain't no stack smashing there!

      *Ahem*. No matter which way you go, you will hit something eventually. Throw a ton of noops into the stack, followed by the shellcode, and you've exploited an incrementing* stack.

      * Terms like up & down don't work very well when talking about virtual space, as people may envision it differently. You seem to think of a higher memory address as "down"; others do not.

      Spaf: You can't secure a machine with a privileged user.

      That's nice to hear, but I completely disagree. The only problems it has ever caused is the fact that people are lazy and run everything as Root. Run every service as a normal user, remove SUID everywhere possible, and there is no way anyone can break-in, without a very bad kernel bug, or some sort of system misconfiguration.
      • by doug_wyatt ( 532721 ) on Tuesday December 03, 2002 @12:23PM (#4802030)
        Spaf: You can't secure a machine with a privileged user.
        evilviper : That's nice to hear, but I completely disagree. The only problems it has ever caused is the fact that people are lazy and run everything as Root. Run every service as a normal user, remove SUID everywhere possible, and there is no way anyone can break-in, without a very bad kernel bug, or some sort of system misconfiguration.
        That's nice to hear, as well, but there have been numerous instances where the privileged user model has caused security problems. The privileged user model forces you to have more authority than you want when you need to do any number of things. That, combined with resource naming indirection (e.g. filenames to inodes) and race conditions (e.g. if (has_certian_attributes(filename)) { delete(filename); } where someone can change what filename refers to beween the if and the then) has a long a ugly history of allowing non-trusted code to trick trusted (i.e. privileged) code to do Bad Things(tm). And it's not because the privileged code should have been run as a normal user, since there are many things that only root can do.

        Just look at how complicated sshd has had to become to try to prevent these kinds of problems. It's unacceptable that every program which needs to do one minor root-only task needs to be this complicated.

        Systems which use explicit non-indirected resource-specific privilige tokens (so you can bestow on an application the rights to do exactly what it needs to be able to do, and nothing more) are much less susceptible to such bugs/attacks.

        • The privileged user model forces you to have more authority than you want when you need to do any number of things.

          Well, there are some ways around that. Probably the best solution to date is systrace, which can give each application only the privlidges it needs.

          Just look at how complicated sshd has had to become to try to prevent these kinds of problems.

          SSH needs to perform many privlidged operations. It's complexity is both because of that, and because they have gone to great legnths to make sure a serius bug will still not result in exploitation.

          There is now a privlidge seperation library, so a program can utilize that same protection without nearly as much work.
  • by RazzleDazzle ( 442937 ) on Tuesday December 03, 2002 @12:49PM (#4802262) Journal
    They recently got round robin routing included in pf. They also got altq in pf also. They already merged nat.conf into pf.conf. They did a massive suid audit and a major license audit. Now propolice. I though OpenBSD was cool before a lot of this stuff came about. Some things like no-exec code are not available on all architectures though. There is also a calling for more gigabit equipment for furthur and continued testing, read the want pages [openbsd.org] and I believe Nate [mailto] for more precise info, and make sure you contact him to make sure you don't get something already being donated.
    • Don't forget systrace, which lets a program have only the privileges it needs. Check out Project Hairy Eyeball [blafasel.org], which is a collection of systrace policies (some of them from OpenBSD developers themselves). They just released version 1.1 of their policies.

      I'm wondering if there are plans to use systrace to get around the super-user requirement for binding to low ports. That would pretty cool.

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Working...