Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 10222 - /dev/log permits anyone to forge arbitrary audit records
/dev/log permits anyone to forge arbitrary audit records
Product: Red Hat Linux
Classification: Retired
Component: sysklogd (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
: Security
Depends On:
  Show dependency treegraph
Reported: 2000-03-17 10:35 EST by David A. Wheeler
Modified: 2014-03-16 22:13 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-18 11:36:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David A. Wheeler 2000-03-17 10:35:36 EST
Greetings; I have a Red Hat 6.1 system which uses your sysklogd program
version 1.3.31.  I've found a security issue with sysklog's

It appears that the default configuration on this system
lets anyone write to /dev/log, e.g., ls -l:
srw-rw-rw-   1 root     root            0 Mar  6 10:54 /dev/log

This means that any local user can forge any logged message they'd like.
This can make it impossible for administrators to determine
"what's really going on"; there's no way to know which messages are real
and which are forged.  I can forge a thousand break-ins... which ones
occurred?  Did any?  Did I hide which one happened?  Here's a trivial

logger -p authpriv.none "PAM_pwdb[9999]: (su) session opened for user root
by dwheeler(uid=500)"

logger -p authpriv.none "PAM_pwdb[9999]: (su) session closed for user root"

Obviously, this is not a "break-in" problem, but it is an audit
log integrity problem.

Simple solution: "chmod o= /dev/log".
Comment 1 Nalin Dahyabhai 2000-03-17 13:47:59 EST
Newer versions of logger from util-linux prepend the user's name to the log
entry before sending it to syslogd, but this should really be fixed in syslogd.
Comment 2 Nalin Dahyabhai 2000-03-17 15:03:59 EST
Per private email, logger doesn't have any special privileges, and there's no
way to fix this with the current syslogd while still making the logging facility
available to everyone.  Using a connected Unix-domain socket would let syslogd
identify the UID/GID/PID of the sending process and impose limits that way, but
this was changed to work around a DoS problem that cropped up a while back.
Comment 3 Nalin Dahyabhai 2000-04-05 16:26:59 EDT
Changing the permissions will break many programs, so syslog needs to be able to
distinguish between various users who send it data.
Comment 4 Andrew Bartlett 2000-11-11 03:43:32 EST
Could all users that need to log messages be placed in a special group 'log'
with the respective changes on the /dev/log premissions?

Such a solution would also require stopping access to syslog over the network
(at least from the local computer) to avoid sombody just bypassing the
permissions. (I don't mind network based syslog being fakeable, as long as it
does not contain *my* hostname).

Also it would be nice to make it impossible for a user to write kernel messages,
or at least make sure syslogd gets its kernel input only from klogd, not
Comment 5 Bill Nottingham 2001-01-19 13:08:17 EST
As for the last selection, no. Programs run as arbitrary users still
need to be able to call syslog().
Comment 6 Andrew Bartlett 2001-03-31 07:14:21 EST
This sounds like the job for a small sgid wrapper, which would verify its input
as sane (correct timestamps, program names distinugised by username etc) and
pass it onto the standard syslog.

Is this at all possible?  Or are the implications of yet another set-uid program
not worth the bother?
Comment 7 Alan Cox 2002-12-14 17:09:05 EST
Newer kernels have socket options to get the peer information - so it is now
possible to log this data I think
Comment 8 Josh Bressers 2004-06-18 11:36:53 EDT
Closing; This issue was fixed a while ago.

Note You need to log in before you can comment on or make changes to this bug.