views:

78

answers:

3

Hey all,

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('/')

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

+3  A: 

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.

Alix Axel
Oh haha okay.. I saw it somewhere and it looked bad, so I took a chance and included it in the post. Anyway, thanks for your insight!
Matt
+1 Yup, there is no way to protect a WordPress installation from a runaway plugin. What Wordpress has access to, the Plugin has access to. Things like `safe_mode` and the blocking functions can only be set up to affect the whole installation, not a part of it. Download only from sources you trust, and possibly do a quick audit for suspicious `eval()` s and other things, is the best one can do.
Pekka
@Pekka, you're the man - you're always helping me with my questions. Thanks!
Matt
Yep, this post is correct. I have no idea why mattbasta got the check for this.
Rook
+5  A: 

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!

mattbasta
Awesome! Thanks a lot - this is incredibly helpful! I'll definitely check out the validator, thanks!
Matt
@The Rook: This is why I said "You can't do this programmatically". So many things can affect the function of the code, that the best you can hope for is a decent first-pass that scans for obvious things before the actual code is passed along to human editors.
mattbasta
@mattbasta That is interesting, I didn't read your post very carefully. Although I saw how some Mozilla developers reacted to a talk at Defcon about hacking Mozilla plugins, basically they shrugged it off and sad it wasn't their fault and rejected the idea of limiting plugin's access privileges. I'm using chrome now.
Rook
@The Rook: I can't speak for the other developers, but we're in a position where addons.mozilla.org is the "clean zone" for add-ons. We run a software-based cleanliness check and then follow that up with a fine-tooth review by an actual human before the add-on gets accepted. Granted, Chrome extensions are inherently more secure, though the types of extensions you can build with Chrome are much less sophisticated. Also--for the record--I run Chrome, too ;)
mattbasta
@mattbasta The problem of plugins creating security problems is a big deal for a lot of software packages. At first I thought you where marginalizing the scope of the problem. Now I realize you are on the cutting edge, and the clean zone is a great idea. (+1)
Rook
@mattbasta btw the defcon talk is "Abusing Firefox Addons" and can be found here: (https://www.defcon.org/html/links/dc-archives/dc-17-archive.html#Liverani)
Rook
+1  A: 

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]`;
Rook