Mandriva issued this advisory today (January 10): http://www.mandriva.com/en/support/security/advisories/?dis=2010.1&name=MDVSA-2012:003 The first CVE is a new integer overflow issue for mod_setenvif, and the other is due to an incomplete fix for CVE-2011-3368 (Bug 2947). Advisory: ======================== Updated apache packages fixes security vulnerabilities: Integer overflow in the ap_pregsub function in server/util.c in the Apache HTTP Server 2.0.x through 2.0.64 and 2.2.x through 2.2.21, when the mod_setenvif module is enabled, allows local users to gain privileges via a .htaccess file with a crafted SetEnvIf directive, in conjunction with a crafted HTTP request header, leading to a heap-based buffer overflow (CVE-2011-3607). The mod_proxy module in the Apache HTTP Server 1.3.x through 1.3.42, 2.0.x through 2.0.64, and 2.2.x through 2.2.21, when the Revision 1179239 patch is in place, does not properly interact with use of (1) RewriteRule and (2) ProxyPassMatch pattern matches for configuration of a reverse proxy, which allows remote attackers to send requests to intranet servers via a malformed URI containing an @ (at sign) character and a : (colon) character in invalid positions. NOTE: this vulnerability exists because of an incomplete fix for CVE-2011-3368 (CVE-2011-4317). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3607 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4317 http://www.mandriva.com/en/support/security/advisories/?dis=2010.1&name=MDVSA-2012:003
CC: (none) => alien
These fixes will need to be added in Cauldron as well.
Ping ?
Mandriva issued an additional advisory today (February 2) for Apache with some new CVEs: CVE-2012-0021, CVE-2012-0031, and CVE-2012-0053. They upgraded to the newest version 2.2.22, so we need to follow suit, and this actually simplifies things considerably. I had tried to work on building this update, but divergence in our packages made it very difficult to determine which things had been fixed and which hadn't and where all the patches were. This should make it a lot easier to bring them back in line. Additionally, two related packages were upgraded to their latest versions, so we need to do this as well: apr (1.4.5) and apr-util (1.4.1). The apache-conf SRPM was also updated, so we need this as well.
I forgot the link for the new advisory: http://www.mandriva.com/en/support/security/advisories/?dis=2010.1&name=MDVSA-2012:012
In Apache 2.2.22, a symbol ap_set_accept_ranges was added to httpd, which mod_negotiation.so (in apache-modules) depends on. This has caused an issue with the upgrade on several distributions including Mandriva, and has even affected FreeBSD. The issue is that if the modules get upgraded before the mpm (which they do with urpmi), when the post scriplet tries to restart httpd, it fails because of the missing symbol. Then, when apache-mpm-* gets upgraded, it doesn't restart httpd because it's no longer running. This is mainly a problem for people who automatically install updates with a cron job (bad idea as it may be, some people do this), as a manual restart after the upgrade fixes it. I believe the solution is to add to the apache-modules package: Requires(pre): apache-mpm = %{version}-%{release} or at least = %{version}, to ensure that the httpd binary is upgraded before the modules are.
Just so it doesn't get lost, here's what tv thought about my ideas to make urpmi handle this better. Maybe it will make sense to you D Morgan. https://bugs.mageia.org/show_bug.cgi?id=4413#c1
CC: (none) => guillomovitch
(In reply to comment #5) > In Apache 2.2.22, a symbol ap_set_accept_ranges was added to httpd, which > mod_negotiation.so (in apache-modules) depends on. This has caused an issue > with the upgrade on several distributions including Mandriva, and has even > affected FreeBSD. The issue is that if the modules get upgraded before the mpm > (which they do with urpmi), when the post scriplet tries to restart httpd, it > fails because of the missing symbol. Then, when apache-mpm-* gets upgraded, it > doesn't restart httpd because it's no longer running. This is mainly a problem > for people who automatically install updates with a cron job (bad idea as it > may be, some people do this), as a manual restart after the upgrade fixes it. > > I believe the solution is to add to the apache-modules package: > Requires(pre): apache-mpm = %{version}-%{release} > > or at least = %{version}, to ensure that the httpd binary is upgraded before > the modules are. Guillaume, I was going to use the solution I gave in the problem described in Comment 5, but I noticed that the apache-mpm packages have Requires(pre): apache-modules. Of course, two packages can't Requires(pre) each other, because someone has to go first. Are those Requires(pre) needed? Should I remove them and add the one I said should be added? Or is the solution to remove the %post scriplets in apache-modules and apache-mod_* that restarts httpd?
I'm posting the advisory now so that I don't lose it. It will have to be updated for the updated apache version once a solution to the issue from Comment 5 is implemented (pending feedback from guillomovitch). Advisory: ======================== Updated apache packages fixes security vulnerabilities: Integer overflow in the ap_pregsub function in server/util.c in the Apache HTTP Server 2.0.x through 2.0.64 and 2.2.x through 2.2.21, when the mod_setenvif module is enabled, allows local users to gain privileges via a .htaccess file with a crafted SetEnvIf directive, in conjunction with a crafted HTTP request header, leading to a heap-based buffer overflow (CVE-2011-3607). The mod_proxy module in the Apache HTTP Server 1.3.x through 1.3.42, 2.0.x through 2.0.64, and 2.2.x through 2.2.21, when the Revision 1179239 patch is in place, does not properly interact with use of (1) RewriteRule and (2) ProxyPassMatch pattern matches for configuration of a reverse proxy, which allows remote attackers to send requests to intranet servers via a malformed URI containing an @ (at sign) character and a : (colon) character in invalid positions. NOTE: this vulnerability exists because of an incomplete fix for CVE-2011-3368 (CVE-2011-4317). The log_cookie function in mod_log_config.c in the mod_log_config module in the Apache HTTP Server 2.2.17 through 2.2.21, when a threaded MPM is used, does not properly handle a %{}C format string, which allows remote attackers to cause a denial of service (daemon crash) via a cookie that lacks both a name and a value (CVE-2012-0021). scoreboard.c in the Apache HTTP Server 2.2.21 and earlier might allow local users to cause a denial of service (daemon crash during shutdown) or possibly have unspecified other impact by modifying a certain type field within a scoreboard shared memory segment, leading to an invalid call to the free function (CVE-2012-0031). protocol.c in the Apache HTTP Server 2.2.x through 2.2.21 does not properly restrict header information during construction of Bad Request (aka 400) error documents, which allows remote attackers to obtain the values of HTTPOnly cookies via vectors involving a (1) long or (2) malformed header in conjunction with crafted web script (CVE-2012-0053). The updated packages have been upgraded to the latest 2.2.22 version which is not vulnerable to these issues. Additionally, apr and apr-util have been upgraded to the latest versions 1.4.5 and 1.4.1 respectively, which hold many improvments over the previous versions. Also, apache-mod_suexec is provided with this update, as it was available in Mandriva 2010.2 but was not previously available in Mageia 1. Notes: apache-doc is now built by the apache SRPM distcache support in apache-mod_ssl has been disabled References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3607 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4317 http://www.mandriva.com/en/support/security/advisories/?dis=2010.1&name=MDVSA-2012:003 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0021 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0031 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0053 http://www.apache.org/dist/httpd/CHANGES_2.2.22 http://httpd.apache.org/security/vulnerabilities_22.html http://www.apache.org/dist/apr/CHANGES-APR-1.4 http://www.apache.org/dist/apr/CHANGES-APR-UTIL-1.4 http://www.mandriva.com/en/support/security/advisories/?dis=2010.1&name=MDVSA-2012:012 ======================== Updated packages in core/updates_testing: ======================== libapr1-1.4.5-1.mga1 libapr-devel-1.4.5-1.mga1 libapr-util1-1.4.1-1.mga1 apr-util-dbd-ldap-1.4.1-1.mga1 apr-util-dbd-pgsql-1.4.1-1.mga1 apr-util-dbd-sqlite3-1.4.1-1.mga1 apr-util-dbd-freetds-1.4.1-1.mga1 apr-util-dbd-odbc-1.4.1-1.mga1 apr-util-dbm-db-1.4.1-1.mga1 apr-util-openssl-1.4.1-1.mga1 apr-util-nss-1.4.1-1.mga1 libapr-util-devel-1.4.1-1.mga1 apache-mpm-prefork-2.2.22-1.mga1 apache-mpm-worker-2.2.22-1.mga1 apache-mpm-event-2.2.22-1.mga1 apache-mpm-itk-2.2.22-1.mga1 apache-mpm-peruser-2.2.22-1.mga1 apache-base-2.2.22-1.mga1 apache-modules-2.2.22-1.mga1 apache-mod_dav-2.2.22-1.mga1 apache-mod_ldap-2.2.22-1.mga1 apache-mod_cache-2.2.22-1.mga1 apache-mod_disk_cache-2.2.22-1.mga1 apache-mod_mem_cache-2.2.22-1.mga1 apache-mod_file_cache-2.2.22-1.mga1 apache-mod_deflate-2.2.22-1.mga1 apache-mod_proxy-2.2.22-1.mga1 apache-mod_proxy_ajp-2.2.22-1.mga1 apache-mod_proxy_scgi-2.2.22-1.mga1 apache-mod_userdir-2.2.22-1.mga1 apache-mod_ssl-2.2.22-1.mga1 apache-mod_dbd-2.2.22-1.mga1 apache-mod_authn_dbd-2.2.22-1.mga1 apache-mod_reqtimeout-2.2.22-1.mga1 apache-htcacheclean-2.2.22-1.mga1 apache-devel-2.2.22-1.mga1 apache-source-2.2.22-1.mga1 apache-doc-2.2.22-1.mga1.noarch.rpm apache-mod_suexec-2.2.22-1.mga1 from SRPMS: apr-1.4.5-1.mga1 apr-util-1.4.1-1.mga1 apache-2.2.22-1.mga1 apache-mod_suexec-2.2.22-1.mga1
Mandriva has posted an updated advisory for apr today (Feburary 14): http://www.mandriva.com/en/support/security/advisories/?dis=2010.1&name=MDVSA-2012:019 I've built apr 1.4.6 to fix this. I will change the version reference in the advisory, and add this: "tables/apr_hash.c in the Apache Portable Runtime (APR) library through 1.4.5 computes hash values without restricting the ability to trigger hash collisions predictably, which allows context-dependent attackers to cause a denial of service (CPU consumption) via crafted input to an application that maintains a hash table (CVE-2012-0840)." With these additional references: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0840 http://www.apache.org/dist/apr/CHANGES-APR-1.4
(In reply to comment #7) > (In reply to comment #5) > > In Apache 2.2.22, a symbol ap_set_accept_ranges was added to httpd, which > > mod_negotiation.so (in apache-modules) depends on. This has caused an issue > > with the upgrade on several distributions including Mandriva, and has even > > affected FreeBSD. The issue is that if the modules get upgraded before the mpm > > (which they do with urpmi), when the post scriplet tries to restart httpd, it > > fails because of the missing symbol. Then, when apache-mpm-* gets upgraded, it > > doesn't restart httpd because it's no longer running. This is mainly a problem > > for people who automatically install updates with a cron job (bad idea as it > > may be, some people do this), as a manual restart after the upgrade fixes it. > > > > I believe the solution is to add to the apache-modules package: > > Requires(pre): apache-mpm = %{version}-%{release} > > > > or at least = %{version}, to ensure that the httpd binary is upgraded before > > the modules are. > > Guillaume, I was going to use the solution I gave in the problem described in > Comment 5, but I noticed that the apache-mpm packages have Requires(pre): > apache-modules. Of course, two packages can't Requires(pre) each other, > because someone has to go first. Are those Requires(pre) needed? Should I > remove them and add the one I said should be added? Or is the solution to > remove the %post scriplets in apache-modules and apache-mod_* that restarts > httpd? Or is the solution to use %posttrans instead of %post for the scriplets?
apache-conf-2.2.22 is missing in mga1, and so rpmdrake refuses to install Apache 2.2.22.
CC: (none) => LpSolit
(In reply to comment #11) > apache-conf-2.2.22 is missing in mga1, and so rpmdrake refuses to install > Apache 2.2.22. Thanks for the reminder. apache-conf is uploaded.
Sorry for this late reply. This is a quite complex issue, and the packaging used in mageia doesn't help figuring out how to handle it. The whole point of all those ordering constraints requires(pre) is to ensure than any post-installation script calling 'service httpd' would not fail because of a missing httpd service script: apache-conf package has to be installed first. Another alternative solution is to test for its presence before calling it. In a security update scenario, it seems quite safe to consider than it is already present, so those constraints seems less strictly needed. Also, the whole idea of "let's restart apache everytime a part of it is updated" is a bit overkill, because it often results in multiple uneeded restarts, sometimes even in intermediate non-functional states such as the one you describe. Restarting only once, when the whole transaction is finished, as you suggest, seems to be the best idea there.
you mean, like a sort of filetrigger?
(In reply to comment #14) > you mean, like a sort of filetrigger? That was Thierry Vignaud's suggestion (that or %posttrans): https://bugs.mageia.org/show_bug.cgi?id=4413#c1
Ok, this is ready for QA. Advisory: ======================== Updated apache packages fixes security vulnerabilities: Integer overflow in the ap_pregsub function in server/util.c in the Apache HTTP Server 2.0.x through 2.0.64 and 2.2.x through 2.2.21, when the mod_setenvif module is enabled, allows local users to gain privileges via a .htaccess file with a crafted SetEnvIf directive, in conjunction with a crafted HTTP request header, leading to a heap-based buffer overflow (CVE-2011-3607). The mod_proxy module in the Apache HTTP Server 1.3.x through 1.3.42, 2.0.x through 2.0.64, and 2.2.x through 2.2.21, when the Revision 1179239 patch is in place, does not properly interact with use of (1) RewriteRule and (2) ProxyPassMatch pattern matches for configuration of a reverse proxy, which allows remote attackers to send requests to intranet servers via a malformed URI containing an @ (at sign) character and a : (colon) character in invalid positions. NOTE: this vulnerability exists because of an incomplete fix for CVE-2011-3368 (CVE-2011-4317). The log_cookie function in mod_log_config.c in the mod_log_config module in the Apache HTTP Server 2.2.17 through 2.2.21, when a threaded MPM is used, does not properly handle a %{}C format string, which allows remote attackers to cause a denial of service (daemon crash) via a cookie that lacks both a name and a value (CVE-2012-0021). scoreboard.c in the Apache HTTP Server 2.2.21 and earlier might allow local users to cause a denial of service (daemon crash during shutdown) or possibly have unspecified other impact by modifying a certain type field within a scoreboard shared memory segment, leading to an invalid call to the free function (CVE-2012-0031). protocol.c in the Apache HTTP Server 2.2.x through 2.2.21 does not properly restrict header information during construction of Bad Request (aka 400) error documents, which allows remote attackers to obtain the values of HTTPOnly cookies via vectors involving a (1) long or (2) malformed header in conjunction with crafted web script (CVE-2012-0053). tables/apr_hash.c in the Apache Portable Runtime (APR) library through 1.4.5 computes hash values without restricting the ability to trigger hash collisions predictably, which allows context-dependent attackers to cause a denial of service (CPU consumption) via crafted input to an application that maintains a hash table (CVE-2012-0840). The updated packages have been upgraded to the latest 2.2.22 version which is not vulnerable to these issues. Additionally, apr and apr-util have been upgraded to the latest versions 1.4.6 and 1.4.1 respectively, which hold many improvements over the previous versions. Also, apache-mod_suexec is provided with this update, as it was available in Mandriva 2010.2 but was not previously available in Mageia 1. Notes: apache-doc is now built by the apache SRPM distcache support in apache-mod_ssl has been disabled References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3607 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4317 http://www.mandriva.com/en/support/security/advisories/?dis=2010.1&name=MDVSA-2012:003 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0021 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0031 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0053 http://www.apache.org/dist/httpd/CHANGES_2.2.22 http://httpd.apache.org/security/vulnerabilities_22.html http://www.apache.org/dist/apr/CHANGES-APR-1.4 http://www.apache.org/dist/apr/CHANGES-APR-UTIL-1.4 http://www.mandriva.com/en/support/security/advisories/?dis=2010.1&name=MDVSA-2012:012 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0840 http://www.apache.org/dist/apr/CHANGES-APR-1.4 ======================== Updated packages in core/updates_testing: ======================== libapr1-1.4.6-1.mga1 libapr-devel-1.4.6-1.mga1 libapr-util1-1.4.1-1.mga1 apr-util-dbd-ldap-1.4.1-1.mga1 apr-util-dbd-pgsql-1.4.1-1.mga1 apr-util-dbd-sqlite3-1.4.1-1.mga1 apr-util-dbd-freetds-1.4.1-1.mga1 apr-util-dbd-odbc-1.4.1-1.mga1 apr-util-dbm-db-1.4.1-1.mga1 apr-util-openssl-1.4.1-1.mga1 apr-util-nss-1.4.1-1.mga1 libapr-util-devel-1.4.1-1.mga1 apache-mpm-prefork-2.2.22-2.mga1 apache-mpm-worker-2.2.22-2.mga1 apache-mpm-event-2.2.22-2.mga1 apache-mpm-itk-2.2.22-2.mga1 apache-mpm-peruser-2.2.22-2.mga1 apache-base-2.2.22-2.mga1 apache-modules-2.2.22-2.mga1 apache-mod_dav-2.2.22-2.mga1 apache-mod_ldap-2.2.22-2.mga1 apache-mod_cache-2.2.22-2.mga1 apache-mod_disk_cache-2.2.22-2.mga1 apache-mod_mem_cache-2.2.22-2.mga1 apache-mod_file_cache-2.2.22-2.mga1 apache-mod_deflate-2.2.22-2.mga1 apache-mod_proxy-2.2.22-2.mga1 apache-mod_proxy_ajp-2.2.22-2.mga1 apache-mod_proxy_scgi-2.2.22-2.mga1 apache-mod_userdir-2.2.22-2.mga1 apache-mod_ssl-2.2.22-2.mga1 apache-mod_dbd-2.2.22-2.mga1 apache-mod_authn_dbd-2.2.22-2.mga1 apache-mod_reqtimeout-2.2.22-2.mga1 apache-htcacheclean-2.2.22-2.mga1 apache-devel-2.2.22-2.mga1 apache-source-2.2.22-2.mga1 apache-doc-2.2.22-2.mga1 apache-mod_suexec-2.2.22-1.mga1 apache-conf-2.2.22-1.mga1 from SRPMS: apr-1.4.6-1.mga1.src.rpm apr-util-1.4.1-1.mga1.src.rpm apache-2.2.22-2.mga1.src.rpm apache-conf-2.2.22-1.mga1.src.rpm apache-mod_suexec-2.2.22-1.mga1.src.rpm
CC: (none) => dmorganecAssignee: dmorganec => qa-bugs
QA, please include the following scenario in your tests. Have previous apache package(s) installed (release or updates version, doesn't matter). Make sure the httpd service is running. Install the updated packages. Make sure that httpd restarts successfully in the upgrade, and that after the packages have all been installed, ensure that the httpd service is still running.
Thanks David, thats very thorough and most helpful.
Testing on i586. Installation using mgaapplet went without any problems, httpd was running before and after. http://localhost and https://localhost working. Any specific tests that should be included for the cve's?
CC: (none) => davidwhodgins
CVE-2011-3607 - http://www.halfdog.net/Security/2011/ApacheModSetEnvIfIntegerOverflow/DemoExploit.html CVE-2011-3368 - http://www.securityfocus.com/bid/49957/exploit CVE-2012-0053 - http://www.securityfocus.com/bid/51706/exploit Possibly.. CVE-2012-0840 - http://www.securityfocus.com/bid/51917/exploit
I'm not sure how to make use of those PoC codes so just checking the update for regressions and that installation of new packages is possible. x86_64 Tested with wordpress, bugzilla, zoneminder, phpmyadmin & mediawiki and parts of bacula Tested mod_suexec with the setting in bugzilla installation (/etc/bugzilla/localconfig) then running /usr/share/bugzilla/bin/checksetup.pl From /var/log/httpd/error.log: [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) Update validated Could sysadmin please push from core/updates_testing to core/updates Please see comment 16 for details Thankyou!
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugsHardware: i586 => All
update pushed
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED