CW
Netswimmer
Es wird schon seit Monaten über die neuen (oder bereits für einige Plattformen in der 3.3 vorhandenen) Sicherheitsfunktionen des kommenden OpenBSD 3.4 gesprochen.
Pro-Police und W^X sind die neuen Features die für noch mehr Sicherheit sorgen sollen.
Ich habe heute in der misc@openbsd Mailingliste zwei sehr interessante Postings von Theo de Raadt gelesen, die nicht nur sehr viel über die ProPolice und W^X sagen, sondern auch, warum man sich in der OpenBSD-Gemeinde dafür entschieden hat und nicht z.B. für PAX (in der Linux-Welt bekannt) oder StackGuard.
Ich habe die zwei Antwort-Mails (incl. der Quotes) rauskopiert.
Die Quotes sind kursiv, Theos Zeilen normal.
Die erste Mail beschäftigt sich mit ProPolice, die zweite mit W^X.
Zugleich kann man sich auch ein Bild darüber machen, wie über die Anstrengungen beim OpenBSD-Projekt von Seiten der Linux-Distris geredet wird.
Man kann schon fast sagen, dass sie versuchen die ganze Arbeit des OBSD-Camps kaputt zu reden.
Neid, Neid, Neid ....
Viel Spaß beim Lesen!
----------------------------------------------------------------------------------
Datum: Mon, 18 Aug 2003 16:16:55 -0600 (MDT)
Von: "Theo de Raadt" <deraadt@cvs.openbsd.org>
An: crispin@immunix.com, mtinberg@securepipe.com
Betreff: Re: Buffer overflow prevention
CC: bugtraq@securityfocus.com, peter@trusteddebian.org
>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
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)
-----------------------------------------------------------------------------------
Datum: Mon, 18 Aug 2003 15:31:11 -0600 (MDT)
Von: "Theo de Raadt" <deraadt@cvs.openbsd.org>
An: bugtraq@securityfocus.com, peter@trusteddebian.org
Betreff: Re: Buffer overflow prevention
CC: misc@cvs.openbsd.org
>> 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.
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...
---------------------------------------------------------------------------------
Zusammengestellt von:
ColdWisdom
Pro-Police und W^X sind die neuen Features die für noch mehr Sicherheit sorgen sollen.
Ich habe heute in der misc@openbsd Mailingliste zwei sehr interessante Postings von Theo de Raadt gelesen, die nicht nur sehr viel über die ProPolice und W^X sagen, sondern auch, warum man sich in der OpenBSD-Gemeinde dafür entschieden hat und nicht z.B. für PAX (in der Linux-Welt bekannt) oder StackGuard.
Ich habe die zwei Antwort-Mails (incl. der Quotes) rauskopiert.
Die Quotes sind kursiv, Theos Zeilen normal.
Die erste Mail beschäftigt sich mit ProPolice, die zweite mit W^X.
Zugleich kann man sich auch ein Bild darüber machen, wie über die Anstrengungen beim OpenBSD-Projekt von Seiten der Linux-Distris geredet wird.
Man kann schon fast sagen, dass sie versuchen die ganze Arbeit des OBSD-Camps kaputt zu reden.
Neid, Neid, Neid ....
Viel Spaß beim Lesen!
----------------------------------------------------------------------------------
Datum: Mon, 18 Aug 2003 16:16:55 -0600 (MDT)
Von: "Theo de Raadt" <deraadt@cvs.openbsd.org>
An: crispin@immunix.com, mtinberg@securepipe.com
Betreff: Re: Buffer overflow prevention
CC: bugtraq@securityfocus.com, peter@trusteddebian.org
>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
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)
-----------------------------------------------------------------------------------
Datum: Mon, 18 Aug 2003 15:31:11 -0600 (MDT)
Von: "Theo de Raadt" <deraadt@cvs.openbsd.org>
An: bugtraq@securityfocus.com, peter@trusteddebian.org
Betreff: Re: Buffer overflow prevention
CC: misc@cvs.openbsd.org
>> 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.
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...
---------------------------------------------------------------------------------
Zusammengestellt von:
ColdWisdom
Zuletzt bearbeitet:
