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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.1 - (show annotations) (download) (as text)
Tue Sep 30 04:21:19 2003 UTC (14 years, 11 months ago) by solar
Branch: MAIN
File MIME type: application/xml
xml updates, new etdyn.xml, add capabilities.xml to main page and role changes

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

  ViewVC Help
Powered by ViewVC 1.1.20