README 8.13 KB
Newer Older
Oliver Pinter's avatar
Oliver Pinter committed
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
Paxtest v0.9.13 README file

Copyright (c)2004 by Peter Busser <peter@adamantix.org>

Additional architecture/target support, tests, & fixes
by Brad Spengler <spender@grsecurity.net>

This file has been released under the GNU GPL version 2 or later.


History:
-------
When I started the Adamantix project, one of the first things I did was to add
PaX functionality to the kernel. PaX is a process memory protection patch.
Anything that happens outside the kernel on a UNIX system happens inside a
process. There are many attacks on the Internet that try to corrupt the process
memory, in order to make it do something for which it was not intended. One
example of such an attack is the so called buffer overflow attack. This kind of
attack is one of the most popular at this moment.

PaX protects against such attacks. Or so the author claims. When I started to
add PaX to Adamantix, almost nothing happened. A few libraries broke, but that
was easy to fix, and that was it. I expected many programs to break. So I
started to wonder: ``Does this patch really do anything?'' Instead of
speculating, I decided to write a test suite. After some time, the first
version of paxtest was ready. More functionality was added. With the addition
of every test, it proved that PaX was working just fine. I decided to publish
paxtest, because it can be useful for other people to test the functionality
of the memory protection of their system(s).


Compiling paxtest:
-----------------
Compiling paxtest should be quite straightforward. First unpack paxtest. Then
cd into the directory. And then run one of the following:

make linux		(to create Linux binaries)
make openbsd		(to create OpenBSD binaries)

(Type make to get the above list.)


Running paxtest:
---------------
In order to run paxtest, type the following:

./paxtest kiddie	(to run paxtest in script kiddie mode)

or

./paxtest blackhat	(to run paxtest in blackhat mode)

Loic's avatar
Loic committed
53
This will create a file paxtest.log in the user's home directory.
Oliver Pinter's avatar
Oliver Pinter committed
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


Kiddie and blackhat mode:
------------------------
Paxtest provides two modes. The first mode is the so called kiddie mode, which
makes paxtest behave rather nicely. This simulates the level of sophistication
displayed by script kiddies. Good results in this mode do not necessarily mean
that the security level of your system is high.

The second mode, the blackhat mode, makes paxtest use of a few tricks to try
to get around the protection of the kernel. The attacks done by paxtest in this
mode can be performed in real life by attackers too. But the level of
sophistication is somewhat higher than those of the kiddie mode and the chance
of success is somewhat lower. But there is still a realistic chance of success.

People who are concerned about the security of their systems should look at
the blackhat mode results.


The tests:
---------
There are two types of tests in paxtest. First there are tests which try
different ways to write and then run exploit code. The more different exploits
are stopped, the better the protection provided by the system. Note that the
tests simulate what an exploit could (and would) do, not what an application
does normally. This is especially important in the mprotect tests because
some people claim that normal applicatons do not do this - indeed, but that
is not what these tests are about, they simulate exploits, not applications.

Second, there is a number of tests that measure the randomization of the
system. Randomisation does not provide any security, but only makes it harder
for the attacker to guess where to attack (it is in fact security through
obscurity). It is like rearranging the furniture in a pitch dark room every
time someone enters. The more random the furniture is placed, the more likely
it is that someone stumbles over it. The same applies to randomization in this
context, randomization makes it more likely that an attack does not succeed.
In short: More random bits is better. Zero bits means: No randomization.


Executable anonymous mapping
Executable bss
Executable data
Executable heap
Executable stack

	These tests try to write data to memory and then try to execute it as
	if it was executable code. This is exactly what most buffer exploits
	do. There are five tests, each test tests one specific memory area.

Executable anonymous mapping (mprotect)
Executable bss (mprotect)
Executable data (mprotect)
Executable heap (mprotect)
Executable stack (mprotect)

	These tests do the same as the previous tests. But now the test also
	tries to disable the memory protection in the kernel using mprotect().
	It changes the protection status of memory. An attacker can use it to
	try to switch off memory protection and execute shellcode as usual.

Executable shared library bss (mprotect)
Executable shared library data (mprotect)

	These tests try to overwrite two different data areas in a shared
	library. After that, it tries to execute the data as if it was code.
	Again, these tests try to switch off the memory protection using
	mprotect().

Anonymous mapping randomization test

	Anonymous mappings are used for dynamically allocating memory in a
	program. This test tries to figure out the number of random bits used
	when such an anonymous mapping is requested. More bits is better.

Heap randomization test (ET_EXEC)
Heap randomization test (ET_DYN)

	The heap is used for allocating small chunks of memory in a program.
	There there are two different types of executables, ET_EXEC (normal
	executables) and ET_DYN (basically executable shared libraries). The
	randomization can depend on the kind of executable, therefore there
	are two tests.

	Most Linux distributions ship with ET_EXEC executables only. So for
	those the ET_EXEC randomization is the most relevant. Adamantix ships
	with mostly ET_DYN executables, so the ET_EXEC randomization is not
	very relevant, but the ET_DYN randomization is.

	Normally ET_DYN randomization is bigger than the ET_EXEC randomisation.

Main executable randomization (ET_EXEC)
Main executable randomization (ET_DYN)

	Same here, two tests, because the two different types of executables
	can have different randomization.

Shared library randomization test

	Shared libraries can be located at random addresses too, which is what
	this test tries to find out.

Stack randomization test (SEGMEXEC)
Stack randomization test (PAGEEXEC)

	The stack is used for storing intermediate data. It also contains
	addresses that influence the way programs run. That combination makes
	the stack a popular memory area for attacks. Randomisation makes it
	harder though, which is what these test try to find out.

Return to function (strcpy)
Return to function (strcpy, RANDEXEC)
Return to function (memcpy)
Return to function (memcpy, RANDEXEC)

	Return to function attacks are very nasty. These tests are hard to
	stop by kernel patches, but they show that there you should not expect
	perfect protection from this kind of security patches.

Executable shared library bss
Executable shared library data

	These tests try to overwrite two different data areas in a shared
	library. After that, it tries to execute the data as if it was code.

Writable text segments

	When an attacker can overwrite code, he can basically alter the
	program while it runs. This test tries to do that.


Perfect protection:
------------------
Perfect protection is not possible. That is also the reason why there are
so called return to function tests in paxtest. PaX does not prevent return to
function attacks. Neither do any of the other memory protection patches. But it
is important that people who use kernel patches like PaX do not get a false
sense of security. As the PaX documentation points out: There are three
different classes of attacks, and at this moment PaX can only guarantee
protection against one of them.


Further reading:
---------------
PaX home page:
http://pax.grsecurity.net/

PaX mailing list:
http://lists.adamantix.org/

PaX documentation (also a thorough introduction into memory protection):
http://pax.grsecurity.net/docs/

An article I wrote about PaX has been published in Linux Magazine. The whole
article is available on-line as PDF. It is not very technical, but describes
what memory protection is and why it is important. It can be found here:
http://www.linux-magazine.com/issue/40