Stack-Smashing Protection Added To OpenBSD gcc

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."

Comments

Performance?

[Dan Ost]

Does anyone know how this impacts the performance
of the generated executables?

Re:Performance?

[siliconbunny]

Not as much as smack-stashing does.

yes

[honold]

perhaps you should look at the project web site?

Re:Yes

[Anonymous Coward]

Get your head out of your ass you fucken troll.

Not -stable, only -current

[stab]

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.

Re:Tsarkon Reports: More from this Shit Project?

[Anonymous Coward]

go fuck yourself linus

Yes

[Anonymous Coward]

They're dying

Re:Congratulations!

[Anonymous Coward]

Sorry but you're mistaken.

Re:Tsarkon Reports: More from this Shit Project?

[Anonymous Coward]

FreeBSD is NOT production quality. The -stable branch is laughable at best and StackGuard works ONLY on x86 so what the fuck good is that?

Re:Congratulations!

[Anonymous Coward]

http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/ gcc/ didn't show anything about this. I guess you're wrong.

Why?

[Anonymous Coward]

It's still dying.

Re:Why?

[Anonymous Coward]

You wish it was dying, but that couldn't be further from the truth.

PARENT IS A TROLL - MOD DOWN

[Anonymous Coward]

well isn't this just gosh darn great!

[F2F]

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.

Re:well isn't this just gosh darn great!

[cpeterso]

on which platforms do stacks NOT already grow downward?

Re:well isn't this just gosh darn great!

[F2F]

umm, here is what i mean (see section 4.2)...

Re:well isn't this just gosh darn great!

[evilviper]

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.

Re:well isn't this just gosh darn great!

[James Lanfear]

on which platforms do stacks NOT already grow downward?

Multics, according to a paper I have lying around here somewhere.

Re:well isn't this just gosh darn great!

[doug_wyatt]

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.

Re:well isn't this just gosh darn great!

[Anonymous Coward]

hpux, IIRC.

Re:well isn't this just gosh darn great!

[Anonymous Coward]

*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.

Yes, you'll hit the guard page and segv. The advantage of having your stack grow in the same direction as strcpy(3) is that if you exploit an overflow then you can only overwrite additional buffers in the same stack frame that happen to be allocated after the buffer which is overflowing. Take, e.g.:

int
foo(char *in)
{

char buf[128];

strcpy(buf, in);

}

Now, sure you can overflow that. But if you do manage to get a long string passed into it, what are you going to do with it? The strcpy(3) will happily overwrite not-yet-allocated stack, which is no problem because it has no semantic meaing, and before the strcpy(3) gets to the heap or any mmap(2)ed pages it will hit the stack guard page.

Granted, there are still many overflow exploits that you can pull on incrementing stacks, but some of the easiest ones are gone such as the above example. The incrementing stack makes some errors non-exploitable and so is a bit better than the traditional stack.

It is also interesting to note that StackGuard is mainly interested in preventing stack smashing attacks, which are not an issue with an incrementing stack because the return address is below the locally allocated buffers and hence strcpy(3) et al. will not reach them. It is a faster and arguably more secure method than placing canaries around the return address.

Re:well isn't this just gosh darn great!

[evilviper]

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.

Re:Congratulations!

[Anonymous Coward]

Sorry but you're mistaken.

yeah no shit. that should have read "it's been available for FreeBSD since 4.3" not 4.4. sheesh.

damn trolls cant get their flame attacks right;
i hate this job.

Re:Tsarkon Reports: More from this Shit Project?

[Anonymous Coward]

Hahahaha. Laughable. Totally laughable fucking bull.

And what stable OS might you be using? I'd like to hear it.

If FreeBSD isnt production quality why is it in Juniper Routers? Oh, silence coming out of your mouth. Either you know what a Juniper is and does, or you are too fucking dumb to know what it is/does.

It has nothing to do with stack growth direction.

[Ayanami Rei]

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. ^_^

Yes, I'm biting. I guess I lose.

[Anonymous Coward]

48 of the 50 longest uptime web sites running FreeBSD or a derivative thereof seems pretty stable to me.

Re:Tsarkon Reports: More from this Shit Project?

[Rheingold]

I really shouldn't respond to trolls, but I guess I am anyway. StackGuard is only currently implemented on x86, but I don't think it actually depends on any x86-isms; likewise, even though it is currently only implemented in Linux, it doesn't really depend on any Linux-isms. It's only limited to Linux x86 because that's all anyone with time or money ever bothered to implement it on. I'm told that a GCC 3 implementation is nearly done. I ask about it everytime I venture downtown to have lunch with the WireX folks (I used to work there, but not in the research side).

OpenBSD has lots of new coolness

[RazzleDazzle]

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 and I believe Nate for more precise info, and make sure you contact him to make sure you don't get something already being donated.

Re:OpenBSD has lots of new coolness

[almeida]

Don't forget systrace, which lets a program have only the privileges it needs. Check out Project Hairy Eyeball, 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.

Re:BSD IS DYING!

[Anonymous Coward]

You seem to have forgotten a lot of embedded systems in your statistics; e.g. Nokia Firewalls.

And BSD derived systems like JunOS and MacOS X.

Re:Tsarkon Reports: More from this Shit Project?

[Geekboy(Wizard)]

StackGuard is only currently implemented on x86

Hmm...then how come I have it on my OpenBSD/macppc system?

As for GCC3, well, check http://www.trl.ibm.com/projects/security/ssp/statu schart.html

No

[Anonymous Coward]

The truth is it's dying. And so are you, responding to the cheapest of throwaway trolls.

Re:Tsarkon Reports: double fucknut?

[Anonymous Coward]

Let me get this right. So Mac hardware user and uses OpenBSD...

That must make you a D-Link network card lover and a fucking real asshole, double-fucktard with a cherry on top.

Now stretch your manpussy and take it good, rimmer. You fat fucking homo sexless piece of shit RPG poor state subsidy welfare recipient IDE lover cant afford shit food stampist fat bitch.

Meanwhile

[Anonymous Coward]

The story of Microsoft claiming to be less expensive that Linux has over a thousand posts. Maybe Theo should star saying "we cost more than M$!" and get a thousand fold attention increase. Oh, wait... that will never fly.....

Re:Meanwhile

[Anonymous Coward]

It IS more expensive, if you count the personal cost of dealing with Theo's elephantine ego.

Re:Tsarkon Reports: More from this Shit Project?

[Apathy costs bills]

Any chance we'll see StackGuard for Sparc architecture?

Re:Tsarkon Reports: More from this Shit Project?

[Rheingold]

There's a chance, if someone is willing to port it or maybe if Sun funds it. But the SPARC architecture, while interesting technologically, isn't interesting economically (hence the fact that many of the commerical distros have stopped supporting it) as a Linux platform. Plus, according to the link above, IBM has something based on SG that seems to be already on SPARC.

patent

[Anonymous Coward]

I heard a rumor that ProPolice is patented.
Don't know if it's true.