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

[KF]

Hrmm why does this bring HP to mind... oh yeah I remember...

HP-> "... oh you say you found a bunch of overflows... that does not
matter... there is no way you will bypass our non-executable stack.. we
are not going to fix any of them... we are gonna let em fester... our
non-exec stack is Hack proof"

(time elapse... 2 months)

SNO-> "...oh yeah we bypassed your non-exec stack and have successfully
exploited several of those overflows we told you about a few months ago...
bash-2.05a$ id
uid=201(dotslash) gid=15(users) groups=0(system)
bash-2.05a$ ./TRU64_su
# id
uid=0(root) gid=15(users) groups=15(users),0(system)
# sysconfig -q proc executable_stack
proc:
executable_stack = 0
(hrmm your stack REALLY helped out)

HP-> "ok thanks we will procede to sue you now"

-KF

>
> It's been proved many times that non-executable stack adds NO security at
> all.
> Every single class of vulnerabilities exploitable with executable stack
> can be also exploited with non-executable stack.
> See for example our article (http://www.phrack.org/show.php?p=56&a=5)
> which shows how to bypass a stack protector even with a non-executable
> stack.
>
> What we're discussing here is an internal structures and data protecting.
> IMHO the ProPolice (http://www.research.ibm.com/trl/projects/security/ssp/),
> is the best protection in this kind, even comparing to "two stack"
> approach.
> Beside that it's an existing, well tested and wide used (for example
> OpenBSD uses it by default now).
> I see no real reason why the major Linux companies are not using it for
> its products.
>
> Best regards,
>
> --
> Mariusz Woloszyn
> Internet Security Specialist, GTS - Internet Partners
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>

[Peter Busser]

Hi!

> On August 14, 2003 06:44 am, Mariusz Woloszyn wrote:
> > On Wed, 13 Aug 2003, Patrick Dolan wrote:
> > > There is a flag for the Gnu C/C++ compilers, -fstack-protector, that will
> > > implement ProPolice stack protection. It should prevent stack smashing
> > > techniques.
> > ProPolice (http://www.research.ibm.com/trl/projects/security/ssp/) is a
> > great tool ...
> GRsecurity is a kernel patch wich allows such things as random memallc bases
> and random tcp stacks, as well as a non-executeable stack if you can manage
> this (not to mention a utility to change the PAX flags for indidual binarys
> that may need executable stack). This would work much better because it dosnt
> need to be compiled into anything but the kernel.

The patch you are talking about is called PaX (http://pageexec.virtualave.net).
Gr-security uses PaX and other patches.

To make maximum use of PaX randomisation, you would have to recompile/relink
all executables. That is what we have done for Adamantix. Other distributions,
like Gentoo Hardened recently started doing this also.

> If you turn on GRsecurty's randomizations for memory addresses and tcp stacks
> (wich I have tested, you can do this safely without breaking any software).
> If you do this, then a attacker trying to overflow a return address has a 1
> in 2^32 chance of the exploit actually overflowing the address. You can do
> this and not have any impact on speed, and all of your software is protected
> with this level without having to recompile with a gcc flag.

No, the chance is much bigger than that. It is obviously not possible to do
full 32 bit randomisation in a 32 bit address space. I wrote a test suite that
will measure the number of bits of the various randomisations. However, the
PaX randomisation is larger than you will find in OpenBSD.

ET_EXEC randomisation has an impact on the speed, that is why for Adamantix I
chose to recompile/relink all binaries.

Randomisation of stack/heap/executable/mmaps is a form of obfuscation, noone
should rely on randomisation alone for improving the security of a system.

> Also, you can use chpax, and turn on a non-executable stack, and with a small
> amount of voodoo (in tracking down the binarys and .so's that need the stack,
> wich typically is only a single binary or .so file, wich you can find with
> ptrace, strace, or ltrace) you can have all of your stuff run with a
> non-executeable stack, thus making stack smashing impossible.

A non-executable stack patch provides no protection. It is easy to circumvent.
A few years ago there was a discussion about getting the OpenWall non-exec
stack patch into Linus' kernel tree and Linus refused. He showed that it was
easy to circumvent this stuff. That is why PaX provides more than
non-executable stack and randomisation alone.

> Nothing can
> execute off your stack so a malicous person can override all the addresses he
> wants, his code cant run off your stack.

Well, it doesn't have to execute off the stack to be exploitable. Simply
changing the return address can lead to a succesfull exploit. PaX does not
protect against this. And I don't know any kernel patch that does, for that
matter.

Groetjes,
Peter Busser
--
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world
http://www.adamantix.org/

[Peter Busser]

Hi!

> > AFAIK all those combined do bring real security against generic exploits.
> "Real security" is not the word.

Even though PaX is better than W^X, it is far from being perfect.

> PaX / Propolice / W^X / non-exec stacks don't solve bugs. What they do is
> to _abort_ execution of a process when it behaves abnormally.
> So instead of giving attackers the opportunity to run arbitrary code, you
> only give them the ability to cause a denial of service.

You could say they trade availability for integrity.

> This kind of protection should be coupled with tools that automatically
> restart daemons when they crash (ex: daemontools and monit) to actually keep
> the service running when under attack. Still, all of this is a couple of
> unreliable band-aids.

A better way to deal with would be to automatically warn someone with enough
information to easily find and fix the problem. Restarting the daemon makes the
problem managable, but it won't solve the bug.

Groetjes,
Peter Busser
--
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world
http://www.adamantix.org/

[Avery Buffington]

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

second bullet of http://www.openbsd.org/33.html#new will explain W^X but =
http://archives.neohapsis.com/archives/openbsd/2003-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=20



I believe that Mr. Raadt meant PAX by W^X.=20
We all enjoy ascii art but I wanted to note that renaming somebody=20
elses work is not so ethical.

[Crispin Cowan]

Sam Baskinger wrote:

>It sounds like array bounds checking would offer an almost equivalent effect.
>This would not stop mis-casting a struct and referencing out of it or similar
>casting+address calcuation errors. To prevent that you would need either a
>language that prevented the production of that sort of code or to solve the
>halting problem.
>
Array bounds checking offers greater protection than any of these
protections (StackGuard, ProPolice, PointGuard, W^X, PAX/ASLR, etc.) The
problem is that the very fastest array bounds protection for C (Bounded
Pointers) imposes a 5X slowdown on performance, where as these other
techniques impose overheat somewhere between noise and 20%. See the
comparison chart in the back of the PointGuard paper for a good
comparison of these techniques:

"PointGuard: Protecting Pointers From Buffer Overflow
Vulnerabilities". Crispin Cowan, Steve Beattie, John Johansen and
Perry Wagle. To appear at the 12^th USENIX Security Symposium
<http://www.usenix.org/events/sec03/>, Washington DC, August 4-8,
2003. Paper
<http://immunix.com/%7Ecrispin/pointguard_usenix_security2003.pdf>
and Talk
<http://immunix.com/%7Ecrispin/pointguard_usenix_security2003.ppt>.

Crispin

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

[Shaun Clowes]

On Thu, Aug 14, 2003 at 07:26:47PM +0200, Mariusz Woloszyn wrote:
> On Thu, 14 Aug 2003, Stephen Clowater wrote:
>
> > Also, you can use chpax, and turn on a non-executable stack, and with a small
> > amount of voodoo (in tracking down the binarys and .so's that need the stack,
> > wich typically is only a single binary or .so file, wich you can find with
> > ptrace, strace, or ltrace) you can have all of your stuff run with a
> > non-executeable stack, thus making stack smashing impossible. Nothing can
> > execute off your stack so a malicous person can override all the addresses he
> > wants, his code cant run off your stack.

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.

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.

Cheers,
Shaun

[Matt D. Harris]

Theo de Raadt wrote:
>>Solaris 2.6 and above also support a kernel variable which can be set
>>via /etc/system called "noexec_user_stack", which can make the stack for
>>userland processes non-executable by default. Note that this behavior
>>is the default for 64-bit binaries in Solaris 7, 8, and 9, and this
>>kernel variable forces the behavior for 32-bit binaries. I run all
>>sorts of odd software and have never had an issue with having this
>>always turned on for all of my systems.
>
>
> You just don't get it, do you? Are you even reading what people are
> saying? Protecting just the stack is basically useless. 99.9% of
> exploits that use the stack can be rewritten to NOT use the stack!
>
> But W^X protects THE ENTIRE ADDRESS SPACE.
>

That's fine. I'm not pointing out this functionality as some sort of
be-all-end-all fix for everything. I'm simply pointing out a function
that a system provides that people may find useful. And how many script
kiddies are resourceful enough to re-write an exploit to *not* use the
stack? The fact is, simply preventing the stack isn't perfect. But
it's not entirely worthless, either. To call anything that does
something useful entirely worthless is just downright silly. In today's
day and age, one should do everything possible to protect themselves,
whether it's going to be effective 1% of the time of 99% of the time.
So, when are you releasing the Solaris kernel module to support the W^X
stuff? Someone who's so married to a specific bit of defense would
certainly want to release it to as many potential users as possible,
whether they use OpenBSD or not, right? :-)

[Peter Busser]

Hi!

> >There is a flag for the Gnu C/C++ compilers, -fstack-protector, that will
> >implement ProPolice stack protection. It should prevent stack smashing
> >techniques.
> >
> That is not actually in the standard GCC; it is in a forked GCC that
> OpenBSD chooses to ship.

Adamantix and Gentoo Hardened also ship this patched GCC compiler.

> We (Immunix) are in the process of trying to make StackGuard (the
> original) meet all of the criteria required for acceptance into GCC. At
> the GCC Summit <http://www.gccsummit.org/2003/> in May, we presented a
> StackGuard talk
> <http://www.gccsummit.org/2003/view_abstract.php?talk=31> on that topic.

I would rather see Hiraoke Etoh's Stack Smashing Protector (aka ProPolice) as
standard stack-smashing protection mechanism in GCC than StackGuard.

Groetjes,
Peter Busser
--
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world
http://www.adamantix.org/

[Solar Designer]

Hi,

On Fri, Aug 15, 2003 at 11:10:31AM +0200, Peter Busser wrote:
> > you can have all of your stuff run with a
> > non-executeable stack, thus making stack smashing impossible.
>
> A non-executable stack patch provides no protection.

I am tired of hearing people say both of these things. Neither is
entirely correct (although the first one is worse). The facts are:

- non-executable stack doesn't fix any vulnerabilities and doesn't
make them non-exploitable, but

- non-executable stack may provide a layer of protection, making
certain vulnerabilities harder to exploit in the real world.

Non-executable stack, unlike many more advanced hardening measures
(which have similar properties, only being a "thicker" "layer of
protection"), doesn't have a performance impact. This property, in my
opinion, makes it reasonable to use even despite the fact that the
added protection it brings is very limited. Whether to also use those
"more advanced hardening measures" may be decided on a case by case
basis.

> It is easy to circumvent.

Most of the time, yes. Yet this may be an additional bit of work for
an attacker (or exploit writer) and often lower reliability for the
exploit code with remote attacks (a smaller percentage of automated
attacks succeed).

> A few years ago there was a discussion about getting the OpenWall non-exec
> stack patch into Linus' kernel tree and Linus refused. He showed that it was
> easy to circumvent this stuff.

Linus, for obvious reasons, didn't participate in or read all of the
discussions of the topic occurring on public mailing lists. The
particular attack approach he has pointed out (return-into-libc) was
publicly discussed before that and I was first to post working
exploits relying on this approach to Bugtraq more than a year before
Linus' post (1997 vs. 1998). I've also included a workaround
preventing some attacks of this nature at the same time (1997).
Others have published even smarter attacks since then.

BTW, I've never raised the question of the patch (not) getting into
the official kernel tree, -- other people did. I feel that many
over-estimate the importance of that patch (hack?) I did. I wish some
of their interest in that stuff I've been doing in 1997 would move to
other projects, including Openwall GNU/*/Linux (Owl) which is an
entire OS distribution rather than just a kernel patch.

--
Alexander Peslyak <solar@openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments

[weigelt@metux.de]

On Thu, Aug 14, 2003 at 11:19:03AM -0400, Sam Baskinger wrote:

> It sounds like array bounds checking would offer an almost equivalent effect.
> This would not stop mis-casting a struct and referencing out of it or similar
> casting+address calcuation errors. To prevent that you would need either a
> language that prevented the production of that sort of code or to solve the
> halting problem.

once you have such an language, you also can use an garbage collector
and so throw away an wide field of problems.

cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux ITS
Webhosting ab 5 EUR/Monat. UUCP, rawIP und vieles mehr.

phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
Diese Mail wurde mit UUCP versandt. http://www.metux.de/uucp/

[Crispin Cowan]

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?

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

Crispin

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

[Theo de Raadt]

> > W^X is more than just stack protection. It means that all pages that
> > are writeable are also marked as not executable. At least, it means
> > this is how the system by default operates, until some process asks
> > for something that has both write and execute permission.
> >
> > On some architectures W^X is easy, since the native architecture has a
> > execute-permitted bit per page (sparc, sparc64, alpha, hppa, m88k).
> > On other architectures, it is difficult and various hacks have to be
> > done to make it work (i386, powerpc).
>
> 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.

> This
> doesn't matter if your machine is equipped with 2 GB (RAM+Pagefile) or
> less, because all pages of those 2 GB can completely be mapped to linear
> addresses in either the code or data/stack segment. As soon as there's
> more memory available, you have to decide how large the code and
> data/stack segment should be.

Ridiculous.

> Adressing more than 4 GB on x86 is an ugly hack anyways -PSE as well as
> PAE.

Yet more dribble which is unrelated to the issue at hand.

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... Let me try to summarize the
options.

1) Configure the i386 CS code segment limit register so that it cannot
reach into the stack area at the end of memory.

Hence, you can have code below, and your stack above. This only
protects your stack. As many have pointed out, doing so is useless,
unless other protection techologies such as ProPolice are used to
suppliment the protection.

2) Furthermore, try to make the CS code segment limit register reach only
to the end of the data segment.

But then a problem shows up. When you use shared libraries, you end
up with code followed by data followed by code followed by data etc.
Since you only have one line you can draw in the address space,
clearly you can't make this work!

3) To resolve this, we made modifications to ld.so and to the base ELF
binaries and shared library files that are produced. The idea is to
map all CODE from the program, ld.so, and from each of the shared
libraries low in memory, and then to map their respective DATA segments
HIGHER in memory.

We must remember one thing. Each ELF module is internally pre-linked.
This means that the code of a module use relative addressing to access
the data. Or, put another way, the code and data must remain a FIXED
distance from each other in memory; that distance is determined at
link time. You cannot change it at run time without significant
performance problems and other difficulties.

4) So, now that all the code is down below, and all the data is above we
have something like this


stack

gap
gap
gap

libm data
libc data
ld.so data
program data

gap
gap
gap <----

libm code
libc code
ld.so code
0: program code


5) If we are clever, we can now change our kernel to put the CS limit
register at where the arrow is. If new objects are mapped or unmapped
into the address space with X permission, the CS limit register can
change up or down.

No objects above that line can be executed.


In OpenBSD, we've done steps up to 4. We've not done step 5 perfectly
yet (we use a "fixed" line).


Finally, another option:

As an alternative to all this complicated stuff, it is my
understanding that some 32-bit x86 cpus in PAE (64 bit PTEs) mode
honour the highest bit of the PTE as a NX (non-executable) bit. 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 :)

[Massimo Bernaschi]

The discussion about the various techniques for buffer overflow
prevention is very interesting, but if the target is to prevent the
security threats caused by buffer overflows, then one should look for
an operating system base solution, since it is an OS issue to enforce
the security. Solutions based on the control of system calls execution
like systrace (http://www.citi.umich.edu/u/provos/systrace/) or
remus (http://remus.sourceforge.net/) are just two possible examples of
such approach.

Massimo

--- Massimo Bernaschi: Istituto Applicazioni del Calcolo ----
| IAC-CNR | e-mail: massimo@iac.cnr.it |
| V.le del Policlinico 137 | phone: +39 06 88470229 |
| 00161 Roma - ITALY | fax: +39 06 4404306 |
---------------------------------------------------------------------------
|See http://www.iac.cnr.it/~massimo for my GPG public key or check |
|GnuPG Public Key Fingerprint (keyserver.linux.it) |
|pub 1024/CAA3FB48 2001/01/04 Massimo Bernaschi <massimo@iac.rm.cnr.it> |
| Key fingerprint = 3EFF 7AFF F8A4 F34E 382B DD81 57F3 700A CAA3 FB48|
---------------------------------------------------------------------------

[Tom 7]

Crispin Cowan <crispin@immunix.com> wrote:

> Array bounds checking offers greater protection than any of these
> protections (StackGuard, ProPolice, PointGuard, W^X, PAX/ASLR, etc.) The
> problem is that the very fastest array bounds protection for C (Bounded
> Pointers) imposes a 5X slowdown on performance, where as these other
> techniques impose overheat somewhere between noise and 20%.

This may be true. Doing "safe" pointers in C is difficult because of
pointer arithmetic. But I think this is a bit unfair to bounds checking in
general--type safe compiled languages like ML achieve array bounds
checking (and other checks) at a much smaller penalty (less than 20% for
array-oriented code in my experience). These languages also provide
protection against other common sources of holes, like integer overflow,
double-frees (most are garbage collected) and printf formatting attacks.
This protection is automatic and absolute; the only thing left to worry
about is bugs in the compiler, system library, and kernel (things that C
programmers already need to worry about, anyway).

In my opinion these languages are utterly practical for Unix network
daemons. Of course, this is a bit more work because you don't just
recompile the program, you have to rewrite it from scratch! But there are
other benefits to maintaining code in a modern, safe, high-level language.

- Tom

[ http://www.cs.cmu.edu/~tom7/ ]

[stealth]

On Fri, Aug 15, 2003 at 11:41:18AM +0200, Peter Busser wrote:

Hi,

> The only way to sleep quietly in fact is to feed your computer to a shredder.
Yes, indeed. But if you install PaX and all the other nice and really
usefull things out there I think you can sleep pretty well. I mean
all the bypassing for the really hard stuff (PaX, gr, SELinux)
is really theoretical from what I have seen. I really want to see
that guy (or girl? :) that exploits a GR'ed box remotely where the
target box runs single-service and well audited code. You do not
have to fear that person that gets into it, and you will probably never know
(s)he was there, so who cares?
Not speaking about user-shells, trojans on client-systems and social engenering
here.

> 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).
>
> Groetjes,
> Peter Busser
> --
> The Adamantix Project
> Taking trustworthy software out of the labs, and into the real world
> http://www.adamantix.org/

[noir]

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/archives/openbsd/2003-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/archives/openbsd/2003-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.
>
>

[Theo de Raadt]

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

[pageexec@freemail.hu]

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

[Mark Tinberg]

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

[pageexec@freemail.hu]

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

[Crispin Cowan]

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/

[Shaun Clowes]

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

[pageexec@freemail.hu]

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.

[Mariusz Woloszyn]

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

[Mark Handley]

>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

[Crispin Cowan]

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/

[Peter Busser]

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/

[Crispin Cowan]

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

Crispin

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

[Theo de Raadt]

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

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

> 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?
[...]
> 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]

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

[Peter Busser]

Hi!

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

Groetjes,
Peter Busser
--
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world
http://www.adamantix.org/

[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.clements@virgin.net>

[pageexec@freemail.hu]

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

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]

On Mon, Aug 18, 2003 at 03:31:11PM -0600, Theo de Raadt wrote:
> >> 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?

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.

Groetjes,
Peter Busser
--
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world
http://www.adamantix.org/

[Anil Madhavapeddy]

On Mon, Aug 18, 2003 at 11:38:46PM -0700, Crispin Cowan wrote:
>
> 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.

You're correct that OpenBSD/ProPolice does not protect buffers of length 7
or less, but your analysis appears to be completely wrong.

It's just a simple #define SUSPICIOUS_BUF_SIZE, and looks to be there for
performance reasons. If you run with -Wstack-protector, PP will warn
explicitly when it skips a too-small buffer. If you are feeling particularly
paranoid and don't mind the performance hit, just crank the define down
and recompile GCC.

It certainly isn't gcc optimising away the checks, or anything to do with
architecture.

--
Anil Madhavapeddy http://anil.recoil.org
University of Cambridge http://www.cl.cam.ac.uk

[Crispin Cowan]

Theo de Raadt wrote:

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

Crispin

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

[Mark Tinberg]

-----BEGIN PGP SIGNED MESSAGE-----
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/QoTKFu7F5OUjbGcRAtL6AJ99RkKp4fMz7V8GDvmZRY0Yg2eWzg CfaeVx
OxcYzC40Wh5z+G56zZy48nY=
=DBFH
-----END PGP SIGNATURE-----

[Mariusz Woloszyn]

On Mon, 18 Aug 2003, Crispin Cowan wrote:

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

--
Mariusz Wo³oszyn
Internet Security Specialist, GTS - Internet Partners

[Theo de Raadt]

> i don't care about other peoples war. but:
>
> > W^X was invented because we saw the need for it. We had no idea that
> > anyone else was working in the same area.
>
> i think it is somewhat strange. there realy smart people start building
> 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