Bug 181802

Summary: scripts/services/http lists false positive "exploit" on any URL with "null" in it
Product: [Fedora] Fedora Reporter: Gilbert E. Detillieux <gedetil>
Component: logwatchAssignee: Ivana Varekova <varekova>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: gedetil
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-20 08:47:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch to fix false positive probe matches on "null" none

Description Gilbert E. Detillieux 2006-02-16 18:19:10 UTC
Description of problem:
The logwatch report on the http service incorrectly includes some
valid request URL's (under the 'possible successful probes' heading) if those
log entries have the substring "null" anywhere in the quoted request field.
For example:
 !!!! 1 possible successful probes 
    /horde3/themes/graphics/tree/nullonly.png HTTP Response 200 

Version-Release number of selected component (if applicable):
7.0-2.fc4

How reproducible:
Always

Steps to Reproduce:
1.Produce access_log entries with GET request containing "null" in a valid URL
2.Run: logwatch --service http
3.Note incorrectly flagged "probe" in report.
  
Actual results:
Report includes requests that should be considered valid otherwise.

Expected results:
Such requests should not be included in the report. The match should be made
more explicit, e.g. to match URL's ending in "null" only.


Additional info:
Patch to follow.

Comment 1 Gilbert E. Detillieux 2006-02-16 18:19:11 UTC
Created attachment 124770 [details]
patch to fix false positive probe matches on "null"

Comment 2 Ivana Varekova 2006-02-20 08:47:37 UTC
Thank you for your notice. This problem is fixed in the last version
(logwatch-7.1-8). The result consists of string ^null$ which describes just the
possible exploit.