> 2. UNIX syslog as a de facto standard logging protocol
>
> Syslog as an API provides minimal structure for an error
or notification
> message: a user of the API calls openlog() to set an
enumerated "facil-
> ity" identification number and an "options" flag
indicating some proper-
> ties of the UNIX domain socket connection to the local log
server pro-
> cess, syslogd -- including direct write to console if
syslogd is una-
> vailable. The syslog message is formed by the syslog()
library routine
> as a text string formed with sprintf(3S) with an added
"%m" format
> available for insertion of the message associated with the
current
> "errno" error number variable. The facility ID value
(upper bits) and
> an enumerated priority value (lower bits) are IOR'd to
form a 16 bit
> word value which is placed at the head of the message
within angle
> brackets, followed by the string output of ctime() as a
timestamp. The
> message text is concatenated to this header, and the
resulting text mes-
> sage is sent to the local "syslogd" log server process
using send(3N).
> This message may also be written to the user's standard
error file out-
> put, and/or the system console, independent of the syslogd
process.
IMO, you might want to avoid describing implementation
details like the fact
that UNIX domain sockets are used for the communication,
that the log
handler is called syslogd, how the message is formed by the
syslog()
library routine (as opposed to what that format is), how the
bits or OR'd
together, etc. It's certainly possible to build a syslog
implementation
without doing any of these.
Also, don't forget to mention the POSIX.2 "logger" utility
for logging
from shell scripts.
> Syslog as a network message transport is an extension of
local file log-
> ging by syslogd, through its configuration file,
syslogd.conf (see
> Appendix) which is a semicolon-separated list of priority
specifications
> consisting of a selector followed by an action. A
selector is a list of
> the form "facility.level [ ; facility.level ]", where
facility is a sys-
> tem facility name (as used in openlog(3)) or
comma-separated list of
> facilities, and level is a name of one of the enumerated
values (used as
> first argument to syslog(3)) indicating the severity of
the condition
> being logged. The action is a list of one or more
filenames, usernames,
> or remote host names (identified by prefix "@"). If the
action includes
> a remote host name, the message is forwarded to the named
host via UDP,
> to port 514 (as assigned by IANA, and configurable). The
syslogd pro-
> cess (if any) at that host will receive the message and
dispose of it
> according to its syslogd.conf configuration, possibly
including
> forwarding.
Again, documenting what syslog can do is important, but I
question
documenting the format of the syslog.conf file in the BCP
text itself.
The appendix might be a better place.
> Syslog within a UNIX system has relatively few security
problems, if
> configured and managed properly, using appropriate file
permission
> settings.
Might not want to use the U word here (and generally use it
less). Firstly
because syslog implementations run on NT and other non *nix
systems, and
secondly because syslog implementations run on many *nix
systems that are
not UNIX(TM) (such as Linux).
> Other syslogd vulnerabilities are even more serious. The
most important
> is really a coding error: some early implementations of
syslogd used a
> relatively short buffer on the stack, and did not check
for buffer over-
> flow. This made it possible to kill a syslogd process
with packets to
> udp/514 that were simply larger than this buffer. Since
UDP transport
> is unreliable, log clients would have no indication that
the destination
> log host was no longer available, and access probing could
again proceed
> unobserved.
>
> Still worse, some implementations on some processors made
it possible to
> use this stack overflow to capture the executing syslogd
process, run-
> ning with root privileges, and execute code such as shell
scripts with
> no restrictions.
Again, too implementation specific, IMO. Just say that
coding errors in some
older implementations may lead to additional denial of
service or elevated
priveleges vulnerabilities.
> Finally, if an attack is indeed successful and the
attacker has root
> privileges, the log files themselves are accessible,
allowing the
> attacker to modify them to conceal records of the attack
and any follow-
> ing entries, because each line of a log file is an
independent event
> record and can be deleted without affecting other event
records.
Instead of saying "root" priveleges, how about "necessary"
priveleges.
Syslog runs on systems without the "root" concept or where
the concept is
there but the account has a different name.
> Examine syslog() and syslogd source code and recode as
necessary if
> possible to remove known vulnerabilities.
Probably more appropriate to direct people to pick up
previously fixed
code from their vendor or from from *BSD. The few people
who would
actually examine the code and fix it aren't going to wait
for this
document to tell them to do it, and others will just be
turned off by how
much work it must be to implement syslog properly.
> Syslogd code can be altered for improved filtering and
handling of
> application-specific messages. This has been widespread
in the UNIX
> and Open Source community, with modified versions of
syslog() and
> syslogd sometimes distributed with other applications --
e.g. INN.
Again, this is too implementationsish and too
source-code-jock-ish. Just
mention that there are "extended" implementations such as
the one that's
part of INN.
> 6. Cryptographic security enhancement 1: Authentication
field within
> 7. Cryptographic security enhancement 2: Chained
authentication
> 8. Other security enhancements 3..n:
If you extend the protocol, you'd better provide a reference
implementation that can take advantage of it or the
extension will never
get used. Instead of taking this opportunity to "extend"
syslog yourself,
how about just listing the existing extended syslogs?
Reasons to do this rather than making new extensions
include:
o Not creating even more incompatible extended syslog
implementations.
o Not killing the prospects for a "real" syslog
replacement.
o Doing less work.
--
Chris Calabrese
Internet Infrastructure and Security
Merck-Medco Managed Care, L.L.C.
[EMAIL PROTECTED]
.
