Jouko Pynnönen found  following.  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.

    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

    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.   Jouko  hasn'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 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


    For Slackware:

    For Linux-Mandrake:


    Just like other distributions,  Trustix Secure Linux also  suffers
    from a security hole in  sysklogd.  Everybody running 1.0x  or 1.1
    should  upgrade.   The  hole  is  already  fixed  in  the new beta
    (1.1.80).  The new package can be found at:

    RedHat  has  put  out  an  update  to  the  klogd package due to a
    security bug found  in klogd.   There are built  packages for this
    update for  Immunix OS  6.2 (StackGuarded  versions of  the RedHat
    packages).  They can be found at:

    For Red Hat:

    For Debian:

    For SuSE Linux:

    For Caldera:

    For Turbo Linux:

    For Conectiva Linux: