Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Vulnerability Development: Re: Beating memory address randomization (secuirty) features in Unix/Linux

Re: Beating memory address randomization (secuirty) features in Unix/Linux

From: <c0d3r_at_ihsteam.com>
Date: Sat, 1 Apr 2006 02:05:41 +0430 (IRDT)

think deeper , all the distros with randomization I have seen ; also
have null byte in ret to libc addresses , so that wont work here .

c0d3r of IHS
Network Security Researcher

>> As you can see linux-gate.so.1 is linked on stack program and its
>> address isn't randomized.
>>
>> In this range address there is a lot of instructions mainly JMP *%ESP
>> which can be used to points to stack and execute arbitraty code.
>>
>
> Bothering with the stack is a bore and doesn't always work
> depending on the architecture. Easier to just return to libc
> since even if the stack base isn't randomized (as it often is,
> lately) we don't have to care with finding it. Libc does
> everything you'd need to secure control of your target,
> anyway.
>
> I pretty much stick with return-to-libc for local exploits
> simply because it's often more consistent relative to
> results. Your shell (environment variables, etc) plus
> other environmental issues will skew stack addresses
> slightly enough to make exploitation a little bother.
> However, libc always maps to the same place. Then
> you really only have to worry about the version you're
> using.
>
> Don "north" Bailey
>
>
Received on Mar 31 2006

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos