[Logcheck-devel] Bug#488212: Potential denial-of-service (DOS) attack by anyone with syslog access (e.g. logger(1))

[Trent W. Buck]

Package: logcheck
Severity: normal

I was rolling out a server in a high-security environment, using
logcheck (monitoring auth.log) as part of the infrastructure for
alerting staff about malicious activity.

I was injecting syslog entries with logger(1), to test my custom
logcheck ignore rules, and it occurred to me that a user could do
this (where "ERROR" matches a pattern in violation.d):

    yes ERROR | logger

which causes logger to spam syslog with messages.  Testing shows that
this adds entries faster than logcheck can scan them, preventing the
logcheck job from ever completing.

An attacker could use this technique to indefinitely delay
notification of their attack (say, a dictionary attack on a
password-protected service).  Admittedly, subsequent jobs will create
error mail along the lines of "couldn't get lock", but this sounds
like a low-priority error.

Currently I'm just advising staff to treat logcheck lockfile mails as
high priority, but I figured I should mention it in case there's some
technique that logcheck could (or does, but I don't know about)
support to mitigate this.

PS: by default syslog and syslog-ng accept log entries from local
users, but they can be configured to accept entries from remote hosts
(making this potentially a remote attack).

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash