what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

klogd-linux.txt

klogd-linux.txt
Posted Sep 19, 2000
Authored by Jouko Pynnonen | Site klikki.fi

Kernel logging daemon klogd in the sysklogd package for Linux contains a "format bug" making it vulnerable to local root compromise (successfully tested on Linux/x86). There's also a possibility for remote vulnerability under certain (rather unprobable) circumstances and a more probable semi-remote exploitableness with knfsd.

tags | exploit, remote, x86, kernel, local, root
systems | linux
SHA-256 | 2ecbd0ed65cc65018f64e392edb56708bf8a2ff389e963f1c9c260946bd00f25

klogd-linux.txt

Change Mirror Download
OVERVIEW

Kernel logging daemon klogd in the sysklogd package for Linux contains a
"format bug" making it vulnerable to local root compromise (successfully
tested on Linux/x86). There's also a possibility for remote vulnerability
under certain (rather unprobable) circumstances and a more probable
semi-remote exploitableness with knfsd.



BUG DETAILS

Normally klogd reads kernel messages from /proc/kmsg and after some
processing passes them to syslogd, which in turn writes the messages to
log file(s) as defined in syslog.conf.

The erroneous function calls are located in function LogLine(), klogd.c
lines 680 and 707:

Syslog( LOG_INFO, line_buff );

Each newline-postfixed kernel message goes to Syslog() as a format
string. Before passing the string to Syslog(), the LogLine() function
does some simple processing. Kernel addresses of form [<address>] are
translated to symbol names and '%' chars are checked and duplicated to
avoid format problems. The logics however fail to handle %-symbols
inside a [<foo>] symbol marker, so a malicious user can forge a kernel
message like "[<%s %s %s %s>]" which would be enough to kill klogd with
a segmentation fault. Possibilities of executing arbitrary code are
discussed below.




EXPLOITATION POSSIBILITIES

The vulnerability is exploitable for anyone who can feed strings in the=20
kernel log. There are many ways to do this locally; for example a=20
connect() call with an improperly initialized sockaddr structure
generates a warning to the kernel log containing the program name.
However the program name is taken from task_struct->comm which is a
16-byte buffer. The required "[<" takes 2 bytes so the space gets short
for a conventional shellcode and return address. The warning is printed
only once so exploiting with just this message is probably difficult, but
other warnings in the kernel make it possible.

Other possibilities include special kernel modules that call printk() to
log their things to kernel log, or various device drivers. The driver for
/dev/mixer for instance can be trivially made log a string containing a
31-byte user defineable substring if /dev/mixer is openable (as it is per
default in many systems).

The exploitation process itself isn't so trivial. The buffer in question
is declared static so it's mapped to a low memory address; there's
nothing user-defineable or otherwise usable in stack. I haven't been able
to produce a program doing a standard "%n" exploitation, but it is
possible to create a buffer overflow condition elsewhere in the program
in conjunction with the format bug. If the format string contains
something like "%2000d", a local buffer in vsyslog() overflows. This
function is called from Syslog() and does no bound checking but trusts
Syslog() checks. In addition, "%m" in the format string expands to the
error message (from strerror()) which can be used to "push" the end of
the string further in the memory, making it possible to build a longer
shellcode using multiple klogd messages if needed.

According to my quick test with a knfsd-enabled system, the driver can be
tricked to printk() path names with some race conditioning, which is
probably one of the easiest exploit methods where available.



VENDOR PATCHES

Linux distribution vendors have been informed about the problem via
vendor-sec@lst.de a week ago; patches and advisories will be out today.



CREDITS AND ACKNOWLEDGEMENTS

Vulnerability discovered by:
Jouko Pynn=F6nen

Greets and thanks to:
Esa Etel=E4vuori, vendor-sec team, cc-opers@IRCNet





--
Jouko Pynn=F6nen Online Solutions Ltd Secure your Linux -
jouko@solutions.fi http://www.secmod.com

Login or Register to add favorites

File Archive:

July 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jul 1st
    27 Files
  • 2
    Jul 2nd
    10 Files
  • 3
    Jul 3rd
    35 Files
  • 4
    Jul 4th
    27 Files
  • 5
    Jul 5th
    18 Files
  • 6
    Jul 6th
    0 Files
  • 7
    Jul 7th
    0 Files
  • 8
    Jul 8th
    28 Files
  • 9
    Jul 9th
    44 Files
  • 10
    Jul 10th
    24 Files
  • 11
    Jul 11th
    25 Files
  • 12
    Jul 12th
    11 Files
  • 13
    Jul 13th
    0 Files
  • 14
    Jul 14th
    0 Files
  • 15
    Jul 15th
    28 Files
  • 16
    Jul 16th
    6 Files
  • 17
    Jul 17th
    34 Files
  • 18
    Jul 18th
    6 Files
  • 19
    Jul 19th
    0 Files
  • 20
    Jul 20th
    0 Files
  • 21
    Jul 21st
    0 Files
  • 22
    Jul 22nd
    0 Files
  • 23
    Jul 23rd
    0 Files
  • 24
    Jul 24th
    0 Files
  • 25
    Jul 25th
    0 Files
  • 26
    Jul 26th
    0 Files
  • 27
    Jul 27th
    0 Files
  • 28
    Jul 28th
    0 Files
  • 29
    Jul 29th
    0 Files
  • 30
    Jul 30th
    0 Files
  • 31
    Jul 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close