Created httpd tracking bugs for this issue:

Affects: fedora-all [bug 2176718]

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.1 Update Services for SAP Solutions

Via RHSA-2023:1547 https://access.redhat.com/errata/RHSA-2023:1547

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2023:1593 https://access.redhat.com/errata/RHSA-2023:1593

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.4 Extended Update Support

Via RHSA-2023:1596 https://access.redhat.com/errata/RHSA-2023:1596

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.6 Extended Update Support

Via RHSA-2023:1597 https://access.redhat.com/errata/RHSA-2023:1597

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2023:1670 https://access.redhat.com/errata/RHSA-2023:1670

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.2 Advanced Update Support
  Red Hat Enterprise Linux 8.2 Update Services for SAP Solutions
  Red Hat Enterprise Linux 8.2 Telecommunications Update Service

Via RHSA-2023:1672 https://access.redhat.com/errata/RHSA-2023:1672

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2023:1673 https://access.redhat.com/errata/RHSA-2023:1673

While I can't see the bug due to it being restricted, the patch incorporated into the RHEL7 httpd (217742 - https://bugzilla.redhat.com/show_bug.cgi?id=2177742) has broken existing mod_rewrite behavior in RewriteRule, in a manner not related to mod_proxy or the CVE-2023-25690 issues, and in a manner not consistent with the upstream source (apache).  The SRPM change log notes:

* Tue Mar 21 2023 Luboš Uhliarik <luhliari> - 2.4.6-97.7
- Resolves: #2177742 - CVE-2023-25690 httpd: HTTP request splitting with
  mod_rewrite and mod_proxy 


The patch, with no attribution, adds both:

+    if (*(a2_end-1) == '?') {
+        /* a literal ? at the end of the unsubstituted rewrite rule */
+        newrule->flags |= RULEFLAG_QSNONE;
+    }
+    else if (newrule->flags & RULEFLAG_QSDISCARD) {
+        if (NULL == ap_strchr(newrule->output, '?')) {
+            newrule->flags |= RULEFLAG_QSNONE;
+        }
+    }

and

+    int qsappend = flags & RULEFLAG_QSAPPEND;
+    int qsdiscard = flags & RULEFLAG_QSDISCARD;
+
+    if (flags & RULEFLAG_QSNONE) {
+        rewritelog((r, 2, NULL, "discarding query string, no parse from substitution"));
+        r->args = NULL;
+        return;
+    }


Previously, a RewriteRule set as follows:

RewriteRule ^.*$ /path/endpoint.xyz? [QSA]

would result in the rewritten target receiving the original query string; i.e.:

1) ? causes the query string to be stripped
2) QSA causes the query string to be appended


With the change, QSNONE is being set, causing the QSA to not behave as described and intended, to not behave like it used to, and the query string is now being discarded.  This of course breaks any web application that has a rewriterule in place as described above.  There's no explanation of why Apache's own change for CVE-2023-25690, which solves the problem without breaking existing behavior, was not used instead.

For reference:

Patches:
upstream: https://github.com/apache/httpd/commit/8789f6bb926fa4c33b4231a8444340515c82bdff
upstream: https://github.com/apache/httpd/commit/8b93a6512f14f5f68887ddfe677e91233ed79fb0

Hello Shabba,

There is another upstream commit regarding this CVE[0] which is setting QSNONE flag in the same way as it is backported in RHEL-7. I will look at it ASAP tomorrow.

[0] https://svn.apache.org/viewvc?view=revision&revision=1908098

affects RHEL 8.7

Curious if any luck on consideration for the broken regression on the rewriterule behavior?  We had to downgrade ~1000 VM's to the RHEL7 .6 package to restore service to customers' websites that went down due to the rewrite rule behavior changing.  Fortunately not using proxying.  We're trying to avoid having to hand edit the htaccess files of every affected website given the rule, while obviously not logical stripping the string and adding it back, has worked in the RHEL httpd package all the way back to at least RHEL5 but probably mid 2000's.

(In reply to Shabba from comment #19)
> Curious if any luck on consideration for the broken regression on the
> rewriterule behavior?  We had to downgrade ~1000 VM's to the RHEL7 .6
> package to restore service to customers' websites that went down due to the
> rewrite rule behavior changing.  Fortunately not using proxying.  We're
> trying to avoid having to hand edit the htaccess files of every affected
> website given the rule, while obviously not logical stripping the string and
> adding it back, has worked in the RHEL httpd package all the way back to at
> least RHEL5 but probably mid 2000's.

Hello Shabba, 

Could you please file a ticket through the customer portal and describe what regression are you exactly experiencing?

Hello,

Any news? We've been hit with this issue breaking our site and wondered when a fix might be pushed before we consider a rollback?

Thank you

The regression is as I described it in comment 16; not much more I can add than that.  Previously, in RHEL 7, 6, and at least 5, apache from source, and apache on other distributions that have been patched for the same CVE (e.g. Ubuntu 20LTS and 22LTS), the following RewriteRule directive allows the original query string to pass through to the rewritten target:

RewriteRule ^.*$ /path/endpoint.xyz? [QSA]

In RHEL 7's httpd package after this patch, the query string is discarded.  The reason it is discarded is because of new behavior, where the target terminated by a ? sets a flag which causes the code handling a QSA directive to not execute.

In a hosting shared environment where thousands of websites may have such a rewrite rule, the only option was to downgrade off this patch release, because it isn't feasible, or within terms of service, to alter a customer's content (htaccess files) with what we hope is a successful pattern replacement, but could take the site down if it doesn't work as intended.

I just ran into a variant of this.

A simple rule on the form

RewriteRule /foo /bar? [R]

is now redirecting to /bar%3f

That is ? is being url-encoded and treated as part of the target url effectively breaking the redirect instead of signalling that no query string should be passed on as it's supposed to.

Downgrading to the previous version of the httpd package fixes the issue.

I see this on el7, el8 and el9.

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9.0 Extended Update Support

Via RHSA-2023:1916 https://access.redhat.com/errata/RHSA-2023:1916

Given it's been several weeks now, is it safe to assume RedHat intends to keep this software regression in place?  So, everyone whose websites are broken under the new release, should assume all future httpd updates on RHEL 7, 8, 9 will continue to not permit the prior RHEL httpd, and still working native Apache, behavior?

Hello Shabba,

we are aware of the regression and I'm working on the fix (RHEL-7/8/9) altogether with BCTL|BNE flags backport (RHEL-8/9). The regression was unfortunately revealed by upstream after I created all builds and they have been shipped. 

See:

https://bugzilla.redhat.com/show_bug.cgi?id=2190143
https://bugzilla.redhat.com/show_bug.cgi?id=2189179

This issue has been addressed in the following products:

  Red Hat Software Collections for Red Hat Enterprise Linux 7

Via RHSA-2023:3292 https://access.redhat.com/errata/RHSA-2023:3292

This issue has been addressed in the following products:

  JBCS httpd 2.4.51.sp2

Via RHSA-2023:3355 https://access.redhat.com/errata/RHSA-2023:3355

This issue has been addressed in the following products:

  JBoss Core Services on RHEL 7
  JBoss Core Services for RHEL 8

Via RHSA-2023:3354 https://access.redhat.com/errata/RHSA-2023:3354

This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2023-25690