Reduce chances of PHP plugins being malicious

1 Views

I was wondering what steps you use to keep downloaded plugins from being malicious?

For example, what does wordpress do to ensure that the plugins you download do not simply execute unlink('/')

Read More

I’m assuming it partly depends partly on downloader to install plugins to use his or her own discretion, but do plugin systems take measures to minimize the security risk of running 3rd party plugins?

Thanks!
Matt Mueller

Post Views: 1

Related posts

Leave a Reply

3 comments

  1. Simple answer: you can’t do this programmatically. Simply can’t be done. Certainly WordPress has a validator of some sort to determine whether the plugin is outright nasty, but there’s no way to say for certain that it is safe.

    I’m an intern at Mozilla this summer and I’m working on the validator that scans add-ons as they’re submitted to addons.mozilla.org. I can only imagine that WordPress has a very similar tool on their end. The idea is that the app outright rejects blatantly malicious code (eval("evil nasty code");), while the rest of it is analyzed with some simple heuristics. The algorithms in place mark down some potential red flags based on what it sees in the add-on package and submits those notes to the editors, who then review the code. It effectively ends up being a human-powered process, but the software helps to take care of a lot of the heavy lifting.

    Some techniques that the Mozilla validator uses:

    • Syntax checking
    • Code and markup parsing (HTML/CSS) to find remote code vulnerabilities
    • Javascript parsing and analysis (parse the JS to an AST tree and analyze each statement, evaluating static expressions as deeply as possible)
    • Compatibility/deprecation testing

    You can check out the code here:

    http://github.com/mattbasta/amo-validator

    Hope this helps!

  2. unlink('/') wont do any harm since it only deletes files, you would have to use rmdir or more precisely a recursive rmdir implementation. I don’t think there is any way to prevent malicious code from being executed because there are many ways of being malicious. You can restrict certain functions from being called in php.ini but that will only help you to a certain point. For instance, str_repeat and unserialize are common functions but if called with the right arguments they can exaust all the memory allocated to your PHP scripts in no time. But this is only an example, a more nefarious one could act as a backdoor or email all the logins to the developer. I guess in the end you’ll have to trust the developer and the community if you don’t want to audit the code by yourself.

  3. There are tools for PHP that do Static Source Code Analysis in order to find vulnerabilities. Open source analysis tools for php include RATS and PHP-SAT.

    If you have ever used a Static Source Code Analysis then you know that these tools will produce a TON of false positives and false negatives. No Source Code Analysis tool can tell you 100% weather or not a program has a backdoor or can be malicious. If it could then we wouldn’t have so many problems with websites getting hacked. WordPress its self is extremely insecure, so are all of the plugins, and this is because of mistakes, not malice.

    Malicious code can be obfuscated, hidden and take on many many forms. Trying to find an accidental vulnerability is a whole lot easier problem than an intentional one. A backdoor in PHP can be as simple as adding or removing 2 bytes.

    Removing 2 bytes:

    $id=mysql_real_escape_string($id);
"select * from test where id=$id"
vs
"select * from test where id='$id'"

    or adding 2 bytes:

    `$_GET[b]`;