4 ms·

As a WordPress fanatic, I just want to point out that - other than keeping your WordPress Core, Themes and Plugins up to date (which should be obvious by now) -

by dotBen 15y ago

As a WordPress fanatic, I just want to point out that - other than keeping your WordPress Core, Themes and Plugins up to date (which should be obvious by now) - none of the vectors described are actually WordPress related. If you have an insecure password, are running exploitable services/software on your server or your host's support is social engineer-able then you're screwed regardless of what you're running. So can we end this meme, which this post is somewhat fueling, that WordPress is insecure?

comex 15y ago
> other than keeping your WordPress Core, Themes and Plugins up to date (which should be obvious by now) - none of the vectors described are actually WordPress related. Other than two vectors that encompass all possible WordPress vulnerabilities except for 0days, none of the vectors are actually WordPress related? If you want to evaluate WordPress's (or any webapp's) security, the important question is how often critical security updates have to be released - although, ironically, the more such updates there are, the more likely anyone who cares about security is to have a system to promptly apply them, having lots of them still means the webapp is less secure, and that 0days are more likely to be floating around somewhere. (Since I don't use WordPress, I have no idea whether this is actually the case - I'm only pointing out that your argument is not the right way to establish its security.)
patio11 15y ago
There are particular ways in which Wordpress exacerbates this situation. For example, let's say one of your $10 an hour freelance authors uses an insecure password. What happens? Content defacement? Much of the time, the answer is arbitrary code execution, because Wordpress has had copious local-to-Wordpress privilege escalation vulnerabilities and, once they're admin, they can upload arbitrary PHP to your web server straight through the site. Or let's say you allow anybody to sign up and comment on your blog. What's the downside risk, pesky comments? Nope, arbitrary code execution, because anonymous one-off commenters get an admin area and it has had copious local privilege vulnerabilities to turn them into real admins and then it is off to the races. Then there is the XMLRPC library. Wordpress ships with it on by default. What's the risk of leaving it on? Say it with me, arbitrary code execution, because... And PHP encourages you to do includes, including (when an edge case gets missed) inclusions of remote files (!), which puts you at risk of... I mean, I love Wordpress. Never point it at someone you don't want to kill, always treat it like it is loaded, and keep it in a locked case, and you're mostly pretty much safe.
- dotBen 15y ago
  I'm not aware of any unpatched vectors to perform arbitrary code execution in WordPress Core. Sure perhaps via a dodgy plugin (and then ok you could run a SQL query directly to change the privilege level of a given user). XMLRPC ships in an 'off' state in WordPress, and has done for some time now. You need a copy of Dr dotBen's "How I learned to stop worrying and love the WordPress", published by WP Engine! ;)
tptacek 15y ago
Wordpress is insecure. There's not much point arguing about it. You can do things to mitigate the practical impact of its insecure design, but castigating people for pointing out how insecure it is isn't productive.
- dotBen 15y ago
  Actually, simply saying "WordPress is insecure" without reason or explanation isn't very productive at all. WordPress Core has so many eyeballs looking through the code, and some great full-time engineers working on it, that's it's actually very secure. WordPress insecurities mainly occur when you add in badly written plugins - but that's not the fault of WordPress. While I don't want to verge off-topic, that's actually the root cause of most WordPress-related vectors, and so it's sad that the original post didn't really reflect on that more (other than "keep the plugin up to date")
  - tptacek 15y ago
    This is what people said about Sendmail from 1995 through 2006. "Sure, it has a spotty track record, but so many people have looked at it that it must be the safest choice". No. Sendmail wasn't insecure because of how many people were or weren't looking at it; it was insecure because it was neither designed nor implemented for security. The continuous stream of ever-more-interesting remote code execution flaws in Sendmail were just symptoms of those two underlying flaws --- that Sendmail had a design that didn't anticipate hostile deployment environments, and that Sendmail was implemented by a team that wasn't well-versed in secure programming. WordPress has exactly the same problems, and while the pace of security flaws in WordPress has surely slowed, what security researcher believes it has come close to stopping? I stand by this comment I wrote almost two years ago: http://news.ycombinator.com/item?id=1328261 http://news.ycombinator.com/item?id=1328261 Incidentally, "the security of WordPress plugins isn't the fault of Wordpress" is a dodge, because the severity of WordPress plugin flaws is a consequence of the fact that all WordPress plugins are just PHP programs with the same access as e.g. the code that handles site administration. I recommend that people who care about security avoid WordPress, but if you don't want to do that, there are plenty of things you can do to mitigate your exposure. Yelling about whether that exposure exists at all is not one of the things I would recommend.

by dotBen 15y ago

comex 15y ago

> other than keeping your WordPress Core, Themes and Plugins up to date (which should be obvious by now) - none of the vectors described are actually WordPress related. Other than two vectors that encompass all possible WordPress vulnerabilities except for 0days, none of the vectors are actually WordPress related? If you want to evaluate WordPress's (or any webapp's) security, the important question is how often critical security updates have to be released - although, ironically, the more such updates there are, the more likely anyone who cares about security is to have a system to promptly apply them, having lots of them still means the webapp is less secure, and that 0days are more likely to be floating around somewhere. (Since I don't use WordPress, I have no idea whether this is actually the case - I'm only pointing out that your argument is not the right way to establish its security.)

patio11 15y ago

There are particular ways in which Wordpress exacerbates this situation. For example, let's say one of your $10 an hour freelance authors uses an insecure password. What happens? Content defacement? Much of the time, the answer is arbitrary code execution, because Wordpress has had copious local-to-Wordpress privilege escalation vulnerabilities and, once they're admin, they can upload arbitrary PHP to your web server straight through the site. Or let's say you allow anybody to sign up and comment on your blog. What's the downside risk, pesky comments? Nope, arbitrary code execution, because anonymous one-off commenters get an admin area and it has had copious local privilege vulnerabilities to turn them into real admins and then it is off to the races. Then there is the XMLRPC library. Wordpress ships with it on by default. What's the risk of leaving it on? Say it with me, arbitrary code execution, because... And PHP encourages you to do includes, including (when an edge case gets missed) inclusions of remote files (!), which puts you at risk of... I mean, I love Wordpress. Never point it at someone you don't want to kill, always treat it like it is loaded, and keep it in a locked case, and you're mostly pretty much safe.

dotBen 15y ago
I'm not aware of any unpatched vectors to perform arbitrary code execution in WordPress Core. Sure perhaps via a dodgy plugin (and then ok you could run a SQL query directly to change the privilege level of a given user). XMLRPC ships in an 'off' state in WordPress, and has done for some time now. You need a copy of Dr dotBen's "How I learned to stop worrying and love the WordPress", published by WP Engine! ;)

tptacek 15y ago

Wordpress is insecure. There's not much point arguing about it. You can do things to mitigate the practical impact of its insecure design, but castigating people for pointing out how insecure it is isn't productive.

dotBen 15y ago
Actually, simply saying "WordPress is insecure" without reason or explanation isn't very productive at all. WordPress Core has so many eyeballs looking through the code, and some great full-time engineers working on it, that's it's actually very secure. WordPress insecurities mainly occur when you add in badly written plugins - but that's not the fault of WordPress. While I don't want to verge off-topic, that's actually the root cause of most WordPress-related vectors, and so it's sad that the original post didn't really reflect on that more (other than "keep the plugin up to date")
- tptacek 15y ago
  This is what people said about Sendmail from 1995 through 2006. "Sure, it has a spotty track record, but so many people have looked at it that it must be the safest choice". No. Sendmail wasn't insecure because of how many people were or weren't looking at it; it was insecure because it was neither designed nor implemented for security. The continuous stream of ever-more-interesting remote code execution flaws in Sendmail were just symptoms of those two underlying flaws --- that Sendmail had a design that didn't anticipate hostile deployment environments, and that Sendmail was implemented by a team that wasn't well-versed in secure programming. WordPress has exactly the same problems, and while the pace of security flaws in WordPress has surely slowed, what security researcher believes it has come close to stopping? I stand by this comment I wrote almost two years ago: http://news.ycombinator.com/item?id=1328261 http://news.ycombinator.com/item?id=1328261 Incidentally, "the security of WordPress plugins isn't the fault of Wordpress" is a dodge, because the severity of WordPress plugin flaws is a consequence of the fact that all WordPress plugins are just PHP programs with the same access as e.g. the code that handles site administration. I recommend that people who care about security avoid WordPress, but if you don't want to do that, there are plenty of things you can do to mitigate your exposure. Yelling about whether that exposure exists at all is not one of the things I would recommend.