diff options
Diffstat (limited to 'html/etdyn.html')
| -rw-r--r-- | html/etdyn.html | 213 |
1 files changed, 213 insertions, 0 deletions
diff --git a/html/etdyn.html b/html/etdyn.html new file mode 100644 index 0000000..64c8b3c --- /dev/null +++ b/html/etdyn.html @@ -0,0 +1,213 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> +<html lang="en"> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<link title="new" rel="stylesheet" href="http://www.gentoo.org/css/main.css" type="text/css"> +<link REL="shortcut icon" HREF="http://www.gentoo.org/favicon.ico" TYPE="image/x-icon"> +<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/www-gentoo-org.xml" title="Gentoo Website"> +<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/forums-gentoo-org.xml" title="Gentoo Forums"> +<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/bugs-gentoo-org.xml" title="Gentoo Bugzilla"> +<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/packages-gentoo-org.xml" title="Gentoo Packages"> +<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/archives-gentoo-org.xml" title="Gentoo List Archives"> +<title>Gentoo Linux Documentation +-- + </title> +</head> +<body style="margin:0px;" bgcolor="#ffffff"><table width="100%" border="0" cellspacing="0" cellpadding="0"> +<tr><td valign="top" height="125" bgcolor="#45347b"><a href="http://www.gentoo.org/"><img border="0" src="http://www.gentoo.org/images/gtop-www.jpg" alt="Gentoo Logo"></a></td></tr> +<tr><td valign="top" align="right" colspan="1" bgcolor="#ffffff"><table border="0" cellspacing="0" cellpadding="0" width="100%"><tr> +<td width="99%" class="content" valign="top" align="left"> +<br><h1></h1> +<form name="contents" action="http://www.gentoo.org"> +<b>Content</b>: + <select name="url" size="1" OnChange="location.href=form.url.options[form.url.selectedIndex].value" style="font-family:sans-serif,Arial,Helvetica"><option value="#doc_chap1">1. Introduction</option> +<option value="#doc_chap2">2. How to produce ET_DYN ELF executables</option> +<option value="#doc_chap3">3. ET_DYN ELF executables (The Gentoo Way)</option> +<option value="#doc_chap4">4. Credits</option></select> +</form> +<p class="chaphead"><a name="doc_chap1"></a><span class="chapnum">1. + </span>Introduction</p> +<p>One of the features of PaX is Address Space Layout Randomization (ASLR) + that allows the kernel to randomize the addresses of various areas in + the task's address space. While most of ASLR requires no changes in + userland, randomizing the main executable's base address presents a + challenge as traditionally such ELF executables of the ET_EXEC kind + do not contain enough relocation information. Nevertheless, PaX provides + two ways to solve this problem: RANDEXEC and RANDMMAP. </p> +<p>RANDEXEC works by mapping the ET_EXEC ELF file in a special way in memory + and requires no changes in userland (except for actually enabling it on + a given file, as this feature is disabled by default). The drawback of + this approach is that it is slow (the kernel compilation benchmark sees + a 3 times slow down for example) and prone to false positive detections + of so-called return-to-libc style attacks (which renders it unusable on + such executables). </p> +<table class="ncontent" width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td bgcolor="#ffbbbb"><p class="note"><b>Warning: </b>Therefore this method mainly exists to prove a point + and is not intended for production use.</p></td></tr></table> +<p>RANDMMAP on the other hand works on ELF files of the ET_DYN kind which is + normally used for dynamically linkable libraries. This approach has none + of the drawbacks that plague RANDEXEC because such ET_DYN ELF files have + enough relocation information and the dynamic linker has no problem with + relocating them (and there is no performance penalty at runtime), nor is + there a chance for false positive attack detections as none is done in the + first place. This means that protecting against the return-to-libc style + attack (in case the information about the randomization can leak to the + attacker) requires other approaches, which is not discussed here.</p> +<p>It should be clear by now that the preferable way of randomizing the main + executable's base address is via RANDMMAP and not RANDEXEC. This in turn + means that we need a way to produce ET_DYN ELF executables instead of the + ET_EXEC kind. The following parts describe the process in detail and + hopefully provide enough information so that modifying existing packages + to produce ET_DYN ELF targets will not be a problem. Software authors + and/or package maintainers are encouraged to provide such make targets + themselves in the future.</p> +<p class="chaphead"><a name="doc_chap2"></a><span class="chapnum">2. + </span>How to produce ET_DYN ELF executables</p> +<p>The following discussion assumes that the GNU toolchain (such as gcc and + ld) is used to produce the target file, other languages and tools should + follow the same principles however. The process has two main steps, first + compilation then linking, both of which need to be modified for producing + an ET_DYN ELF executable.</p> +<p>Compilation has to be modified in order to produce position independent + code (PIC) which in turn allows the linker to not emit so-called text + relocations in the final ET_DYN ELF file. Although this step is not + strictly required (it does not affect the relocatability of the result), + it is useful as this allows for another security related hardening: PaX + normally makes it impossible to make an executable file mapping writable, + however for text relocations it has to make an exception. If there are + no such ET_DYN ELF files on a system, this exception can be removed and + then the only way to introduce new executable code into a task's address + space will be via file creation and mapping (which can be prevented by + other methods such as ACL systems). Producing PIC is very easy, one just + has to add the -fPIC switch to the compiler command line. This will not + get rid of all text relocations however as there are other sources of + (position dependent) code contributing to the final ET_DYN ELF file that + will lead us to the next step.</p> +<p>Linking the main executable is governed by a special script called the + 'specs' file ('gcc -v' tells us what is used by default). Studying it in + detail is beyond our scope, but let's note the fact that there are more + object files linked into the result than one has specified on the linker + command line. These extra objects are necessary for implementing such + features as calling constructors/destructors or the low-level entry point + of the code (the main() C function is not the actual entry point of an ELF + executable). </p> +<p>Linking an ET_DYN ELF file is initiated by specifying the -shared switch + on the gcc command line which in turn will affect what extra object files + go into the result. Since our actual goal is to produce the main executable + (vs. a shared library), we have to make sure that we link in all extra + objects normally expected by an ET_EXEC target and not necessarily those + specified by the specs file for libraries. Luckily there is only one extra + object we have to take care of: crt1.o (we will ignore profiling and not + care about gcrt1.o). It is no coincidence that crt1.o is not linked into + shared libraries as this object contains (among others) the low-level entry + point and startup code that invokes the C library startup code which in + turn calls main(). + <table class="ncontent" width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td bgcolor="#ffbbbb"><p class="note"><b>Warning: </b>Initiating the building of ET_DYN executables on Gentoo does not require us to put -shared in our CFLAGS or LDFLAGS</p></td></tr></table></p> +<p>Making crt1.o position independent is easy, we just have to make use of the + GOT (in keeping with the tradition of the glibc naming convention for the + position independent version of the extra object files, we will call it + crt1S.o). There is one last issue to take care of: a dynamically linked + executable requires a special program header that specifies the dynamic + linker to be mapped into memory by the kernel on task creation. As we can + see it from the specs file, having the -shared switch on the linker command + line will omit the dynamic linker specification and would produce an + unusable ET_DYN ELF file. The solution is simple, we follow the approach + of glibc which is also an executable ET_DYN ELF file: the dynamic linker + is specified in an object file that contains the full path to the dynamic + linker in a specific ELF section that ld will recognize and convert into + the corresponding program header.</p> +<p>The above method is demonstrated on a simple 'hello world' program that + is included with this document. The source code of the main executable + is in a.c, our PIC crt1 is in crt1S.S (it has to be written in assembly, + the code is directly derived from glibc 2.2) and finally interp.c defines + the dynamic linker (technically it could be put into crt1S.S as well to + reduce the number of extra files to a minimum). The makefile is very + simple as well, it compiles each source file into an object file and then + links them together. One important thing to note is the order of the + object files on the linker command line: crt1S.o must come first (that is, + before any object file of the application) and interp.o should follow it + directly as this will result in the interpreter program header getting + emitted before the PT_LOAD headers (which is the normal program header + ordering in ET_EXEC files, although it is not strictly necessary). Since + crt1S.o and interp.o are constant (they do not depend on the application + code) they can be compiled once and put into the same directory where + the other systemwide crt* files are.</p> +<p class="chaphead"><a name="doc_chap3"></a><span class="chapnum">3. + </span>ET_DYN ELF executables (The Gentoo Way)</p> +<p>On Gentoo this is accomplished by merging <span class="code-input">hardened-gcc</span>: </p> +<a name="doc_chap3_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0"> +<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.1: Emerging hardened-gcc</p></td></tr> +<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre> +<span class="code" dir="ltr"># emerge hardened-gcc</span> +</pre></td></tr> +</table> +<p><span class="code-input">hardened-gcc</span> is an umbrella package for non-mainstream gcc modifications + The <span class="code-input">hardened-gcc</span> packages was initially created by Alexander Gabert + for this special purpose we are serving here: rolling out the etdyn + specs file and interp.o together with the position independent + crt1S.o. But this package is not limited to that purpose. + It was designed to be the be used for any future changes to gentoo-hardened systems + regarding the improvement of gcc compiling binaries that are more secure + than the default product coming out when the vanilla gcc is used. And it can be used for ebuild packages to + "trigger" some alternative action once they "realize" that they are + getting built on a system equipped with a modified gcc for enforcing + gentoo hardened protection measures. Straight this means that when a + package is found to be breaking when used with the hardened-gcc changes, + the particular ebuild of that failing package can and will be modified + by our gentoo-hardened developers to put some "check" logic into it when + the hardened-gcc is found on the target system. </p> +<p>As an example lets try the rebuilding our chpax binary as an ET_DYN + shared executable. We can use the file(1) command to determine if we + in fact we are building our executables as ET_EXEC or ET_DYN.</p> +<p>The first example here we have chpax built as an ET_DYN and the second + one is chpax built as an ET_EXEC.</p> +<a name="doc_chap3_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0"> +<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.2: Example files</p></td></tr> +<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre> +<span class="code" dir="ltr"># file /sbin/chpax</span> +/sbin/chpax: ELF 32-bit LSB shared object, Intel 80386, version 1 \ +(GNU/Linux), stripped +/sbin/chpax: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for \ +GNU/Linux 2.0.0, dynamically linked (uses shared libs), stripped +</pre></td></tr> +</table> +<p class="chaphead"><a name="doc_chap4"></a><span class="chapnum">4. + </span>Credits</p> +<p class="secthead"><a name="doc_chap4_sect1">Works Cited</a></p> +<ul><li><a href="http://pax.grsecurity.net">PaX Homepage</a></li></ul> +<ul><li><a href="http://pax.grsecurity.net/docs/index.html">PaX Documentation</a></li></ul> +<ul><li>Collective Work. PaX - Gentoo Wiki.</li></ul> +<br><br> +</td> +<td width="1%" bgcolor="#dddaec" valign="top"><table border="0" cellspacing="4px" cellpadding="4px"> +<tr><td class="topsep" align="center"><p class="altmenu"><a title="View a printer-friendly version" class="altlink" href="http://www.gentoo.org/proj/en/hardened/etdyn.xml?style=printable">Print</a></p></td></tr> +<tr><td class="topsep" align="center"><p class="alttext">Updated 5 Aug 2003</p></td></tr> +<tr><td class="topsep" align="left"><p class="alttext"><b>Summary: </b> +This guide contains documentation and examples on how to create dynamic ELF executables. +These guidelines are required to achieve full Address Space Layout Randomization. +</p></td></tr> +<tr><td align="left" class="topsep"><p class="alttext"> + <a href="mailto:pageexec@freemail.hu" class="altlink"><b>The PaX Team</b></a> +<br><i>Author</i><br><br> + <a href="mailto:solar@gentoo.org" class="altlink"><b>solar</b></a> +<br><i>Contributor</i><br><br> + <a href="mailto:pappy@gentoo.org" class="altlink"><b>Alexander Gabert</b></a> +<br><i>Contributor</i><br><br> + <a href="mailto:zhen@gentoo.org" class="altlink"><b>John Davis</b></a> +<br><i>Editor</i><br><br> + <a href="mailto:klasikahl@gentoo.org" class="altlink"><b>Zack Gilburd</b></a> +<br><i>Editor</i><br></p></td></tr> +<tr lang="en"><td align="center" class="topsep"> +<p class="alttext"><b>Donate</b> to support our development efforts. + </p> +<form action="https://www.paypal.com/cgi-bin/webscr" method="post"> +<input type="hidden" name="cmd" value="_xclick"><input type="hidden" name="business" value="paypal@gentoo.org"><input type="hidden" name="item_name" value="Gentoo Linux Support"><input type="hidden" name="item_number" value="1000"><input type="hidden" name="image_url" value="http://www.gentoo.org/images/paypal.png"><input type="hidden" name="no_shipping" value="1"><input type="hidden" name="return" value="http://www.gentoo.org"><input type="hidden" name="cancel_return" value="http://www.gentoo.org"><input type="image" src="http://images.paypal.com/images/x-click-but21.gif" name="submit" alt="Donate to Gentoo"> +</form> +</td></tr> +<tr lang="en"><td align="center"><iframe src="http://sidebar.gentoo.org" scrolling="no" width="125" height="850" frameborder="0" style="border:0px padding:0x" marginwidth="0" marginheight="0"><p>Your browser does not support iframes.</p></iframe></td></tr> +</table></td> +</tr></table></td></tr> +<tr><td colspan="2" align="right" class="infohead"> +Copyright 2001-2010 Gentoo Foundation, Inc. Questions, Comments? <a class="highlight" href="http://www.gentoo.org/main/en/contact.xml">Contact us</a>. +</td></tr> +</table></body> +</html> |