Apache 2.4.60 and CVE-2024-38474 conflict with pwModal() and ProcessPageEditLink.

[elabx]

Short description of the issue

In Apache version Apache 2.4.60 this vulnerability was addressed by disallowing encoded "?" in URLs this means ProcessPageEdit link breaks (throws a 403) when getting loaded with a URL that contains parameters.

Optional: Suggestion for a possible fix

In wire/modules/Jquery/JqueryUI/modal.js, decode the paremeters again:

if(href.indexOf('modal=') > 0) {
    url = decodeURIComponent(href); 
} else {
    url = decodeURIComponent(href) + (href.indexOf('?') > -1 ? '&' : '?') + 'modal=1';
}

Steps to reproduce the issue

1. LAMP stack installation with Apache 2.4.60
2. Set up a link in CKEditor or TinyMCE with a url parameter.
3. Save and try to open the link again.

[adrianbj]

@elabx and @ryancramerdesign - I think there is more that needs attending to than just that Jquery piece. It also affects the UserActivity module and it can also affect our own template code. There is more info here: https://processwire.com/talk/topic/30208-user-activity-module-ajax-forbidden-due-to-updated-apache/#comment-242913

but basically it looks like Drupal has taken the approach of changing the way their htaccess rewrite works which I believe fixes any and all of these issues in one place, and I think perhaps PW might need to do the same.

[elabx]

but basically it looks like Drupal has taken the approach of changing the way their htaccess redirect works which I believe fixes any and all of these issues in one place.

@adrianbj Do you happen to have a link to that fix?? Thanks!

[adrianbj]

@elabx - this post (https://processwire.com/talk/topic/30208-user-activity-module-ajax-forbidden-due-to-updated-apache/?do=findComment&comment=242881) in that thread links to it and details my experiments with it.

[ryancramerdesign]

@elabx Do you find it fixes it to do this?

if(url.indexOf('%3F') > -1) url = url.replace('%3F', '?');

@adrianbj I'm not sure that making PW use its abnormal request fallback would fix this particular case (even if it helps in others) because wouldn't there still be a %3F in this URL? It's Apache that's refusing the request right (?), so whatever originates the URL would have to replace the %3F with a ?, or maybe I don't fully understand it yet. I don't have an environment using this version, so can't observe it myself yet.

I'm curious why Apache is doing this, as an encoded question mark is valid in a URL. It gives the appearance that Apache is blocking access to the bug rather than fixing the bug?

[adrianbj]

@elabx - I am not certain of anything, regarding this and life in general :) but my understanding is that it's only a problem with an Apache ReWrite rule gets involved and I think this note for the new UnsafeAllow3F flag confirms my theory:

Setting this flag is required to allow a rewrite to continue If the HTTP request being written has an encoded question mark, '%3f', and the rewritten result has a '?' in the substiution. This protects from a malicious URL taking advantage of a capture and re-substitution of the encoded question mark.

Do you agree based on that, or do you think I am misunderstanding?

[ryancramerdesign]

@adrianbj I'm not really sure, I don't understand the reason for it or why having an encoded question mark is a problem. I think I'd need an example of how to exploit the "capture and re-substitution of the encoded question mark" issue. But reading through this thread, it looks like maybe they've identified it as a bug and might be fixing it? https://lists.apache.org/thread/rk8mmo5nd4fdz2cs7mhls1tc9hglozyx

[adrianbj]

Not at my computer right now but nice find on that Apache site. Maybe they will fix the particular scenario that is causing us problems.

[adrianbj]

@elabx - following the links from your post, it looks like a fix has already been committed: https://svn.apache.org/viewvc?view=revision&revision=1919325 but I have no idea when that will make it into a released version that is included in the various package managers.

[adrianbj]

Looks like 2.4.62 was released on the same day that the fix (https://github.com/apache/httpd/commit/a1a93beb58b81f1de2b713ae5f96c41ed5952a74) was added, but from what I can tell, the fix was committed after the release so we might need to wait for 2.4.63

https://dlcdn.apache.org/httpd/CHANGES_2.4.62

[elabx]

@adrianbj @ryancramerdesign Sorry lost track of this issue for a few days. Thank you both for chiming in. So what we could expect is for things to go back to how it was before 2.4.62? No need for UnsafeAllow3F flag?

[adrianbj]

So what we could expect is for things to go back to how it was before 2.4.62?

That's my expectation of the change that's already been committed. Of course who know how long it will be until 2.4.63 is released and whether it will make it in to distro packages in a timely manner or not. Hopefully it will be considered a security update and made available quickly.

[matjazpotocnik]

@elabx @adrianbj does this fix https://github.com/processwire/processwire/commit/1c0aa2d2486f9ef141092783f54077131f5d14e4 solve the issue?

[matjazpotocnik]

Closing on the assumption this is fixed. @elabx, please reopen if that is not the case.