The issue of arbitrary code access and execution

  • Another Guy

    (@another-guy)


    11 years, 3 months ago

    Here’s another one to toss out to consider, which is the problem of code being directly accessed and executed, often in things like plug ins and themes (a recurring security nightmare).

    One of the things that made wordpress easy to extend is that coding a theme or a plugin isn’t really that hard – and that these features have full access to “all the toys” as it were without very much control from the core itself. The results are often things like XXS issues, upload plugins that have security leaks and let people upload anything, anywhere, and so on. While most of the security problems are blamed on poor coding or errors made in the process, I think there is perhaps a bigger issue: too many files that can just be called and executed, and that can do too much without dealing with the core.

    I mentioned a while back that I think wordpress needs to move to a more strict API model. I would like to take it one step further, which is to make it so that theme and plugin code is effectively useless without being run by a core handler.

    In practical terms, it would mean that while a plug in might allow you to upload files, the actual upload should be handled in core and properly sanitized and security checked for the protection of the entire installation. So it a poorly written plugin allows someone to upload a.jpg.php file that would be executable, the core would see it and disallow the upload.

    People attempting to access to code directly to force an upload would be stymied because the plugin itself doesn’t actually do the work – it still needs the core. Basically, no function that accesses data, saves or modifies files, databases, or otherwise does anything within wordpress should be handled in the core, and not as a tack on / plug in.

    I would further say it might be time to have things like sliders, genericons, and whatever classes as either plugins or perhaps a new class called “helpers”, added to an installation ONCE and called by themes or plugins that need to use them. One of the true disasters of the recent slider security issue is how many themes had the slider, and that it could be arbitrarily executed even if the theme was not active. Properly squashing that bug involved making sure that any unused themes were deleted from every install. The problem of themes not maintained is a real pain when it comes to common code like this. Again, for security purposes, it might be good to have ways to call these helpers via core, so that their operations could be controlled.

    It’s just a think out loud thing. One suggestion would be to use an encoder / decoder (even base64 or whatever) to make it so that plugins and such can only be exectute by a core controller, rendering them useless to access directly. However, I think that the system load to do this versus the security might not be worth it.

Viewing 4 replies - 1 through 4 (of 4 total)
  • catacaustic

    (@catacaustic)

    11 years, 3 months ago

    While most of the security problems are blamed on poor coding or errors made in the process, I think there is perhaps a bigger issue: too many files that can just be called and executed, and that can do too much without dealing with the core.

    So you want to be able to execute the code without.. executing the code? Core is good and all, but that’s not where all of the processing is done, and you can’t limit processing to core as that’s making WordPress way to restrictive and controlling what people can and can’t do with it.

    it would mean that while a plug in might allow you to upload files, the actual upload should be handled in core and properly sanitized and security checked for the protection of the entire installation.

    Good themes/plugins already do that with the built-in WordPress functions that are available.

    Basically, no function that accesses data, saves or modifies files, databases, or otherwise does anything within wordpress should be handled in the core, and not as a tack on / plug in.

    How would you handle connecting to a remote database to retrieve data that’s outside of the WordPress system? At this point the $wpdb object can do it, and anyone can set up another WPDB object to connect to external databases – and this lets them use all of the available escaping and preparation functions associated with it.

    I would further say it might be time to have things like sliders, genericons, and whatever classes as either plugins or perhaps a new class called “helpers”

    This isn’t a bad idea at all, but needs some thought, and it also would lead to more fragmentation of the ecosystem. Using sliders as an example, there’s already a lot of slider plugins out there, so would a new one be a plugin like the rest, or would it be a helper? Where is the line drawn for differentiating between the two? What would define a helper and what defines a plugin?

    Over all the issue is that you’re dealing with code, and code is made to be run. It’s almost impossible in PHP to block a bit of code from running just because you don’t want it to. As soon as you try that people will jsut find ways around it because they want to have their code run as their code, not from some other “black box” system that they can’t control.

    There are some good points there, but as much as most of us would love a lot of the encapsulation that you are asking for, it’s just not reasonable to do, and in a lot of cases just isn’t possible to do.

    Thread Starter Another Guy

    (@another-guy)

    11 years, 3 months ago

    “Over all the issue is that you’re dealing with code, and code is made to be run. It’s almost impossible in PHP to block a bit of code from running just because you don’t want it to. As soon as you try that people will jsut find ways around it because they want to have their code run as their code, not from some other “black box” system that they can’t control.”

    The balance is allowing people to create plugins that can directly access the entire system, and can interact with it without any supervision. That leads to the inevitable issues with programs that let you upload files but do not properly check and sanitize the inputs, leading to those plugins being able to upload executable files or perhaps to have javascript or whatnot added without due consideration.

    “It’s almost impossible in PHP to block a bit of code from running just because you don’t want it to”

    yet, but it is entirely possible to make it impossible for that code to do anything unless used in context. Almost all of the exploits you see on themes and plugins involve directly accessing a file, which has enough accesses within it’s code to do harm. It’s not a simple concept, but finding ways to make code run only in context would be a major step forward in security.

    Possibly that might involve something like session tracking, or verifying that a plug in or theme is currently active before code can have access to the WP variables. Not permitting the databases to be opened, not populating the WP variables… in a lot of cases that would make many plugins and sections of code just fail harmlessly if directly accessed.

    “Good themes/plugins already do that with the built-in WordPress functions that are available.”

    Hence the problem… perhaps it would be better as part of the process of approving a plugin to be on the wordpress.org list that it in fact conforms and uses appropriate built in functions, and doesn’t go rogue and directly write files and such. It would be a real plus for the community if we could feel that everything we can get here is up to snuff and working in the most secure ways possible.

    “How would you handle connecting to a remote database to retrieve data that’s outside of the WordPress system?”

    Does it matter? The question would be much more about HOW that data is treated as it enters into the wordpress ecosystem and how it is displayed within a wordpress site. If there is something people are going around to avoid the ecosystem, then perhaps it’s something that should be included IN the ecosystem so that it can be properly tested and secured to the higher standards of tested code.

    catacaustic

    (@catacaustic)

    11 years, 3 months ago

    Out of curiosity, how would you block PHP code in a plugin from doing soemthing?

    I have a feeling that you’re trying to get everything to work through core functions only, but as far as I can see at this point, that is an impossible task.

    As an example, say you want to get a posts meta data. There’s already set ways to get that using get_post_meta(), and that is what’s always recommended to use and is secure as it’s core code. You can also use your own SQL query to get the same thing using the $wpdb object, which is sort of through core code. You can also create your own database connection, use your own SQL query and do anything that you want to with in that, and if I’m right, that’s what you are trying to block?

    Thread Starter Another Guy

    (@another-guy)

    11 years, 3 months ago

    Catacaustic, the idea is that plugins (and themes for that matter) should not be able to operate with wordpress files (database, wp-content, and the like) without using the core to do so. $WPDB should be reserved for dealing with OUTSIDE databases and not part of WP itself. At the very most, it should be READ ONLY when it comes to anything related to wordpress.

    Most of the risk of code execution is (a) directly accessing the code, and (b) having the code doing something which is not vetted by the core. Many of the problems relate to functions which manipulate images or allow different forms of uploads to occur without proper vetting. It’s a pretty simple thing, every time you add a function that can directly write files onto a server, you add a level of risk of a coding error leading to a problem, or a lack of sanitizing leading to abuse.

    I understand that you cannot stop people from doing this. It’s their chocie. However, wordpress.org has the choice to allow or not allow plugins and themes to be part of their system (similar to, say, the Apple app store) and can apply standards. Hold the coders to a slightly higher standard, and in turn let the public using these things feel a little more secure in choosing wordpress.org rather than other sources for code.

Viewing 4 replies - 1 through 4 (of 4 total)

The topic ‘The issue of arbitrary code access and execution’ is closed to new replies.