BugTraq
Re: Preventing exploitation with rebasing Feb 05 2003 10:29AM
David Litchfield (david ngssoftware com) (4 replies)
Re: Preventing exploitation with rebasing Feb 05 2003 10:43PM
Bugtraq User (bq soft-analysts com)
Re: Preventing exploitation with rebasing Feb 05 2003 09:30PM
Todd Sabin (tsabin optonline net) (1 replies)
Re: Preventing exploitation with rebasing Feb 06 2003 12:07AM
Seth Breidbart (sethb panix com) (2 replies)
Re: Preventing exploitation with rebasing Feb 06 2003 11:29PM
Carolyn Meinel (cmeinel techbroker com)
Re: Preventing exploitation with rebasing Feb 06 2003 05:50PM
Richard Moore (rich westpoint ltd uk)


Seth Breidbart wrote:
> In theory, it's easy to prove that some programs cannot be relocated,
> period. Anybody who has been programming long enough has seen people
> re-use a memory location as both an address and a constant in order to
> keep the program small enough (12k OK; 12k + 2 bytes really bad
> news). That can't be relocated.
>
> Even under the assumption that locations aren't re-used, it's provably
> impossible (Turing-complete) to determine whether the contents of a
> location can be used as an address by a program.

Sure, that is a basic corollary of the Von-Neuman programming model
(whereby a program is simply a type of data). However, it is possible to
make this untrue if you modify the model slightly to make memory areas
that are executable unreadable. Of course you are then no longer running
on a Von-Neuman machine, so the Turing machine abstraction breaks down
somewhat. Unfortunately it is difficult to acheive this with modern CPUs
and even were it to be possible, there does need to be a part of the
system somewhere that can read/write to these segments in order to
handle the loading of shared libraries etc.

Cheers

Rich/

>
> That said, _if_ a program is relocatable, relocating it would seem to
> be an easy way to gain some security. Whether that's worth the cost
> (in fragility and undebuggability) is another question.
>
> Seth
>

[ reply ]
Re: Preventing exploitation with rebasing Feb 05 2003 08:48PM
D.C. van Moolenbroek (dc van moolenbroek chello nl)
Re: Preventing exploitation with rebasing Feb 05 2003 08:36PM
Michal Zalewski (lcamtuf coredump cx)


 

Privacy Statement
Copyright 2010, SecurityFocus