Re: [VulnDiscuss] Re: Preventing exploitation with rebasing

> 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: <[email protected]>
> To: "David Litchfield" <[email protected]>
> 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!
> >
> >
> Hey David,

> 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.

Well, it is true -- if you have a complete & correct disassembly of an .EXE
you can rebase it. Problem is the "correct". Only one misidentified offset
will introduce bugs into the program, and that can easily happen. Consider
an application that has the data 0x00412D42 in it's global heap -- is this
going to be an offset into the application or just the string "A-B" ?

It's a dangerous game, and once you have a code analysis engine sufficiently
advanced to be able to handle even very complex cases, you might as well
use it to find the buffer overflows in the first place.

Of course, a company could use IDA and spend massive time to ensure the
disassembly is correct, then generate a list of relocs, rebase and test the
application. Would make for a great subscription service <g> :)

Point is: No Bank is going to run your rebased software if it a) threatens
stability of production systems and b) voids all warranty :)

Cheers,
Halvar

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!