|
BugTraq
Preventing exploitation with rebasing Feb 04 2003 05:08AM David Litchfield (david ngssoftware com) (7 replies) Re: Preventing exploitation with rebasing Feb 05 2003 01:41PM dullien gmx de (1 replies) Re: Preventing exploitation with rebasing Feb 04 2003 10:52PM David Litchfield (david ngssoftware com) (2 replies) Re: Preventing exploitation with rebasing Feb 04 2003 02:00PM sd hysteria sk (1 replies) Re: Preventing exploitation with rebasing Feb 04 2003 11:20PM David Litchfield (david ngssoftware com) Re: Preventing exploitation with rebasing Feb 04 2003 02:00PM Torbjörn Hovmark (torbjorn hovmark abtrusion com) Re: Preventing exploitation with rebasing Feb 04 2003 11:38AM Charlie Root (weedpower home ro) (4 replies) Re: Preventing exploitation with rebasing Feb 06 2003 01:00AM Deus, Attonbitus (Thor HammerofGod com) Re: Preventing exploitation with rebasing Feb 04 2003 08:08PM Brian Hatch (bugtraq ifokr org) (2 replies) Re: Preventing exploitation with rebasing Feb 04 2003 05:26PM Alan DeKok (aland freeradius org) (2 replies) Re: Can't Preventing exploitation with rebasing Feb 05 2003 10:06AM bugtraq gaza halo nu (2 replies) Observation on randomization/rebiasing... Feb 05 2003 09:10PM Nicholas Weaver (nweaver CS berkeley edu) (1 replies) Re: Preventing exploitation with rebasing Feb 04 2003 06:38PM David Litchfield (david ngssoftware com) (1 replies) Re: [VulnDiscuss] Re: Preventing exploitation with rebasing Feb 05 2003 05:32PM Halvar Flake (halvar gmx net) Re: [VulnDiscuss] Preventing exploitation with rebasing Feb 03 2003 09:49PM Michal Zalewski (lcamtuf coredump cx) |
|
Privacy Statement |
> *******
> The problem with operating systems is that they all have pretty much the
> same "genetic code" which makes each and every one of them vulnerable to a
> new exploit. So we need to make them different and this can be achieved
> through rebasing. Rebasing is the process of changing the Image Base of an
> image file. By doing this the DLL/EXE is loaded into a different location in
> the virtual address space.
Similar idea, applied to the location of stack, was implemented in OpenBSD.
This is from OpenBSD CVS (August 2001):
"Add a possibility to add a random offset to the stack on exec. This makes
it slightly harder to write generic buffer overflows. This doesn't really
give any real security, but it raises the bar for script-kiddies and it's
really cheap.
The range of the random offsets is controlled by the sysctl
kern.stackgap_random (must be a power of 2)."
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/kern_exec.c.diff?r1=1
.54&r2=1.55
[ reply ]