What is root cause of this vulnerability? The fix looks strange, it filters “bad” requests instead of fixing vulnerable parts of code. Maybe it’s urgent fix before actually fixing underlying bugs, or it’s done to not disclose actual bugs too early?
I don’t know much about practices of fixing urgent vulnerabilities in popular projects, is it common practice to add fixes like this to not disclose root cause early?
In Drupal a commonly used coding convention throughout the api is to pass information state around in arrays. Notable, for page rendering, but also for Form processing and state.
Array keys are used to denote either data or function chains to call to pre/post process the array packaged data. Special keys starting with # symbol denote internal-use api keys. But any programmer is free to add/modify #keys as they need for their own business logic.
Various sub systems of Drupal take (user) inputs and pack into these arrays … It appears as care was not taken to assure malicious
#key values are not added into arrays – possibly allowing RCE.
There is no excuse these days not to have an autoupdating CMS. Even Wordpress has that (well, until Wordpress was Wordpress and they broke the autoupdater in a patch release, but I digress).
I dunno. Giving an application (Wordpress, Drupal, etc) with a fucking atrocious security history, permission to overwrite it’s own files doesn’t seem that smart to me.
Autoupdates but no cryptography, https, made by the worst PHP developers on the planet.
Autoupdates, no cryptography or https, made by competent developers
Autoupdates, no cryptographical signing over https, made by competent people
Autoupdates, cryptographically signed updates delivered over https prepared by competent people
Autoupdates, reproducible builds / updates with cryptographically signed updates delivered over https with a transparent and well designed/documented process made by competent people
If the app server (eg either php-fpm or apache w/mod_php) has write permissions to the files it executes, and an attacker finds an RCE vulnerability, all the reproducible builds in the world won’t help the average joe whose site just got hosed or compromised to serve malware or whatever.
remote code execution is also pretty bad without the app server having write permission on the files and - given the way most Wordpress plugins, for example, are developed - there will be RCE opportunities. Auto upgrades greatly decrease the chance that those will be exploited in the wild. So sadly it’s a tradeoff which makes sense for the target audience. i.e hobby sites and businesses on shared hosting or so, without a dedicated ops team.
What is root cause of this vulnerability? The fix looks strange, it filters “bad” requests instead of fixing vulnerable parts of code. Maybe it’s urgent fix before actually fixing underlying bugs, or it’s done to not disclose actual bugs too early?
I don’t know much about practices of fixing urgent vulnerabilities in popular projects, is it common practice to add fixes like this to not disclose root cause early?
In Drupal a commonly used coding convention throughout the api is to pass information state around in arrays. Notable, for page rendering, but also for Form processing and state.
Array keys are used to denote either data or function chains to call to pre/post process the array packaged data. Special keys starting with
#symbol denote internal-use api keys. But any programmer is free to add/modify #keys as they need for their own business logic.Various sub systems of Drupal take (user) inputs and pack into these arrays … It appears as care was not taken to assure malicious #key values are not added into arrays – possibly allowing RCE.
There is no excuse these days not to have an autoupdating CMS. Even Wordpress has that (well, until Wordpress was Wordpress and they broke the autoupdater in a patch release, but I digress).
even? I don’t see too many CMS nowadays, but isn’t that an almost unique feature of Wordpress? Which other CMS do support auto updating functionality?
And Wordpress auto-updating supports only Wordpress itself, no plugins or themes.
I dunno. Giving an application (Wordpress, Drupal, etc) with a fucking atrocious security history, permission to overwrite it’s own files doesn’t seem that smart to me.
It’s a hierarchy (from worst to least worst)
Tag yourself ;)
That isn’t least worst. “Auto update” implies the software can overwrite itself. That’s the whole problem.
It isn’t that much of a problem if one is able to verify the modifications, i.e. by using reproducible builds and update them in place.
If the app server (eg either php-fpm or apache w/mod_php) has write permissions to the files it executes, and an attacker finds an RCE vulnerability, all the reproducible builds in the world won’t help the average joe whose site just got hosed or compromised to serve malware or whatever.
remote code execution is also pretty bad without the app server having write permission on the files and - given the way most Wordpress plugins, for example, are developed - there will be RCE opportunities. Auto upgrades greatly decrease the chance that those will be exploited in the wild. So sadly it’s a tradeoff which makes sense for the target audience. i.e hobby sites and businesses on shared hosting or so, without a dedicated ops team.
Cloud computing