Support » Requests and Feedback » Negative although honest feedback : wordpress still generates systemwide risk

  • Hello,

    Two years ago, I posted this discussion :
    (that was under a previous account, based on a dead email so I couldn’t recover its password once I forgot it)

    In short, I was telling that the wordpress (.org, I’m not talking about .com’s unencrypted cookie recent headlines) way of dealing with security wasn’t fit for a piece of software installed on MILLIONS of web servers and having a MASSIVE global impact.

    My point was : wordpress will *not* notify the blog administrators when one of the blog’s plugins or themes is removed from the official repository.

    And yet, the only reasons for such a plugin or a theme to be removed from the repisitory are :
    – prolungated state of neglect, which is the open door to exploitable code
    – recognition there is already an exploitable code within the plugin/theme
    – intolerable behaviour hard-coded inside the plugin/theme

    We’ve made progress from my thread creation two years ago, still, as I saw wordpress update itself for security releases, just a month ago, huge props for this !

    However, the plugins/theme issue remains.
    Can you imagine the number of poorly maintained blogs, for which the only reason the admins will run an update is if they receive a clear and strong private message (I suggest : both in header on every page of the blog administration panel, and with an email sent to the admin account’s email address) to tell an action is required “right now”.
    Can you imagine the systemwide negative impact it has in terms of security, the greater number of bots that means ?

    Well, that was for my point.
    I hope my feedback may not piss off too much the concerned persons, I’m trying to help improve things within the very limited extent of my ability 🙂

Viewing 9 replies - 1 through 9 (of 9 total)
  • We know.

    And I know how crappy an answer that is, but the issue is actually technical :/ We need to make some improvements on the backend for this to work, and if you think about it, the auto-update feature of core is one of them.

    But yes, we are well aware this isn’t a great way to handle it, and we are trying to come up with a solution that would

    (a) inform people “this plugin was removed”

    (b) tell them WHY (sometimes we pull them because they’re not supported anymore, sometimes they violate other rules like powered-by links)

    (C) allow them to auto-upgrade any security issues

    (d) Do all this in a way that doesn’t slow your site down (or .org) when it checks

    (e) doesn’t conflict with self-hosted plugins (or ones you may have written yourself)

    Whew. Oh and we totally have to build the backend on .org to support that FIRST.

    But yeah, this is something that need a lot of concentrated work :/

    Oh WordPress has bigger problems than that. They are more worried about a 5 minute install than actual database security for an application that will run for years after the 5 minute install.

    It needs to have different DB users for different tasks, not one all powerful user that can do anything and everything on any table in the database.

    One bad plugin with an SQL injection hole and the whole damn thing is compromisded. Running wordpress is just like running your linux box as root all the time.

    That’s why I refuse to run wordpress on any website I admin. I’ll fix bugs in plugins for people, but I refuse to run it as long as they are more interested in a fast easy install than a secure database scheme.

    @ipstenu : thanks for the reply, at least, it’s reassuring you know it’s an issue.

    However, since it’s been more than two years (likely more) and it’s not getting close to being done, this leaves the systemic responsability issue live.
    In this regard, how about placing this plugin :
    among the recommended, the highlighted plugins ? This “Secure” plugin features most of the things that would be expected from the core of wordpress. It’s true that it’s backed by a commercial firm, but it seems their plugin works free from boot and won’t bother the users with “money pleaaaase !” requests.

    @alice : if all your websites are running under the same username or a single username is able to access PHP rights for every process, then you were doomed even before wordpress was installed.
    Although, now that you mention it, it sure would be goddamn cool to have database access restrictions, with a distinguo between the core and the post contents. But that requires rights (database username management) that are alien to wordpress itself, I guess that could be enough reason not to blame WP for this.

    AliceWonderFull – Can you name another widely-used PHP-based CMS system that uses different DB users with different roles?

    At this point I can’t think of any. Drupal, Jooomla, etc don’t do that. Even the big e-commerce systems like Magento and Prestashop where there are commercial and enterprise versions don’t do that.

    I’m also concerned that you think that running a database as a privilidged user is the same as running root in *nix all the time. There’s a great deal of things a root user can do that a database user can’t, and anything that the database user is allowed to do is limited to the database that they have permission set for. That user can’t touch any other part of the system.

    You do have a point that it can be done differntly, but in reality how many people that install WordPress are going to know how to set differing permissions for different DB users – most don’t have any idea of what a DB user is in the first place, and won’t ever want to learn. Security like that is all well and good, but if you wanted to implement that you’d loose something like 99% of your standard user codebse and have WordPress useful only by experienced developers.

    It is the same as running as rooy.

    With database driven content systems, the database is everything. With one database user that has permission to everything and every database query runs as that all powerful user, the application is vulnerable from a design point, especially when it is possible to make queries that aren’t via prepared statements – as many php coders learned to do because MySQL did not even support them early on in the LAMP boom.

    You don’t have to lose 99% of your users. Two database users is usually enough, one for sensitive data (like login passwords, configuration options, e-mail addresses, etc.) and one for stuff like user comments.

    That way when the second is used with an un-safe query, the cracker can’t dump your sensitive data or screw with your site configuration, because the db user used for the leaky query doesn’t have the permission to.

    Its not the same as running root.

    Running as a user with full permissions over that database gives that user permissions over that database. Running as root gives you permission over every database. See the difference? I know that you’re only talking about it from a completely singular point of view, but that’s not being realistic.

    Trying to use two databases comes back to my initial argument. What other CMS system does that? I’m sure that there are some specially-devleoped ones that have that ability, but nothing out there now that’s open-source, widely used and available to the general public has any of the features that you’re saying should be manditory.

    I do understand your position, and I do agree that security is important. But I do also understand that by the time a hacker has access to one database, it’s not that hard to get access to another one. The configuration to connect to both databases has to be stored somewhere, so finding it for the second one will be trivial after finding it for the first one. If you’re working on the assumption that the hacker could break into the code, then it works the same. They’ll have access to both as the”more secure” DB connection will need to be available to access site configuration. As for queries… If developers aren’t doing the right thing to correctly escape any varlues that they are using, then they won’t be doing that for either DB, so it’s just as easy to send an unsafe query to either DB.

    Obviously I’m not talking about every database, I’m talking about the scope of the web application platform – wordpress – a CMS used to run your business.

    It is ridiculous that the same DB user that executes the request from an anonymous person anywhere on the web has the authority to read every table, delete every table, insert into every table, on the CMS platform.

    The more I am reading about WordPress the worse its security model seems. For example, it looks like all Ajax requests are handled in the admin context whether or not the request was sent with a cookie that authenticates the user’s session as an admin session.

    As I’ve asked before, what other PHP-based CMS out there today does what you’re asking for? I know that both Drupal and Joomla don’t have that sort of functionality. Even if you know of something that’s even sort-of-widely used that’s not PHP, I still haven’t seen any popular CMS that uses two or more database users for different queries. Is there some system that you’re thinking of that I’m not guessing here?

    You are partly right about AJAX requests. If you have a look at you’ll see that while AJAX commands are normally done thorugh the admin area, they don’t have to be. But all AJAX requests through the admin area are authenticated to ensure that there’s a logged in user, and it’s up to the developer to determine if that user has the permissions set to perform the action that’s been requested. And, again that comes down to the developer that’s coding the theme/plugin. If they don’t do it the right way it’s not a fault of WordPress.

    @sabinooo – actually we are WAY closer to solving it than we were 2 years ago. You can’t see it, but I promise we are 🙂

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘Negative although honest feedback : wordpress still generates systemwide risk’ is closed to new replies.