Update coming for Apache in Virtual Labs?

[DHoltmann]

My information security office is hounding me to update Apache on my Veeam virtual lab. Apache in the current lab is vulnerable to CVE-2021-40438, which gets a VPR score of 10 in Tenable. Any chance we will see an update for B&R soon where the lab has the latest version of Apache? If not, is there a way I can update the lab myself?

[HannesK]

Hello,
and welcome to the forums.

I searched for CVE-2021-40438 and to me it looks like, that it is only relevant for mod_proxy. But mod_proxy is not available on our appliance as far as I see. I checked /usr/local/apache2/modules and "grep -ir proxy /usr/local/apache2/conf/"

Is Tenable maybe just checking just the version number of Apache (which is 2.4.43) and ignoring the fact that mod_proxy might not be enabled?

Best regards,
Hannes

[DHoltmann]

Yes, we found that Tenable is just checking the version number. Thank you for your help.

[Hidalgo]

Hello,

The company's security team checked some vulnerabilities in Virtual Labs, I'll list some below.

####Apache 2.4.x < 2.4.56 Multiple Vulnerabilities###

The version of Apache httpd installed on the remote host is prior to 2.4.56. It is, therefore, affected by multiple vulnerabilities as referenced in the 2.4.56 advisory.

- HTTP request splitting with mod_rewrite and mod_proxy: Some mod_proxy configurations on Apache HTTP Server versions 2.4.0 through 2.4.55 allow a HTTP Request Smuggling attack. Configurations are affected when mod_proxy is enabled along with some form of RewriteRule or ProxyPassMatch in which a non-specific pattern matches some portion of the user-supplied request-target (URL) data and is then re-inserted into the proxied request-target using variable substitution. For example, something like: RewriteEngine on RewriteRule ^/here/(.*) http://example.com:8080/elsewhere?$1 http://example.com:8080/elsewhere ; [P] ProxyPassReverse /here/ http://example.com:8080/ http://example.com:8080/ Request splitting/smuggling could result in bypass of access controls in the proxy server, proxying unintended URLs to existing origin servers, and cache poisoning. Acknowledgements: finder: Lars Krapf of Adobe (CVE-2023-25690)

- Apache HTTP Server: mod_proxy_uwsgi HTTP response splitting: HTTP Response Smuggling vulnerability in Apache HTTP Server via mod_proxy_uwsgi. This issue affects Apache HTTP Server: from 2.4.30 through 2.4.55.
Special characters in the origin response header can truncate/split the response forwarded to the client.
Acknowledgements: finder: Dimas Fariski Setyawan Putra (nyxsorcerer) (CVE-2023-27522)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.


####OpenSSL 1.1.1 < 1.1.1o Vulnerability####

The version of OpenSSL installed on the remote host is prior to 1.1.1o. It is, therefore, affected by a vulnerability as referenced in the 1.1.1o advisory.

- The c_rehash script does not properly sanitise shell metacharacters to prevent command injection. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool.
Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2). Fixed in OpenSSL 1.1.1o (Affected 1.1.1-1.1.1n).
Fixed in OpenSSL 1.0.2ze (Affected 1.0.2-1.0.2zd). (CVE-2022-1292)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

####OpenSSL 1.1.1 < 1.1.1p Vulnerability####

he version of OpenSSL installed on the remote host is prior to 1.1.1p. It is, therefore, affected by a vulnerability as referenced in the 1.1.1p advisory.

- In addition to the c_rehash shell command injection identified in CVE-2022-1292, further circumstances where the c_rehash script does not properly sanitise shell metacharacters to prevent command injection were found by code review. When the CVE-2022-1292 was fixed it was not discovered that there are other places in the script where the file names of certificates being hashed were possibly passed to a command executed through the shell. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. Fixed in OpenSSL 3.0.4 (Affected 3.0.0,3.0.1,3.0.2,3.0.3). Fixed in OpenSSL 1.1.1p (Affected 1.1.1-1.1.1o). Fixed in OpenSSL 1.0.2zf (Affected 1.0.2-1.0.2ze). (CVE-2022-2068)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

Does anyone know of any predictions for fixing these vulnerabilities?

Best regards,
Hidalgo

[Gostev]

Hi, these look to be false positives, as usual with automated vulnerability scanners. For example, our appliance doesn't use c_rehash in principle.