[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#570740: marked as done (apache: log file injection)



Your message dated Mon, 22 Feb 2010 21:37:40 +0100
with message-id <201002222137.41264.sf@sfritsch.de>
and subject line Re: Bug#570740: apache: log file injection
has caused the Debian Bug report #570740,
regarding apache: log file injection
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
570740: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570740
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: apache2
Severity: normal
Tags: security

Hi, the following issues were dislcosed in 2003 for apache, but they
just got CVE numbers a few days ago. I haven't checked whether the
latest version of apache2 is affected, and if it isn't, please close
this bug. The problem actually seems rather unimportant to me since the
real issue is input sanitization for any vulnerable apache log analyzer.

CVE-2003-1580[0]:
| The Apache HTTP Server 2.0.44, when DNS resolution is enabled for
| client IP addresses, uses a logging format that does not identify
| whether a dotted quad represents an unresolved IP address, which
| allows remote attackers to spoof IP addresses via crafted DNS
| responses containing numerical top-level domains, as demonstrated by a
| forged 123.123.123.123 domain name, related to an "Inverse Lookup Log
| Corruption (ILLC)" issue.

CVE-2003-1581[1]:
| The Apache HTTP Server 2.0.44, when DNS resolution is enabled for
| client IP addresses, allows remote attackers to inject arbitrary text
| into log files via an HTTP request in conjunction with a crafted DNS
| response, as demonstrated by injecting XSS sequences, related to an
| "Inverse Lookup Log Corruption (ILLC)" issue.

If you fix the vulnerabilities please also make sure to include the
CVE ids in your changelog entry.

For further information see:

[0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1580
    http://security-tracker.debian.org/tracker/CVE-2003-1580
[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1581
    http://security-tracker.debian.org/tracker/CVE-2003-1581



--- End Message ---
--- Begin Message ---
Hi Michael,

I don't think there is anything in Apache that should be changed for 
these issues. I will close the bug and mark them as unimportant in the 
security tracker:

On Sunday 21 February 2010, Michael Gilbert wrote:
> CVE-2003-1580[0]:
> | The Apache HTTP Server 2.0.44, when DNS resolution is enabled for
> | client IP addresses, uses a logging format that does not identify
> | whether a dotted quad represents an unresolved IP address, which
> | allows remote attackers to spoof IP addresses via crafted DNS
> | responses containing numerical top-level domains, as demonstrated
> | by a forged 123.123.123.123 domain name, related to an "Inverse
> | Lookup Log Corruption (ILLC)" issue.

This doesn't seem much different from a PTR record pointing to an 
arbitrary domain name. Both cases can be handled by doing double 
reverse lookups. Apache does this if configured with "HostNameLookups 
double". It should be well known that single reverse lookups are 
unreliable, so I don't see a security issue here.

> CVE-2003-1581[1]:
> | The Apache HTTP Server 2.0.44, when DNS resolution is enabled for
> | client IP addresses, allows remote attackers to inject arbitrary
> | text into log files via an HTTP request in conjunction with a
> | crafted DNS response, as demonstrated by injecting XSS sequences,
> | related to an "Inverse Lookup Log Corruption (ILLC)" issue.

This is purely a log analyzer issue. Apache correctly escapes control 
characters in hostnames. For everything else, the log analyzer is 
responsible.

Cheers,
Stefan


--- End Message ---

Reply to: