Going back to exe image files and rebasing. Surely they can be rebased even
without a .reloc section? All I need to do is edit the image base in the PE
header then parse the assembly looking for absolute addresses such as
function addresses, static variables etc and modify these addresses, too.

For example assume an image base for an exe is 0x00400000 and the c code
does

printf("hello");

This will generate something like

push 0x0042001C // push pointer to hello
call 0x00401060 // call printf

If I then make the image base 0x00410000 and I also change

push 0x0042001C
call 0x00401060

to become

push 0x0043001C
call 0x00411060

then the exe should still run (as long as you get all the absolute
addresses) and it has been rebased.

?
David

----- Original Message -----
From: <Dulliengmx.de>
To: "David Litchfield" <davidngssoftware.com>
Sent: Tuesday, February 04, 2003 12:35 PM
Subject: Re: Re[2]: Preventing exploitation with rebasing

> Hey Dave,
>
> > How's it going?
>
> Uni exam crunch :-( spending days with 10+ hours of math.
>
> >The idea of rebasing has merit - but it also has it's
> > problems. I would have thought that someone with your deep knowledge in
> > this
> > area would have, not just pointed out the problems, but also worked on
the
> > idea and provided solutions for where rebasing fails. Seems everyone, as
> > opposed to working together, wants to jump on and squash an idea and be
> > done
> > with it.
>
> Sorry ;)
> The idea of rebasing has come up in the PaX project for other reasons, and
> has
> been very extensively discussed there -- including solutions for most
> problems,
> which are unfortunately only feasible if you can recompile binaries.
>
> The method is used on the Unix platform as on non-x86 architectures you
> frequently
> have the capability of setting memory pages to be readable but not
> executable.
> That way, the injection & execution of shellcode is stopped completely, as
> no
> writable page is executable. So the attacker can only attempt
> return-into-libc
> exploits, which are properly prevented by randomizing the entire address
> range.
>
> In combination with truly non executable writable pages, base address
> randomization
> is a good thing. Problem is still: How to rebase binaries without relocs ?
> You can't.
>
> The reason why the idea is clever on Unix and not clever on Windows has to
> do
> with these three factors:
> a) Unix bins can be recompiled to be relocatable, Windows bins can't :)
> b) Linux supports true non-exec heap pages, BSD on SPARC too, etc...
> Windows does not, and as achieving it on x86 is an undocumented
> hack against Intel's will MS will not implement this. This may
change
> on
> Itanium
> c) Unix doesn't keep any interesting structures mapped to static
places,
> but Windows does -- TEB and PEB addresses are more or less
hardcoded,
> so one could always try to attack data stored there
>
> So the idea would be clever if
> a) MS (and all other closed src vendors) would start building exes with
> relocs
> b) Non-exec heap pages are supported & enforced
> c) All statically mapped structures are either moved to kernel space or
> randomized
> as well.
>
> Please excuse, I didn't want to be destructive -- but the paper's current
> form discussed
> none of the drawbacks/problems, so I thought it would be in order to
mention
> them and
> put the claims made in the paper into perspective. And I did post the link
> to PaX which
> discusses & implements a few of the solutions (and makes owning systems a
> fucking
> nightmare).
>
> Hope I didn't piss you off with my posts :)
>
> How is life at your place ? I'll come to visit London sometime this spring
> (march/april), we
> need to go for beers :) I heard NGSSEC is doing real well nowadays,
> congratulations,
> you'll outlive the stake wankers :)
>
> Cheers,
> Thomas
>
>
>
> --
> +++ GMX - Mail, Messaging & more http://www.gmx.net +++
> NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]