Bug 81145 - Log message treated as a regexp???
Summary: Log message treated as a regexp???
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: logwatch
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Elliot Lee
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-01-06 04:41 UTC by Aleksey Nogin
Modified: 2007-04-18 16:49 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-07-10 13:43:16 UTC
Embargoed:


Attachments (Terms of Use)
Demonstrates problem in logwatch 'secure' script regexp (801 bytes, text/plain)
2003-03-07 22:02 UTC, Stephen Walton
no flags Details

Description Aleksey Nogin 2003-01-06 04:41:40 UTC
Some time ago I've received the following message from logwatch:

 ################## LogWatch 2.6 Begin ##################### 

Nested quantifiers in regex; marked by <-- HERE in m/sudo:  aleksey : TTY=tty1 ;
PWD=/home/aleksey ; USER=root ; COMMAND=/bin/rpm -e compat-libstdc++ <-- HERE /
at /etc/log.d/scripts/services/secure line 88, <STDIN> line 43.


 ###################### LogWatch End ######################### 

Which means that somehow logwatch managed to interpret the *user* input as a
regexp! Can this be a security issue?

Comment 1 Elliot Lee 2003-02-19 23:04:11 UTC
Can you try the logwatch 4.3.1 in rawhide and see if it has this issue? I can't
see any lines in 4.3.1 in the script mentioned that would fit the description.

Comment 2 Stephen Walton 2003-03-07 22:02:02 UTC
Created attachment 90521 [details]
Demonstrates problem in logwatch 'secure' script regexp

Running this script creates and executes a Perl program called 'bugdemo.pl' in
the current directory.

Comment 3 Stephen Walton 2003-03-07 22:04:37 UTC
My comment to my demo got lost:  the problem arises when a line in
/var/log/secure contains the string ++, as it does for the original poster, and
did for me, when an 'sudo' command is executed to manipulate a C++ library.  My
attachment demonstrates the problem but I'm not enough of a Perl hacker to
figure out a patch.

I don't think this should be marked CLOSED but I can't change the status.

Comment 4 Elliot Lee 2003-07-10 13:43:16 UTC
4.3.2 has this problem fixed, and probably 4.3.1.

Comment 5 Stephen Walton 2003-07-10 17:58:07 UTC
Fair enough, but the original bug was against RH 8.0, and the latest version of
logwatch released for 8.0 seems to be the one on the original release, 2.6-8. 
4.3.1-2 is on my RH9 systems, though.  I did "rpm -U --test" on an RH8.0 system
against the logwatch 4.3.1-2 RPM shipped with RH9 and got no errors;  would it
be safe to install it?




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