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>] [day] [month] [year] [list]

Message-ID: <3F40B615.30971.E269C0B@localhost>
Date: Mon, 18 Aug 2003 11:18:45 +0200
From: pageexec@...email.hu
To: bugtraq@...urityfocus.com
Cc: full-disclosure@...ts.netsys.com
Subject: Re: Buffer overflow prevention

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.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html