-
Notifications
You must be signed in to change notification settings - Fork 1
/
README
166 lines (114 loc) · 6.53 KB
/
README
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
Trinity: Linux system call fuzzer.
"After the initial euphoria of witnessing the explosion had passed, test
director Kenneth Bainbridge commented to Los Alamos director J. Robert
Oppenheimer, "Now we are all sons of bitches." Oppenheimer later stated
that while watching the test he was reminded of a line from the Hindu
scripture the Bhagavad Gita:
Now I am become Death, the destroyer of worlds."
Warning: This program may seriously corrupt your files, including any of those
that may be writable on mounted network file shares. It may create network
packets that may cause disruption on your local network.
Run at your own risk.
System call fuzzers aren't a particularly new idea. As far back as 1991,
people have written apps that bomb syscall inputs with garbage data,
that have had a variety of success in crashing assorted operating systems.
After fixing the obvious dumb bugs however, a majority of the time
these calls will just by rejected by the kernel very near the beginning
of their function entry point as basic parameter validation is performed.
Trinity is a system call fuzzer which employs some techniques to
pass semi-intelligent arguments to the syscalls being called.
The intelligence features include:
- If a system call expects a certain datatype as an argument
(for example a file descriptor) it gets passed one.
This is the reason for the slow initial startup, as it generates a
list of fd's of files it can read from /sys, /proc and /dev
and then supplements this with fd's for various network protocol sockets.
(Information on which protocols succeed/fail is cached on the first run,
greatly increasing the speed of subsequent runs).
- If a system call only accepts certain values as an argument,
(for example a 'flags' field), trinity has a list of all the valid
flags that may be passed.
Just to throw a spanner in the works, occasionally, it will bitflip
one of the flags, just to make things more interesting.
- If a system call only takes a range of values, the random value
passed is ensured to fit within that range.
Trinity logs it's output to a files (1 for each child process), and fsync's
the files before it actually makes the system call. This way, should you trigger
something which panics the kernel, you should be able to find out exactly what
happened by examining the log.
There are several test harnesses provided (test-*.sh), which run trinity in
various modes and takes care of things like cpu affinity, and makes sure it runs from the
tmp directory. (Handy for cleaning up any garbage named files; just rm -rf tmp afterwards)
######### options ###############################################
--quiet/-q: reduce verbosity.
Specify one to not output register values, or twice to also suppress syscall count,
and just reseed values.
--verbose: increase verbosity.
-D: Debug mode.
This is useful for catching core dumps if trinity is segfaulting, as by default
the child processes ignore those signals.
-sN: use N as random seed. (Omitting this uses time of day as a seed).
Note: There are currently a few bugs that mean no two runs are necessary 100%
identical with the same seed. See the TODO for details.
--list/-L: list known syscalls and their offsets
--monochrome/-m: Don't output ANSI control codes
--proto/-P: For network sockets, only use a specific packet family.
--victims/-V: Victim file/dirs. By default, on startup trinity tree-walks /dev, /sys and /proc.
Using this option you can specify a different path.
(Currently limited to just one path)
-p: Pause after making a syscall
--children/-C: Number of child processes (Max: 64)
-x: Exclude a syscall from being called. Useful when there's a known kernel bug
you keep hitting that you want to avoid.
-cN: do syscall N with random inputs.
Good for concentrating on a certain syscall, if for eg, you just added one.
--group/-g vm
Just call VM related syscalls
--logging/-l off: This disables logging. Useful if you have a serial console, though you
will likely lose any information about what system call was being called,
what maps got set up etc. Does make things go considerably faster however,
as it no longer fsync()'s after every syscall
--ioctls/-I will dump all available ioctls.
#######################################################################
Examples:
./trinity -c splice
Stress test the splice syscall
./trinity -x splice
Call every syscall except for splice.
./trinity -qq -l off -C16
Turn off logging, and suppress most output to run as fast as possible. Use 16 child processes
#######################################################################
WARNINGS:
* Trinity may generate the right selection of syscalls to start sending random network
packets to other hosts. While every effort is made to restrict this to IP addresses
on local lans, multicast & broadcast, care should be taken to not allow the
packets it generates to go out onto the internet.
#######################################################################
Development discussion of trinity occurs at trinity@vger.kernel.org
As with all vger mailing lists, subscribe by sending 'subscribe trinity'
in the body of a mail to majordomo@vger.kernel.org
Reporting bugs upstream:
If you find a kernel bug using trinity, first check the list at
http://www.codemonkey.org.uk/projects/trinity/bugs-found.php
You may find that the bug is either already fixed (in which case
a git commit hash should point to the fix), or there will be a link
to an existing upstream report on the bug.
If you find something new, report it to the relevant kernel component maintainer,
CC'd to linux-kernel. CC'ing trinity@ will also be appreciated, so it
can be recorded in the 'known bugs' section
######### Links to similar projects ####################################
= tsys - 1991.
http://groups.google.com/groups?q=syscall+crashme&hl=en&lr=&ie=UTF-8&selm=1991Sep20.232550.5013%40smsc.sony.com&rnum=1
= iknowthis
http://iknowthis.googlecode.com
Fuzzer by Tavis Ormandy with very similar goals to this project.
= sysfuzz
basic fuzzer by Ilja van Sprundel
mentioned in http://events.ccc.de/congress/2005/fahrplan/attachments/683-slides_fuzzing.pdf
http://leetupload.com/dbindex2/index.php?dir=Linux/&file=sysfuzz.tar.gz
= xnufuzz
https://github.com/fintler/xnufuzz/tree/
basic fuzzer for XNU. Looks to be based on Ilja's sysfuzz.
= kg_crashme / ak_crashme / dj_crashme
Kurt Garloff wrote a fuzzer similar to Ilja's sysfuzz in 2003.
The ak / dj variants were improvements added by Andi Kleen, and Dave Jones.