Having Fun With "dmesg"

Problem description:

On standard Linux systems, e.g. Ubuntu Trusty, normal users are allowed to call dmesg to read the kernel logging ring buffer. From security point of view, the reader might gain some interesting data from there.

This is only a quick and dirty write-up of my thoughts after finding this "feature" previously hidden from my plain sight. It will definitely be incomplete since it was just a byproduct working on another issue.

Methods

Get some info about the kernel memory layout:

This was produced calling the vm86 syscall:

$ ./Virtual86RandomCode < /dev/urandom > x Segmentation fault $ dmesg -c [33711.248897] bounds: 0000 [#1] SMP [33711.249134] Modules linked in: vboxsf xt_multiport xt_hashlimit xt_tcpudp xt_NFLOG nfnetlink_log nfnetlink nf_log_ipv4 nf_log_common xt_LOG xt_conntrack iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_filter ip_tables x_tables ppdev vboxguest vboxvideo serio_raw drm i2c_piix4 parport_pc parport 8250_fintek mac_hid mptspi psmouse mptscsih mptbase scsi_transport_spi pata_acpi [33711.251711] CPU: 0 PID: 1455 Comm: Virtual86Random Not tainted 3.19.0-7-generic #7-Ubuntu [33711.252178] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [33711.252327] task: ddaa3720 ti: df948000 task.ti: df948000 [33711.252327] EIP: 1000:[<00000015>] EFLAGS: 00030246 CPU: 0 [33711.252327] EIP is at 0x15 [33711.252327] EAX: 000000b2 EBX: 0000d301 ECX: 00000000 EDX: 00000000 [33711.252327] ESI: 00000000 EDI: 00003020 EBP: 00000400 ESP: 00000400 [33711.252327] DS: 0000 ES: 0000 FS: 0000 GS: 0000 SS: 1000 [33711.252327] EIP: [<00000015>] 0x15 SS:ESP 1000:00000400 [33711.255841] ---[ end trace 138aeb251da50f1d ]---

Bypass ASLR:

When a daemon forks and one child crashes, e.g. Apache, memory layout can be read using dmesg. This sample was produced using a forking test server:

First crash of child after fresh start:

[42285.639737] DamagedHelloSer[3184]: segfault at 6 ip 00007f8502fafa03 sp 00007fffb75df2e0 error 4 in libc-2.19.so[7f8502f64000+1bb000]

Restart of parent, crash of new child:

[42319.196530] DamagedHelloSer[3190]: segfault at 6 ip 00007ff170606a03 sp 00007fff79c26e70 error 4 in libc-2.19.so[7ff1705bb000+1bb000]

Crashing another forked child, addresses are the same like before:

[42354.131069] DamagedHelloSer[3194]: segfault at 6 ip 00007ff170606a03 sp 00007fff79c26e70 error 4 in libc-2.19.so[7ff1705bb000+1bb000]

See what is going on outside a chroot jail:

When jailed in chroot, access to /proc might not be possible, the syslog(SYSLOG_ACTION_READ_ALL, "... syscall will help.

Use iptables LOG target information:

When iptables LOG target is used, which is quite useful e.g. to let firewall log messages make it directly to (remote) syslog, a user on the machine may learn about connections, used ports of other processes. This would be essentially the same as using netstat, except for:

Learn about dropped packets: Netstat will not show those as no connection was established. Learn about dropped broadcasts or blocked connections
Learn about the MAC addresses/IPs of devices on same link, infer vendor or perhaps software running on them from that data.
UDP packets: If such packets makes it to the log, also source port, destination port, ID is logged. Not much more needed to fake a DNS response, ...
Sequence number logging: Documentation states that --log-tcp-sequence is insecure when log could be read by user. As it should read is ALWAYS insecure because logs can be retrieved by any user on the machine, misuse of this feature is quite likely.

More to come?

Thinking on it ...

Results, Discussion

Restrict access via kernel parameter:

Marek Kroemeke pointed out, that there is a kernel parameter to restrict access, which seems to be disabled on e.g. Ubuntu Vivid. See also https://lwn.net/Articles/414813/

echo 1 > /proc/sys/kernel/dmesg_restrict

The parameter's effect is similar to the effects of the grsecurity kernel patch (GRKERNSEC_DMESG). While it is arguable that reading kernel messages messages during debugging, I can see no use not restricting access in default configuration.

Introduction