klogd-linux.txt

`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  
[email protected] 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 -  
[email protected] http://www.secmod.com  
  
`