Contents of /xml/htdocs/proj/en/hardened/etdyn.xml

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.4 - (hide annotations) (download) (as text)
Wed May 4 21:44:59 2011 UTC (7 years, 2 months ago) by klondike
Branch: MAIN
Changes since 1.3: +26 -20 lines
File MIME type: application/xml
Solving QA issues

1 solar 1.1 <?xml version='1.0' encoding="utf-8"?>
2 solar 1.2 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
3 solar 1.1 <guide link="/proj/en/hardened/etdyn.xml">
4 klondike 1.4 <title>ETDYN guide</title>
5 solar 1.1 <author title="Author">
6     <mail link="pageexec@freemail.hu">The PaX Team</mail>
7     </author>
8     <author title="Contributor">
9     <mail link="solar@gentoo.org">solar</mail>
10     </author>
11     <author title="Contributor">
12     <mail link="pappy@gentoo.org">Alexander Gabert</mail>
13     </author>
14     <author title="Editor">
15     <mail link="zhen@gentoo.org">John Davis</mail>
16     </author>
17     <author title="Editor">
18     <mail link="klasikahl@gentoo.org">Zack Gilburd</mail>
19     </author>
20     <abstract>
21     This guide contains documentation and examples on how to create dynamic ELF executables.
22     These guidelines are required to achieve full Address Space Layout Randomization.
23     </abstract>
25     <version>1.1</version>
26 klondike 1.4 <date>2003-08-05</date>
27 solar 1.1
28     <chapter>
29     <title>Introduction</title>
30 klondike 1.4 <section>
31 solar 1.1 <body>
32     <p>One of the features of PaX is Address Space Layout Randomization (ASLR)
33     that allows the kernel to randomize the addresses of various areas in
34     the task's address space. While most of ASLR requires no changes in
35     userland, randomizing the main executable's base address presents a
36     challenge as traditionally such ELF executables of the ET_EXEC kind
37     do not contain enough relocation information. Nevertheless, PaX provides
38     two ways to solve this problem: RANDEXEC and RANDMMAP. </p>
40     <p>RANDEXEC works by mapping the ET_EXEC ELF file in a special way in memory
41     and requires no changes in userland (except for actually enabling it on
42     a given file, as this feature is disabled by default). The drawback of
43     this approach is that it is slow (the kernel compilation benchmark sees
44     a 3 times slow down for example) and prone to false positive detections
45     of so-called return-to-libc style attacks (which renders it unusable on
46     such executables). </p>
48     <warn>Therefore this method mainly exists to prove a point
49     and is not intended for production use.</warn>
51     <p>RANDMMAP on the other hand works on ELF files of the ET_DYN kind which is
52     normally used for dynamically linkable libraries. This approach has none
53     of the drawbacks that plague RANDEXEC because such ET_DYN ELF files have
54     enough relocation information and the dynamic linker has no problem with
55     relocating them (and there is no performance penalty at runtime), nor is
56     there a chance for false positive attack detections as none is done in the
57     first place. This means that protecting against the return-to-libc style
58     attack (in case the information about the randomization can leak to the
59     attacker) requires other approaches, which is not discussed here.</p>
61     <p>It should be clear by now that the preferable way of randomizing the main
62     executable's base address is via RANDMMAP and not RANDEXEC. This in turn
63     means that we need a way to produce ET_DYN ELF executables instead of the
64     ET_EXEC kind. The following parts describe the process in detail and
65     hopefully provide enough information so that modifying existing packages
66     to produce ET_DYN ELF targets will not be a problem. Software authors
67     and/or package maintainers are encouraged to provide such make targets
68     themselves in the future.</p>
70     </body>
71 klondike 1.4 </section>
72 solar 1.1 </chapter>
74     <chapter>
75     <title>How to produce ET_DYN ELF executables</title>
76 klondike 1.4 <section>
77 solar 1.1 <body>
79     <p>The following discussion assumes that the GNU toolchain (such as gcc and
80     ld) is used to produce the target file, other languages and tools should
81     follow the same principles however. The process has two main steps, first
82     compilation then linking, both of which need to be modified for producing
83     an ET_DYN ELF executable.</p>
85     <p>Compilation has to be modified in order to produce position independent
86     code (PIC) which in turn allows the linker to not emit so-called text
87     relocations in the final ET_DYN ELF file. Although this step is not
88     strictly required (it does not affect the relocatability of the result),
89     it is useful as this allows for another security related hardening: PaX
90     normally makes it impossible to make an executable file mapping writable,
91     however for text relocations it has to make an exception. If there are
92     no such ET_DYN ELF files on a system, this exception can be removed and
93     then the only way to introduce new executable code into a task's address
94     space will be via file creation and mapping (which can be prevented by
95     other methods such as ACL systems). Producing PIC is very easy, one just
96     has to add the -fPIC switch to the compiler command line. This will not
97     get rid of all text relocations however as there are other sources of
98     (position dependent) code contributing to the final ET_DYN ELF file that
99     will lead us to the next step.</p>
101     <p>Linking the main executable is governed by a special script called the
102     'specs' file ('gcc -v' tells us what is used by default). Studying it in
103     detail is beyond our scope, but let's note the fact that there are more
104     object files linked into the result than one has specified on the linker
105     command line. These extra objects are necessary for implementing such
106     features as calling constructors/destructors or the low-level entry point
107     of the code (the main() C function is not the actual entry point of an ELF
108     executable). </p>
110     <p>Linking an ET_DYN ELF file is initiated by specifying the -shared switch
111     on the gcc command line which in turn will affect what extra object files
112     go into the result. Since our actual goal is to produce the main executable
113     (vs. a shared library), we have to make sure that we link in all extra
114     objects normally expected by an ET_EXEC target and not necessarily those
115     specified by the specs file for libraries. Luckily there is only one extra
116     object we have to take care of: crt1.o (we will ignore profiling and not
117     care about gcrt1.o). It is no coincidence that crt1.o is not linked into
118     shared libraries as this object contains (among others) the low-level entry
119     point and startup code that invokes the C library startup code which in
120 klondike 1.4 turn calls main(). </p>
121     <warn>Initiating the building of ET_DYN executables on Gentoo does not require us to put -shared in our CFLAGS or LDFLAGS</warn>
122 solar 1.1
123     <p>Making crt1.o position independent is easy, we just have to make use of the
124     GOT (in keeping with the tradition of the glibc naming convention for the
125     position independent version of the extra object files, we will call it
126     crt1S.o). There is one last issue to take care of: a dynamically linked
127     executable requires a special program header that specifies the dynamic
128     linker to be mapped into memory by the kernel on task creation. As we can
129     see it from the specs file, having the -shared switch on the linker command
130     line will omit the dynamic linker specification and would produce an
131     unusable ET_DYN ELF file. The solution is simple, we follow the approach
132     of glibc which is also an executable ET_DYN ELF file: the dynamic linker
133     is specified in an object file that contains the full path to the dynamic
134     linker in a specific ELF section that ld will recognize and convert into
135     the corresponding program header.</p>
137     <p>The above method is demonstrated on a simple 'hello world' program that
138     is included with this document. The source code of the main executable
139     is in a.c, our PIC crt1 is in crt1S.S (it has to be written in assembly,
140     the code is directly derived from glibc 2.2) and finally interp.c defines
141     the dynamic linker (technically it could be put into crt1S.S as well to
142     reduce the number of extra files to a minimum). The makefile is very
143     simple as well, it compiles each source file into an object file and then
144     links them together. One important thing to note is the order of the
145     object files on the linker command line: crt1S.o must come first (that is,
146     before any object file of the application) and interp.o should follow it
147     directly as this will result in the interpreter program header getting
148     emitted before the PT_LOAD headers (which is the normal program header
149     ordering in ET_EXEC files, although it is not strictly necessary). Since
150     crt1S.o and interp.o are constant (they do not depend on the application
151     code) they can be compiled once and put into the same directory where
152     the other systemwide crt* files are.</p>
153     </body>
154 klondike 1.4 </section>
155 solar 1.1 </chapter>
157     <chapter>
158     <title>ET_DYN ELF executables (The Gentoo Way)</title>
159 klondike 1.4 <section>
160 solar 1.1 <body>
162 klondike 1.4 <p>On Gentoo this is accomplished by merging <c>hardened-gcc</c>: </p>
163 solar 1.1
164     <pre caption = "Emerging hardened-gcc">
165 klondike 1.4 # <i>emerge hardened-gcc</i>
166 solar 1.1 </pre>
168 klondike 1.4 <p><c>hardened-gcc</c> is an umbrella package for non-mainstream gcc modifications
169     The <c>hardened-gcc</c> packages was initially created by Alexander Gabert
170 solar 1.1 for this special purpose we are serving here: rolling out the etdyn
171     specs file and interp.o together with the position independent
172     crt1S.o. But this package is not limited to that purpose.
173     It was designed to be the be used for any future changes to gentoo-hardened systems
174     regarding the improvement of gcc compiling binaries that are more secure
175     than the default product coming out when the vanilla gcc is used. And it can be used for ebuild packages to
176     "trigger" some alternative action once they "realize" that they are
177     getting built on a system equipped with a modified gcc for enforcing
178     gentoo hardened protection measures. Straight this means that when a
179     package is found to be breaking when used with the hardened-gcc changes,
180     the particular ebuild of that failing package can and will be modified
181     by our gentoo-hardened developers to put some "check" logic into it when
182     the hardened-gcc is found on the target system. </p>
184     <p>As an example lets try the rebuilding our chpax binary as an ET_DYN
185     shared executable. We can use the file(1) command to determine if we
186     in fact we are building our executables as ET_EXEC or ET_DYN.</p>
188     <p>The first example here we have chpax built as an ET_DYN and the second
189     one is chpax built as an ET_EXEC.</p>
191     <pre caption = "Example files">
192 klondike 1.4 # <i>file /sbin/chpax</i>
193 solar 1.1 /sbin/chpax: ELF 32-bit LSB shared object, Intel 80386, version 1 \
194     (GNU/Linux), stripped
195     /sbin/chpax: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for \
196     GNU/Linux 2.0.0, dynamically linked (uses shared libs), stripped
197     </pre>
199 klondike 1.4 <!--To keep the bugs down for us we really dont want the
200     end user mucking with the specs -solar -->
201 solar 1.1
202 klondike 1.4 <!-- We can further simplify the building of ET_DYN executables by modifying
203 solar 1.1 a few sections of the default gcc specs file as demonstrated in the
204     specs.2.95.3 and specs.3.2.3 files (for the respective gcc versions).
205     To use the new specs file we can either replace the default one or pass
206     it on the gcc command line via the -specs switch (in the latter case we
207     could further trim down the new specs file and keep only the sections
208     that we changed: *cpp, *cc1, *endfile, *link and *startfile). From now
209     on invoking gcc as 'gcc -et_dyn' will produce an ET_DYN executable (the
210 klondike 1.4 same goes for g++).
211 solar 1.1
212 klondike 1.4 Readers interested in rebuilding entire distributions are encouraged to
213 solar 1.1 take a look at the Adamantix (http://www.adamantix.org) and Hardened
214 klondike 1.4 Gentoo projects (http://www.gentoo.org/proj/en/hardened/).
215     -->
216     </body>
217     </section>
218     </chapter>
221 solar 1.1 <chapter>
222     <title>Credits</title>
223     <section>
224     <title>Works Cited</title>
225     <body>
226 solar 1.3 <ul><li><uri link="http://pax.grsecurity.net">PaX Homepage</uri></li></ul>
227     <ul><li><uri link="http://pax.grsecurity.net/docs/index.html">PaX Documentation</uri></li></ul>
228 solar 1.1 <ul><li>Collective Work. PaX - Gentoo Wiki.</li></ul>
229     </body>
230     </section>
231     </chapter>
233     </guide>

  ViewVC Help
Powered by ViewVC 1.1.20