blob: 0ca40392a1f28b27031c5e95c412df03666fbbd1 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
|
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">
<glsa id="200602-03">
<title>Apache: Multiple vulnerabilities</title>
<synopsis>
Apache can be exploited for cross-site scripting attacks and is vulnerable
to a Denial of Service attack.
</synopsis>
<product type="ebuild">Apache</product>
<announced>2006-02-06</announced>
<revised count="03">2007-12-30</revised>
<bug>115324</bug>
<bug>118875</bug>
<access>remote</access>
<affected>
<package name="www-servers/apache" auto="yes" arch="*">
<unaffected range="ge">2.0.55-r1</unaffected>
<unaffected range="rge">2.0.54-r16</unaffected>
<unaffected range="eq">1.3.34-r2</unaffected>
<unaffected range="rge">1.3.34-r11</unaffected>
<unaffected range="rge">1.3.37</unaffected>
<vulnerable range="lt">2.0.55-r1</vulnerable>
</package>
</affected>
<background>
<p>
The Apache HTTP server is one of the most popular web servers on the
Internet. mod_imap provides support for server-side image maps; mod_ssl
provides secure HTTP connections.
</p>
</background>
<description>
<p>
Apache's mod_imap fails to properly sanitize the "Referer" directive of
imagemaps in some cases, leaving the HTTP Referer header unescaped. A
flaw in mod_ssl can lead to a NULL pointer dereference if the site uses
a custom "Error 400" document. These vulnerabilities were reported by
Marc Cox and Hartmut Keil, respectively.
</p>
</description>
<impact type="normal">
<p>
A remote attacker could exploit mod_imap to inject arbitrary HTML or
JavaScript into a user's browser to gather sensitive information.
Attackers could also cause a Denial of Service on hosts using the SSL
module (Apache 2.0.x only).
</p>
</impact>
<workaround>
<p>
There is no known workaround at this time.
</p>
</workaround>
<resolution>
<p>
All Apache users should upgrade to the latest version, depending on
whether they still use the old configuration style
(/etc/apache/conf/*.conf) or the new one (/etc/apache2/httpd.conf).
</p>
<p>
2.0.x users, new style config:
</p>
<code>
# emerge --sync
# emerge --ask --oneshot --verbose ">=www-servers/apache-2.0.55-r1"</code>
<p>
2.0.x users, old style config:
</p>
<code>
# emerge --sync
# emerge --ask --oneshot --verbose "=www-servers/apache-2.0.54-r16"</code>
<p>
1.x users, new style config:
</p>
<code>
# emerge --sync
# emerge --ask --oneshot --verbose "=www-servers/apache-1.3.34-r11"</code>
<p>
1.x users, old style config:
</p>
<code>
# emerge --sync
# emerge --ask --oneshot --verbose "=www-servers/apache-1.3.34-r2"</code>
</resolution>
<references>
<uri link="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3352">CVE-2005-3352</uri>
<uri link="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3357">CVE-2005-3357</uri>
</references>
<metadata tag="requester" timestamp="2006-01-23T08:56:54Z">
koon
</metadata>
<metadata tag="submitter" timestamp="2006-01-27T06:31:39Z">
frilled
</metadata>
<metadata tag="bugReady" timestamp="2006-02-06T06:26:14Z">
jaervosz
</metadata>
</glsa>
|
