[wp-testers] Re: Bugs/Fixes, Security Requests

[g30rg3_x]

Well about the Security Requests...

I have been trying to promote this idea/change since almost 2 years[1]
but even if we change the perspective of the problem this change isn't
going to happen... even that exist a variation of the version
enumeration[2] (introduced in milestone 2.6) that makes every
plugin-based solution totally ineffective (example[3]).

As for user enumeration on login, well you can still hide that
messages truth the login_errors filter but you can still enumerate
users via /author/<username>, which also can prevented by changing
(directly in the BD) the user_nicename to something different to the
user_login.

As and example: i have my own personal/private plugin which contains
all this changes (plus one more), you can view it here[4], as you can
see is fairly simple what the plugin does, just as remind about the
version hidden: its changed only inside the admin panel so in order to
fully work you would need to first change the version number on
wp-includes/version.php to something different to real version.

However i must notice that this modifications won't enhance your
wordpress-based site security, they would make just the exploitation
of _critical_ vulnerability more hard (but just a little), a good
cracker can still be very dangerous even if you hide your version and
other sensitive information, so the best advice is always keep up to
date your WordPress based-site.

Regards

[1] http://trac.wordpress.org/ticket/4155
[2] http://trac.wordpress.org/ticket/7545
[3] http://activeblogging.com/wp-admin/gears-manifest.php
[4] http://paste.ideaslabs.com/show/xgJhcf4a0g

2008/12/1 Jacob Santos <wordpress at santosj.name>:
> See reply below previous messages.
>
> Admin wrote:
>>
>> Hi - I'm sorry I'm a bit late to this list, but I encountered some bugs
>> (w/fixes) in the code - hope it's not too late to add them. As well, I had
>> some security requests:
>>
>> Bugfix:
>> -------
>> "Warning: Cannot modify header information - headers already sent by..."
>>
>> Caused on windows/apache install, when starting with no wp-config.php file
>> - auto-creating it adds spaces at end, which gives this message (first
>> visible during the install pages). The fix is to change this line
>> 158@/wp-admin/setup-config.php to add +b for binary:
>>
>> $handle = fopen('../wp-config.php', 'w+b');
>>
>> this prevents the function from defaulting to text format, and inserting
>> the extra lines (tested)
>
> I don't think writing text is binary, but okay. It isn't about that, as it
> is about the new line character. I've been using the
> wp-admin/setup-config.php and not once has it created an extra newline where
> it shouldn't. Would be nice to do it, if it works and fixes the problem.
>
>> Security Request:
>> -----------------
>> Remove the generator meta display in themes when called by wp_head(),
>> which is the hook set at line 173@/wp-includes/default-filters.php:
>>
>> add_action('wp_head', 'wp_generator');
>>
>> Although it can be removed in the theme or via plugin (I did a blog post
>> at
>> http://activeblogging.com/info/wordpress-security-version-numbers-and-themes/
>> explaining how), broadcasting the version by default seems a bad idea - an
>> easy way for a spam program to patrol for older installs (or zero day
>> exploits).
>
> Like you said, you can already remove it. That was the reason it was added
> as to the filter as opposed to being hard coded. Well, one of the reasons.
>
>> Request:
>> --------
>> Add non-indexing code to the login page to keep it out of indexes - it
>> doesn't help search results, and exposes details of the site to casual
>> viewers. To solve, you can insert this around about line 48 at wp-login.php:
>>
>> <meta name='robots' content='noindex,nofollow' />
>
> Well, you could probably do this using a plugin as well. Also you can add it
> to the robots.txt file for good measure.
>
>>
>> Security Request:
>> -----------------
>> While a bit more involved, the security for the login page reveals a lot
>> of information - if I enter a correct user name but bad password, it tells
>> me; if I enter an invalid user name, it tells me. It might be a good idea to
>> replace the specific messages with generic ones - eg "error: incorrect
>> password or invalid username." This makes fishing for information less
>> useful (for example, guessing user names and checking the message to see if
>> they exist). The error strings involved all have ">ERROR<" in them, in
>> wp-login.php
>
> This horse as already been beaten to death, risen from the dead and then set
> on fire to prevent the zombie from coming back. The reason for it (from what
> I can remember from past discussions) are 1) security through obscurity
> usually isn't and 2) It is very helpful when you've forgotten both your
> username and password and don't have immediate or any access to the database
> tables.
>
>>
>>
>> Misc:
>> -----
>> While fixing the generator metatag issue, I read the documentation at
>> http://codex.wordpress.org/Function_Reference/remove_action that:
>>
>> "To remove a hook, the $function_to_remove and $priority arguments must
>> match when the hook was added...No warning will be given on removal
>> failure."
>>
>> While not a problem in my case, it means that if later on you change the
>> priority of an action added, other code with remove actions will fail
>> silently (unless they are updated to the same priority). This could be an
>> unnecessary maintenance issue in the future. Perhaps a function could be
>> exposed allowing ALL occurrences of the action function, regardless of
>> priority, to be removed. I'd be happy to submit one if no one has time to
>> write it.
>
> It is never going to change. You have no need to worry.
>
> Jacob Santos
>
> _______________________________________________
> wp-testers mailing list
> wp-testers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-testers
>



-- 
_________________________
             g30rg3_x