Onderwerp: Re: [Full-Disclosure] Re: Buffer overflow prevention

pros and cons of the two ?
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/archiv...3-04/1681.html

- noir

w as in http://stargliders.org/phrack/mmhs.jpg


On Thu, 14 Aug 2003, Avery Buffington wrote:

>
> no, he ment W^X ("W xor X") but I'm not about to go into a comparison of the two or their pros and cons.
>
> second bullet of http://www.openbsd.org/33.html#new will explain W^X but http://archives.neohapsis.com/archiv...3-04/1678.html will make you chuckle
>
>
> -----Original Message-----
> From: noir [mailto:noir@gsu.linux.org.tr]
> Sent: Thursday, August 14, 2003 5:01 PM
> To: bugtraq@securityfocus.com
> Subject: Re: Buffer overflow prevention
>
>
>
> I believe that Mr. Raadt meant PAX by W^X.
> We all enjoy ascii art but I wanted to note that renaming somebody
> elses work is not so ethical.
>
>

> pros and cons of the two ?
> 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/archiv...3-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?

Subject: Re: Buffer overflow prevention
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

-----BEGIN PGP SIGNED MESSAGE-----
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 <MTinberg@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+c0PGSjVg CePcES
agepSknw833x7altZ7VFLYc=
=tjsu
-----END PGP SIGNATURE-----

> 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?

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?

Shaun Clowes wrote:

>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/

On Fri, Aug 15, 2003 at 11:48:14AM -0700, Crispin Cowan wrote:
> 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

Subject: Buffer overflow prevention
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.

On Mon, 18 Aug 2003 pageexec@freemail.hu wrote:

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

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

Now, if you're promiscuous and come into contact with enough
strangers, you'll catch the pathogen either way. But if you're not
promiscuous, you greatly reduce the change of contracting the pathogen
if you are part of a heterogeneous population.

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.

Cheers,
Mark

Mark Handley wrote:

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

Crispin

--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Chief Scientist, Immunix http://immunix.com
http://www.immunix.com/shop/

Hi!

> 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/

Mark Tinberg wrote:

>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/pa...s-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/pa...-oakland01.pdf>,
slides
<http://www.cs.berkeley.edu/%7Edaw/pa...nd01-slides.ps>]

Crispin

--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
Chief Scientist, Immunix http://immunix.com
http://www.immunix.com/shop/

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

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