Schinckel.net

Over on Neo Security Team, some guy whose Engrish is teh bom writes about supposed vulnerabilities within WordPress 2.0.1 and below. I’ll detail each of them, and how real I think they are. Firstly, all of them seem to be JavaScript related. That affects me, as I require JavaScript for commenting, which implies I want users to have JavaScript turned on. First potential issue:

‘name’ variable is not filtered when it’s assigned to ‘value’ on the <input> in the form when the comment it’s posted.

I’ll assume he means that when the comment is posted. Let us test that. Nope, this is not true. When using the normal comment posting form (i.e. the individual post page) all fields are stripped of HTML, except the Comment field (see below). In fact, this problem is no more or less serious than number 2, below. It is the same problem! This problem also exists for URL field, and possibly email field (although this is generally not shown in a blog comment, as it’s a bit of a Spam magnet.

Second potential issue:

‘comment’, this variable only filtered “ and ‘ chars, this makes possible to use < and >, thus this permit an attacker to inject any HTML (or script) code that he/she want but without any “ or ‘ character, this only happends if the user that post the comment it’s the admin (any registered kind of ‘user’).

I’ve confirmed this, even though it’s not really clear what this person is saying. If you post a comment, then all <script> tags are stripped. However, if you edit a comment, you can insert HTML. I think this is what the author means. Short answer - don’t allow other users to register. That is an absolute fix. Casual commenters cannot cause this bug. In fact, this trick could be used to great effect: the script would be run by an admin trying to delete the comment, too! Again, the best way to avoid these issues is to not allow people to register as users, as they then would not be able to edit comments. Incidentally, the fixes they suggest would either not fix the problem, or in fact remove the ability to have any HTML in any comments. Since I want people to be able to style their own comments, this is not acceptable. WordPress already has some method of filtering out ‘nasty’ HTML - lists, images and scripts are not allowed in comments, for instance. Surely these same filters can be used when an admin edits a comment, too? A much better solution!

Third issue:

Full path disclosure & Directory listing When I discovered this bug, I reported it to some pepople before public disclosure, I was noticed that this isn’t new and I decided to look why they haven’t patch this bug. As this bug it isn’t patched yet, I tryed to know why and I found something like this in their forum (I don’t know if the person that posted this was the admin but it gives the explanation): (Something like the following, it’s not textual). ‘… these bugs are caused by badly configured .ini file, it’s not a bug generated by the script so it cannot be accepted as a bug of WordPress…’. This is not an acceptable answer, if you think it is, a bug caused because of register_globals is Off it’s .ini fault and not the script, they have to be kidding, if they want to make good software, they have to make as far as the language can, to prevent all bugs. There’re multiple files that don’t check if they are been call directly. This is a problem because they expect that functions that the script is going to be called to be declared. This kind of bug it’s taken as a Low Risk bug, but it can help to future attacks.

This took me ages to figure out what they meant - apparently files can be accessed directly if you know the URL. For instance: http://www.victim.com/wordpress/wp-includes/ Actually, this is more of an http rewrite issue - and as such, specifically does not affect Blogsome. And even if it did, I’m not really sure it could do much harm. I might be wrong about that, but I’m almost certain that Blogsome is immune to this, since every URL that Blogsome serves from each blog doesn’t directly access the source files, but goes through the database.