Date: Fri, 6 Dec 2013 23:55:10 +0200
From: "MustLive" <mustlive@...security.com.ua>
To: "Ryan Dewhurst" <ryandewhurst@...il.com>
Cc: full-disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: Vulnerabilities hiddenly fixed in WordPress
	3.6 and 3.6.1

Hello Ryan!

There are many cases with different classes of vulnerabilities hiddenly fixed in WordPress (during 2007-2013 I wrote about many such cases, including wrote on English in security mailing lists). These FPD vulnerabilities just particular examples for WP 3.6 and 3.6.1. The main point is that WP developers for a long time are doing such bad thing as hidden fixing holes and it must never be done for any classes of vulnerabilities.

Concerning Full Path Disclosures holes in WordPress.

At 24.03.2013 I checked different versions of WP and find all external (non in admin panel) FPD holes in them with my tool FPD Finder. Particularly in WordPress 3.3.1 (which was the last version at that time) I found 176 FPD holes. The amount of such holes is increasing all the time, because WP developers ignore them. I know about YEHG's inspathx tool, but I don't like to use other tools and like to make and use my own tools. So I made my tool FPD Finder in the beginning of 2012 and made tests of FPD holes in different web applications, including WordPress. When I'll find time and desire to publish WP results and the tool itself, I'll do it. At that last year I wrote about FPD vulnerabilities in MODx (which I found in May 2012 with my tool) - I also disclosed it to this list (http://lists.grok.org.uk/pipermail/full-disclosure/2012-November/088924.html). So results of the work of FPD Finder already available for the public.

> WordPress's stance on this is: 
>
> "Why are there path disclosures when directly loading certain files?
> This is considered a server configuration problem. Never enable display_errors on a production site." 

This is default PHP configuration (so all holes are a priori valid). So it's up to developers to manually prevent FPD in all their php-scripts. Since they are lazy (don't do it) and lamers (don't understand the holes), hence the large amount of FPD holes. As all other holes in this and all those web applications, about vulnerabilities in which have been written during the whole history of WWW.

> WordPress do not consider this a security bug and instead a configuration problem.

A lot of lamers do the same. As a lot of lamers don't consider any arbitrary class of vulnerabilities (which exists in WASC and OWASP classifications) as a hole - I see it all the time during last 9 years. Which doesn't change nothing - the holes are indeed the holes regardless of point of view of individual developers.

> They will not fix any and therefor WordPress is absolutely full of FPD issues.

As it always was, is and will be. Until the developers will change their opinion and start fixing them. But main point in my letter was, that developers regularly fix some of the FPD holes. Sometimes they mentioned them in "fixed bugs" section, sometimes not, but there were cases where they fixed FPD and wrote about it in announcement as vulnerability (like in version 3.5.2). And all FPD holes must be handled in the same way, not just position with "directly loaded certain files", but with all others (now the developers have different approach with them). And don't ignore all FPD, but exactly fix all FPD.

And the holes, which I wrote about, those exactly are not "directly loaded certain files", but are FPD at certain actions at web site, so developers fixed them. But didn't mentioned about them officially. But they exactly wrote in announcement about FPD in WP 3.5.2 (http://wordpress.org/news/2013/06/wordpress-3-5-2/). So it's double standards, which is unacceptable for any developer.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua
  ----- Original Message ----- 
  From: Ryan Dewhurst 
  To: MustLive 
  Cc: submissions@...ketstormsecurity.org ; full-disclosure 
  Sent: Saturday, November 30, 2013 10:19 PM
  Subject: Re: [Full-disclosure] Vulnerabilities hiddenly fixed in WordPress 3.6 and 3.6.1


  Although I do not agree with this point, WordPress's stance on this is: 


  "Why are there path disclosures when directly loading certain files?
  This is considered a server configuration problem. Never enable display_errors on a production site." - http://codex.wordpress.org/Security_FAQ#Why_are_there_path_disclosures_when_directly_loading_certain_files.3F


  WordPress do not consider this a security bug and instead a configuration problem. They will not fix any and therefor WordPress is absolutely full of FPD issues.


  I did some research back in 2011 and found that the first version of WordPress I could install (0.71-gold) had 44 FPDs, whereas the latest at the time of the research (3.2.1) had 155 FDPs - http://www.ethicalhack3r.co.uk/full-path-disclosure-fpd/


  Here is every FPD issue I identified from version 0.71-gold to version 3.2.1 - http://ethicalhack3r.co.uk/files/misc/wp_paths.tar (I would estimate thousands across the versions, I used YEHG's inspathx tool)


  From this research I found that the "wp-includes/rss-functions.php" file is the most consistent to give a FPD across all versions, this is the file now used in WPScan to detect FPDs in WordPress reliably - https://github.com/wpscanteam/wpscan/blob/2fb6f7169acb5263f11586e742474193ed3b4ee1/lib/wpscan/wp_target/wp_full_path_disclosure.rb


  Until WordPress decide to start fixing them, individual FPD bugs are a non-issue.



  On Sat, Nov 30, 2013 at 8:44 PM, MustLive <mustlive@...security.com.ua> wrote:

    Hello list!

    In July I wrote about one vulnerability in WordPress, which were hiddenly fixed in version 3.5.2 (http://securityvulns.ru/docs29555.html). Here are new ones.

    These are hiddenly fixed vulnerabilities in such versions of WordPress as 3.6 and 3.6.1. Developers of WP intentionally haven't wrote about them to decrease official number of fixed holes. Which is typical for them - since 2007 they often hide fixed vulnerabilities.

    As I wrote in September (http://websecurity.com.ua/6795/), there are 9 FPD vulnerabilities, which were hiddenly fixed in WP 3.6. They were not mentioned in announcement, only mentioned in Codex (as "bugs"). Even there were cases, when WP developers wrote about fixed FPD in official announcements.

    Full path disclosure (WASC-13):

    In Media Library if an attachment parent does not exist.
    In function parent_dropdown().
    In function wp_new_comment().
    In function mb_internal_encoding().
    At processing of image metadata.
    In function get_post_type_archive_feed_link().
    In function WP_Image_Editor::multi_resize().
    In function wp_generate_attachment_metadata().
    At deleting or restoring an item that no longer exists.

    Vulnerable are WordPress 3.5.2 and previous versions.

    As I wrote in November (http://websecurity.com.ua/6904/), there are 3 FPD vulnerabilities, which were hiddenly fixed in WP 3.6.1. They were not mentioned in announcement or Codex. Even there were cases, when WP developers wrote about fixed FPD in official announcements.

    Full path disclosure (WASC-13):

    In function get_allowed_mime_types().
    In function set_url_scheme().
    In function comment_form().

    Vulnerable are WordPress 3.6 and previous versions.

    Best wishes & regards,
    MustLive
    Administrator of Websecurity web site
    http://websecurity.com.ua 

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.grok.org.uk/full-disclosure-charter.html
    Hosted and sponsored by Secunia - http://secunia.com/
Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists