full-disclosure - Re: Paper: How to exploit overflow vulnerability under Fedora Core 2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

From: arjanv at redhat.com (Arjan van de Ven)
Subject: Re: Paper: How to exploit overflow vulnerability
	under Fedora Core 2

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.