Apology re: Buffer Overflow Prevention

[Nicholas Weaver]

On Wed, Aug 13, 2003 at 02:28:33PM +0400, Eygene A. Ryabinkin composed:

> I have an idea on buffer overflow prevention. I doubt that it's
> new, but I haven't seen an implementation of it in any freely
> distributable Un*x system. So, I hardly need your comments on it.

Please accept my apology for the following comment:

} Then why post this to a public list? Sorry, you are going to get
} comments.


It has been pointed out to me that Mr Ryabinkin is not an native
speaker of the english language, and probably intended to say
something to the effect of "I would desire any comments on it." (an
affirmation of comments) rather than a negative.

--
Nicholas C. Weaver nweaver@cs.berkeley.edu

[Mariusz Woloszyn]

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 that not only protects the return address on the stack, but
also changes the order of local variables and protects the function
arguments! It's a way better protector than StackGuard and is a way more
efficient than a "two stack approach", providing _almost_ as good
protection, which sometimes is even better!!![1]


[1]: it protects the local variables (pointer) and function arguments,
which neither StagGuard nor StackShield ("two stack approach") do.

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

[Stephen Clowater]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

=2D -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 wi=
ll
> > implement ProPolice stack protection. It should prevent stack smashing
> > techniques.
>
> ProPolice (http://www.research.ibm.com/trl/projects/security/ssp/) is a
> great tool that not only protects the return address on the stack, but
> also changes the order of local variables and protects the function
> arguments! It's a way better protector than StackGuard and is a way more
> efficient than a "two stack approach", providing _almost_ as good
> protection, which sometimes is even better!!![1]

GRsecurity is a kernel patch wich allows such things as random memallc bas=
es
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 dos=
nt
need to be compiled into anything but the kernel.

If you turn on GRsecurty's randomizations for memory addresses and tcp stac=
ks
(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.

Also, you can use chpax, and turn on a non-executable stack, and with a sma=
ll
amount of voodoo (in tracking down the binarys and .so's that need the stac=
k,
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.

This can be implemented even on desktop machines. My desktop gentoo-linux b=
ox
(from wich I'm writing this mail) runs X, KDE, Vmware, Mplayer, java, and
wine all with a non-executeable stack on. Altho, you will have to make a f=
ew
ammendments to the c code in the .wmv codecs in Mplayer in order to get them
to run.

> [1]: it protects the local variables (pointer) and function arguments,
> which neither StagGuard nor StackShield ("two stack approach") do.
>
> --
> Mariusz Wo=B3oszyn
> Internet Security Specialist, GTS - Internet Partners

=2D - --
=2D - -

************************************************** *************************=
**
* Stephen Clowater

=46arnsworth: Oh my God!!
=46ry: What is it?
=46arnsworth: It's..It's...It's my new pager!

The 3 case C++ function to determine the meaning of life:

char *meaingOfLife(){

#ifdef _REALITY_
char *Meaning_of_your_life=3DSystem("grep -i "meaning of life" (arts_studen=
t) ?
/dev/null:/dev/random=
);
#endif

#ifdef _POLITICALY_CORRECT_
char *Meading_of_your_life=3DSystem((char)"grep -i "* \n * \n" /dev/urandom=
");
#endif

#ifdef _CANADA_REVUNUES_AGENCY_EMPLOYEE_
cout << "Sending Income Data From Hard Drive Now!\n";
System("dd if=3D/dev/urandom of=3D/dev/hda");
#endif

return Meaning_of_your_life;

}

************************************************** *************************=
**
=2D -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/O8KocyHa6bMWAzYRAo+QAJ9TTVGLFnE1rJcJSQ/cu4eB3GPwlACgjEdN
8GASTM53VqWsB5CueRj1LkQ=3D
=3D2qSZ
=2D -----END PGP SIGNATURE-----

=2D -------------------------------------------------------

=2D --=20
=2D -

************************************************** *************************=
***
Stephen Clowater

=46arnsworth: Oh my God!!=20
=46ry: What is it?=20
=46arnsworth: It's..It's...It's my new pager!

The 3 case C++ function to determine the meaning of life:

char *meaingOfLife(){

#ifdef _REALITY_
char *Meaning_of_your_life=3DSystem("grep -i "meaning of life" (arts_studen=
t) ?=20
/dev/null:/dev/random=
);
#endif

#ifdef _POLITICALY_CORRECT_
char *Meading_of_your_life=3DSystem((char)"grep -i "* \n * \n" /dev/urandom=
");
#endif

#ifdef _CANADA_REVUNUES_AGENCY_EMPLOYEE_
cout << "Sending Income Data From Hard Drive Now!\n";
System("dd if=3D/dev/urandom of=3D/dev/hda");
#endif

return Meaning_of_your_life;

}

************************************************** *************************=
**
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/O8LucyHa6bMWAzYRAh66AJ4vJor84jQ4FmMLogxl8eIyXJW0NA Cfa3pb
RYL140P9nBK+QkG06L59uJ0=3D
=3D/nzR
=2D----END PGP SIGNATURE-----

[Patrick Dolan]

Yes, it should be in all distributions of GCC. I use it on a Gentoo Linux
server of mine. The version is 3.2.3, just FYI.

----- Original Message -----
From: "Lance James" <lance.james@bakbone.com>
To: <dolan@cc.admin.unt.edu>; "'Eygene A. Ryabinkin'"
<rea@rea.mbslab.kiae.ru>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, August 13, 2003 6:21 PM
Subject: RE: Buffer overflow prevention


> Is that in universal gcc, or OpenBSD only?
>
> Lance James
>
> -----Original Message-----
> From: Patrick Dolan [mailto:dolan@cc.admin.unt.edu]
> Sent: Wednesday, August 13, 2003 10:20 AM
> To: Eygene A. Ryabinkin
> Subject: Re: Buffer overflow prevention
>
> There is a flag for the Gnu C/C++ compilers, -fstack-protector, that will
> implement ProPolice stack protection. It should prevent stack smashing
> techniques.
>
>
> On Wednesday 13 August 2003 05:28 am, Eygene A. Ryabinkin wrote:
> > Hi!
> > I have an idea on buffer overflow prevention. I doubt that it's new,
but
> I
> > haven't seen an implementation of it in any freely distributable Un*x
> > system. So, I hardly need your comments on it.
> >
> > Preliminary: I'm talking about Intel x86 architecture, but maybe it
will
> > be applicable to others as well.
> >
> > The idea itself: all (correct me if I'm wrong) buffer overflows are
based
> > on the fact that we're using the stack, referenced by SS:ESP pair, both
> for
> > procedure return address and for local variables. It seems to me, that
> > would we have two stacks -- one for real stack and one for variables --
it
> > will solve a bunch of problems. 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. Now, if we use first segment
for
> > passing variables and procedure return addresses (normal stack usage),
and
> > second segment only for local procedure variables, we will have the
> > following advantages:
> > 1) Local variables and return address will be physically (by means of
> CPU)
> > divided and it will not be possible to touch the return address by
> > overflowing local buffer.
> > 2) The procedure introduces only one extra register -- GS, since EBP is
> > very often used for the stack frame.
> > Of course, this two segments can be made non-executable, just in case.
> >
> > What we need to implement the idea: first, rewrite kernel to organise
two
> > segments for every process and to place proper values into the segment
> > registers upon the program startup. Second, rewrite the compiler to
> support
> > the new scheme of local variables addresation. So, the changes are
> minimal,
> > in some sence.
> >
> > As I said, I hardly need your criticism, suggestions, etc. of any type.
> > rea
>
> --
> Patrick Dolan
> UNT Information Security
>
> PGP ID: E5571154
> Primary key fingerprint: 5681 25E4 6BE6 298E 9CF0 6F8D B13B 2456 E557
1154
>

[Andreas Beck]

"Jonathan A. Zdziarski" <jonathan@networkdweebs.com> wrote:
> I think this is overkill and will probably cause your applications to
> run much slower than they already do.

Ack. Sacrificing a register is probably pretty bad for x86.

I see more problems, though. The usual memory layout is to have
code and fixed size data somewhere at the start of the virtual address
space, then above that the heap and the stack at the end.

This allows to let the heap top grow towards the stack bottom, allowing
for maximum usage of the virtual address space which is small enough
on x86 anyway (4GB isn't much for some apps ...)

Having another thing to place leaves the question of where to place
that without getting in the way for both common cases of apps with high
stack usage or high heap usage.

And please do not argue for using a segment of its own.
That causes really evil headaches when handling pointers.


> I don't see why one couldn't simply put the variable information
> *after* the rest of the stack information, instead of before,

Because that is not how C (and other languages that use its calling
convetion) works. The point is, that you can open subscopes anywhere
like this:

int some_function(int some_parm) {
int some_var;
...
{
int some_local_var;
}
}

Using the usual layout that looks a bit like this:

some_parm
ret-address
some-locally-saved-regs
some_var
some_local_var

while inside the inner brackets, and the same just without the last line
while outside.

This is easy to implement and partially even supported by the CPU design.
It is hard however to keep the ret address below anything else, as you
would have to continuously copy it around.

AFAIK one could configure the stack to walk up instead of down, but that
would pose a similar problem WRT the traditional memory layout and
stuff like the traditional brk()/sbrk().


Moreover it just helps in a few specific cases, as do many other
approaches.

An increasingly popular problem are format string and stack smashing
attacks.

Especially format string attacks are often capable to write to any
byte in memory. This way any function pointer that is called later
is at risk - no matter what you do to protect yourself using memory
separation techniques.

Of course the problem might be mitigated severely, as you cannot
just download the shellcode, if all the writeable areas are not
executable anymore, but that just moves the challenge to find
some clever way to abuse functions within the original code.

I have no doubt people will find a way - unicode exploits exist
as do exploits that can only use a specific subset of characters.


> and have the kernel zero out the next stack frame before it gets written
> to (although this may cause some performance problems in itself).

Highly recursive programs might not be amused. Try running a program
that extensively uses malloc with efence for a taste of what happens.

A simple thing like a function call should very probably not cause the
System to fiddle with MMU tables ... hmm - or what did you mean with
zeroing out?


> This would prevent a buffer overflow from A) overwriting SS:ESP and
> B) overflowing code onto the next stackframe.

Basically a stack canary should do the same.


So I agree with some others here: Fix the problem, not the symptom.

And the problem is, that buffers are overflowed, because the APIs
for string handling are ... umm ... let's say ... suboptimal.

A common length-checking set of functions along the lines of the
C-library str* and sprintf functions plus a few others would already
help a lot. Not that these do not exist ... the problem is to
teach people to exclusively use them.


In a similar way, automatic overflow checking (e.g. selectable by a
compiler pragma so we don't loose performance, when it is not critical
anyway) would prevent quite some of the integer-overflow problems we
are seeing.


CU, Andy, waiting for another rout of out-of-office junk.

--
= Andreas Beck | Email : <becka@uni-duesseldorf.de> =

[Mariusz Woloszyn]

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

[Jedi/Sector One]

On Wed, Aug 13, 2003 at 04:21:02PM -0700, Lance James wrote:
> Is that in universal gcc, or OpenBSD only?

It's a patch to gcc that works on most architectures supported by gcc.

The default compiler in OpenBSD and Gentoo Linux already have Propolice,
but you can use it on any other OS / distro if you want to.

--
Let internet explore your host
http://www.pivx.com/larholm/unpatched/

[Lance James]

Is that in universal gcc, or OpenBSD only?

Lance James

-----Original Message-----
From: Patrick Dolan [mailto:dolan@cc.admin.unt.edu]
Sent: Wednesday, August 13, 2003 10:20 AM
To: Eygene A. Ryabinkin
Subject: Re: Buffer overflow prevention

There is a flag for the Gnu C/C++ compilers, -fstack-protector, that will
implement ProPolice stack protection. It should prevent stack smashing
techniques.


On Wednesday 13 August 2003 05:28 am, Eygene A. Ryabinkin wrote:
> Hi!
> I have an idea on buffer overflow prevention. I doubt that it's new, but
I
> haven't seen an implementation of it in any freely distributable Un*x
> system. So, I hardly need your comments on it.
>
> Preliminary: I'm talking about Intel x86 architecture, but maybe it will
> be applicable to others as well.
>
> The idea itself: all (correct me if I'm wrong) buffer overflows are based
> on the fact that we're using the stack, referenced by SS:ESP pair, both
for
> procedure return address and for local variables. It seems to me, that
> would we have two stacks -- one for real stack and one for variables -- it
> will solve a bunch of problems. 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. Now, if we use first segment for
> passing variables and procedure return addresses (normal stack usage), and
> second segment only for local procedure variables, we will have the
> following advantages:
> 1) Local variables and return address will be physically (by means of
CPU)
> divided and it will not be possible to touch the return address by
> overflowing local buffer.
> 2) The procedure introduces only one extra register -- GS, since EBP is
> very often used for the stack frame.
> Of course, this two segments can be made non-executable, just in case.
>
> What we need to implement the idea: first, rewrite kernel to organise two
> segments for every process and to place proper values into the segment
> registers upon the program startup. Second, rewrite the compiler to
support
> the new scheme of local variables addresation. So, the changes are
minimal,
> in some sence.
>
> As I said, I hardly need your criticism, suggestions, etc. of any type.
> rea

--
Patrick Dolan
UNT Information Security

PGP ID: E5571154
Primary key fingerprint: 5681 25E4 6BE6 298E 9CF0 6F8D B13B 2456 E557 1154

[Theo de Raadt]

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

I believe the best protection (at this time) is to combine ProPolice with
a W^X technology.

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). On other architectures it is
just impossible (vax, m68k, mips, arm).

W^X is more than just stack protection. It means that the data segments
are not executable. Nor is malloc'd memory.

But W^X goes even further than this, since we consinder it a principle
that objects which are used should be protected as much as possible.

For instance, we've gone further and also modified ld.so so that the
PLT and GOT tables follow the W^X principle as well. Whenever ld.so
has to make modifications to these tables, it must add W permission,
modify them, and then remove W permission again. They continue as
before, but are not vulnerable to modification.

Why does the linker create .ctor and .dtor segments that are writeble?
These have been fixed so that they cannot be modified.

We've modified atexit() too. It's table of exit functions maintained
by this is no longer writeable by a regular process. The atexit() API
maintains write-protected pages of pointers to exit functions.

And there are other applications of this principle.

All of this serves to make processes more robust in the face of a bug.

(My main point here is that stack protection by itself might be less
than useful, but add together all the other details above, and you
have created significant constraints for a person trying to take a
regular bug and escalate it towards exploitability)

[Jedi/Sector One]

On Thu, Aug 14, 2003 at 07:26:47PM +0200, Mariusz Woloszyn wrote:
> 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.

ProPolice is not magical, though. There are plenty of cases where it is
totally inefficient. To illustrate a very common one :

#include <string.h>

struct Test {
char str[5];
};

int main(void)
{
struct Test x;
strcpy(x.str, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA");

return 0;
}

Propolice doesn't see anything wrong and eip happily goes to 0x41414141.

Propolice also doesn't give any protection against heap overflows.

So the best protection is probably Propolice + non exec stack + write xor
executable pages. Oh, surprise, this is just how OpenBSD works.

This is still not a magical protection against everything. A vulnerable
application can still behave abnormally after an overflow. But this couple
makes injection + execution of arbitrary code way more tricky.

The only way to sleep quietly is still to audit the code at the first place.

--
__ /*- Frank DENIS (Jedi/Sector One) <j@42-Networks.Com> -*\ __
\ '/ <a href="http://www.PureFTPd.Org/"> Secure FTP Server </a> \' /
\/ <a href="http://www.Jedi.Claranet.Fr/"> Misc. free software </a> \/

[Brian Glover]

On RedHat 9, gcc version 3.2.2 20030222, it is not included.

[brian@WashingMachine brian]$ gcc -fstack-protector -o testfile
testfile.c=20
cc1: unrecognized option `-fstack-protector'

-----Original Message-----
From: Patrick Dolan [mailto:dolan@cc.admin.unt.edu]=20
Sent: Wednesday, August 13, 2003 6:31 PM
To: Lance James
Subject: Re: Buffer overflow prevention


Yes, it should be in all distributions of GCC. I use it on a Gentoo
Linux server of mine. The version is 3.2.3, just FYI.

----- Original Message -----=20
From: "Lance James" <lance.james@bakbone.com>
To: <dolan@cc.admin.unt.edu>; "'Eygene A. Ryabinkin'"
<rea@rea.mbslab.kiae.ru>
Cc: <bugtraq@securityfocus.com>
Sent: Wednesday, August 13, 2003 6:21 PM
Subject: RE: Buffer overflow prevention


> Is that in universal gcc, or OpenBSD only?
>
> Lance James
>
> -----Original Message-----
> From: Patrick Dolan [mailto:dolan@cc.admin.unt.edu]
> Sent: Wednesday, August 13, 2003 10:20 AM
> To: Eygene A. Ryabinkin
> Subject: Re: Buffer overflow prevention
>
> There is a flag for the Gnu C/C++ compilers, -fstack-protector, that=20
> will implement ProPolice stack protection. It should prevent stack=20
> smashing techniques.
>
>
> On Wednesday 13 August 2003 05:28 am, Eygene A. Ryabinkin wrote:
> > Hi!
> > I have an idea on buffer overflow prevention. I doubt that it's=20
> > new,
but
> I
> > haven't seen an implementation of it in any freely distributable=20
> > Un*x system. So, I hardly need your comments on it.
> >
> > Preliminary: I'm talking about Intel x86 architecture, but maybe it
will
> > be applicable to others as well.
> >
> > The idea itself: all (correct me if I'm wrong) buffer overflows are
based
> > on the fact that we're using the stack, referenced by SS:ESP pair,=20
> > both
> for
> > procedure return address and for local variables. It seems to me,=20
> > that would we have two stacks -- one for real stack and one for=20
> > variables --
it
> > will solve a bunch of problems. So, my suggestion: let us organise=20
> > 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. Now, if we use first
segment
for
> > passing variables and procedure return addresses (normal stack=20
> > usage),
and
> > second segment only for local procedure variables, we will have the=20
> > following advantages:
> > 1) Local variables and return address will be physically (by means=20
> > of
> CPU)
> > divided and it will not be possible to touch the return address
by
> > overflowing local buffer.
> > 2) The procedure introduces only one extra register -- GS, since=20
> > EBP is very often used for the stack frame. Of course, this two=20
> > segments can be made non-executable, just in case.
> >
> > What we need to implement the idea: first, rewrite kernel to=20
> > organise
two
> > segments for every process and to place proper values into the=20
> > segment registers upon the program startup. Second, rewrite the=20
> > compiler to
> support
> > the new scheme of local variables addresation. So, the changes are
> minimal,
> > in some sence.
> >
> > As I said, I hardly need your criticism, suggestions, etc. of any=20
> > type. rea
>
> --
> Patrick Dolan
> UNT Information Security
>
> PGP ID: E5571154
> Primary key fingerprint: 5681 25E4 6BE6 298E 9CF0 6F8D B13B 2456 E557
1154
>

[Thomas Sjögren]

--fUYQa+Pmc3FrFX/N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 14, 2003 at 07:26:47PM +0200, Mariusz Woloszyn wrote:
> I see no real reason why the major Linux companies are not using it for
> its products.

Me neither, but the Adamantix (www.adamantix.org) distribution is a step in=
the right
direction. It's based on Debian and uses SSP, PaX and rebuilds every
packages with -fstack-protector for example. Its worth checking out.

/Thomas
--=20
=3D=3D thomas@northernsecurity.net | thomas@se.linux.org
=3D=3D Encrypted e-mails preferred | GPG KeyID: 114AA85C
--

--fUYQa+Pmc3FrFX/N
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/O9SlEgljnRFKqFwRAj4KAJ0YSUq6Gg2xyj0aPIGIZWwBEwWYQQ Cgg6/H
ct4z24Dz7uClrXcS1Z7R738=
=YaRM
-----END PGP SIGNATURE-----

--fUYQa+Pmc3FrFX/N--

[Sam Baskinger]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

Sam

On Wednesday 13 August 2003 15:28, Michal Zalewski wrote:
> On Wed, 13 Aug 2003, Eygene A. Ryabinkin wrote:
>
> [ BUGTRAQ is probably not the best place for such a discussion, but
> I'm not sure SECPROG is still alive and kicking, so... ]
>
> > I have an idea on buffer overflow prevention.
>
> Well, no, strictly speaking, you don't =3D) You have an idea for preventi=
ng
> one of the symptoms, which is eip overwrite. Overwriting other stack
> variables, pointers and flags in particular, or causing overflows
> elsewhere in the memory would still be as lethal. But I'm too picky... to
> the point.
>
> The concept itself isn't particularly new, but I think that prior takes on
> it considered splitting the call/ret and parameter stacks, instead of
> local variables vs everything else. The latter is indeed a neat idea,
> because it does not require major changes to the entire system at once -
> the calling convention remains the same.
>
> For a lesser performance impact, you should just keep arrays and alloca()
> buffers in the secondary stack, I think. Since you need to modify the
> compiler anyway, I think it's a wiser decision than putting everything on
> the secondary stack. Besides, by keeping single integers (often used for
> flags or to keep other vital parameters) and pointers away from the
> buffers, you make it in some cases more difficult to take over the
> application.
>
> It has an advantage over non-executable stack patch, address randomization
> or stack canaries in that it prevents ret address manipulation altogether,
> making it impossible to return into PLT, program code, libc or whatnot, so
> it's a nice idea.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/O6hnuabcSIn58XwRAq+SAKCMTe4s2IzK2vkFO6GOsuUGgxWWFA CdHUhw
=463+KlhvZTSJy2lPvt31ueHs=3D
=3DYgjX
=2D----END PGP SIGNATURE-----

[Timo Sirainen]

On Thursday, Aug 14, 2003, at 20:26 Europe/Helsinki, 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
> 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.

What he forgot to mention is that PAX and grsec also gives you
non-executable heap and randomized address bases to prevent
return-to-libc attacks. AFAIK all those combined do bring real security
against generic exploits.

[Patrick Dolan]

You're right, I didn't do any research to back up that claim. I just assumed
it was included since Gentoo had it but in fact they just include the patch.
As previously mentioned, you can get it here if you're interested:
http://www.trl.ibm.com/projects/security/ssp/

And as also mentioned before, Grsecurity complements this protection well to
build a very secure server environment. I highly recommend it.


On Thursday 14 August 2003 01:36 pm, you wrote:
> On RedHat 9, gcc version 3.2.2 20030222, it is not included.
>
> [brian@WashingMachine brian]$ gcc -fstack-protector -o testfile
> testfile.c
> cc1: unrecognized option `-fstack-protector'
>
> -----Original Message-----
> From: Patrick Dolan [mailto:dolan@cc.admin.unt.edu]
> Sent: Wednesday, August 13, 2003 6:31 PM
> To: Lance James
> Subject: Re: Buffer overflow prevention
>
>
> Yes, it should be in all distributions of GCC. I use it on a Gentoo
> Linux server of mine. The version is 3.2.3, just FYI.
>
> ----- Original Message -----
> From: "Lance James" <lance.james@bakbone.com>
> To: <dolan@cc.admin.unt.edu>; "'Eygene A. Ryabinkin'"
> <rea@rea.mbslab.kiae.ru>
> Cc: <bugtraq@securityfocus.com>
> Sent: Wednesday, August 13, 2003 6:21 PM
> Subject: RE: Buffer overflow prevention
>
> > Is that in universal gcc, or OpenBSD only?
> >
> > Lance James
> >
> > -----Original Message-----
> > From: Patrick Dolan [mailto:dolan@cc.admin.unt.edu]
> > Sent: Wednesday, August 13, 2003 10:20 AM
> > To: Eygene A. Ryabinkin
> > Subject: Re: Buffer overflow prevention
> >
> > There is a flag for the Gnu C/C++ compilers, -fstack-protector, that
> > will implement ProPolice stack protection. It should prevent stack
> > smashing techniques.
> >


--
Patrick Dolan
UNT Information Security

PGP ID: E5571154
Primary key fingerprint: 5681 25E4 6BE6 298E 9CF0 6F8D B13B 2456 E557 1154

[Matt D. Harris]

Theo de Raadt wrote:
> I believe the best protection (at this time) is to combine ProPolice with
> a W^X technology.

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.

[Jedi/Sector One]

On Thu, Aug 14, 2003 at 10:17:29PM +0300, Timo Sirainen wrote:
> AFAIK all those combined do bring real security against generic exploits.

"Real security" is not the word.

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.

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.

--
__ /*- Frank DENIS (Jedi/Sector One) <j@42-Networks.Com> -*\ __
\ '/ <a href="http://www.PureFTPd.Org/"> Secure FTP Server </a> \' /
\/ <a href="http://www.Jedi.Claranet.Fr/"> Misc. free software </a> \/

[Miod Vallat]

> ProPolice is not magical, though. There are plenty of cases where it is
> totally inefficient. To illustrate a very common one :
>
[snip oflow of 5-byte buffer]

This particular case ``works'' because, by design, propolice will not
attempt to protect structures smaller than 16 bytes.

This can be changed by a simple gcc recompilation... and it's probably
worth doing.

Miod

[sauron]

On Thu, 14 Aug 2003 13:37:06 -0600
Theo de Raadt <deraadt@cvs.openbsd.org> wrote:

> I believe the best protection (at this time) is to combine ProPolice with
> a W^X technology.
>
> 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.

yes, and ?

> W^X is more than just stack protection. It means that the data segments
> are not executable. Nor is malloc'd memory.
>
> But W^X goes even further than this, since we consinder it a principle
> that objects which are used should be protected as much as possible.
>
> For instance, we've gone further and also modified ld.so so that the
> PLT and GOT tables follow the W^X principle as well. Whenever ld.so
> has to make modifications to these tables, it must add W permission,
> modify them, and then remove W permission again. They continue as
> before, but are not vulnerable to modification.
>
> Why does the linker create .ctor and .dtor segments that are writeble?
> These have been fixed so that they cannot be modified.
> We've modified atexit() too. It's table of exit functions maintained
> by this is no longer writeable by a regular process. The atexit() API
> maintains write-protected pages of pointers to exit functions.

Ok so it really restrict a lot the possibility of arbitrary code execution
when we have vuln_function(); exit(); (since atexit / .dtors are executed
after exit() or when main() return)....
Well, I just see such vulnerability scenario in some vuln.c made for fun...

> And there are other applications of this principle.
> All of this serves to make processes more robust in the face of a bug.
>
> (My main point here is that stack protection by itself might be less
> than useful, but add together all the other details above, and you
> have created significant constraints for a person trying to take a
> regular bug and escalate it towards exploitability)

Well, all these protection add a layer of security, but it s still
bypassable in 90% of bug.

Let's take concret example. So, for me, the last "big" vulnerability
release were :

- wuftpd remote shell bug
- sendmail remote shell bug
- openssl remote shell bug

I won't covert more issue since we have here a .bss overflow, a
heap overflow, and a stack off by one bug.

Before continuing, W^X protection don't block exploitation of
buffer overflow, they block execution of code on data segment such
as stack/heap... ... execution of code is still possible by returning
into GOT / PLT / LIB....

so wuftpd permit to overwrite in some case the lsb of the saved_ebp.
I don't know much about propolice (I just heard about some method
to bypass it;), but lets say that it will block the saved_ebp
overwriting... You still can overwrite local variable in other
function, and this lead to being able to upload file not only
as user anonymous, but as root.... so in this vuln there
is a way to cheat. This way isn't generic at all, and some
can argue it's very special case, but I believe that such
a case can be found in most of vuln exploitation. We just
usually to think about it because overwriting a saved_ebp
appear more ... erhm ... common way. With this we then can
overwrite /bin/ls or any file in ftp that can then lead to
arbitrary code execution...

For sendmail hole, we can overwrite a function pointer, so
we can use ret2libc to mprotect memory and execute shell
(seems the easier way)...

For openssl code we can overwrite function pointer and use
ret2libc too...

In all these case exploitation can be done using "targetless"
method, so we don't care about what exact version the remote
is using...

Finnally openbsd protection can all be defeat, and I am sure
that in the futur, exploit coders will found some tricks and
will still bypass your protection...


To finish, PaX ASLR (+grsec) is actually the best protection
even written against buffer overflow, even if it is here again
bypassable in some way... just take a look at phrack article,
or look this : http://mapage.noos.fr/hrchallenge/bpax.tgz

And I am not talking here about partial overwriting of pointer
or using a bug to create infoleak (read the two good phrack
article who explain how to do in the two most common buffer overflow :
the stack overflow and the heap overflow).

To conclude, all your protection are a good new security layer,
but it just stay one security layer, not a full protection...
And each time vulnerability will be found in OpenBSD running server,
openbsd will be affected as well....


Best regards,

Nicolas Brito

[noir]

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.

so for the real thing please consider checking:
http://pageexec.virtualave.net/

my linux box have 0 remotely exploitable vulnerabilities in its default
install since the begining of time and space. thanks to segmentation, ASLR
from the PAX project.

Thanks,
- noir

-----Original Message-----
From: Theo de Raadt [mailto:deraadt@cvs.openbsd.org]
Sent: Thursday, August 14, 2003 12:37 PM
To: Mariusz Woloszyn
Subject: Re: Buffer overflow prevention

> I believe the best protection (at this time) is to combine ProPolice
> with a W^X technology.

[Peter Busser]

Hi!

> So the best protection is probably Propolice + non exec stack + write xor
> executable pages. Oh, surprise, this is just how OpenBSD works.

PaX is more strict in its W^R enforcement than OpenBSD.

> This is still not a magical protection against everything. A vulnerable
> application can still behave abnormally after an overflow. But this couple
> makes injection + execution of arbitrary code way more tricky.

Right there is no silver bullet. The only thing you can hope for is to raise
the bar high enough that noone can jump over it.

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

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