Vulnerability Development mailing list archives

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


From: Pravin <shindepravin () gmail com>
Date: Tue, 3 Oct 2006 09:52:13 +0530

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 <list-recv () crepinc com> 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


Current thread: