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]

Date: Thu, 14 Aug 2003 11:19:03 -0400
From: Sam Baskinger <sam@...fedge.com>
To: Michal Zalewski <lcamtuf@...edump.cx>,
	"Eygene A. Ryabinkin" <rea@....mbslab.kiae.ru>
Subject: Re: Buffer overflow prevention


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

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.

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 =) You have an idea for preventing
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/O6hnuabcSIn58XwRAq+SAKCMTe4s2IzK2vkFO6GOsuUGgxWWFACdHUhw
F3+KlhvZTSJy2lPvt31ueHs=
=YgjX
-----END PGP SIGNATURE-----