1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
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
--
ETDYN guide</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>ETDYN guide</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(). </p>
<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>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" dir="ltr">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-input">emerge hardened-gcc</span>
</pre></td></tr>
</table>
<p><span class="code" dir="ltr">hardened-gcc</span> is an umbrella package for non-mainstream gcc modifications
The <span class="code" dir="ltr">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-input">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="etdyn.xml?style=printable">Print</a></p></td></tr>
<tr><td class="topsep" align="center"><p class="alttext">Page updated August 5, 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:a.gabert@fh-trier.de" class="altlink"><b>Alexander Gabert</b></a>
<br><i>Contributor</i><br><br>
<a href="mailto:john_davis@pauldavisautomation.com" class="altlink"><b>John Davis</b></a>
<br><i>Editor</i><br><br>
Zack Gilburd
<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-2012 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>
|
GitWeb