We had a security audit and in the report we have a recommendation to upgrade apache from version 2.2.x to 2.4.35 or later
Can we do this ?
If yes how we do this
Thanks !
We had a security audit and in the report we have a recommendation to upgrade apache from version 2.2.x to 2.4.35 or later
Can we do this ?
If yes how we do this
Thanks !
If you’d upgrade to ucs 4.3, you’d already have 2.4.25.
How can we verify this ?
dpkg -l | grep apache
?
Ok here is the output
So i guess im at version 2.4.25 but the audit guy suggest us to be at minimum version 2.4.35
Do you know if it will be update soon ?
I would not think so. Debian Testing currently has 2.4.37, and as far as I can see there is no backport of this version in Jessie. The question would be why the auditor wants this specific version and why he wrongly identified your apache version 2.2.x.
If there would be a critical security issue in 2.4.25, I would expect that the Debian developers would backport the fix to their version.
Here the report
100995 - Apache 2.2.x < 2.2.33-dev / 2.4.x < 2.4.26 Multiple Vulnerabilities
Synopsis
The remote web server is affected by multiple vulnerabilities.
Description
According to its banner, the version of Apache running on the remote host is 2.2.x prior to 2.2.33-dev or 2.4.x
prior to 2.4.26. It is, therefore, affected by the following vulnerabilities :
An authentication bypass vulnerability exists due to third-party modules using the ap_get_basic_auth_pw()
function outside of the authentication phase. An unauthenticated, remote attacker can exploit this to bypass
authentication requirements. (CVE-2017-3167)
A NULL pointer dereference flaw exists due to third-party module calls to the mod_ssl
ap_hook_process_connection() function during an HTTP request to an HTTPS port. An unauthenticated, remote
attacker can exploit this to cause a denial of service condition. (CVE-2017-3169)
A NULL pointer dereference flaw exists in mod_http2 that is triggered when handling a specially crafted
HTTP/2 request. An unauthenticated, remote attacker can exploit this to cause a denial of service condition.
Note that this vulnerability does not affect 2.2.x.
(CVE-2017-7659)
An out-of-bounds read error exists in the ap_find_token() function due to improper handling of header
sequences. An unauthenticated, remote attacker can exploit this, via a specially crafted header sequence, to
cause a denial of service condition.
(CVE-2017-7668)
An out-of-bounds read error exists in mod_mime due to improper handling of Content-Type response headers.
An unauthenticated, remote attacker can exploit this, via a specially crafted Content-Type response header, to
cause a denial of service condition or the disclosure of sensitive information. (CVE-2017-7679)
Note that Nessus has not tested for these issues but has instead relied only on the application’s self-reported
version number.
See Also
https://archive.apache.org/dist/httpd/CHANGES_2.2.32
https://archive.apache.org/dist/httpd/CHANGES_2.4.26
https://httpd.apache.org/security/vulnerabilities_22.html
https://httpd.apache.org/security/vulnerabilities_24.html
Solution
Upgrade to Apache version 2.2.33-dev / 2.4.26 or later.
Risk Factor
High
CVSS v3.0 Base Score
7.3 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L)
CVSS v3.0 Temporal Score
6.4 (CVSS:3.0/E:U/RL:O/RC:C)
CVSS Base Score
7.5 (CVSS2#AV:N/AC:L/Au:N/C:P/I:P/A:P)
CVSS Temporal Score
5.5 (CVSS2#E:U/RL:OF/RC:C)
References
BID 99132
BID 99134
BID 99135
BID 99137
BID 99170
CVE CVE-2017-3167
CVE CVE-2017-3169
CVE CVE-2017-7659
CVE CVE-2017-7668
CVE CVE-2017-7679
Plugin Information:
Published: 2017/06/22, Modified: 2018/09/17
Plugin Output
tcp/443
Source : Server: Apache/2.4.25 (Univention)
Installed version : 2.4.25
Fixed version : 2.4.26
Hi,
I would never trust such security scanners. As they only check vanilla version but mostly not the versions of the Linux distributions.
A quick search for “debian CVE-2017-3167” showed useable replies:
https://security-tracker.debian.org/tracker/CVE-2017-3167
And now comparing to the version installed on an nearly up-to-date UCS 4.3-x shows:
root@ucs:/ dpkg -l | grep apache2
ii apache2 2.4.25-3+deb9u6A~4.3.2.201811190845 amd64 Apache HTTP Server
Compared to the above link the issue is fixed already in Debian. And in UCS then, too.
If you like you can check the other mentioned vulnerabilities. But if I were you I would completly disable this scanner as it produces obviously loads of false positives (like most of the other scanners, too).
May I assume you can not (or just will not) compile packages on your own and like the way of easy package handling through the distributions? Even if the above scanner would be right, what could you do instead of waiting until the package maintainer releases a fixed version?
As I said, throw away this stupid piece of software and set your cron to update packages automatically when updates are available.
/CV
Ok lol thanks for the info i just wanted to be sure im ok with the server since it’s public
Is there a doc on how to set cron to update packages automatically when updates are available ?
Thanks for your help i appreciate it !
Hey,
there is: a while ago I posted an article how to configure automatic updates and how to limit the versions that are updated to (e.g. you shouldn’t update from 4.3 to 4.4 or even 5.0 automatically but it should be safe to update from 4.3-3-123 to 4.3-3-456).
Kind regards
mosu