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

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
>

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/

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/

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

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/pointg...curity2003.pdf>
and Talk
<http://immunix.com/%7Ecrispin/pointg...curity2003.ppt>.

Crispin

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

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

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

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/

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

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/

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/

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

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

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

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/