No one expects the spanish inquisition and no developer expects that parsing data by itself can lead to a security weakness, but still PHP is always happy to help you have an interesting life.
So what is the problem with json_decode? the problem is that with a properly crafted JSON structure an attacker can force a very slow parsing of the JSON and hang up the CPU. The weakness comes from the way PHP internally stores arrays in memory that in the normal use case is very fast to access and retrieve data, but the worst case is horrible and json_decode by default tries to create an array from a JSON string, Not sure if the object option of the API is any better.
Mitigation? It doesn’t seem like you can guess anything about the content/structure of a JSON string without actually parsing it therefor it is probably a good idea to check that the length of the input “make sense” before processing it.
There is an exploit that can hit only those that know how to use linux to manage their site. Apparently linux editors store a backup copy of the file being edited in the same directory of the file. Therefor when a config file is being edited a copy of it is created, and since the names the editor gives to the backup files is predictable, and usually accessible as plain text from the web, all the data in the config is exposed at edit time. It is even worse if the editor failed to erase the backup after editing was finished.
Therefor you either should not edit config files locally, but transfer them over FTP, or put then in an inaccessible location (If wordpress is installed at the root directory you can put the config file at the usually inaccessible directory above it) or replace the config script with a script that read the config, or the secret parts of it from other location.
The news are that twitter got hacked and up to 250k user accounts where compromised. I’m not a real user of twitter although I have an account, so I might be wrong but in my opinion no one will feel extremely sad if some of his mental farts will be deleted or changed. Content on twitter, by the nature of the service that focuses on real time updates, is just not important enough in the long run.
But…. twitter is also a leading identity authentication provider on the web. If my twitter account was compromised it means that for a while the hacker had access to all the sites to which I have registered with my twitter account. It is hard to generalize how much cascading damage can follow from the hacker using my account, but it is not nice to even think about it. Twitter didn’t disclose the nature of the information to which the hacker got access, but I truly hope they don’t have a log of the sites to which I authenticate myself using my twitter account.
Yeh, the best that you can do is not to display them. All the site wide and per post options control whether the pingback/trackback will be stored in the DB, but the piece of code handling pingbacks from reception till checking if to put them in DB will always be executed.
This is probably not a big thing as I don’t remember exploits utilizing pingbacks, but it annoys me esthetically that an option described “Allow link notifications from other blogs (pingbacks and trackbacks.) ” doesn’t do what can be interpreted from the description (what it does is to set the default of the ping option on the post edit page).
xml-rpc protocol is basically used to expose a set of API implemented by a site/server which enables other software to interact with the site/server in a way which is easier to program then trying to mimic user interaction. WordPress currently (version 3.5) expose API for publishing pingbacks, and content. Software like windows live writer by Microsoft uses the content publishing API supplied by WordPress to create a non browser editing environment, but the main users of the protocol right now are smartphones because the small screen size makes the WordPress web interface almost unusable.
Upto WordPress version 3.4 the remote publishing by XML-RPC was disabled by default, and the text explaining the option in the admin was technical and said nothing about smartphones.
With the rise of smartphone use, and the number of smartphone apps that use XML-RPC to publish content to wordpress, it is only a logical move to enable XML-RPC by default, but the development moto of “decisions not options” was taken too far as in this case the option has enough importance to justify having it.
The reasons are mainly security related
- It doesn’t matter how robust is WordPress code there is always a chance of a security bug that might relate only to the XML-RPC code
- Plugin authors will probably start supporting XML-RPC opening more attack vectors, and user will not even know about it because it will not have any GUI indication, and you will not know that unless you read the plugins documentation.
- There is no knowledge base on how to defend against brute force/dictionary attacks from XML-RPC. Current plugins might work,but will they give you a notice like “You failed to login 3 times, please wait 5 minutes till the next attempt” on the XML-RPC layer, and how the app will display that notice?
It might be that core developers are right and there is no risk added by having XML-RPC on all the time, but I think that a more conservative two step approach like
- Make it default to on, leave the option in the admin
- In two releases look at the experience of running WordPress that way and decided whether to eliminate the option as well
The reason it should work that way is that most user just leave the default setting on, so there will be a big enough user base to field test the feature even when the option to turn it off exist.