Buffer overflow prevention
Theo de Raadt
> i think the comparison should be like "how much more does wOpenBSD lacks
> compared to PAX ?"
>
> he might try to mean whatever but there is one thing obvious which is best
> known as "rip-off"
>
> i think you should read this instead:
> http://archives.neohapsis.com/archives/openbsd/2003-04/1681.html
>
> - noir
>
> w as in http://stargliders.org/phrack/mmhs.jpg
I have made it clear many times that W^X inside OpenBSD came into
being without me even being aware of PAX.
I may have stumbled past HAL2001 on my way from IETF in London to
Usenix Security in DC, but I never went to any of the talks there, and
I do not recall ever talking to anyone about anything in any way like
W^X. I spent most of the time talking with European OpenBSD
developers and Solar Designer, and do not recall any topics about
protecting the address space ever coming up. Almost a year later, we
started working on W^X. We started on non-i386 machines like the
sparc and alpha because at the time we could not think of a way of
doing i386 W^X.
If we had been aware of PAX as you claim, why would we have thought
that i386 solutions were impossible?
There is only one thing I have found the various PAX people to have in
common; they are very persistant at calling other people liars. Can
you people please grow up?
page...@freemail.hu
From: Theo de Raadt <deraadt () cvs ! openbsd ! org>
Date: 2003-08-14 21:43:10
> > It's not difficult at all on x86, but having non-overlapping Segments
> > for Code and Data/Stack would limit the virtual address space.
>
> I am not sure if you have heard of this neat technology called "shared
> libraries". Either you have never heard of them, or you are unaware
> of they work on an x86. Let me be completely blunt. What you are
> suggesting is unfeasable. Please go do some learning before making
> any more utterly ridiculous proposals.
Oh, the strong words of a strong man ;-). Seriously, you are wrong, the
segmentation based non-executable pages feature of PaX (SEGMEXEC [1]) does
exactly this, it creates separate (non-overlapping) segments for data/code
and has no problems with coping with shared libraries (the key to this is
vma mirroring [2]).
[...]
> Anyways, on an i386 you can do W^X somewhat. Not as perfectly as you
> can on cpus that have a per-page X bit...
You are wrong again, PaX provides perfect per-page non-executable pages
using segmentation (SEGMEXEC), there are no restrictions on the ordering
of data/code pages like in OpenBSD.
[...]
> This would give per-page execution stuff like we have on better cpus.
> We've not worked on this yet; it is less valuable since I think it is
> only newer Xeons and high-end AMD cpus which support this. And we've
> never found documentation for it either :)
Page 286 in [3] and section 5.6 in [4] have enough information about this
feature (and of course linux 2.4/2.6 source code).
[1] http://pageexec.virtualave.net/docs/segmexec.txt
[2] http://pageexec.virtualave.net/docs/vmmirror.txt
[3] http://www.amd.com/us-
en/assets/content_type/white_papers_and_tech_docs/26094.PDF
[4] http://www.amd.com/us-
en/assets/content_type/white_papers_and_tech_docs/24593.pdf
Mark Tinberg
Hash: SHA1
On Fri, 15 Aug 2003, Peter Busser wrote:
> > The only way to sleep quietly is still to audit the code at the first place.
>
> The only way to sleep quietly in fact is to feed your computer to a shredder.
>
> Auditing code alone will not provide much security. In fact, it will lead to a
> false sense of security. The problem is that a modern UNIX system is that it
> contains millions of lines of code. Auditing this amount of code is simply
> impossible. Furthermore, auditors are humans. Humans make mistakes, not only
> when they are programmers, but also when they are auditors. So audited code
> will still contain security bugs.
>
> In fact, the amount of security in OpenBSD is only slightly less horrible than
> that of most *NIX operating systems (which includes Adamantix for that matter).
Thank you for bringing up this point. ISTM that expecting all
security-critical userspace code to be audited to perfection as a
prerequisite to system security is foolish. No one, not even the most
intelligent and knowledgeable security guru can write every program to be
perfectly secure all the time without fail.
I don't know how many times I've heard "You should write secure programs,
the only solution for system security is to write programs that are not
susceptible to (buffer overflows, heap overflows, format string, etc)
attacks." This is an impossibility and a bit of self-abuse to keep
repeating this mantra. Repetition won't make it true.
Again, ISTM that the only way to get close to a reasonably secure system
is to only rely on the smallest, most audited codebase possible to enforce
security policy. To me this means something enforced by the kernel
itself, like standard POSIX permissions and capabilities, NSA Flask,
Systrace, SubDomain, LIDS, GRSecurity, etc. (note that this is not a
particularly accurate list). For example one thing that could be done is
to automatically build bare-bones systrace profiles at compile time so
that any attempt to use a syscall not specified in the source causes the
program to immediately abort. Not a catch-all, but something that raises
the bar.
In any event, implementing the above is a far more complicated affair than
can be accomplished by even an intelligent, knowledgeable and dedicated
sysadmin. The only way that there will be significant uptake of more
comprehensive access control/policy enforcement systems such as the above
is if they are correctly configured and included by the OS manufacturer.
OpenBSD seems to be taking the right approach here by developing systrace
and including systrace profiles for the base system, which is much better
than the previous approach of trying to perfect the crufty and inadequate
UNIX "security" model.
I'd like to see the other major OS distributors, Microsoft, RedHat, SuSE,
Sun, IBM, Novell, etc. take an active part in this and not only provide
systems with advanced security controls, but also ship them fully
configured rather than relying on the system administrator who can't
possibly understand the system well enough to fully configure them.
- --
Mark Tinberg <MTin...@securepipe.com>
Network Security Engineer, SecurePipe Inc.
New Key fingerprint = FAEF 15E4 FEB3 08E8 66D5 A1A1 16EE C5E4 E523 6C67
Your daily fortune . . .
Watson's Law:
The reliability of machinery is inversely proportional to the
number and significance of any persons watching it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/
iD8DBQE/PYqrFu7F5OUjbGcRArfFAJsEbws18Ngj78ZfPpwaT+c0PGSjVgCePcES
agepSknw833x7altZ7VFLYc=
=tjsu
-----END PGP SIGNATURE-----
page...@freemail.hu
> common; they are very persistant at calling other people liars. Can
> you people please grow up?
Can you provide the evidence where we called you or other people a liar?
Does your calling other people's ideas ridiculous (and being wrong on it
too, see another mail, if it gets through) make you a grown up?
Crispin Cowan
>I think it's generally accepted that homogenity breeds insecurity, in
>which case it makes sense to try to be as different from everyone else
>as possible even if that doesn't make it impossible for someone to break
>you.
>
That is a commonly held view, but I would not say it is widely accepted.
I certainly don't accept it.
Heterogeneity increases survivability of the *species*, but does little
to protect the individual. A site manager seeking to protect their own
servers cares little if an attack that takes them down doesn't take down
their competitors. In fact, it's kind of bad if heterogeneity means that
you go down and your competitors don't. At most, you could say that
running the most common system makes you somewhat more vulnerable to
attack, and you should take that into consideration when planning your
security.
So heterogeneity is really just security by obscurity, dressed up to
sound pretty. It also comes at a cost: in direct proportion to the
security benefits of running an obscure system is elevated operational
costs due to incompatibilities induced by your diversity. Exactly what
those incompatibility costs are varies according to the ways in which
you diverge from others. For that matter, so do the security benefits
vary according to what aspects of your system you diversified.
So before spending a bucket of $ on contrived diversity, consider
spending that $ on actual security mechanisms: you will get a much more
predictable ROI.
Caveat: there is a gray spectrum between natural diversity (Windows vs.
Linux vs. BSD) and synthetic diversity (PAX/ASLR, PointGuard). The
former are diverse, but the ways in which they are divers are rigidly
fixed aspects of system architecture, and cannot be changed. The latter
use cryptographically secure random numbers (to the extent possible) to
provide per-instance diversity that is readily changed, much like crypto
session keys. Cryptography itself is just a form of obscurity, albeit
with some very important properties surrounding key management.
Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Chief Scientist, Immunix http://immunix.com
http://www.immunix.com/shop/
Shaun Clowes
> Shaun Clowes wrote:
>
> >Perhaps I'm the only one who feels this way, but I believe that the vast
> >majority of the exploitation of systems is being performed by people
> >with no knowledge of how to write an exploit and that the vast majority
> >of exploits are fragile. Doing anything that makes you different from
> >every other installation of Linux/HPUX/Solaris/InsertOSHere will
> >drastically decrease the changes of any point and click exploit working
> >against you.
> >
> >Could a determined (and knowledgable) attacker still get through? Sure.
> >But if we're talking protections that take very little effort to
> >implement, have a minor performance impact and will save your
> >skin some of the time, it's obvious that it's worth deploying them. As
> >long as you're not kidding yourself that you're then totally secure.
> >
> Exactly: trivial changes will protect you from script kiddies.
> Non-bypassability is required to protect you from determined attackers.
> It depends on your threat model: how much will a penetration event cost
> you? What is it worth to someone to hack you?
Well, you've immediately eliminated 90% or more of the threat, so it's a
good start. In any case, if we are talking about the famous determined
attacker it's reasonable to assume that they are going to get you no
matter what you do and that you need to carefully consider methods of
reducing the damage from intrusion (rather than betting on stopping the
intrusion all together).
> >Its kind of reminiscent of that old joke about the two guys running away
> >from the lion. You don't have to beat the lion, just the other person.
> >
> But if you taste better (you are a bank and he is a basement RH box)
> then the lion may choose to chase you anyway.
If I'm the bank I'm probably running Solaris, HP-UX, AIX, Irix etc, in
which case I don't even have the option of PaX etc. I would deploy any
kind of protection technology I could find (including non-executable
stack, moved library images etc).
There is no such thing as a perfect protection, and most of the
protection technologies that have been discussed in this thread are
worth considering. It would seem most pragmatic to deploy whatever you
can in your environment.
I think it's generally accepted that homogenity breeds insecurity, in
which case it makes sense to try to be as different from everyone else
as possible even if that doesn't make it impossible for someone to break
you.
Cheers,
Shaun
page...@freemail.hu
From: "Eygene A. Ryabinkin" <rea () rea ! mbslab ! kiae ! ru>
Date: 2003-08-13 10:28:33
> So, my suggestion: let us organise two segments: one for normal
> stack, growing downwards, referenced by SS:ESP pair and the second
> one, for local variables, referenced by GS:EBP pair, with either
> upwards or downwards growing.
[...]
> Second, rewrite the compiler to support the new scheme of local
> variables addresation. So, the changes are minimal, in some sence.
As soon as you create two segments with different base addresses you
will have to increase the size of the internal pointer representation
(to store or at least identify the segment in which the given pointer
as a logical address is valid), otherwise functions taking pointers
would not be able to tell in which segment to dereference a given
pointer value. This change will open a whole can of worms, it's
definitely not a minimal change as you suggest and if you go to this
trouble, you might as well go for full bounds checking.
Mariusz Woloszyn
> > Anyways, on an i386 you can do W^X somewhat. Not as perfectly as you
> > can on cpus that have a per-page X bit...
>
> You are wrong again, PaX provides perfect per-page non-executable pages
> using segmentation (SEGMEXEC), there are no restrictions on the ordering
> of data/code pages like in OpenBSD.
>
BTW: have anyone tried to talk wih Linus about implementing some PaX (or
even GR) functionality in official Kernels?
I know that the argument for not implementing Solar Designer's
nonexecutable stack patch in official kernel was that it is easily
bypassable, so what about PaX???
I hate seeing GOT and other segments rwx nowdays (while it's marked as r-x
it IS executable).
--
Mariusz Wołoszyn
Internet Security Specialist, GTS - Internet Partners
Crispin Cowan
>>Heterogeneity increases survivability of the *species*, but does little
>>to protect the individual.
>>
>>
>What you're not taking into account is contagion. Amongst a
>homogeneous population, a pathogen that infects your friends can
>likely infect you. Amongst a heterogeneous population, if the same
>pathogen infects a friend, there's a significantly lower probability
>it can infect you.
>
To the contrary, I did take this into account in the portion of the
quote that you cut:
A site manager seeking to protect their own servers cares little if
an attack that takes them down doesn't take down their competitors.
In fact, it's kind of bad if heterogeneity means that you go down
and your competitors don't. At most, you could say that running the
most common system makes you somewhat more vulnerable to attack, and
you should take that into consideration when planning your security.
Running more common species makes you more vulnerable.
>How does this affect networks? Well, if you're a webserver or
>mailserver that talks to everyone, the heterogeneity doesn't buy you
>so much (other than, as you said, there might be more pathogens for
>popular systems). But if you're configured to not talk to the whole
>world (via a firewall, or something equivalent), then you're a whole
>lot safer if the machines you do communicate with are different from
>you in ways that make contagion harder.
>
As I said the last time the bio analogy came up, analogies are like
goldfish: sometimes they have nothing to do with the topic at hand. The
notion of being non-promiscuous and careful about who you talk to does
not work here: non-vulnerable Linux mail servers are fully capable of
passing virus-infected mails to vulnerable Windows clients. Firewall
mailing lists are currently full fo sorry stories about Blaster coming
in through VPNs, even though the firewall was blocking the right ports
from the outside.
Peter Busser
> If we had been aware of PAX as you claim, why would we have thought
> that i386 solutions were impossible?
You have thought that i386 solutions were possible, because you have
implemented them.
> There is only one thing I have found the various PAX people to have in
> common; they are very persistant at calling other people liars. Can
> you people please grow up?
I'd say that the one thing that ``the various PaX people'' have in common is
that they use PaX. I believe I am one of them and I don't call you a liar. I
also know others who probably fit your definition who do not call you a liar.
You get rewarded for working on OpenBSD by donations and by selling CDs. For
other people the only reward is often public acknowledgement. The way you have
presented W^R to the world, i.e. as if there was nothing like it on this planet
does not acknowledge the hard work of others. Hard work that implemented what
you thought was impossible before you even started thinking about it. I would
say that is impressive, don't you think so? When people contacted you about it,
you treated them in a manner that was not exactly what one might expect from
a grown-up person.
Groetjes,
Peter Busser
--
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world
http://www.adamantix.org/
Crispin Cowan
>Thank you for bringing up this point. ISTM that expecting all
>security-critical userspace code to be audited to perfection as a
>prerequisite to system security is foolish. No one, not even the most
>intelligent and knowledgeable security guru can write every program to be
>perfectly secure all the time without fail.
>
I agree whole heartedly. It is interesting to see OpenBSD transition
from a stance of "audit is the only way" to actually employing access
control and intrusion prevention technologies. It is tough to change
your mind on big issues when you have a big public record to live down,
so I don't particularly want to abuse Theo for making this policy
change. I just want to tease him for choosing ProPolice instead of
StackGuard without so much as talking to me :)
>Again, ISTM that the only way to get close to a reasonably secure system
>is to only rely on the smallest, most audited codebase possible to enforce
>security policy. To me this means something enforced by the kernel
>itself, like standard POSIX permissions and capabilities, NSA Flask,
>Systrace, SubDomain, LIDS, GRSecurity, etc. (note that this is not a
>particularly accurate list). For example one thing that could be done is
>to automatically build bare-bones systrace profiles at compile time so
>that any attempt to use a syscall not specified in the source causes the
>program to immediately abort. Not a catch-all, but something that raises
>the bar.
>
David Wagner and Drew Dean had a very nice paper at Oakland 2001 on
that. Their static analyzer constructed an automata of valid states the
program could be in, and a run-time monitor watched the program execute.
If the program ever did a state transition that the automata didn't
like, the automata would kill the program. The effect is to enforce that
the program only execute compliant with its source code, effectively
blocking all but the most subtle malcode insertion.
Intrusion Detection via Static Analysis
<http://www.cs.berkeley.edu/%7Edaw/papers/ids-oakland01.ps>
David Wagner and Drew Dean. 2001 IEEE Symposium on Security and
Privacy <http://www.ieee-security.org/TC/sp2001.html>. [pdf
<http://www.cs.berkeley.edu/%7Edaw/papers/ids-oakland01.pdf>,
slides
<http://www.cs.berkeley.edu/%7Edaw/papers/ids-oakland01-slides.ps>]
Theo de Raadt
>> that i386 solutions were impossible?
>
>You have thought that i386 solutions were possible, because you have
>implemented them.
Can you please stop spinning this?
W^X was up and running on some of our architectures before we had
heard of PAX.
Months later, ways of doing W^X for i386 were discussed, but this was
also before we had heard of PAX.
Even later, W^X was starting to work on i386, but even this was before
we had heard of PAX.
And finally, as you guys keep saying: W^X does not do what PAX does!
In essence, PAX attempts a best-effort of mapping existing and unchanged
Linux binaries (except for marking) so that they are mapped best for
security. They do this by changing almost only kernel code.
In essence, the OpenBSD method attempts to make changes through the
entire system so that userland binaries are better organized and so
that kernel changes can be reduced or simplified. For instance, the
most complicated component of the W^X changes is not the kernel
modifications, but the changes to binutils and ld.so to map binaries
more carefully! OpenBSD/i386 3.3 binaries will not easily run on an
OpenBSD/i386 3.4 system, and if they do run, they will NOT HAVE
PROTECTION! This is something the PAX people knew the Linux community
would not accept; having entirely different constraints caused us to
take an ENTIRELY different approach to these problems.
W^X does not do what PAX does; rather, W^X attempts to solve many of
the same problem AREAS, but using entirely DIFFERENT SOLUTIONS.
Yet, persistantly we have been flooded by PAX supporters demanding
that we should give credit to the PAX people for the ideas in W^X.
When we had NOT known about PAX, and when W^X does NOT technically do
what PAX does.
How is it that out of one side of the mouth PAX people say that things
which I say are not possible on i386 using W^X (full per-page X bit) are
possible using PAX, and then the other side of the mouth says that W^X
is just derived from PAX ideas?
Holy cow, can you guys please stop crowing for me to revise history!
>> There is only one thing I have found the various PAX people to have in
>> common; they are very persistant at calling other people liars. Can
>> you people please grow up?
>
>I'd say that the one thing that ``the various PaX people'' have in common is
>that they use PaX. I believe I am one of them and I don't call you a liar. I
>also know others who probably fit your definition who do not call you a liar.
>
>You get rewarded for working on OpenBSD by donations and by selling CDs. For
>other people the only reward is often public acknowledgement.
Oh? So to get their reward, they send out their drones to assault other
projects, and get credit that is not theirs?
It is clear that W^X was developed without knowlege of PAX; it is clear
that this is a case of two solutions to a similar problem space -- call it
convergent evolution; it is clear that begging for credit is just making
your efforts look more and more political and less and less techical.
I urge the PAX authors to get their community's rabid foaming under control.
In attack after attack posted to our mailing lists, we were not being asked
to say that the ideas from the PAX people predated the ideas in W^X. No, no!
We were being told to say that W^X ideas were *COPIED* from PAX, when
we had no idea that such a thing as PAX even existed! Furthermore, there are
difference in approach between W^X and PAX which are so fundamental that
it is clear we did not copy from PAX! Like, our idea that mprotect should
still permit a user to request a page that is PROT_EXEC|PROT_WRITE; by default
the PAX people prefer to deny such requests.
>The way you have
>presented W^R to the world, i.e. as if there was nothing like it on this planet
>does not acknowledge the hard work of others.
We informally (in mail to lists, etc) presented W^X to say we have
shipped a system that does this and this and that, to improve
resistance against exploitation of bugs, in concert with ProPolice.
If you look at the PAX web and other much more formal documentation,
you will find that they do not mention W^X.
If you look at Crispin's StackGuard papers, you will not find a
mention of ProPolice -- which is clearly a better StackGuard. Why
should we mention PAX? It does not influence what OpenBSD users
encounter. Are Linux people being specifically told "This is PAX,
like W^X in OpenBSD"?
>Hard work that implemented what
>you thought was impossible before you even started thinking about it.
So? If our efforts were parallel, without any communication, how can I
give them credit? You want me to say that W^X is based on PAX, right?
You want me to lie. Get stuffed! I will not make that lie which you want
me to make.
W^X was invented because we saw the need for it. We had no idea that anyone
else was working in the same area.
Your continued insistance that we knew of PAX is making you look ridiculous.
>I would
>say that is impressive, don't you think so? When people contacted you about it,
>you treated them in a manner that was not exactly what one might expect from
>a grown-up person.
I have seen about 50 mails from PAX developers or PAX-associated developers or
users insisting that we say that W^X is a PAX derivative. I continue to tell
them that I will not agree to such revisionism.
I will not revise history to make your ego feel less bruised.
>Groetjes,
>Peter Busser
>--
>The Adamantix Project
>Taking trustworthy software out of the labs, and into the real world
>http://www.adamantix.org/
Competing against OpenBSD security efforts, but starting out 6 years later...
noir
> If we had been aware of PAX as you claim, why would we have thought
> that i386 solutions were impossible?
because of POSIX compliance obsesions ? or incompetiance ?
you name it.
>
> There is only one thing I have found the various PAX people to have in
> common; they are very persistant at calling other people liars. Can
> you people please grow up?
>
i have no affiliation with the PAX or grsec team other than being a user
of it. please do not make assumptions.
PAX people ? what is that supposed to mean ? it is only OpenBSD "people"
that are into cultism. i guess you be the fake jesus ? please grow up and
leave your fanatical ways behind.
- noir
a good poet once said: netbsd with bunch of strlcpy ...
Darren Reed
> that we should give credit to the PAX people for the ideas in W^X.
> When we had NOT known about PAX, and when W^X does NOT technically do
> what PAX does.
>
> How is it that out of one side of the mouth PAX people say that things
> which I say are not possible on i386 using W^X (full per-page X bit) are
> possible using PAX, and then the other side of the mouth says that W^X
> is just derived from PAX ideas?
> Oh? So to get their reward, they send out their drones to assault other
> projects, and get credit that is not theirs?
> I urge the PAX authors to get their community's rabid foaming under control.
Damn, this looks like textbook OpenBSD methodology for getting a vendor
to release hardware documentation or otherwise do what OpenBSD wants.
I guess it's a methodology that's only acceptable when it's being done
for the "noble" goals of the OpenBSD project and not when it is being
targetted at OpenBSD itself.
I suppose you might say this is a case of OpenBSD getting back what it
dishes out to others.
I sincerely doubt that this will have any impact, however, on the behaviour
of the OpenBSD drones. But one can still hope.
Now if I could think of a security-related angle, this email might even
have a chance of ending up being sent to the bugtraq list...
(o)
Theo de Raadt
>from a stance of "audit is the only way" to actually employing access
I persist in my belief that policy-based mechanisms do not improve
security. If you cannot make a default policy that everyone can live
under, you are creating a trap:
90-99% of people use the default policy, because they do not
change it
if that policy is restrictive, you have made a decision that
security is more important than useability
if that policy is not restrictive, you have made a decision that
useability is more important than security
(then there is also the issue of "it is restrictive towards what")
The trap I talk of is the one where you believe that security
technologies which make such a tradeoff (security vs useability) are
useful. They're useless! These things are buttons for experts, for
tweakers, for only security concerned people, to be used only by those
who feel threatened, and at best can only be used in SPECIFIC
instances. I do not know why there is so much emphass on such crap
tech from some parts of the community (research?) when it is clear
that the best technologies "just work" (translation: why do
researchers research crap "smart" tech instead of dump tech that just
works?). I still believe very strongly that efforts directed at
"security technologies that only experts can use" matter far less than
"security techologies that invisibly improve everything".
>It is tough to change
>your mind on big issues when you have a big public record to live down,
>so I don't particularly want to abuse Theo for making this policy
>change.
Hah, there is no public record to live down. Nor a policy change,
since we still audit code (with more emphasis on "audit means to
improve wholesale"). We also modify a lot of software for
priv-seperation or priv-revocation these days, to internally improve
specific application's resistance against successful exploitation (for
the situation of: it has a bug, but if you can exploit it, you gain
much less). Since we have more people interested in other areas, we
can expend efforts in other directions as well.
> and intrusion prevention technologies.
I translate this to mean that when some random bug does exist, system
features exist which decrease the ease with which it can be exploited.
ProPolice, StackGaurd, non-executable objects, random object addresses
-- these kinds of things fall in that area. Such mechanisms must be
automatic and always on. They must be very cheap. They must not
break any part of POSIX or another defacto standard . I repeat - they
must NOT break any part of POSIX; when developers have as much trouble
understanding the interactions between POSIX, please do not make
interactions that are even MORE magical.
One of these days someone is going to use the magic of a system call
interposition mechanism such systrace; and for their application
accidentally create an operating system behaviour that is un-POSIX,
and some application is going to misbehave as a result of that change
and inadvertantly this will result in the CREATION of a hole. Be very
careful when people tell you that their magic solutions are right.
The programs we run expect the system to act in a POSIX way -- and
consistantly too; but those who are writing policies do not understand
the details of POSIX. Details matter more than anything else. Like a
gun, these things create an process environment which is "POSIX
maybe".
There are things that can be done inside libc too, such as the atexit,
stdio, and malloc modifications we have. Or inside ld.so, where W^X is
done for the GOT and PLT. Some of this is fun, other stuff is really
difficult.
>I just want to tease him for choosing ProPolice instead of
>StackGuard without so much as talking to me :)
Hah, on the contrary, I chose ProPolice because I had talked to you. At
least three times over the last five years I asked you if StackGuard
had ever found a bug in software. Not a security hole, no... I was
asking if a system compiled entirely with StackGuard had resulted in
someone finding bugs, something inane like a buffer overflow in cat or
ls or nroff or something minor. It is clear these bugs do exist.
Come on.. programs dump core all the time! Bugs which had not been
found another way yet, but bugs that were found because a user or
programmer suddenly had StackGaurd abort their program due to such a
bug. You replied "no" twice, and if I recall correctly the third time
you just ignored my question (CHATS in Napa).
Since we incorporated ProPolice into OpenBSD, we have found many bugs
of this ilk. We've even found 2 buffer overflows inside our kernel.
These were not as such security holes per se, but just bugs. This means
the technology is working.
If any security technology shows no success at finding other related but
minor bugs, I really just don't see the point.
(We've found a few other such "minor bugs" with W^X too)
At some point, any serious technology must show side effects that also
help improve quality, or there is something wrong. I've been told by
a few people (who understand this area better than I) that StackGuard
puts the canary in the wrong place (maybe that has been fixed in the
meantime) I do not know if that is related.
We chose ProPolice for three other reasons:
1) it also re-organizes the local stack frame to put buffers closer to
the canary; non-buffer objects therefore cannot be overflowed without
a hit on the canary. i think this is the other fantastic part of
ProPolice rarely mentioned; I think the consequences of this change
are fantastic.
2) ProPolice is multi-architecture -- mostly portable code. Support exists
for at least i386, vax, m68k, sparc, sparc64, alpha, mips, powerpc. the
author is apparently working on the difficult task of supporting hppa.
3) the author is very eager. Since ProPolice was not yet bug-free
at the time we integrated it, we needed direct interaction with
the author to get some of the last problem areas fixed.
ProPolice impresses me. StackGuard did not, because it has not found bugs.
>>Again, ISTM that the only way to get close to a reasonably secure system
>>is to only rely on the smallest, most audited codebase possible to enforce
>>security policy. [...]
whenever I see the word 'security policy' everything after it starts to
sound a lot like 'blah blah blah maybe NSA or DOD will give me money' and
my brain fades out...
(sorry, perhaps that is a little bit strong)
Peter Busser
> > In fact, the amount of security in OpenBSD is only slightly less horrible than
> > that of most *NIX operating systems (which includes Adamantix for that matter).
> Again, ISTM that the only way to get close to a reasonably secure system
> is to only rely on the smallest, most audited codebase possible to enforce
> security policy.
I think you are right about that.
> To me this means something enforced by the kernel
> itself, like standard POSIX permissions and capabilities, NSA Flask,
> Systrace, SubDomain, LIDS, GRSecurity, etc. (note that this is not a
> particularly accurate list).
And this is in contradiction to the above, because normally, *NIX kernels do
not fit the ``smallest, most audited code base possible''. *NIX kernels are way
too big and too complex to be seriously audited. That is exactly why I say that
the if you believe that OpenBSD provides more security than others, it can only
be slightly less insecure compared to other *NIX systems.
There is no proof that adding security to a *NIX kernel afterwards results in a
highly secure system. It is like putting a powerfull engine in a family car and
then claiming it is a formula 1 racing car. It simply isn't because it wasn't
designed to be a F1 racing car. Similarly claiming that a *NIX system is
``secure'' is either a sign of ignorance or an attempt to deceive people (or
both :-).
> In any event, implementing the above is a far more complicated affair than
> can be accomplished by even an intelligent, knowledgeable and dedicated
> sysadmin. The only way that there will be significant uptake of more
> comprehensive access control/policy enforcement systems such as the above
> is if they are correctly configured and included by the OS manufacturer.
Agreed, that is why the Adamantix project was started, to create a distribution
that provides this.
> OpenBSD seems to be taking the right approach here by developing systrace
> and including systrace profiles for the base system, which is much better
> than the previous approach of trying to perfect the crufty and inadequate
> UNIX "security" model.
Well, it is quite elegant, I wouldn't call it crufty. And it was adequate for
an environment with only trustworthy users (including the system
administrator). It clearly wasn't designed for the kind of environment people
find themselves in on the Internet today. For that it is horribly insufficient.
Anyway, I always thought that perfecting this, what you call, crufty and
inadequate UNIX ``security'' model, is exactly what OpenBSD has been putting a
lot of effort in so far.
As far as Systrace profiles go: Personally, I'd rather have profiles for a
useful system, and not just for a base system. Furthermore, systrace is too
low level and too inflexible to be useful, which makes it too complex. That is
why it is taking people so long to effectively use it. And complexity is the
enemy of security.
> I'd like to see the other major OS distributors, Microsoft, RedHat, SuSE,
> Sun, IBM, Novell, etc. take an active part in this and not only provide
> systems with advanced security controls, but also ship them fully
> configured rather than relying on the system administrator who can't
> possibly understand the system well enough to fully configure them.
Right, you have described the next Adamantix release that is under development
at this moment. :-)
Glynn Clements
Theo de Raadt wrote:
> One of these days someone is going to use the magic of a system call
> interposition mechanism such systrace; and for their application
> accidentally create an operating system behaviour that is un-POSIX,
> and some application is going to misbehave as a result of that change
> and inadvertantly this will result in the CREATION of a hole.
For a concrete example regarding POSIX 1e capabilities (which
are essentially a "system call interposition mechanism"):
http://ciac.llnl.gov/ciac/bulletins/k-064.shtml
Summary: If a root process doesn't have CAP_SETUID, attempts to give
up root privilege fail, resulting in the process continuing to run as
root.
--
Glynn Clements <glynn.c...@virgin.net>
page...@freemail.hu
> Linux binaries (except for marking) so that they are mapped best for
> security. They do this by changing almost only kernel code.
This is not correct. PaX is about researching various ways of protection
against memory corruption bugs. The kernel land approach has just happened
to be the first step, it does not mean it's the last one. And indeed, ever
since we introduced full ASLR (more than 2 years ago), PaX has extended
its reach into userland, since to make proper use of this, you have to
create so called ET_DYN executables (a userland change, available in both
Adamantix [1] and Hardened Gentoo [2] these days), and of course our
userland changes do not stop here, as you can see it in the future plan
documentation [3].
> W^X does not do what PAX does; rather, W^X attempts to solve many of
> the same problem AREAS, but using entirely DIFFERENT SOLUTIONS.
One of the PaX features ([4]) implements the least privilege policy
in the context of runtime code generation (which is one of the possible
ways to exploit a memory corruption bug). This is achieved by
separating writable and executable pages into distinct sets (and
keeping them that way, at least by default because we believe in
'secure by default'). To be able to do this separation you have to
have the ability to mark pages non-executable of course (writability
is not a problem). Now tell me how this is different from W^X which,
err, also implements non-executable pages (for the same purpose, no
less)?
> Yet, persistantly we have been flooded by PAX supporters demanding
> that we should give credit to the PAX people for the ideas in W^X.
> When we had NOT known about PAX, and when W^X does NOT technically do
> what PAX does.
You keep stating that you had not known about PaX yet when asked for
presenting the internal discussions you had while developing your
W^X and other solutions ([5]), you suddenly go silent? Do you want to
tell me that there are no mailing list archives, icb logs, etc about
your technical discussions? Or are they secret?
> Holy cow, can you guys please stop crowing for me to revise history!
In order to revise history, one would need to know it in the first
place.
> It is clear that W^X was developed without knowlege of PAX; it is clear
> that this is a case of two solutions to a similar problem space -- call it
> convergent evolution; it is clear that begging for credit is just making
> your efforts look more and more political and less and less techical.
> I urge the PAX authors to get their community's rabid foaming under control.
I see you have the habit of creating paper tigers then burning them hard
and then thinking you're the hero of the jungle. The fact is, there is no
such thing as 'our community with rabid foaming'. We're not OpenBSD after
all, so there's noone to control.
> In attack after attack posted to our mailing lists, we were not being asked
> to say that the ideas from the PAX people predated the ideas in W^X. No, no!
> We were being told to say that W^X ideas were *COPIED* from PAX, when
> we had no idea that such a thing as PAX even existed!
Interesting, this [5] says otherwise, where did you pull that out of,
another paper tiger of yours?
> Furthermore, there are difference in approach between W^X and PAX which
> are so fundamental that it is clear we did not copy from PAX!
I don't think anyone was questioning the origin of your *code* since
there's next to no way to share such between Linux and the BSDs (at
least not in the VM).
> Like, our idea that mprotect should still permit a user to request a
> page that is PROT_EXEC|PROT_WRITE; by default the PAX people prefer to
> deny such requests.
We chose that because that's the more secure way. You allow runtime
code generation because there's maybe 0.1% of all applications that
need it and at the same time compromise the security measures you want
to provide as has been pointed out earlier in this thread (return-to-libc
style attack to call mprotect() and others). I personally believe that
it's better to have the best security out of the box for stuff like
sshd or apache, and live with the inconvenience of having to exempt
java explicitly.
> If you look at the PAX web and other much more formal documentation,
> you will find that they do not mention W^X.
For this there is a simple explanation: i have yet to finish the
documentation on related work (it will be a separate document),
it's a big undertaking when you consider the almost 40 references
i dug up on the net (some of which have apparently been unknown
even to researchers in this area well), so i chose to write code
instead. But rest assured, once it's finished, your work will be
a part of it as well (at the then current level of course, not long
forgotten and obsolete history as it happens in some papers).
> If you look at Crispin's StackGuard papers, you will not find a
> mention of ProPolice -- which is clearly a better StackGuard. Why
> should we mention PAX? It does not influence what OpenBSD users
> encounter. Are Linux people being specifically told "This is PAX,
> like W^X in OpenBSD"?
Indeed, it's not about influencing others but simple courtesy of
acknowledging related work - something you have failed to do, or
when you did, you made misleading statements (think of your earlier
POSIX (non-)compliance claims in PaX which i see you stopped now).
> W^X was invented because we saw the need for it. We had no idea
> that anyone else was working in the same area.
Actually i don't think this is something you should be so proud of,
it means that despite your claim ("Our aspiration is to be NUMBER ONE
in the industry for security") you didn't actually follow the industry
and have missed out on certain developments for years.
> I have seen about 50 mails from PAX developers or PAX-associated
> developers or users insisting that we say that W^X is a PAX derivative.
Please provide the references to these 50 emails from me or 'associated'
people.
> I will not revise history to make your ego feel less bruised.
There is no need to revise history, just make it known/available to
all.
[1] http://adamantix.org/
[2] http://www.gentoo.org/proj/en/hardened/
[3] http://pageexec.virtualave.net/docs/pax-future.txt
[4] http://pageexec.virtualave.net/docs/noexec.txt
[5] http://marc.theaimsgroup.com/?l=openbsd-misc&m=105060386219963&w=2
Peter Busser
> >> If we had been aware of PAX as you claim, why would we have thought
> >> that i386 solutions were impossible?
> >
> >implemented them.
>
> Can you please stop spinning this?
How could you implement an i386 solution if you still think it is impossible?
> W^X was up and running on some of our architectures before we had
> heard of PAX.
>
> Months later, ways of doing W^X for i386 were discussed, but this was
> also before we had heard of PAX.
>
> Even later, W^X was starting to work on i386, but even this was before
> we had heard of PAX.
>
> W^X does not do what PAX does; rather, W^X attempts to solve many of
> the same problem AREAS, but using entirely DIFFERENT SOLUTIONS.
Ok, thank you for clarifying that. I didn't know that. All I've seen so far is
abusive language from you against the people who contacted you about this
matter.
> Holy cow, can you guys please stop crowing for me to revise history!
Can you please stop making generalisations?
> It is clear that W^X was developed without knowlege of PAX; it is clear
> that this is a case of two solutions to a similar problem space -- call it
> convergent evolution; it is clear that begging for credit is just making
> your efforts look more and more political and less and less techical.
PaX is not my effort.
> I urge the PAX authors to get their community's rabid foaming under control.
I can't speak for other people in the community you mention, but it seems to
me that the one who is foaming right now is you.
> Like, our idea that mprotect should
> still permit a user to request a page that is PROT_EXEC|PROT_WRITE; by default
> the PAX people prefer to deny such requests.
Right, PROT_EXEC|PROT_WRITE is W|X and not W^X. Denying it is what you could
call secure by default.
> We informally (in mail to lists, etc) presented W^X to say we have
> shipped a system that does this and this and that, to improve
> resistance against exploitation of bugs, in concert with ProPolice.
> If you look at the PAX web and other much more formal documentation,
> you will find that they do not mention W^X.
If you look at the PaX web site, you will notice that it mentions other Linux
patches that do memory protection. The Adamantix web site links to the OpenBSD
web site and to systrace.
> Your continued insistance that we knew of PAX is making you look ridiculous.
My continued insistance? I've written only two messages about the subject, this
one being the second.
> I will not revise history to make your ego feel less bruised.
There is a saying which goes like: It takes one to know one.
> >The Adamantix Project
> >Taking trustworthy software out of the labs, and into the real world
> >http://www.adamantix.org/
>
> Competing against OpenBSD security efforts, but starting out 6 years later...
Thank you for thinking of Adamantix as competition. I think competition is
good and having a choice is also good.
Crispin Cowan
>>and intrusion prevention technologies.
>>
>>
>I translate this to mean that when some random bug does exist, system
>features exist which decrease the ease with which it can be exploited.
>ProPolice, StackGaurd, non-executable objects, random object addresses
>-- these kinds of things fall in that area.
>
Agreed.
>>I just want to tease him for choosing ProPolice instead of
>>StackGuard without so much as talking to me :)
>>
>>
>Hah, on the contrary, I chose ProPolice because I had talked to you [StackGuard did not find bugs]
>
That's a very peculiar complaint, which is inconsistent with the purpose
of StackGuard: it is an intrusion prevention technique, not a debugging
technique. If you want to go hunting for buffer overflows, use either a
static analysis tool like RATS, or a dynamic analysis tool like Fuzz.
Fuzz-like tools will slam programs with big strings, causing them to seg
fault where buffer overflow bugs appear. StackGuard and ProPolice only
slightly enhance the diagnostic output when you get a hit, and do
nothing at all to help find more bugs.
>Since we incorporated ProPolice into OpenBSD, we have found many bugs
>of this ilk. We've even found 2 buffer overflows inside our kernel.
>
>These were not as such security holes per se, but just bugs. This means
>the technology is working.
>
It means no such thing. StackGuard and ProPolice have exactly the same
(weak) ability to detect buffer overflow bugs. If you found bugs with
ProPolice and not with StackGuard, that means only that you tried with
ProPolice, and did not try with StackGuard.
You might respond that it is my job & not yours to try with StackGuard,
We have not done that, because StackGuard is completely the wrong tool
to use for such a bug hunt. None the less, if it helps you understand,
we have found two trivial bugs with StackGuard:
1. iwconfig (WiFi network configuration tool) had a bug that
triggered a StackGuard alert when the program exited. Something
was doing a buffer overflow that corrupted an activation record
just as the program terminated, so it was a non-fatal error.
iwconfig is not privileged and the error probably occurs too late
to exploit, so we did not bother to report it.
2. glibc has a fault in its self-test bootstrap
http://sources.redhat.com/ml/bug-glibc/2002-05/msg00766.html This
too was insignificant, because Ulrich had already found and fixed it.
"How many bugs have you found with this tool?" is just a silly metric
for measuring intrusion prevention technologies. I understand that bug
hunting is your primary modus operandi, but just because you're really
into pounding nails does not mean that every tool should be evaluated
for its applicability as a hammer.
OTOH, here's a metric for you: ProPolice lets buffer overflows through:
obsd# uname -a
OpenBSD obsd.int.wirex.com 3.3 GENERIC#44 i386
obsd# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd3.3/2.95.3/specs
gcc version 2.95.3 20010125 (prerelease, propolice)
obsd# cat fail.c
#include <stdio.h>
#include <unistd.h>
int foo(char *blah) {
char buffer[7];
sprintf(buffer, "12345678901234567890123456789012345678901234567890");
return(1234);
}
int main(int argc, char **argv) {
printf("before foo()\n");
foo("blah");
printf("after foo()\n");
}
obsd# gcc -fstack-protector -o fail fail.c
obsd# ./fail
before foo()
Segmentation fault (core dumped)
ProPolice does not protect functions containing arrays of length 7 or
less. We don't know what other cases exist in which ProPolice fails to
protect. This kind of risk exists precisely because of the design choice
that gives ProPolice its multi-architecture capability: putting the
protection way up high in the compiler. This creates the potential for
later stages of GCC to optimize away the security checks, or move them
so far away from relevant code that they are no longer effective. When
you choose ProPolice, you choose CPU portability over security.
OTOH, I like the variable sorting hack in ProPolice, and thought about
implementing it, but chose instead to concentrate on PointGuard, which
protects all of the cases that ProPolice variable sorting protects, and
then some.
Mark Tinberg
Hash: SHA1
Theo de Raadt wrote:
>>I agree whole heartedly. It is interesting to see OpenBSD transition
>>from a stance of "audit is the only way" to actually employing access
>>control [...]
>
> I persist in my belief that policy-based mechanisms do not improve
> security. If you cannot make a default policy that everyone can live
> under, you are creating a trap:
>
> 90-99% of people use the default policy, because they do not
> change it
This has to be the golden rule of any functional security system. 99%
of the admins aren't going to change the default system because 99% of
the admins aren't the guys who wrote the system. In any moderately
complex system the vast majority of the system administrators aren't
going to understand every possible facet enough to be able to
competantly make any large scale changes.
> if that policy is restrictive, you have made a decision that
> security is more important than useability
>
> if that policy is not restrictive, you have made a decision that
> useability is more important than security
Um, doesn't this kind of cancel out 8^)
> (then there is also the issue of "it is restrictive towards what")
>
And that may be the beginnings of an important distinction. The
security system needs to be flexible enough to support both the most
anal (can only browse to single intranet site) and permissive (every
desktop runs a quake server).
[snip]
> works?). I still believe very strongly that efforts directed at
> "security technologies that only experts can use" matter far less than
> "security techologies that invisibly improve everything".
This is kind of the main point I was saying. A new security system can
only improve overall security when it is widely deployed. The only way
it will ever be widely deployed is if it's almost completely transparent
to the end of the line admin who runs the system. Anything that
requires complicated setup is a non-starter, no matter how good and
secure it is.
>
> Hah, there is no public record to live down. Nor a policy change,
> since we still audit code (with more emphasis on "audit means to
> improve wholesale"). We also modify a lot of software for
> priv-seperation or priv-revocation these days, to internally improve
> specific application's resistance against successful exploitation (for
> the situation of: it has a bug, but if you can exploit it, you gain
> much less). Since we have more people interested in other areas, we
> can expend efforts in other directions as well.
This is all well and good, and I appreciate the efforts y'all have put
in this area but I think there are more fundamental problems about how
access controls are assigned that isn't being addressed by band-aid work
like privsep. It would be nice, if possible given the contstraints I
mentioned above, if the system's security archetecture could kill off
the process when it is comprimised, rather than relying on the
comprimise happening in a user-level privilidge section where it
"shouldn't" be able to do _too_ much damage. It's a good solution that
works with the system we've got, but I think there is a better solution
out there somewhere.
[snip]
> the details of POSIX. Details matter more than anything else. Like a
> gun, these things create an process environment which is "POSIX
> maybe".
Anything that requires a bunch of extra work from everybody
(programmers, admins, etc.) is a no-go from the start. It's unfortunate
that we can't completely start from a clean slate, but it just isn't
practical.
[snip]
> If any security technology shows no success at finding other related but
> minor bugs, I really just don't see the point.
While this seems like a pointless and arbitrary distinction, it is kind
of on the right track. Programs designed and implemented before
$whizzy_security_system probably exhibit all sorts of ill behaviour that
you'd never notice until the security system starts clamping down on it,
catching bugs. More of a side effect than a main feature though, ISTM
that whether this happens at all would depend on what kind of security
system you are talking about. I don't think a security system _has_ to
kick out bugs in existing software to be useful, but if it does kick out
bugs it is evidence that you're on the right track I think.
[snip]
>>>Again, ISTM that the only way to get close to a reasonably secure system
>>>is to only rely on the smallest, most audited codebase possible to enforce
>>>security policy. [...]
>
> whenever I see the word 'security policy' everything after it starts to
> sound a lot like 'blah blah blah maybe NSA or DOD will give me money' and
> my brain fades out...
>
> (sorry, perhaps that is a little bit strong)
Haha, no I wasn't trolling for DoD money I just mean "security policy"
in the generic sense. These things (machines, programs, people) should
be doing these things (talking to fileserver, sorting text, browsing
web) and not these other things (scanning network, executing shells,
reading accounting's files). I don't think that requiring each
application to be responsible for its own security is ever going to
work. It sure hasn't yet 8^)
- --
Mark Tinberg
Network Security Engineer
SecurePipe, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/
iD8DBQE/QoTKFu7F5OUjbGcRAtL6AJ99RkKp4fMz7V8GDvmZRY0Yg2eWzgCfaeVx
OxcYzC40Wh5z+G56zZy48nY=
=DBFH
-----END PGP SIGNATURE-----
Mariusz Woloszyn
> OTOH, I like the variable sorting hack in ProPolice, and thought about
> implementing it, but chose instead to concentrate on PointGuard, which
> protects all of the cases that ProPolice variable sorting protects, and
> then some.
>
I's not just a "hack" it's a great improvement that distinguish ProPolice
from Stackguard.
To be honest, it's the main reason why I migrated form SG to PP.
Beside that PP protects function arguments unlike SG!
To recapitulate: SG vs PP 0:2.
Theo de Raadt
>
> > W^X was invented because we saw the need for it. We had no idea that
> > anyone else was working in the same area.
>
> something before they do some research and look if someone else is
> doing something similar?
PAX was not really published in anything that I read. Compare it to
stackghost, a usenix security paper, which we have put some effort at
integrating.
Our tact was to support it first on cpu's that had a proper X bit in
their pte. Ie, sparc64 and alpha and such. Solving the problem on
x86 was not on our radar until, lemme think, perhaps while we were
eating curry during Usenix Monterey at that Irish pub....
As one of our developers said yesterday:
<miod> more exactly, we heard of pax when they started bitching