Leaderboard

This is the part that I was most confused about. The post goes to detail about trivial stuff such as how to create a zip file, but then simply states that... They make it sound super easy, and obviously it is when you are both the attacker and the victim, but that has little to do with real world. Of course MITM is a serious threat and systems should be configured properly and users should be educated about risks of e.g. connecting via public wifis, but it's not something you can just pull off like it was nothing. And yes, any system that allows the user to directly execute code or upload files that are executed as code is technically "vulnerable" once you gain access to those features. That being said, I do see some potential for improvement here. For an example I think the default settings for moduleInstall should be as strict as possible, and I'm also wondering if ProcessWire could do light-weight scanning of obviously dangerous actions? Something like checking if an uploaded module/PHP file contains exec/eval/etc. or base64 encoded values, and at least displaying a warning to the user. Not sure if that's really feasible or particularly useful, though, and it could no doubt be circumvented by a targeted attack. Just a rough idea ?‍♂️

I wonder if @ryan was ever contacted about this. I've tried to come up with a scenario where the URL injection mentioned in the CVE can become exploitable, but I'm having a hard time. When you can intercept a communication to that level and modify the message body, you could just forge the necessary requests, supply them with the intercepted session information and use the built-in module upload functionality. That's why we have DANE, so the communication stays confidential even if you're routed through untrustworthy networks. I've sent a rejection request to MITRE with the following rationale:

A new vulnerability (CVE-2023-24676) was published last week, detailing how module install can be used to execute code and set up a reverse shell on a site. After going through the post that explains the exploit a couple of times I'm wondering if someone could confirm that I've got it right: First of all it requires that a) web server has write access to the modules directory and b) ProcessWire is configured to allow file uploads, right? The latter is by default true in debug mode, which is also mentioned in aforementioned post as one of the conditions. Built-in module downloading features check the moduleInstall setting (in ProcessModuleInstall class) and I couldn't find any way to circumvent them. For anything bad to happen, user with (presumably) superuser access must type in an URL of a ZIP file with malicious code, or someone must be able to intercept the request and change it. First part seems to be a non-issue, e.g. if a superuser really does that then there's very little that can be done to protect them, while the second part (to my understanding) sounds like it would be very unlikely and quite difficult, at least assuming that requests are passed through HTTPS. According to the post the PHP file in the zip is automatically executed by the system. I find this part a bit strange — I'm not exactly familiar with every involved piece of code, but it doesn't seem like ProcessWire should do that. On the other hand if the file in the package was a properly formatted module class, then this would be more likely, and again probably not something that can be prevented. So, in other words, it seems to me that this vulnerability isn't really a vulnerability — more like a way to use a built-in feature to do potentially harmful actions, of which users are specifically warned about in UI of said feature? Let me know if I got something wrong here, though. If anything, it seems to me that this is a good reminder that it is indeed dangerous to enable file uploads from arbitrary URLs or allow web server to write files that could be executed as PHP (or any other language for that matter, including JavaScript). Only thing that I think we could do better is to set those module file download settings false by default, instead of debug as they are now, just to be extra sure that a developer has indeed intentionally enabled them ?

@flydev I confirm that is what the file path appears on dev and production, but on production i would get 404s on paths because they included the domain as a prefix to the path i.e. https://my-site/my-site/site/assets/files/1/44849-the-image-2016.897x0-is.jpg I was able to do a hot fix on my prod server by using @ryan TextformatterFindReplace module and attaching it to the body textarea fields in question that had the images added via TinyMCE … and set the rule to e.g. my-site/= This fixed my issue, by converting the redundant domain name to an empty string.

Based on how they kept specifically mentioning the requests containing the download_zip_url variable and the relatively high score this CVE has (7.2 High) I was expecting that they'd found some major issue, or perhaps a way to circumvent normal core behaviour. But really it just seems like they figured out that if you are able to inject code into the system you can use it to do nasty things. There is one difference to the Tracy example, of course: in that case the administrator would have to install Tracy and then type in the command to the Console panel. If the attacker doesn't have superuser access but they know a system that matches aforementioned conditions, they could lure an existing superuser to install malicious code via the admin ? -- I don't want to belittle any potential security issues, but it seems that this one is blown way out of proportion. I'm not familiar with the process used to validate and score CVE's, but it seems that they definitely err on the side of "always assume that reports are true, and always assume that the issue is as bad as it could theoretically be".

Yes, exactly. Everything in the vulnerability description after "we require a user account with administrative privileges and the application must have debug mode activated" seems redundant to me. At that point it's game over. Rather than following all the subsequent steps you could simply install Tracy Debugger and start executing arbitrary PHP code in the Console panel. It's up to every superuser to ensure that malicious users cannot get an account with administrator privileges so I don't understand how this vulnerability description adds anything beyond that basic point.

Hi Nico, Thanks for this module! Love it much I think I may have found a conflicting issue when this module is installed along side with ProcessBackup (DB Backup module). There is an error when you try to view the Database Backup detail and I believe it may be caused by the following line: $editedPage = wire('pages')->get($this->config->input->get->id); The SEO module kicks in when trying to view the database backup page because there is a querystring id in the url. setup/db-backups/info/?id=0:dev.cc26012015-01.sql The fix is pretty simple: public function ready() { // backend hooks if(@$this->page->process == 'ProcessPageEdit') { $editedPage = wire('pages')->get($this->config->input->get->id); if(in_array($editedPage->template->name, $this->includeTemplates)) { $this->addHookAfter("ProcessPageEdit::buildFormContent", $this, 'hookCustomizeSeoTab'); } } // frontend hooks if($this->page->template != 'admin' && in_array($this->page->template->name, $this->includeTemplates)) { $this->addHookProperty("Page::seo", $this, 'hookFrontendPage'); $this->addHookProperty("Config::seo", $this, 'hookFrontendConfig'); } } Check the ProcessEditPage first before look for the edited page object. But anyway, I thought I let you know Thanks much again!