[ advisories | exploits | discussions | news | conventions | security tools | texts & papers ]
 main menu
- feedback
- advertising
- privacy
- FightAIDS
- newsletter
- news
 
 discussions
- read forum
- new topic
- search
 

 meetings
- meetings list
- recent additions
- add your info
 
 top 100 sites
- visit top sites
- sign up now
- members
 
 webmasters

- add your url
- add domain
- search box
- link to us

 
 projects
- our projects
- free email
 
 m4d network
- security software
- secureroot
- m4d.com
Home : Advisories : klogd format bug

Title: klogd format bug
Released by: Jouko Pynnönen
Date: 18th September 2000
Printable version: Click here
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 [
] are translated to symbol names and '%' chars are checked and duplicated to avoid format problems. The logics however fail to handle %-symbols inside a [] 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 kernel log. There are many ways to do this locally; for example a 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önen Greets and thanks to: Esa Etelävuori, vendor-sec team, cc-opers@IRCNet






(C) 1999-2000 All rights reserved.