5 ms·

What serious exploits have popped up in WordPress lately?

by rmccue 13y ago

nkuttler 13y ago
I guess http://www.openwall.com/lists/oss-security/2013/06/11/3 http://www.openwall.com/lists/oss-security/2013/06/11/3 isn't serious enought? Oh, right, it's just in some third party code WordPress passes unsanitized data to. I also find it interesting that you as a core dev narrow down possible answers by using "serious" and "lately" in your question. Of course you specifically ask for "WordPress exploits" as well, maybe because themes and plugins run with the same privileges as WordPress core code, and there's no review process for official plugins hosted on wordpress.org? Not to mention from other sources..
- rmccue 13y ago
  To clarify: I'm not part of the core team, I'm just a contributor. (I've also only briefly looked at this issue.) Keep in mind that while I'm an active contributor, I don't speak on behalf of the core/security teams. The aforementioned bug is in the phpass library used in WordPress. As fun as implementing our own cryptography is, we use the phpass library to abstract ourselves from this. Personally, I'd say this is something that phpass should be handling, as the use of crypt_private() is an implementation detail that we shouldn't need to know or worry about. (This is also an issue that affects a small portion of sites, as "Exploitation of this vulnerability is possible only when there is at least one password protected post on the blog.") As to the response from the security team (which is not exactly the core team), that's something I've called them out on before. Security is a serious issue that is usually handled very well on WP's behalf, but there have been a few notable instances lately where it's not. (Also, the reason I "narrow down" the answers is because there are smaller "security" issues that tend to boil down to "admins can do anything", which is intentional.)
  - stephenr 13y ago
    It's not a bug in phpass any more than using a user supplied string as a db query is a bug in MySQL. Wp is/was using the library wrong
- jacques_chester 13y ago
  I hate Wordpress as much as the next fellow, but I'm wary of blaming them for architectural constraints they can't control. Plugins run in the same process, with the same privileges, because there is basically no other way to do it. OK, sure, you can do a kind of kabuki theatre where you present an API and insist plugin authors use it. But then they can access everything anyway and can find the MySQL login details by introspection. So it's pointless. Another reason why I think apps should target virtual machines and be designed from the OS up. In such a design you can isolate plugins as standalone users and standalone processes.
  - stephenr 13y ago
    Plugins can only access "everything" because of the complete lack of architecture or design. Wordpress is a series of ill thought out hacks, extended by other hacks, extended by yet more hacks. Every time one of our WP developers asks me to help with something (usually they assume its a server config issue) I'm astounded at the shit I find when I discover the source of the problem.
    - jacques_chester 13y ago
      Like I said, I don't like Wordpress either. But within the constraints of shared hosting LAMP, guaranteed isolated processes are not possible. PHP adds a lot of introspection, so anything declared anywhere can be read or changed. Wordpress is not alone in this. It's the platform.
      - stephenr 13y ago
        You don't need isolated processes to have better architecture and a sane plugin model.
        jacques_chester 13y ago
        We're still talking about different things. Yes, WP could be better. This is demonstrable from other, better-designed engines within the LAMP/shared constraints. But no such system can prevent any plugins from doing whatever they want to do.

What serious exploits have popped up in WordPress lately?

by rmccue 13y ago

What serious exploits have popped up in WordPress lately?

I guess http://www.openwall.com/lists/oss-security/2013/06/11/3 http://www.openwall.com/lists/oss-security/2013/06/11/3 isn't serious enought? Oh, right, it's just in some third party code WordPress passes unsanitized data to. I also find it interesting that you as a core dev narrow down possible answers by using "serious" and "lately" in your question. Of course you specifically ask for "WordPress exploits" as well, maybe because themes and plugins run with the same privileges as WordPress core code, and there's no review process for official plugins hosted on wordpress.org? Not to mention from other sources..

rmccue 13y ago
To clarify: I'm not part of the core team, I'm just a contributor. (I've also only briefly looked at this issue.) Keep in mind that while I'm an active contributor, I don't speak on behalf of the core/security teams. The aforementioned bug is in the phpass library used in WordPress. As fun as implementing our own cryptography is, we use the phpass library to abstract ourselves from this. Personally, I'd say this is something that phpass should be handling, as the use of crypt_private() is an implementation detail that we shouldn't need to know or worry about. (This is also an issue that affects a small portion of sites, as "Exploitation of this vulnerability is possible only when there is at least one password protected post on the blog.") As to the response from the security team (which is not exactly the core team), that's something I've called them out on before. Security is a serious issue that is usually handled very well on WP's behalf, but there have been a few notable instances lately where it's not. (Also, the reason I "narrow down" the answers is because there are smaller "security" issues that tend to boil down to "admins can do anything", which is intentional.)
- stephenr 13y ago
  It's not a bug in phpass any more than using a user supplied string as a db query is a bug in MySQL. Wp is/was using the library wrong
jacques_chester 13y ago
I hate Wordpress as much as the next fellow, but I'm wary of blaming them for architectural constraints they can't control. Plugins run in the same process, with the same privileges, because there is basically no other way to do it. OK, sure, you can do a kind of kabuki theatre where you present an API and insist plugin authors use it. But then they can access everything anyway and can find the MySQL login details by introspection. So it's pointless. Another reason why I think apps should target virtual machines and be designed from the OS up. In such a design you can isolate plugins as standalone users and standalone processes.
- stephenr 13y ago
  Plugins can only access "everything" because of the complete lack of architecture or design. Wordpress is a series of ill thought out hacks, extended by other hacks, extended by yet more hacks. Every time one of our WP developers asks me to help with something (usually they assume its a server config issue) I'm astounded at the shit I find when I discover the source of the problem.
  - jacques_chester 13y ago
    Like I said, I don't like Wordpress either. But within the constraints of shared hosting LAMP, guaranteed isolated processes are not possible. PHP adds a lot of introspection, so anything declared anywhere can be read or changed. Wordpress is not alone in this. It's the platform.
    - stephenr 13y ago
      You don't need isolated processes to have better architecture and a sane plugin model.
      - jacques_chester 13y ago
        We're still talking about different things. Yes, WP could be better. This is demonstrable from other, better-designed engines within the LAMP/shared constraints. But no such system can prevent any plugins from doing whatever they want to do.