[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Full-Disclosure] Re: Paper: How to exploit overflow vulnerability under Fedora Core 2
- To: full-disclosure@xxxxxxxxxxxxxxxx
- Subject: [Full-Disclosure] Re: Paper: How to exploit overflow vulnerability under Fedora Core 2
- From: Arjan van de Ven <arjanv@xxxxxxxxxx>
- Date: Wed, 19 Jan 2005 09:30:20 +0100
This is a response to a bugtraq posting
(http://www.securityfocus.com/archive/1/387192/2005-01-14/2005-01-20/0)
that the bugtraq moderators repeatedly don't let through; I wanted to get
the remarks wrt the original paper out anyway.
On Fri, 2005-01-14 at 03:08 +0000, vangelis vangelis wrote:
> This paper is about the way of exploiting overflow vulnerability under
> Fedora Core 2.
> I don't think this is a perfect guide to the exploitation.
> If there are some mistakes, give your feedback.
> I just want this paper will help you to make much better papers about
> subject.
> 3. What is exec-shield?
> You can understand 'what exec-shield is' by redaing
> "ANNOUNCE-exec-shield". You can find
> "ANNOUNCE-exec-shield" in
> "http://people.redhat.com/mingo/exec-shield/ANNOUNCE-exec-shield".
the text at this url was outdated, we've updated it to link to two other
documents:
exec-shield description:
http://www.redhat.com/f/pdf/rhel/WHP0006US_Execshield.pdf
description of security enhancements in RHEL/FC
http://people.redhat.com/drepper/nonselsec.pdf
which closer resemble the state of affairs in FC2 and FC3 (and RHEL3)
> Good! The first step is quite easy. You can find the address of
> <execl+3> by using gdb.
I would like to point 2 things out here:
1) You can only find this address because prelink has put glibc in a
fixed (but randomized) location. This fixed location will change
every 2 weeks to a new randomized value. This means that every
machine out there has a different value for execl(), and the value
changes every 2 weeks.
You can unprelink your system if you don't believe prelink caused
this.
2) You did not make your application a PIE executable (you can do so
with gcc -fpie -pie vul.c -o vul ). PIE executables are in themselves
randomized, and in addition will ignore the prelink "fixing" of
addresses, and thus making it near impossible to find the address of
the app you want to exploit[1], unless you do it from the same
debugging session (but if you can attach a debugger you fully own the
app anyway) Most (if not all) network facing daemons in FC are
compiled as PIE for this reason, and we're in progress to extending
that to other "sensitive" binaries
[1] As with all randomisations, one can in principle do a brute-force
attempt, at which point it comes down to statistics and the entropy of
the randomisation.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html