Re: bypassing randomized stack using linux-gate.so.1

> As I recall, in distributions such as Debian, linux-gate is at a static
> address. Thus this isn't a kernel-level thing, but rather something the
> Fedora team did.
>
> If you look in a debugger, you'll see that linux=gate only moves a few
> hundred bytes or so per execution. The stack can move several thousand!
> So it's not stack VA (the randomization) that moves it. I'm not sure why
> it moves, but the space it moves in is small enough that you could brute
> force it if you needed to.
>
> Still, even if you can find it you can't JMP to it due to the ASCII sheild.
>
> Let me know what you find out,

As linux-gate was using randomized addresses and ascii-shield also,
I managed to find the "call *%edx" instruction within the vulnerable
program itself.
and overwrote the return address with the address of this "call *%edx"
instruction.
The shellcode was passed as argument to function.

I found "call *%edx" instruction in <__do_global_dtors_aux>  in ".text" section
of disassembled vulnerable code.

The advantage with using "call *%edx" instruction from vulnerable
program only is that,
These addresses are not ascii-shielded.
I also found that this part was not randomized,
so address of "call *%edx" was always fix,
and thats why I was able to provide the address for overwriting.

The only problem is that shell-code is still in stack
(I am passing it as command line argument), and so this method will
work only when
exec-shield is turned off or not present.

Is there any other place to keep the shellcode, where some general
purpose register will point ?
>
> -Jack Carrozzo
> jack _[@]_ crepinc.com
>
> Pravin wrote:
> > Thanx Jack Carrozzo,
> > I have already broken my head to learn that point :-(
> > Actually, all shared liabraries are ASCII shielded in Fedora
> >
> > linux-gate.so.1 =>  (0x00111000)
> > libc.so.6 => /lib/libc.so.6 (0x00bb0000)
> > /lib/ld-linux.so.2 (0x00b8f000)
> >
> > So, even "return-to-libc" method is also useless in this case.
> > But what I dont understand is "linux-gate.so.1" is supposed to have
> > "fixed location" in all processes.
> > Is Fedora kernel is patched up to change the location of
> > "linux-gate.so.1" in every process?
> >
> > Thanx again
> >
> > On 9/22/06, Jack C <[email protected]> wrote:
> >> You can't JMP to liux-gate.so on Fedora: It's ASCII Shielded.
> >>
> >> linux-gate.so.1 =>  (0x00111000)
> >>
> >> The first byte is 0x00, or a null char. It's next to impossible to get a
> >> NULL as the first byte of the ESP.
> >>
> >> Have fun,
> >>
> >> -Jack Carrozzo
> >> jack _[@]_ crepinc.com
> >>
> >> Pravin wrote:
> >> > Hi,
> >> > I was working with bypassing randomized stack using "linux-gate.so.1"
> >> > I am using Fedora Core 5 and problem with it is that location of
> >> > linux-gate.so.1 is not fixed.
> >> > But other libraries are having fixed location ( like libc.so.6 and
> >> > ld-linux.so.2 )
> >> >
> >> > I changed the value of "/proc/sys/kernel/randomize_va_space" to 0 and
> >> > tested.
> >> > But still it was of no use for me.
> >> > Simillarly I changed the value of "/proc/sys/kernel/exec_shield" to 0
> >> > and tested,
> >> > but even that didn't helped :-(
> >> >
> >> > I have given bellow, output of two consecutive ldd executions.
> >> >
> >> > $ ldd vulerable02
> >> > linux-gate.so.1 =>  (0x00111000)
> >> > libc.so.6 => /lib/libc.so.6 (0x00bb0000)
> >> > /lib/ld-linux.so.2 (0x00b8f000)
> >> >
> >> > $ ldd vulerable02
> >> > linux-gate.so.1 =>  (0x00d47000)
> >> > libc.so.6 => /lib/libc.so.6 (0x00bb0000)
> >> > /lib/ld-linux.so.2 (0x00b8f000)
> >> >
> >> > I know that I can use other libraries to get fix physical addresss of
> >> > "JMP *%ESP"
> >> > or "CALL 8%ESP", but I want to know why is it happening like this?
> >> >
> >> > I tried googling, bt didn't got much.
> >> > Linux-gate.so.1 is supposed to have same address space
> >> > (that is 0xffffe000 ) in all  processes. (as per
> >> > http://www.trilithium.com/johan/2005/08/linux-gate/)
> >> >
> >> > Can someone please help me by explaining me why is it happening like
> >> > this?
> >> >
> >> > I was refering links like
> >> > "http://milw0rm.org/papers/55"
> >> > "http://rawlab.mindcreations.com/codes/exp/randstack/exp_call_rand.pl"
> >> >
> >> > Thank you.
> >>
> >>
> >
> >
>
>


--
 Pravin Shinde