Executable stacks
n...@xf0rce.dom.de
dear tobias,
dear openbsd fans,
i have followed the discussion on the misc openbsd mailinglist, webarchived
here: http://www.tryc.on.ca/archives/obsd/misc/1999_6/0191.html
i am building hardened leenox servers using both stackguard (immunix.org)
and solar designers patches (ftp.openwall.com) for some time now and
considered switching to openbsd due to some strange conveniences in
glibc which makes use of the heavily abusable gcc trampolines.
i really still miss stack guarding techniques when it comes to openbsd.
stackguard (immunix.org) applies as long as gcc is being used.
2.6 (i have ordered the cds and some t-shirts being true soldier)
still uses gcc, so i am fine. but whats with 2.95 and so on using
egcs? no living person willing to talk to me knows about executable
stack issues when using egcs.
openbsd still has no kernel option to deactivate gcc trampolines,
what i really dislike and miss. :(
is anybody currently implementing such? i am willing to help you,
if you still need somebody.
does anybody have the same thoughts and/or needs?
solutions maybe?
greetings ns
--
ns at dom.de
http://3259848303/
Trevor Schroeder
> Why? It's a workaround slash band-aid solution for the real problem:
> poorly written/audited code. Instead of wasting time with such things, we
> prefer to just fix the bugs.
Because sometimes people like to install software other than that which
comes as part of the base system. It's a nice second tier of defense.
We all agree that the right thing to do is to write good code, but
sometimes that doesn't happen, for various reasons. Just as frequently
(if not more) users do not have the time or the expertise to audit the
code themselves prior to installing the software. Take a look at the
ports tree and how many of the ports actually have a SECURITY file. That
gives you a feel for how much *OpenBSD ports maintainers* actually audit
the code. It's only got to be worse in the general user population.
Take the recent RSAREF2 buffer overflow. OpenBSD got nabbed by that one
too. A single line of defense (code auditing) was breached and could
lead to a complete system compromise. A non-executable stack would have
been a nice backup.
..........................................................................
: "I knew it was going to cost me my head and also my swivel chair, but :
: I thought: What the hell--better men than I have risked their heads :
: and their swivel chairs for truth and justice." -- James P. Cannon :
:........... http://www.zweknu.org/ for PGP key and more ................:
n...@xf0rce.dom.de
i have expressed my further opinions
intensively enough, i think.
greetings ns
On Thu, Dec 16, 1999 at 11:10:39AM -0600, Trevor Schroeder wrote:
> On Thu, 16 Dec 1999, Aaron Campbell wrote:
>
> > Why? It's a workaround slash band-aid solution for the real problem:
> > poorly written/audited code. Instead of wasting time with such things, we
> > prefer to just fix the bugs.
>
> Because sometimes people like to install software other than that which
> comes as part of the base system. It's a nice second tier of defense.
>
> We all agree that the right thing to do is to write good code, but
> sometimes that doesn't happen, for various reasons. Just as frequently
> (if not more) users do not have the time or the expertise to audit the
> code themselves prior to installing the software. Take a look at the
> ports tree and how many of the ports actually have a SECURITY file. That
> gives you a feel for how much *OpenBSD ports maintainers* actually audit
> the code. It's only got to be worse in the general user population.
>
> Take the recent RSAREF2 buffer overflow. OpenBSD got nabbed by that one
> too. A single line of defense (code auditing) was breached and could
> lead to a complete system compromise. A non-executable stack would have
> been a nice backup.
Theo de Raadt
> too. A single line of defense (code auditing) was breached and could
> lead to a complete system compromise. A non-executable stack would have
> been a nice backup.
Huh?
1) The attack didn't work in OpenSSH. That is code we audited. As we've
said before, we fixed the recent RSAREF2 bug BY ACCIDENT. We were not
vulnerable because our proactive code-quality improving process,
resulted in checks being inserted into earlier code, thus making the
problem not happen in the first place.
2) I believe the core-sdi attack places the code it executes in non-stack
memory. (And if it didn't, it's trivial to make it so. Just put the
egg into the attack host's hostname, and voila, there it is, sitting in
the heap inside the DNS routines).
Trevor Schroeder
> 1) The attack didn't work in OpenSSH. That is code we audited. As we've
No, but not everyone is running 2.6 or OpenSSH on < 2.6. I would bet
there are still quite a few ssh-1.2.2x out there, even on OpenBSD. While
SSH was not shipped by OpenBSD, it was recommended software.
> 2) I believe the core-sdi attack places the code it executes in non-stack
[ I'll be honest, I haven't really paid as much attention to this as I ]
[ should have. I'm in the process of finishing finals, moving, finding ]
[ a replacement administrator, and a bunch of other things. I cannot ]
[ speak to the truth or non-truth of this. ]
> memory. (And if it didn't, it's trivial to make it so. Just put the
> egg into the attack host's hostname, and voila, there it is, sitting in
> the heap inside the DNS routines).
Which makes another point (one that I failed to make because I figured it
was obvious): a non-exec stack is not a silver bullet and is no
substitute for good auditing and coding practices.
However, I stand by my original statement that I think it's a nice backup
defense. Having said that, I should also say that I'm not losing a great
deal of sleep w.r.t. the fact that it's not available on OpenBSD. I'm
selective about what network services run on my machine and have it
firewalled like an SOB. I'm not so concerned about local compromises.
Theo de Raadt
> other points we mentioned.
>
> the ports security, full disclosure and the better-than-nothing
> attitude.
what attitude? I don't see any attitude being expressed here.
Please tell us of a buffer overflow that we're missing. That's the
attitude we have -- an uncompromising "give us the bugs so we can fix
it".
I asked the author of immunix if his software had ever found holes.
You know, when a buffer overflow happens, it alerts the user that one
exists. He said no. He's got no bugs to report to us, so that we can
look for them in our source code and fix them. I'm not saying their
software doesn't work, but their process is diametrically headed in
the opposite direction if they don't even spend 5 minutes trying to
find new overflows with it, so that they can be fixed at the source!
> people who know about buffer overflows with executable stacks
> usually know even harder exploits like these dns shellcodes
> you mentioned. ok. we never stated that either solars patches
> or stackguard are 100%-solutions.
Converting an executable stack egg to a non-executable stack egg is
pretty damn easy. Any egg writer could do so in about half a day. In
98% of cases, there's a non-stack buffer in the program which the
person can feed his code into.
We've just never written code to protect the stack, because that's
really difficult.
Dug Song
> i don't want you to copy solars' patches into the openbsd kernel.
> but that would be better than nothing.
it would also be impossible, as his patch is for Linux.
if there were a clean, correct implementation of a non-exec stack for
OpenBSD across all supported platforms (say, controllable by a sysctl), i
think few people would object.
but it's just not a priority for any of the developers. if other people
want to do it, please do, and share it with the rest of us. there's no
reason this can't be implemented outside the OpenBSD tree, maintained, and
supported as a third-party patch.
-d.
---
http://www.monkey.org/~dugsong/
Dug Song
n...@xf0rce.dom.de
> > unfortunately your answer does not address some important
> > other points we mentioned.
> >
> > the ports security, full disclosure and the better-than-nothing
> > attitude.
>
> what attitude? I don't see any attitude being expressed here.
sorry. i referenced e-mails earlier in this thread. you will find
the better-than-nothing attitude somewhere there. mr. schroeder
mentioned the large unaudited ports database ...
i still think executable stack protection is a must.
if administrative thoughts (wasting time on not 100% proof means
of protection) prevent you from attempting this, i accept that.
> Please tell us of a buffer overflow that we're missing. That's the
> attitude we have -- an uncompromising "give us the bugs so we can fix
> it".
i don't know a single one but i have not tried it hard enough, i guess.
> I asked the author of immunix if his software had ever found holes.
> You know, when a buffer overflow happens, it alerts the user that one
> exists. He said no. He's got no bugs to report to us, so that we can
> look for them in our source code and fix them. I'm not saying their
> software doesn't work, but their process is diametrically headed in
> the opposite direction if they don't even spend 5 minutes trying to
> find new overflows with it, so that they can be fixed at the source!
i think success is where we can concentrate all means to a single
goal.
pragmatically/theroretical: - software auditing
and
empirically: - feeding random input to stackguarded
processes with kernel stack protection
turned on
- feeding well designed input to stackguarded
processes with kernel stack protection
turned on
furthermore i have to admit that i didn't view the situation from
your/openbsd's/and other openbsdfans' points of view thoroughly
enough.
i don't want to doubt the attitude openbsd has grown up with.
it positively impresses me, though. and i want to learn from that.
and maybe improve it even.
> > people who know about buffer overflows with executable stacks
> > usually know even harder exploits like these dns shellcodes
> > you mentioned. ok. we never stated that either solars patches
> > or stackguard are 100%-solutions.
>
> Converting an executable stack egg to a non-executable stack egg is
> pretty damn easy. Any egg writer could do so in about half a day. In
> 98% of cases, there's a non-stack buffer in the program which the
> person can feed his code into.
phew. i guess this quote will make me really BAD dreams.
hopefully to some other with more knowledge and ability, too. ;-)
i never saw such an exploit or i missed something really
important. i guess the latter is the case, i admit.
> We've just never written code to protect the stack, because that's
> really difficult.
is it impossible due to some theroretical proven problem or just
hard to implement, because one has to know the kernel, the compiler
and the library as well as their inner workings?
is it possible to implement a secure c development system?
no?
thanks and greets
ns
--
n...@dom.de
http://3259848303/
Aaron Campbell
> executable stacks are a weakness. openbsd obviously still sells it
> as a feature. i know no sensible code that makes use of gcc
> trampolines. if there was sensible code using it, i would
> try to avoid it.
Ok, admittedly I sounded a little defensive in my reply. I look at it this
way. When you start implementing safety nets for bad programming
practices, those bad programming practices just get worse. "Oh, we don't
have to check the buffer bounds here, that nifty new non-executable stack
stuff will protect everyone."
If someone produced a non-stack-executable patch that worked and didn't
break everything I would not object to it. I am simply trying to promote
code auditing practices that have been proven to work well.
Think about it this way. OpenBSD is your house, you keep it nice and clean
looking outside, fertilize your lawn, trim your hedges, and paint it once
a year. Your next door neighbor (the third-party software) is a complete
slob and it makes you look bad. So what do you do first, try to convince
your buddy to shape up, or spend thousands of dollars of your own money to
fix the other house yourself? I think you would choose the former.
.
: Aaron Campbell <aa...@cs.dal.ca> - [ http://www.biodome.org/~fx ]
`-------------------------------------------------------------------
Aaron Campbell
n...@xf0rce.dom.de
> > i really still miss stack guarding techniques when it comes to openbsd.
>
> Why? It's a workaround slash band-aid solution for the real problem:
> poorly written/audited code. Instead of wasting time with such things, we
> prefer to just fix the bugs.
"pride comes before a fall"
i heard openbsd developers are addressing important lacks common in
all current operating systems quite well but being arrogant.
fortunately, this was a prejudice. i have found many good points
in this thread.
i have the opinion to have to switch over to openbsd more
than before.
i still think that guarding the stack is by far more than a
"workaround slash band-aid solution".
especially when i read this quote from the openbsd.org web site:
"Many vendors, even of free software, still try to
hide issues from their users."
did aaron want to hide that openbsd suffers from the same
disadvantages some other operating systems have already
addressed? nobody said that stackguard was complete or
solars patches address all the bugs left.
isn't it more constructive to give in to this and to point out that
there are even worse disadvantages than the one mentioned? i think so.
i hope aaron will forgive me dramaticising the topic and attacking
himself personally. i just did this to kick the thread. this
has worked quite well. thanks again.
ns
On Thu, Dec 16, 1999 at 11:02:50AM -0700, Theo de Raadt wrote:
> > as the openbsd developers, i believe in full disclosure and i
> > hate this hidy-tidy attitude you show about this problem.
>
> I see no such attitude.
>
> Please be careful with the words you use... this sounds nasty.
--
n...@dom.de
http://3259848303/
Trevor Schroeder
> 2. full disclosure
>
> as the openbsd developers, i believe in full disclosure and i
> hate this hidy-tidy attitude you show about this problem.
At the cost of prolonging this thread for little benefit, I would like to
simply say that this is NOT a case of full-disclosure versus
non-full-disclosure.
Nobody is denying that stack buffer overflows are a problem. There is
merely disareement about whether the proposed workaround is really viable
or even worth it.
Marc Espie
>
> > Why? It's a workaround slash band-aid solution for the real problem:
> > poorly written/audited code. Instead of wasting time with such things, we
> > prefer to just fix the bugs.
>
> comes as part of the base system. It's a nice second tier of defense.
>
`Doctor, when I bang my head against the wall, it hurts.'
`Well, don't do that, then.'
--
Marc Espie
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'
Marc Espie
> "Many vendors, even of free software, still try to
> hide issues from their users."
I have a ghost whispering to my shell:
`False sense of security'.
As Theo stated, most eggs that exploit an executable stack problems are
easy to turn into eggs that exploit other buffer overflows.
It is much better to find and remove buffer overflows in the first place.
> executable stacks are a weakness. openbsd obviously still sells it
> as a feature. i know no sensible code that makes use of gcc
> trampolines. if there was sensible code using it, i would
> try to avoid it.
You should go out more often, experience stuff. There is life out of the
C community. Lexical closures are a fairly standard features on lots of
languages, and fairly useful.
kwoo...@codetalker.com
Ah. Well said Trevor.
I've wanted such a beast (stackguard) occasionally, when I've been forced to
run something from ports, and didn't have the time to start auditing it.
The downside, however, is that once you have the tool, you tend to STOP
auditing and reading the code, because you've got it in your head that
the tool will save you.
Still, the whole point is moot until someone with significant motivation
ports, or makes the equivalent for OpenBSD. Talking about it rarely produces
code. (and as theo is prompt to point out, I'm pretty good at talkin'
myself ;-)
-kj
Toomas Kiisk
On Thu, 16 Dec 1999, Trevor Schroeder wrote:
>
> Take the recent RSAREF2 buffer overflow. OpenBSD got nabbed by that one
> too. [..]
Not true, because openssl is not vulnerable to mentioned bug
in rsaref, be it patched or not. Passing longer key than
RSAref_MAX_LEN (1024) to rsa routines ends up with RSAREF_R_LEN.
This holds for ssleay too, at least for versions 0.8.1a and
upwards (I don't have older versions close at hand).
--
vix