Some very quick background -
I just updated my web host with the newest version of Apache2 for security, and stability.
A vast majority of people won't be affected by this yet.
Server Software
about:
title: "[Removed]"
theme: "danbooru2"
url: "[Removed]"
What steps trigger this bug
Steps to trigger are to have Ubuntu 22.04, and install the latest version of Apache2. (2.4.52 or 2.4.55)
Go to any page with a tag search bar and search two or more tags at once.
This will result in an error that says: "Forbidden You don't have permission to access this resource."
Searching one tag at a time works.
What did you expect to happen?
What I expected to happen was for it to give me the search results from the query I asked for.
What actually happened?
What is actually happening here is a result of the new Apache2 update that addresses CVE-2023-27522, a vulnerability that has to do with encoding spaces in the address bar like this: "%20" and escape characters.
Encoding queries with a '+' however immediately makes the page work again.
For example:
https://www.[Hidden].net/post/list/reptile%20sunflower/1 <-- This will result in an error.
https://www.[Hidden].net/post/list/reptile+sunflower/1 <-- This works as is.
The resulting error in my Apache2 logs:
[Wed Mar 15 07:28:34.981016 2023] [rewrite:error] [pid 547623] [client 192.168.1.20:49523] AH10411: Rewritten query string contains control characters or spaces, referer: https://www.[Hidden].net/post/list
How am I handling this issue?
I made my own fix to the issue while I was writing this. (However, it may not be a good fix) I just recently updated my web server and I was surprised by this change. This is my production site though.
How to fix this issue temporarily?In .htaccess:
RewriteEngine On
# rather than link to images/ha/hash and have an ugly filename,
# we link to images/hash/tags.ext; mod_rewrite splits things so
# that shimmie sees hash and the user sees tags.ext
RewriteRule ^_(images|thumbs)/([0-9a-f]{2})([0-9a-f]{30}).*$ data/$1/$2/$2$3 [B,L]
# any requests for files which don't physically exist should be handled by index.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?q=$1&%{QUERY_STRING} [B,L]
Changing the end of the rewrite rule from "[L]" to "[B,L]" seems to work, however disables you from making queries with "+" because you are specifying escape backreferences in your rewrite. I don't think this breaks anything else, but I will keep you updated. There is probably a more elegant solution to this problem, like just having the "%20" encoded as a "+" instead. I think going forward, that may be the best option as PHP and Apache2 get updated. I haven't tested Nginx yet.
I will continue to run my production site with this until a better solution is found. I'll probably work on a fix later and submit it if I find one. I will also update Shimmie to 2.9.2 soon.
shish
commented
1 year ago
Some very quick background - I just updated my web host with the newest version of Apache2 for security, and stability. A vast majority of people won't be affected by this yet.
Server Software about: title: "[Removed]" theme: "danbooru2" url: "[Removed]"
versions: shimmie: "2.9.1" (Only slightly modified) schema: 21 php: "8.1.2-1ubuntu2.11" db: "mysql 10.6.12-MariaDB-0ubuntu0.22.04.1" os: "Linux 5.15.0-60-generic #66-Ubuntu SMP Fri Jan 20 14:29:49 UTC 2023 x86_64" server: "Apache/2.4.52 (Ubuntu)"
extensions: core: ["admin","alias_editor","bbcode","comment","download","et","ext_manager","four_oh_four","handle_pixel","help_pages","image","index","media","mime","setup","static_files","system","tag_edit","tag_list","upgrade","upload","user","user_config","view"] extra: ["auto_tagger","autocomplete","biography","blocks","blotter","browser_search","bulk_actions","bulk_download","custom_html_headers","danbooru_api","downtime","favorites","handle_svg","handle_video","home","image_hash_ban","image_view_counter","link_image","numeric_score","ouroboros_api","pm","pools","post_peek","random_image","random_list","rating","regen_thumb","relationships","report_image","shimmie_api","site_description","source_history","tag_categories","tag_editcloud","tag_history","tag_tools"] handled_mimes: ["image/jpeg","image/gif","image/png","image/webp","image/svg+xml","video/x-ms-asf","video/x-msvideo","video/x-flv","video/x-matroska","video/mp4","video/ogg","video/quicktime","video/webm"]
stats: images: 151447 comments: [Removed] users: [Removed]
media: memory_limit: "64.0MB" disk_use: "380.9GB" disk_total: "491.1GB"
thumbnails: engine: "convert" quality: 100 width: 128 height: 128 scaling: 400 mime: "image/jpeg"
Client Software
What steps trigger this bug Steps to trigger are to have Ubuntu 22.04, and install the latest version of Apache2. (2.4.52 or 2.4.55)
What did you expect to happen? What I expected to happen was for it to give me the search results from the query I asked for.
What actually happened? What is actually happening here is a result of the new Apache2 update that addresses CVE-2023-27522, a vulnerability that has to do with encoding spaces in the address bar like this: "%20" and escape characters. Encoding queries with a '+' however immediately makes the page work again. For example: https://www.[Hidden].net/post/list/reptile%20sunflower/1 <-- This will result in an error. https://www.[Hidden].net/post/list/reptile+sunflower/1 <-- This works as is.
The resulting error in my Apache2 logs: [Wed Mar 15 07:28:34.981016 2023] [rewrite:error] [pid 547623] [client 192.168.1.20:49523] AH10411: Rewritten query string contains control characters or spaces, referer: https://www.[Hidden].net/post/list
How am I handling this issue? I made my own fix to the issue while I was writing this. (However, it may not be a good fix) I just recently updated my web server and I was surprised by this change. This is my production site though.
How to fix this issue temporarily? In .htaccess:
Changing the end of the rewrite rule from "[L]" to "[B,L]" seems to work, however disables you from making queries with "+" because you are specifying escape backreferences in your rewrite. I don't think this breaks anything else, but I will keep you updated. There is probably a more elegant solution to this problem, like just having the "%20" encoded as a "+" instead. I think going forward, that may be the best option as PHP and Apache2 get updated. I haven't tested Nginx yet.
I will continue to run my production site with this until a better solution is found. I'll probably work on a fix later and submit it if I find one. I will also update Shimmie to 2.9.2 soon.
Sources I used to help fix this issue: https://nvd.nist.gov/vuln/detail/CVE-2023-27522 https://webmasters.stackexchange.com/questions/141824/rewriterule-started-returning-403-forbidden-error