aboutsummaryrefslogtreecommitdiffstats
path: root/documentation/README.md
blob: a4e885329218ba37b89abb843f0e9092577a0707 (plain) (blame)
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
STLDoctor
=========

STLDoctor is a plain-text protocol service, that allows users to upload STL files
and generate reports that include information on the files..

- model name
- binary header
- file type (bin vs ascii)
- file size
- triangle count
- bounding box size and position

Uploaded models and generated reports are stored in a directory structure.

Unregistered users have their files saved in a collective directory, which
allows users to query for public models via model name. Registered users have
their uploads saved to a private directory. This (theoretically) prevents other
users from accessing their files.

The service is hosted with socat, one process per client.

A cron job is used to periodically clean up models by using their *last modified* date.


RCE Countermeasures
===================

It is good practice to take preventitive measures against unintentional RCE,
which can be used to cause havoc on vulnboxes and make services go mumble.

1. Enable additional security features via flags during compilation:

	`CFLAGS = "-fPIE -fstack-protector-strong -D_FORTIFY_SOURCE=2"`

	- `-fPIE`: enable position independent executable section
	- `-fstack-protector-strong`: enable stack canaries in functions with local variables that are prone to overflow
	- `-D_FORTIFY_SOURCE=2`: gcc buffer overflow detection

	`LDFLAGS = "-Wl,-z,now -Wl,-z,relro"`

	- `-Wl,-z,now`: tell dynamic linker to resolve symbols ASAP instead of lazy loading
	- `-Wl,-z,relro`: tell dynamic linker to make `got` section read-only after resolving symbols

2. Chroot each service instance via socat so it can only access
	uploaded files and not corrupt the system.

3. Prevent the service binary from creating child processes.


Checker
=======

The checker checks the following behavior:

- File upload and query (for both bin and ascii):
	- Open a session
	- Upload a file of random, valid contents with random model name
	- Ensure file is listed in query
	- Open a new session
	- Ensure file is listed in query
	- Ensure file is not listed in query for different model name
- Registering and private files (for both bin and ascii):
	- Open a session
	- Register with a random password
	- Upload a file of random, valid contents with random model name
	- Open a new session
	- Ensure file is not listed in query
	- Register with previous password
	- Ensure file is listed in query

The checker does the following to submit the first flagstore's flag:

- Open a session
- Use `submit` to upload a file of random, valid contents with a
	the flag as the model name

The checker does the following to submit the second flagstore's flag:

- Open a session
- Use `submit` to upload a file of the encoded, binary STL flag with
	a random model name chosen from a wordlist with numbers for
	collision resistance

The checker should not be easily identifiable, since this could allow
players to only enable certain service functions when the checker is
detected.

Notes on evading detection of the checker through traffic analysis:

- File upload contents are randomly generated valid STLs and the model name is
	picked randomly from a wordlist to blend in with regular requests
- The username used for premium user registration is chosen at random from
	a wordlist (with numbers appended for collision resistance) to blend
	in with other requests
- The STL file which belongs to the second flagstore is not easily identifiable
	since the binary file format is used and viewing the file contents does not
	help identify the 3d model encoded
- The first flagstore's flag IS easily identifiable, since it is sent in cleartext
	to the service, however, the checker makes sure to test upload and querying
	functionality of files with other model names in another session as well


Vuln 1: Value Collision
=======================

Discovery
---------

This vulnerability can be found by reading the source code.

The internal utility function `void freadstr(FILE *f, char **dst)` reads a
null-terminated string from the given file, allocates space for it and saves the
pointer to its contents in `dst`.

```C
void
freadstr(FILE *f, char **dst)
{
	size_t start, len;
	char c;

	start = ftell(f);
	for (len = 0; (c = fgetc(f)) != EOF && c; len++);
	fseek(f, start, SEEK_SET);

	*dst = checkp(calloc(1, len + 1));
	fread(*dst, len, 1, f);
	fgetc(f);
}

```

To determine whether the end-of-file was reached, the return value of `int
fgetc(FILE *f)` is compared to the constant `EOF`, which has a value of `-1`.
The problem lies in the fact, that this comparison is done following a demotion
of the return value to `char` through the assignment and a subsequent promotion
to `int`, which results in an arithmetic extension. As a result, reading the
value char `0xff` would promote it to `0xffffffff` with a value of `-1`,
preventing the function from reading the complete string.

This allows an attacker to cleverly truncate a string before it has ended to
manipulate the content of strings which follow it. In this case, the model name
is saved before the model hash in the information file. By adding a `0xff` to
the end of our uploaded model's name, the model hash is read as an empty string
following a `query` of the file's contents. Since any following `query` will use
the previously loaded models hash to find the file via prefix match, any files
uploaded by unregistered users may be accessed by a user.

The flag is saved in the model name.


Exploiting
----------

1. Open a session
2. Use `submit` to upload an STL file and specify a model name ending in `0xff`
3. Open a new session
4. Use `query` with the same model name from **step 1** to retrieve to load the
	parsed information of the file you just uploaded
5. Use `query` again.. this will now use the cached hash which should be empty,
	allowing you to accesss any of the files uploaded by unregistered users


Patching
--------

For an example fix, see the unified patch `patches/flagstore1.diff`.


Vuln 2: Invalid Format String
=============================

Discovery
---------

This vulnerability can be found by reading the source code.

TODO..

The flag is saved in a binary STL as a 3d model. Each character is constructed
in the XY-Plane via a minimal number of triangles. The positions and triangles
per character do not change, which should help automation. Additionaly, drawing
the triangles into a 2d buffer and running a text-detection over it should be
possible.


Exploiting
----------

TODO..


Patching
--------

For an example fix, see the unified patch `patches/flagstore2.diff`.