pearcmd.php must exist, and register_argc_argv must be on, not common with hosting providers. But I am assuming the other themes and meeting conditions possibly affect a lot of WordPress sites.
As the article points out, one issue is that the official Docker container for PHP has this configuration.
However at least in principle all of the affected versions [0] could be automatically updated. Not sure if they have set it to auto-update as far back as 4.7 though.
[0] except 4.9.3 which has a bug in its automatic update mechanism.
pearcmd and register_argc_argv are just examples. get_page_template was unsanitized in some themes, that's the flaw, you could then combine it with one of a million unauthorized file upload in wordpress plugins to try and eval code. An attacker would like to use upload + this chain of requires (instead of just uploading a php) because of hardened configuration and the pwn can go unnoticed in the logs.
Also, with pearcmd (if you can get to that, there's no open_basedir) and containers a novice sysadmin will publish insecure sites.
These CVSS scores don't mean anything and it would be better for everyone if they stopped showing up in headlines. This is a somewhat situational Wordpress RCE that impacts only a couple themes.
This score specifically means that given some specific conditions, anyone can execute code over the network on a vulnerable WordPress setup. Is this not true?
I'm not saying that the vulnerability isn't severe or important to people running Wordpress, only that CVSS scores are literally a Ouija Board that can come out to whatever the user wants them to.
CVSS scores are literally a Ouija Board that can come out to whatever the user wants them to.
Not really. They are very good at describing the technical impact. Sometimes pre-condition is very rare and that reduces overall likelihood but for those few it applies, the impact still could be catastrophic. Who wants to risk it if whole business could go down?
Published CVSS is a base score that gives you a hint of how important the analysis of a vulnerability is to prioritise the patching or mitigation. What you see on websites is only ever the base spiciness so to speak. If you have for example wordpress only running in an isolated environment behind internal firewall rules you‘d downgrade it accordingly. It’s a imperfect metric but so far the best we have to signal priorities. It’s all described in its spec that no one seems to read and websites also communicate it badly.
These metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user’s organization, measured in terms of complementary/alternative security controls in place, Confidentiality, Integrity, and Availability. The metrics are the modified equivalent of base metrics and are assigned metric values based on the component placement in organization infrastructure.
You need to reason about both probability and impact, not one or the other. In your example, it just means that the probability is very low, perhaps even down to 0 in your specific case. But even at a low probability, the impact of the vulnerability remains very high so it helps you reason about it.
For example, you might react differently to these scores:
- <8/10: check that your systems are indeed secure
- 8.6/10: check that your systems are indeed secure and tell your junior analyst to train on creating a custom monitoring rule for that attack and follow-up with you
- 9.8/10: double-check that your systems are indeed secure, ensure that if you had a hole another security layer would have caught it (if not, that's a problem!), set up a honeypot to get some info on the assholes that have repeatedly attacked you lately and will undoubtedly try to 0-day you in the next few hours, etc.
Yeah give me a vuln and I can make it anything between a 2 and 8 quite easily. I routinely see 10s that are "Critical 10.0 CVE (but only if you're using X language with X setting changed from default, and the attacker can MiTM your traffic)"
This is a somewhat situational Wordpress RCE that impacts only a couple themes.
reply
That is dangerously incorrect, a whole lot of themes are vulnerable. The main pre-condition, "presence of a top-level directory named 'page-xxx' like 'page-templates' in the theme's directory" is actually an official recommendation in the WordPress documentation.
As discussed in Organizing Theme Files, WordPress can recognize page templates stored in the theme’s root folder or in a first-level subdirectory of the theme folder. *The page-templates/ folder is a common convention* for organizing global page templates, but it is not required. Page templates can also be stored in other first-level subdirectories, such as templates/ or page_templates/.
Yeah not sure why you’re being downvoted when the built in themes are vulnerable as is the default docker image pre php8.5 which a lot of people use as a base and I bet a lot of hosting providers use as well behind the scenes.
Not sure if it’s a couple. Devs routinely make heavily edited copies of the core themes so there will be many, many unpublished themes that use the “page-“ prefix for templates; it was (is?) a reasonably common convention.
(No particular disagreement with the rest of your comment though)
Ironically, this 9 years old comment on the official documentation page of one of the affected functions perfectly describes both the nature and remediation of this major security flaw:
Paul Ryan 9 years ago
Note that locate_template() does not prevent directory traversal attacks, so if you’re passing a user-provided template name to the function, be sure to verify that it’s from one of the three appropriate locations (active theme directory, parent theme directory, or /wp-includes/theme-compat/ directory).
Ahahah I remember to have patched themes for clients by hand, years ago. A different time, where a core team would for whatever reason leave security holes around to be sure you need three frameworks around their pile of dung code.
These are the reason, why every easily reachable web server will be spammed with /something/something.php?somearg=someval. If I had to guess, which software on the web has been the most exploitable over all of the web's history, WP would surely be among the top candidates. Maybe right after MS Teams or Sharepoint or some stuff like that.
pearcmd.php must exist, and register_argc_argv must be on, not common with hosting providers. But I am assuming the other themes and meeting conditions possibly affect a lot of WordPress sites.
As the article points out, one issue is that the official Docker container for PHP has this configuration.
However at least in principle all of the affected versions [0] could be automatically updated. Not sure if they have set it to auto-update as far back as 4.7 though.
[0] except 4.9.3 which has a bug in its automatic update mechanism.
pearcmd and register_argc_argv are just examples. get_page_template was unsanitized in some themes, that's the flaw, you could then combine it with one of a million unauthorized file upload in wordpress plugins to try and eval code. An attacker would like to use upload + this chain of requires (instead of just uploading a php) because of hardened configuration and the pwn can go unnoticed in the logs.
Also, with pearcmd (if you can get to that, there's no open_basedir) and containers a novice sysadmin will publish insecure sites.
These CVSS scores don't mean anything and it would be better for everyone if they stopped showing up in headlines. This is a somewhat situational Wordpress RCE that impacts only a couple themes.
This score specifically means that given some specific conditions, anyone can execute code over the network on a vulnerable WordPress setup. Is this not true?
I'm not saying that the vulnerability isn't severe or important to people running Wordpress, only that CVSS scores are literally a Ouija Board that can come out to whatever the user wants them to.
Not really. They are very good at describing the technical impact. Sometimes pre-condition is very rare and that reduces overall likelihood but for those few it applies, the impact still could be catastrophic. Who wants to risk it if whole business could go down?
So if I get a 9.8 that doesn't apply to my usage, what is the CVSS score doing for me?
Published CVSS is a base score that gives you a hint of how important the analysis of a vulnerability is to prioritise the patching or mitigation. What you see on websites is only ever the base spiciness so to speak. If you have for example wordpress only running in an isolated environment behind internal firewall rules you‘d downgrade it accordingly. It’s a imperfect metric but so far the best we have to signal priorities. It’s all described in its spec that no one seems to read and websites also communicate it badly.
Yes. It's amazing how supposedly security professionals only take the base score "as is" and never adjust.
Many GUI CVSS calculators exist just for this, it takes a minute to requalify a vuln and adjust its CVSS based on your specific environment.
This one for example is pretty basic but works well: https://www.first.org/cvss/calculator/3.0
You need to reason about both probability and impact, not one or the other. In your example, it just means that the probability is very low, perhaps even down to 0 in your specific case. But even at a low probability, the impact of the vulnerability remains very high so it helps you reason about it.
For example, you might react differently to these scores:
- <8/10: check that your systems are indeed secure
- 8.6/10: check that your systems are indeed secure and tell your junior analyst to train on creating a custom monitoring rule for that attack and follow-up with you
- 9.8/10: double-check that your systems are indeed secure, ensure that if you had a hole another security layer would have caught it (if not, that's a problem!), set up a honeypot to get some info on the assholes that have repeatedly attacked you lately and will undoubtedly try to 0-day you in the next few hours, etc.
Yeah give me a vuln and I can make it anything between a 2 and 8 quite easily. I routinely see 10s that are "Critical 10.0 CVE (but only if you're using X language with X setting changed from default, and the attacker can MiTM your traffic)"
My assumption is that any Wordpress setup whatsoever allows anyone to execute code remotely.
Indeed, it's a foothold into a network.
That is dangerously incorrect, a whole lot of themes are vulnerable. The main pre-condition, "presence of a top-level directory named 'page-xxx' like 'page-templates' in the theme's directory" is actually an official recommendation in the WordPress documentation.
See here: https://developer.wordpress.org/themes/classic-themes/templa...
Yeah not sure why you’re being downvoted when the built in themes are vulnerable as is the default docker image pre php8.5 which a lot of people use as a base and I bet a lot of hosting providers use as well behind the scenes.
Not sure if it’s a couple. Devs routinely make heavily edited copies of the core themes so there will be many, many unpublished themes that use the “page-“ prefix for templates; it was (is?) a reasonably common convention.
(No particular disagreement with the rest of your comment though)
hmm, this may be why i just saw an unexpected update to a very old theme.
Ironically, this 9 years old comment on the official documentation page of one of the affected functions perfectly describes both the nature and remediation of this major security flaw:
https://developer.wordpress.org/reference/functions/locate_t...
Ahahah I remember to have patched themes for clients by hand, years ago. A different time, where a core team would for whatever reason leave security holes around to be sure you need three frameworks around their pile of dung code.
These are the reason, why every easily reachable web server will be spammed with /something/something.php?somearg=someval. If I had to guess, which software on the web has been the most exploitable over all of the web's history, WP would surely be among the top candidates. Maybe right after MS Teams or Sharepoint or some stuff like that.