Message-ID: <005f01cf2f50$485ae7c0$9b7a6fd5@pc>
Date: Fri, 21 Feb 2014 23:58:54 +0200
From: "MustLive" <mustlive@...security.com.ua>
To: "Timothy Goddard" <tim@...dard.net.nz>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: DoS via tables corruption in WordPress

Hello Timothy!

As I wrote in my first letter with description of my video and additionally
in my answer to Aris (http://seclists.org/fulldisclosure/2014/Feb/115), in
2009 WordPress developers made a fix for this DoS vulnerability - without
thanking me and without mentioning me as researcher of this
vulnerability/attack (as they did a lot since 2007). So you can consider my
attack, described in my article "Attack via tables corruption in MySQL"
(http://websecurity.com.ua/articles/attack-via-tables-corruption-in-mysql/),
as "not related to WP" and "it's not a hole in WP", but WordPress developers
from December 2009 officially considered this hole/attack as related to WP.

They did it 7 months after my advisory in 2009, so they read it and made a
fix (lame one, which can't be consider as fix, because tables repair is not
automated) - which is exactly confirmation, that developers considered such
attack is possible. So since release of WP 2.9 this DoS hole in WP is
officially confirmed, but still not fixed correctly, so all version of WP
are affected.

> then some mitigation is called for

Note, that WP developers exactly did some steps to protect against tables
corruption attack. It's weak, but they did it in December 2009. IPB
developers haven't did such protection, but since IPB 1.x they had database
management inside admin panel (with tables fix function), which can be used
for mitigation - as I wrote in my 2012's advisory. So IPB devs don't want to
do anything more about that and WP devs made only first step, but both of
them need to make protection better (tables repair must be automated). As
any developer of any web application with MyISAM tables.

Note one important thing. You and anybody should ask me questions in time.
If I wrote advisory and published it at multiple sites in May 2009, then
asking questions should be that time. Or when I wrote new advisory in 2012
about weakness of that fix and possibility to use it for attack, or when I
published my article in 2012. All people who wanted to ask me, they did it
in 2009 and 2012. And not asking me now, when I have almost civil war in my
country and only for previous three days near 100 people were killed and
hundreds were injured. Read news, my dear, about situation in Ukraine.

* Will an error running a database statement lead to WordPress showing the
install process to visitors?

Only for special tables. Which vary for different versions of WP (and those
tables are harder to corrupt, then others). That case at perishablepress.com
was only one, which I know about, which happened on web site in Internet,
with showing install process. Which allows to conduct engine reinstall. All
other web sites, where I found tables corruption in Invision Power Bulletin
(since 2007) and WordPress (since 2009), have issues with tables that leaded
only to DoS. So main attack scenario of tables corruption attack is DoS of
web site and only in lucky case, as with that site, it can be used for such
attack scenario as engine reinstall.

* What additional privileges do they then have?

In case of DoS - none. Web site will be just non-working. In case of engine
reinstall - attacker will have admin privileges after reinstall of WP.

* Could this cause a non-exploitable db bug to become exploitable?

No. It only affects web applications. In that rare case, which happed at
perishablepress.com, table corruption allowed to reinstall engine, so there
can be cases (vary for different webapps), when it will allow attack more
then DoS ("non-exploitable" in normal state).

In my video I showed DoS attack. And it's the first video in Internet which 
shows live tables corruption attack (in real time). And I made for that site 
100% reproducible DoS.

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

----- Original Message ----- 
From: Timothy Goddard
To: nacin@...dpress.org ; mustlive@...security.com.ua
Cc: full-disclosure@...ts.grok.org.uk
Sent: Tuesday, February 11, 2014 10:03 PM
Subject: Re: [Full-disclosure] DoS via tables corruption in WordPress


I agree that the DoS part is vague and not a vulnerability in WordPress.
However, my question would be:


* Will an error running a database statement lead to WordPress showing the
install process to visitors?
* What additional privileges do they then have?
* Could this cause a non-exploitable db bug to become exploitable?


If the answers there lean towards yes, lots and yes, then some mitigation is
called for.




Sent from Samsung Mobile



-------- Original message --------
From: Andrew Nacin <nacin@...dpress.org>
Date:
To: MustLive <mustlive@...security.com.ua>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: [Full-disclosure] DoS via tables corruption in WordPress



On Mon, Feb 10, 2014 at 8:02 AM, MustLive <mustlive@...security.com.ua>
wrote:
There is DoS vulnerability in WordPress, <snip>


As pointed out by others, this is unbearably vague.


But it's also invalid.


Your "attack" requires that a maintenance script to repair tables is left
open for anyone to access. The constant that you point out must be set,
WP_ALLOW_REPAIR, is only there so a user can access this script, run the
script, then remove the constant (as the script instructs).


Your suggestion appears to be to validate the logged-in user. But because
this script is to fix a *corrupt database,* we would have no way of
authenticating users. Thus, the script is instead secured by a temporary
configuration change.


Aris mentions he experienced corruption in his own WordPress setup. It's
most likely the options table simply crashed, not as a result of any
particular exploit. This is, after all, why MySQL has a REPAIR command (and
why we have a script for users to use).


I have read to quite a few of your "attacks" against WordPress core, but I
don't recall ever reading a valid one.


Perhaps for WordPress issues you should switch from "full disclosure" to a
more responsible course of action, such as contacting us first
(security@...dpress.org) so we can evaluate it. I understand the general
appeal of full disclosure, but when all you're doing is publishing invalid
vulnerabilities, it's only spreading FUD and also making it tough for others
to take any of your "attacks" seriously. This mailing list would probably
appreciate the higher signal-to-noise ratio.


Regards,


Andrew Nacin
Lead Developer
WordPress 


_______________________________________________
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