5 ms·

Now of course it was improper to reveal this before informing WooThemes, so they can patch it and inform their users before this hole gets exploited on a massiv

by rickmb 14y ago

Now of course it was improper to reveal this before informing WooThemes, so they can patch it and inform their users before this hole gets exploited on a massive scale. But just look at the code itself. Does this look like the authors even give a crap about security? Or half decent code in general? Those 3 lines of code alone make me cry, and it pretty much screams "potential security issue". This kind of crap is endemic in the WordPress ecosystem, and virtually every theme and plugin is a security hole waiting to be exploited. Now if you're sharing your code freely that's one thing, but these guys run a business and are asking money for this. One of their selling points, the first on their homepage: "Solid Code Framework". Seriously.

masklinn 14y ago
And one of the authors commented the issue was patched... apparently discretely without notifying any user that they're at risk.
- marklindhout 14y ago
  All the glory of closed source development back in action!
- damncabbage 14y ago
  Apparently it wasn't fixed (or at least the fix hasn't been released to customers yet): https://gist.github.com/2523147#gistcomment-288527 https://gist.github.com/2523147#gistcomment-288527 (Gist author posts a longer explanation, and mentions this as part of his message.)
  - jasongill 14y ago
    It appears that they wrote a fix but then (the next day, I believe) had their server troubles. During that mix-up, the file which alerts the theme that there is an update was broken, so their patch basically hasn't "been released" to their existing customers yet.
Michiel 14y ago
"WordPress installations with unsecured shortcodes (such as [php] which allows raw PHP code to be run) are vulnerable to serious attacks if WooThemes are installed..." (emphasis mine) Wow, I had no idea that was even possible, but on the surface it seems incredibly stupid to allow an editor to add server-side code to content in a CMS.
- patio11 14y ago
  Welcome to WordPress! + Marvel at the efficiency where anonymous subscribers are stored in the same database table as all-powerful system admins, which makes it much easier to upgrade anonymous Internet commenters to admins using local privilege escalation. + Enjoy at least five different ways to execute arbitrary code against the server from the admin console. For added fun, they're secured independently from each other! + Stop wasting time with fine-grained permissions models: all plugins/themes get unrestricted read/write access to the database and arbitrary code execution by default. + Experiencing a shortage of qualified engineers? No problem! We've lowered barriers to contribution so much that a significant portion of the community output has been made by people who know just enough PHP to eval($_GET["something"]). You'll find them in our semi-curated plugin/themes lists, sorted by star rating, with easy one-click access for admins to install on your server. (I actually like Wordpress, but certainly not for its security record.)
  - ceol 14y ago
    Wordpress requires a single database user that has CRUD access to the entire thing, so I'm not sure how you could benefit by separating admins and commenters. Could you give an example? I agree with your comment, though. Wordpress has poor coding practices built into the core (arguably like the language it's written in).
    - patio11 14y ago
      Happy to elaborate. Here's the way NOT to do it: Bingo Card Creator has a single users table with a role attribute. Setting role to "admin" makes your account into me. This is dangerous because it increases the damage someone can do with other attacks -- if, for example, I was bitten by the (common to Rails applications) vulnerability of letting users' profile pages reassign roles on update due to a mass assignment vulnerability, that would cough up everything my web app can do. WordPress has the same pattern, which means any of the (historically quite common) ways to convince WP that the logged in user is_admin() mean you can go to town on the software. This is made more problematic because, as noted, WordPress gives admins arbitrary code execution. There are smarter ways to do this for y'alls own software, by the way. Probably the gold standard is: + keep the admin functionality in an entirely separate application at admin.example.com rather than example.com/admin/ + enforce a strict access policy to the admin application at the network level. Probably the most straightforward is firewalling the admin app from the outside world -- the only way to get to it would be e.g. VPNing into the local network. That would probably not be a viable option for WordPress, but you're free to not have the security of your businesses informed by WordPress' hard requirement that anybody be able to install the software within 5 minutes and have it work magically.
cheez 14y ago
PHP is an abbreviation for Pretty Horrible Everything.

by rickmb 14y ago

masklinn 14y ago

And one of the authors commented the issue was patched... apparently discretely without notifying any user that they're at risk.

marklindhout 14y ago
All the glory of closed source development back in action!
damncabbage 14y ago
Apparently it wasn't fixed (or at least the fix hasn't been released to customers yet): https://gist.github.com/2523147#gistcomment-288527 https://gist.github.com/2523147#gistcomment-288527 (Gist author posts a longer explanation, and mentions this as part of his message.)
- jasongill 14y ago
  It appears that they wrote a fix but then (the next day, I believe) had their server troubles. During that mix-up, the file which alerts the theme that there is an update was broken, so their patch basically hasn't "been released" to their existing customers yet.

Michiel 14y ago

"WordPress installations with unsecured shortcodes (such as [php] which allows raw PHP code to be run) are vulnerable to serious attacks if WooThemes are installed..." (emphasis mine) Wow, I had no idea that was even possible, but on the surface it seems incredibly stupid to allow an editor to add server-side code to content in a CMS.

patio11 14y ago
Welcome to WordPress! + Marvel at the efficiency where anonymous subscribers are stored in the same database table as all-powerful system admins, which makes it much easier to upgrade anonymous Internet commenters to admins using local privilege escalation. + Enjoy at least five different ways to execute arbitrary code against the server from the admin console. For added fun, they're secured independently from each other! + Stop wasting time with fine-grained permissions models: all plugins/themes get unrestricted read/write access to the database and arbitrary code execution by default. + Experiencing a shortage of qualified engineers? No problem! We've lowered barriers to contribution so much that a significant portion of the community output has been made by people who know just enough PHP to eval($_GET["something"]). You'll find them in our semi-curated plugin/themes lists, sorted by star rating, with easy one-click access for admins to install on your server. (I actually like Wordpress, but certainly not for its security record.)
- ceol 14y ago
  Wordpress requires a single database user that has CRUD access to the entire thing, so I'm not sure how you could benefit by separating admins and commenters. Could you give an example? I agree with your comment, though. Wordpress has poor coding practices built into the core (arguably like the language it's written in).
  - patio11 14y ago
    Happy to elaborate. Here's the way NOT to do it: Bingo Card Creator has a single users table with a role attribute. Setting role to "admin" makes your account into me. This is dangerous because it increases the damage someone can do with other attacks -- if, for example, I was bitten by the (common to Rails applications) vulnerability of letting users' profile pages reassign roles on update due to a mass assignment vulnerability, that would cough up everything my web app can do. WordPress has the same pattern, which means any of the (historically quite common) ways to convince WP that the logged in user is_admin() mean you can go to town on the software. This is made more problematic because, as noted, WordPress gives admins arbitrary code execution. There are smarter ways to do this for y'alls own software, by the way. Probably the gold standard is: + keep the admin functionality in an entirely separate application at admin.example.com rather than example.com/admin/ + enforce a strict access policy to the admin application at the network level. Probably the most straightforward is firewalling the admin app from the outside world -- the only way to get to it would be e.g. VPNing into the local network. That would probably not be a viable option for WordPress, but you're free to not have the security of your businesses informed by WordPress' hard requirement that anybody be able to install the software within 5 minutes and have it work magically.

cheez 14y ago

PHP is an abbreviation for Pretty Horrible Everything.