forked from pool/apache2
7a70b52ac1
- Update to 2.4.61
*) SECURITY: CVE-2024-39884: Apache HTTP Server: source code
disclosure with handlers configured via AddType (cve.mitre.org)
[boo#1227353]
A regression in the core of Apache HTTP Server 2.4.60 ignores
some use of the legacy content-type based configuration of
handlers. "AddType" and similar configuration, under some
circumstances where files are requested indirectly, result in
source code disclosure of local content. For example, PHP
scripts may be served instead of interpreted.
Users are recommended to upgrade to version 2.4.61, which fixes
this issue.
- Update to 2.4.60
*) SECURITY: CVE-2024-39573: Apache HTTP Server: mod_rewrite proxy
handler substitution (cve.mitre.org) [boo#1227271]
Potential SSRF in mod_rewrite in Apache HTTP Server 2.4.59 and
earlier allows an attacker to cause unsafe RewriteRules to
unexpectedly setup URL's to be handled by mod_proxy.
Credits: Orange Tsai (@orange_8361) from DEVCORE
*) SECURITY: CVE-2024-38477: Apache HTTP Server: Crash resulting in
Denial of Service in mod_proxy via a malicious request
(cve.mitre.org) [boo#1227270]
null pointer dereference in mod_proxy in Apache HTTP Server
2.4.59 and earlier allows an attacker to crash the server via a
malicious request.
Credits: Orange Tsai (@orange_8361) from DEVCORE
*) SECURITY: CVE-2024-38476: Apache HTTP Server may use
exploitable/malicious backend application output to run local
handlers via internal redirect (cve.mitre.org) [boo#1227269]
Vulnerability in core of Apache HTTP Server 2.4.59 and earlier
are vulnerably to information disclosure, SSRF or local script
execution via backend applications whose response headers are
malicious or exploitable.
Note: Some legacy uses of the 'AddType' directive to connect a
request to a handler must be ported to 'AddHandler' after this fix.
Credits: Orange Tsai (@orange_8361) from DEVCORE
*) SECURITY: CVE-2024-38475: Apache HTTP Server weakness in
mod_rewrite when first segment of substitution matches
filesystem path. (cve.mitre.org) [boo#1227268]
Improper escaping of output in mod_rewrite in Apache HTTP Server
2.4.59 and earlier allows an attacker to map URLs to filesystem
locations that are permitted to be served by the server but are
not intentionally/directly reachable by any URL, resulting in
code execution or source code disclosure.
Substitutions in server context that use a backreferences or
variables as the first segment of the substitution are affected.
Some unsafe RewiteRules will be broken by this change and the
rewrite flag "UnsafePrefixStat" can be used to opt back in once
ensuring the substitution is appropriately constrained.
Credits: Orange Tsai (@orange_8361) from DEVCORE
*) SECURITY: CVE-2024-38474: Apache HTTP Server weakness with
encoded question marks in backreferences (cve.mitre.org)
[boo#1227278]
Substitution encoding issue in mod_rewrite in Apache HTTP Server
2.4.59 and earlier allows attacker to execute scripts in
directories permitted by the configuration but not directly
reachable by any URL or source disclosure of scripts meant to
only to be executed as CGI.
Note: Some RewriteRules that capture and substitute unsafely will now
fail unless rewrite flag "UnsafeAllow3F" is specified.
Credits: Orange Tsai (@orange_8361) from DEVCORE
*) SECURITY: CVE-2024-38473: Apache HTTP Server proxy encoding
problem (cve.mitre.org) [boo#1227276]
Encoding problem in mod_proxy in Apache HTTP Server 2.4.59 and
earlier allows request URLs with incorrect encoding to be sent
to backend services, potentially bypassing authentication via
crafted requests.
Credits: Orange Tsai (@orange_8361) from DEVCORE
*) SECURITY: CVE-2024-38472: Apache HTTP Server on WIndows UNC SSRF
(cve.mitre.org) [boo#1227267]
SSRF in Apache HTTP Server on Windows allows to potentially leak
NTML hashes to a malicious server via SSRF and malicious
requests or content
Note: Existing configurations that access UNC paths
will have to configure new directive "UNCList" to allow access
during request processing.
Credits: Orange Tsai (@orange_8361) from DEVCORE
*) SECURITY: CVE-2024-36387: Apache HTTP Server: DoS by Null
pointer in websocket over HTTP/2 (cve.mitre.org) [boo#1227272]
Serving WebSocket protocol upgrades over a HTTP/2 connection
could result in a Null Pointer dereference, leading to a crash
of the server process, degrading performance.
Credits: Marc Stern (<marc.stern AT approach-cyber.com>)
OBS-URL: https://build.opensuse.org/request/show/1185778
OBS-URL: https://build.opensuse.org/package/show/Apache/apache2?expand=0&rev=704
67 lines
2.5 KiB
Plaintext
67 lines
2.5 KiB
Plaintext
Dear System Administrator,
|
|
|
|
with apache 2.4, some changes have been introduced that affect apache's
|
|
access control scheme.
|
|
|
|
Previously, the directives "Allow", "Deny" and "Order" have determined
|
|
if access to a resource has been granted with apache 2.2.
|
|
Example (from /etc/apache2/httpd.conf, the main apache configuration file):
|
|
<Directory />
|
|
Options None
|
|
AllowOverride None
|
|
Order deny,allow
|
|
Deny from all
|
|
</Directory>
|
|
|
|
With 2.4, these directives have been replaced by the "Require" directive,
|
|
which is contained in the mod_authz_core module, and enhanced by the
|
|
mod_authz_host module.
|
|
"Require" understands several regulative groups, such as
|
|
env access granted if an apache environment variable is set
|
|
method access granted only for given HTTP methods (GET, POST, ...)
|
|
expr access granted if the expression following expr evaluates to true
|
|
user access granted if the named users can access the resource
|
|
group analogous to user for groups
|
|
valid-user access granted if a valid user requests it
|
|
ip access granted if the client's IP address matches
|
|
all granted unconditionally accepted/granted
|
|
all denied unconditionally denied access
|
|
|
|
By consequence, the set of 2.2 directives
|
|
Order deny,allow
|
|
Deny from all
|
|
can be translated to the apache 2.4 Require directive
|
|
Require all denied
|
|
|
|
|
|
The SUSE Linux Enterprise 12 package set for apache comes with a compatibility
|
|
module called mod_access_compat, which, if loaded, causes apache to understand
|
|
the 2.2 "Allow/Deny" directives. Unfortunately, the mixed usage of the
|
|
2.2 "Allow/Deny" and the 2.4 "Require" directive will lead to either unexpected
|
|
or inconclusive results. By consequence, one should decide if the 2.2 or the
|
|
2.4 access control mimics shall be used.
|
|
|
|
Fortunately, it is easy to switch from the new back to the old scheme:
|
|
|
|
a2enmod access_compat
|
|
|
|
will enable the 2.2 scheme,
|
|
|
|
a2enmod -d access_compat
|
|
|
|
will disable the old scheme again, thereby enabling the new scheme.
|
|
Of course, an apache restart is needed:
|
|
|
|
systemctl restart apache2
|
|
|
|
The SUSE apache configuration framework can work with both the new and the
|
|
old scheme, conditional if the access_compat apache module is loaded.
|
|
|
|
Additional pointers about the access controls new in apache 2.4 and about
|
|
the access_compat module can be found here:
|
|
|
|
http://httpd.apache.org/docs/current/mod/mod_authz_core.html
|
|
http://httpd.apache.org/docs/current/mod/mod_authz_host.html
|
|
http://httpd.apache.org/docs/current/mod/mod_access_compat.html
|
|
|