#488212 Potential denial-of-service (DOS) attack by anyone with syslog access (e.g. logger(1))

Package:
logcheck
Source:
logcheck
Submitter:
"Trent W. Buck"
Date:
2023-03-13 12:45:06 UTC
Severity:
normal
Tags:
#488212#5
Date:
2008-06-27 05:37:39 UTC
From:
To:
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).
#488212#10
Date:
2008-06-27 06:55:39 UTC
From:
To:
tags 488212 wontfix confirmed
thanks

Sure thing, but I don't see how logcheck could guard against this.
If you are letting people write to your log, you're asking for it.
They might also just drown legitimate entries with junk (cat
/dev/urandom...).

So you should lock down the logger.

I also advise people never to rely on logcheck. It's convenient, but
it's not reliable *at all*.
#488212#17
Date:
2010-10-26 07:08:17 UTC
From:
To:
Hit related issue, with USB device errors causing extremely large syslog and kern.log files. Results in logcheck consuming excessive CPU.

Whilst there are many easy work arounds and perhaps this should be fixed with the kernel logging or in syslogd, but occurred to me logcheck should have a maximum file size limit at which it refuses to process the log.
#488212#22
Date:
2010-10-26 07:43:23 UTC
From:
To:
also sprach Simon Waters <simon@technocool.net> [2010.10.26.0908 +0200]:

Patches welcome. Note that if someone chooses to spam your syslog
with logger, you have a completely different set of problems than
logcheck though.
#488212#27
Date:
2023-03-13 12:40:49 UTC
From:
To:
The idea below looks like a good safety net, easy to implement, and would
seem to mitigate this bug as much as is reasonable (the only question is
how big a cutoff to use)

to look at post bookworm!
process the log.