Bug 130188 - logwatch http parsing error prevents email from being sent.
logwatch http parsing error prevents email from being sent.
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: logwatch (Show other bugs)
2
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Elliot Lee
:
Depends On: 128841
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-17 16:06 EDT by Dave Strauss
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-23 12:28:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dave Strauss 2004-08-17 16:06:41 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031114

Description of problem:
The pattern strings for matching some of the buffer overflow exploits
are incorrect in the logwatch http service script.  This leads to
logwatch reporting the exploit as an "unidentified 'other' record"
instead of logging it as a probe.  Usually this would not be a problem
(only confusing, as you can see if you do a google search for
"logwatch \x90\x02\xb1\x02\xb1'"), but in some cases it can prevent
the logwatch email from being sent because (a) the "other" records are
dumped into the logwatch output verbatim and (b) cyrus-imapd doesn't
want to accept emails with lines that are too long.

The ultimate fix is to correct the parsing of the exploits; note that
this has been done in logwatch-5.2.

For reference, I'm using cyrus-imapd-2.2.3-11 for reading email and
postfix-2.0.18-4 as the MTA.

Version-Release number of selected component (if applicable):
logwatch-5.1-3

How reproducible:
Always

Steps to Reproduce:
1. requires httpd and logwatch; optionally requires cyrus-imapd
2. wait for some script kiddie to try a buffer-overflow exploit such
as "SEARCH
\x90\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02
... "
3. wait for logwatch log
    

Actual Results:  Sometimes logwatch will just identify the attempted
exploit as an "other" record instead of a probe.  Other times if the
search line is long enough the logwatch email will not get sent.


Expected Results:  logwatch should identify the probe.

Additional info:

Note as I said above this is fixed in logwatch-5.2; I'm just noting it
here in case other people have the same problem with not getting
logwatch emails.  The simplest way to fix the problem is to change
/etc/log.d/scripts/services/http; look for these lines:

   '\\x90\\x02\\xb1\\x02\\xb1',
   '\\x02\\xb1\\x02\\xb1',
   '\\x90\\x90\\x90\\x90',
   '\\x04\\x01',
   '\\x05\\x01',

and change them by adding an extra backslash to each pair, like this:

   '\\\x90\\\x02\\\xb1\\\x02\\\xb1',
   '\\\x02\\\xb1\\\x02\\\xb1',
   '\\\x90\\\x90\\\x90\\\x90',
   '\\\x04\\\x01',
   '\\\x05\\\x01',

Either that or upgrade to logwatch-5.2
Comment 1 Elliot Lee 2004-08-23 12:28:51 EDT
logwatch 5.2.2 is in CVS - I'll make sure to build it sometime soon.

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