bugtraq - Re: Buffer overflow prevention

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.56.0308131111010.7947@mariner.cs.ucdavis.edu>
Date: Wed, 13 Aug 2003 11:18:01 -0700 (PDT)
From: "Jingmin (Jimmy) Zhou" <jimmy@....dhs.org>
To: "Eygene A. Ryabinkin" <rea@....mbslab.kiae.ru>
Subject: Re: Buffer overflow prevention


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is not a complete solution. It's just like non-executable
stack that prevents a certain number of buffer overflows in the
stack. Heap overflows, or some advanced buffer overflow attacks
can easily bypass this approach. Furthermore, let's suppose we
have the following code. How do you prevent the overwrite of
the critical variable 'pass' if 'buf' is overflowed (yes, it's
an extreme case, but still possible in some programs)?

foo (char* password)
{
   int  pass = 0;
   char buf[N];

   while (*password)
     *buf++ = *password++;

   ...
   if (pass)
     grant_privilege (...);
   else
     error ("invalid password");
}

On Wed, 13 Aug 2003, 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
>

____________________________________________________________
Jingmin (Jimmy) Zhou             Mail : jimmy AT mtc.dhs.org
Web : www.mtc.dhs.org             ICQ : 19587415

The future is not set.  There is no fate but what we make
for ourselves.             - Terminator II, Judgement Day
____________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/OoDcVieKrU8JxnkRAn8bAKDWdQCH5VRXnEFYHXYsEgE/c3kYcQCdGPRZ
yuxDDOlflab+yfkGUAQn1nM=
=SkN8
-----END PGP SIGNATURE-----