Mailing List Archive

Hi,

In none of your papers you document (in english) how you manage to
produce a table corruption in mysql, let alone from the web layers. I
still think that's possible because I experienced it on my own wordpress
+ mysql (had to do a manual repair), be it from an accident or your own
exploit.

Don't you think that's a bug in mysql itself ? Being able to corrupt
tables using basic SQL statements like insert and select should not be
possible.

Thanks,

Aris

Le 10/02/14 14:02, MustLive a écrit :
> Hello participants of Mailing List.
>
> There is DoS vulnerability in WordPress, about which I wrote in 2009
> (http://websecurity.com.ua/3152/, on English
> http://perishablepress.com/important-security-fix-for-wordpress/comment-page-5/#comment-71666),
> which allows to conduct DoS attack or reinstall of the engine (depending
> on corrupted table). And in 2012 (http://websecurity.com.ua/5774/, on
> English http://securityvulns.ru/docs27968.html) I wrote that developers
> hadn't fixed it, even they said so, and they made new DoS vulnerability.
>
> In April 2012 I wrote my article "Attack via tables corruption in MySQL"
> (http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2012-May/008363.html)
> and in July made English version of the article
> (http://websecurity.com.ua/articles/attack-via-tables-corruption-in-mysql/).
> Where I described vulnerabilities in WordPress and IPB which are based
> on my conception of attack via tables corruption.
>
> On Saturday I published a video with my WordPress DoS exploit
> (http://www.youtube.com/watch?v=kwv5ni_qxXs), which shows this DoS
> attack on one security site on WordPress. Vulnerable are all versions of
> WordPress. This video is a proof of this vulnerability in WP and of the
> attack described in the article.
>
> 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/
>

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

I have a similar frustration. We operate a lot of WordPress sites and
our clients value us, in part, because of our good security posture.

As such your emails always catch my attention and I always read them
promptly. But I often find a lack of detail that allows me to understand
whether they're issues that need me to take action, or just stuff it's
interesting to be aware of.

It would be useful if you could include steps to replicate the issues
you find.

Harry


On 10/02/2014 13:35, Aris Adamantiadis wrote:
> Hi,
>
> In none of your papers you document (in english) how you manage to
> produce a table corruption in mysql, let alone from the web layers. I
> still think that's possible because I experienced it on my own wordpress
> + mysql (had to do a manual repair), be it from an accident or your own
> exploit.
>
> Don't you think that's a bug in mysql itself ? Being able to corrupt
> tables using basic SQL statements like insert and select should not be
> possible.
>
> Thanks,
>
> Aris
>
> Le 10/02/14 14:02, MustLive a écrit :
>> Hello participants of Mailing List.
>>
>> There is DoS vulnerability in WordPress, about which I wrote in 2009
>> (http://websecurity.com.ua/3152/, on English
>> http://perishablepress.com/important-security-fix-for-wordpress/comment-page-5/#comment-71666),
>> which allows to conduct DoS attack or reinstall of the engine (depending
>> on corrupted table). And in 2012 (http://websecurity.com.ua/5774/, on
>> English http://securityvulns.ru/docs27968.html) I wrote that developers
>> hadn't fixed it, even they said so, and they made new DoS vulnerability.
>>
>> In April 2012 I wrote my article "Attack via tables corruption in MySQL"
>> (http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2012-May/008363.html)
>> and in July made English version of the article
>> (http://websecurity.com.ua/articles/attack-via-tables-corruption-in-mysql/).
>> Where I described vulnerabilities in WordPress and IPB which are based
>> on my conception of attack via tables corruption.
>>
>> On Saturday I published a video with my WordPress DoS exploit
>> (http://www.youtube.com/watch?v=kwv5ni_qxXs), which shows this DoS
>> attack on one security site on WordPress. Vulnerable are all versions of
>> WordPress. This video is a proof of this vulnerability in WP and of the
>> attack described in the article.
>>
>> 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/
>>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

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

On Mon, Feb 10, 2014 at 8:02 AM, MustLive <mustlive@websecurity.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@wordpress.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

Le 11/02/14 09:34, Andrew Nacin a écrit :
> 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).
>
This happened again last night. The mysql corruption was caused by an
OOM random kill (thanks linux) that chose mysql daemon as a victim. The
cause of the OOM was either wordpress or piwik, probably made possible
through apache misconfiguration (too many children). I have yet to
determine if that was an accident or an attack.

If Mustlive has any real and concrete information (URL, exploit code),
please share with us.

Aris

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

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

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@wordpress.org>
Date:
To: MustLive <mustlive@websecurity.com.ua>
Cc: full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] DoS via tables corruption in WordPress

On Mon, Feb 10, 2014 at 8:02 AM, MustLive <mustlive@websecurity.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@wordpress.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

Hello Aris!

First of all, I wrote all required information in my post in May 2009 at
perishablepress.com. And I answered on all questions (including lame ones
and scepsis) concerning attack on WordPress, which I proposed to owner of
that site as explanation why his site was hacked that time (via engine
reinstall). And since I developed conception of this attack yet in 2007 (for
IPB, because I have forum on this engine) and made advisories for WordPress
and IPB concerning possibility of attacks via table corruption, so in 2012 I
made detailed article "Attack via tables corruption in MySQL"
(http://websecurity.com.ua/articles/attack-via-tables-corruption-in-mysql/),
which I published at my site and in WASC mailing list.

So all aspects of attacks were described and all questions were answered by
me many years ago. Those who didn't read that information should read it,
those who have questions should read my 2009's advisory and 2012's article -
AND THEY WILL HAVE NO QUESTIONS. And for those who have scepsis about
database corruption attacks - that it's not possible to make reliable attack
with 100% chance to conduct attack on real web site - for those I made
exploit and video of its use on web site in Internet. So unbelievers should
watch video and believe.

> I have yet to determine if that was an accident or an attack.

I'm sure that your case is an accident, not an attack. Since everyone after
I proposed this attack from 2009 and till now didn't believe in possibility
of this attack and considered it as "conceptual". I.e. that was "luck" for
attackers to hack perishablepress.com with using of tables corruption that
particular day and it'll not happen again for nobody as skeptics thought. My
video should change their mind.

First of all it's hard attack and I didn't release my exploit (and will not
release it in near future) and not aware about anyone's exploit in the
public for 5 years after my 2009's advisory. So you have exact combination
of hardware and software (MySQL and WordPress) that makes your site
vulnerable to this attack. Most of web sites on WordPress can sleep tight
until some day an attacker will test their site on "crashability" and make
them vulnerable to this attack.

For all nuances of attacking on tables in MySQL read my article to
understand your case and create scenario of possible attack on your site to
trigger table crash, which leads to DoS. Concerning your case I'll write
more information to you privately. It's needed to you to find out the exact
way of crashing tables at site to prevent "accident" turn into "attack".

Note, that WP developers later in 2009, after reading that my publication
and thinking for 7 months, made a fix for this DoS in WP 2.9. But they made
not automated tables repair, but manual, so it can't be considered as a fix,
since tables can be crashed and site will be DoSed - until admin will find
it and manually repair the tables. So WP developers made lame fix for this
DoS attack, as I wrote in my 2012 advisory and WP is still vulnerable (and
also I described DoS vulnerability in protection functionality against this
DoS attack).

> If Mustlive has any real and concrete information (URL, exploit code),
> please share with us.

All real and concrete information is in my 2009's advisory and 2012's
article. With addition of my 2014's video (I was planning to make it in
2012, but found time only this month). So reading and watching of them will
help. For now I'll not release any exploits (don't need to create a risk not
for that lame site in my video, nor for all other WordPress sites, since WP
developers haven't fixed hole properly), but I'll do it in the future.

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

----- Original Message -----
From: "Aris Adamantiadis" <aris@0xbadc0de.be>
To: "Andrew Nacin" <nacin@wordpress.org>; "MustLive"
<mustlive@websecurity.com.ua>
Cc: <full-disclosure@lists.grok.org.uk>
Sent: Tuesday, February 11, 2014 3:46 PM
Subject: Re: [Full-disclosure] DoS via tables corruption in WordPress



Le 11/02/14 09:34, Andrew Nacin a ?crit :
> 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).
>
This happened again last night. The mysql corruption was caused by an
OOM random kill (thanks linux) that chose mysql daemon as a victim. The
cause of the OOM was either wordpress or piwik, probably made possible
through apache misconfiguration (too many children). I have yet to
determine if that was an accident or an attack.

If Mustlive has any real and concrete information (URL, exploit code),
please share with us.

Aris


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

Hi MustLive,

Just to make things a bit easier, would you mind replying with links for
the perishablepress.com article, the 2009 advisory and the 2012 article?

Many thanks!

Harry


On 12/02/2014 14:44, MustLive wrote:
> Hello Aris!
>
> First of all, I wrote all required information in my post in May 2009 at
> perishablepress.com. And I answered on all questions (including lame ones
> and scepsis) concerning attack on WordPress, which I proposed to owner of
> that site as explanation why his site was hacked that time (via engine
> reinstall). And since I developed conception of this attack yet in
> 2007 (for
> IPB, because I have forum on this engine) and made advisories for
> WordPress
> and IPB concerning possibility of attacks via table corruption, so in
> 2012 I
> made detailed article "Attack via tables corruption in MySQL"
> (http://websecurity.com.ua/articles/attack-via-tables-corruption-in-mysql/),
>
> which I published at my site and in WASC mailing list.
>
> So all aspects of attacks were described and all questions were
> answered by
> me many years ago. Those who didn't read that information should read it,
> those who have questions should read my 2009's advisory and 2012's
> article -
> AND THEY WILL HAVE NO QUESTIONS. And for those who have scepsis about
> database corruption attacks - that it's not possible to make reliable
> attack
> with 100% chance to conduct attack on real web site - for those I made
> exploit and video of its use on web site in Internet. So unbelievers
> should
> watch video and believe.
>
>> I have yet to determine if that was an accident or an attack.
>
> I'm sure that your case is an accident, not an attack. Since everyone
> after
> I proposed this attack from 2009 and till now didn't believe in
> possibility
> of this attack and considered it as "conceptual". I.e. that was "luck"
> for
> attackers to hack perishablepress.com with using of tables corruption
> that
> particular day and it'll not happen again for nobody as skeptics
> thought. My
> video should change their mind.
>
> First of all it's hard attack and I didn't release my exploit (and
> will not
> release it in near future) and not aware about anyone's exploit in the
> public for 5 years after my 2009's advisory. So you have exact
> combination
> of hardware and software (MySQL and WordPress) that makes your site
> vulnerable to this attack. Most of web sites on WordPress can sleep tight
> until some day an attacker will test their site on "crashability" and
> make
> them vulnerable to this attack.
>
> For all nuances of attacking on tables in MySQL read my article to
> understand your case and create scenario of possible attack on your
> site to
> trigger table crash, which leads to DoS. Concerning your case I'll write
> more information to you privately. It's needed to you to find out the
> exact
> way of crashing tables at site to prevent "accident" turn into "attack".
>
> Note, that WP developers later in 2009, after reading that my publication
> and thinking for 7 months, made a fix for this DoS in WP 2.9. But they
> made
> not automated tables repair, but manual, so it can't be considered as
> a fix,
> since tables can be crashed and site will be DoSed - until admin will
> find
> it and manually repair the tables. So WP developers made lame fix for
> this
> DoS attack, as I wrote in my 2012 advisory and WP is still vulnerable
> (and
> also I described DoS vulnerability in protection functionality against
> this
> DoS attack).
>
>> If Mustlive has any real and concrete information (URL, exploit code),
>> please share with us.
>
> All real and concrete information is in my 2009's advisory and 2012's
> article. With addition of my 2014's video (I was planning to make it in
> 2012, but found time only this month). So reading and watching of them
> will
> help. For now I'll not release any exploits (don't need to create a
> risk not
> for that lame site in my video, nor for all other WordPress sites,
> since WP
> developers haven't fixed hole properly), but I'll do it in the future.
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua
>
> ----- Original Message ----- From: "Aris Adamantiadis"
> <aris@0xbadc0de.be>
> To: "Andrew Nacin" <nacin@wordpress.org>; "MustLive"
> <mustlive@websecurity.com.ua>
> Cc: <full-disclosure@lists.grok.org.uk>
> Sent: Tuesday, February 11, 2014 3:46 PM
> Subject: Re: [Full-disclosure] DoS via tables corruption in WordPress
>
>
>
> Le 11/02/14 09:34, Andrew Nacin a ?crit :
>> 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).
>>
> This happened again last night. The mysql corruption was caused by an
> OOM random kill (thanks linux) that chose mysql daemon as a victim. The
> cause of the OOM was either wordpress or piwik, probably made possible
> through apache misconfiguration (too many children). I have yet to
> determine if that was an accident or an attack.
>
> If Mustlive has any real and concrete information (URL, exploit code),
> please share with us.
>
> Aris
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

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

Hello.

After reading the original 2009'th post
(http://websecurity.com.ua/3152), in the last paragraph the author
says that it is possible(in Wordpress 2.0.x) to corrupt wp_users table
by automatically registering multiple accounts, so I think the problem
is to be found there.

Just a small reminder, youtube has lot's of "proof" for unbelievers of
all sorts including water to wine, ddosing by ping, etc, but in my
opinion, the POC code is normally used to show the proof in security
communities.

Have a nice day.

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

Mustlive is just a troll and has nothing to show. Thanks for wasting our
time.

Le 12/02/14 15:51, Harry Metcalfe a écrit :
> Hi MustLive,
>
> Just to make things a bit easier, would you mind replying with links
> for the perishablepress.com article, the 2009 advisory and the 2012
> article?
>
> Many thanks!
>
> Harry
>
>
> On 12/02/2014 14:44, MustLive wrote:
>> Hello Aris!
>>
>> First of all, I wrote all required information in my post in May 2009 at
>> perishablepress.com. And I answered on all questions (including lame
>> ones
>> and scepsis) concerning attack on WordPress, which I proposed to
>> owner of
>> that site as explanation why his site was hacked that time (via engine
>> reinstall). And since I developed conception of this attack yet in
>> 2007 (for
>> IPB, because I have forum on this engine) and made advisories for
>> WordPress
>> and IPB concerning possibility of attacks via table corruption, so in
>> 2012 I
>> made detailed article "Attack via tables corruption in MySQL"
>> (http://websecurity.com.ua/articles/attack-via-tables-corruption-in-mysql/),
>>
>> which I published at my site and in WASC mailing list.
>>
>> So all aspects of attacks were described and all questions were
>> answered by
>> me many years ago. Those who didn't read that information should read
>> it,
>> those who have questions should read my 2009's advisory and 2012's
>> article -
>> AND THEY WILL HAVE NO QUESTIONS. And for those who have scepsis about
>> database corruption attacks - that it's not possible to make reliable
>> attack
>> with 100% chance to conduct attack on real web site - for those I made
>> exploit and video of its use on web site in Internet. So unbelievers
>> should
>> watch video and believe.
>>
>>> I have yet to determine if that was an accident or an attack.
>>
>> I'm sure that your case is an accident, not an attack. Since everyone
>> after
>> I proposed this attack from 2009 and till now didn't believe in
>> possibility
>> of this attack and considered it as "conceptual". I.e. that was
>> "luck" for
>> attackers to hack perishablepress.com with using of tables corruption
>> that
>> particular day and it'll not happen again for nobody as skeptics
>> thought. My
>> video should change their mind.
>>
>> First of all it's hard attack and I didn't release my exploit (and
>> will not
>> release it in near future) and not aware about anyone's exploit in the
>> public for 5 years after my 2009's advisory. So you have exact
>> combination
>> of hardware and software (MySQL and WordPress) that makes your site
>> vulnerable to this attack. Most of web sites on WordPress can sleep
>> tight
>> until some day an attacker will test their site on "crashability" and
>> make
>> them vulnerable to this attack.
>>
>> For all nuances of attacking on tables in MySQL read my article to
>> understand your case and create scenario of possible attack on your
>> site to
>> trigger table crash, which leads to DoS. Concerning your case I'll write
>> more information to you privately. It's needed to you to find out the
>> exact
>> way of crashing tables at site to prevent "accident" turn into "attack".
>>
>> Note, that WP developers later in 2009, after reading that my
>> publication
>> and thinking for 7 months, made a fix for this DoS in WP 2.9. But
>> they made
>> not automated tables repair, but manual, so it can't be considered as
>> a fix,
>> since tables can be crashed and site will be DoSed - until admin will
>> find
>> it and manually repair the tables. So WP developers made lame fix for
>> this
>> DoS attack, as I wrote in my 2012 advisory and WP is still vulnerable
>> (and
>> also I described DoS vulnerability in protection functionality
>> against this
>> DoS attack).
>>
>>> If Mustlive has any real and concrete information (URL, exploit code),
>>> please share with us.
>>
>> All real and concrete information is in my 2009's advisory and 2012's
>> article. With addition of my 2014's video (I was planning to make it in
>> 2012, but found time only this month). So reading and watching of
>> them will
>> help. For now I'll not release any exploits (don't need to create a
>> risk not
>> for that lame site in my video, nor for all other WordPress sites,
>> since WP
>> developers haven't fixed hole properly), but I'll do it in the future.
>>
>> Best wishes & regards,
>> MustLive
>> Administrator of Websecurity web site
>> http://websecurity.com.ua
>>
>> ----- Original Message ----- From: "Aris Adamantiadis"
>> <aris@0xbadc0de.be>
>> To: "Andrew Nacin" <nacin@wordpress.org>; "MustLive"
>> <mustlive@websecurity.com.ua>
>> Cc: <full-disclosure@lists.grok.org.uk>
>> Sent: Tuesday, February 11, 2014 3:46 PM
>> Subject: Re: [Full-disclosure] DoS via tables corruption in WordPress
>>
>>
>>
>> Le 11/02/14 09:34, Andrew Nacin a ?crit :
>>> 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).
>>>
>> This happened again last night. The mysql corruption was caused by an
>> OOM random kill (thanks linux) that chose mysql daemon as a victim. The
>> cause of the OOM was either wordpress or piwik, probably made possible
>> through apache misconfiguration (too many children). I have yet to
>> determine if that was an accident or an attack.
>>
>> If Mustlive has any real and concrete information (URL, exploit code),
>> please share with us.
>>
>> Aris
>>
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

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

Hi Harry!

The links to my advisories and article about attack via tables corruption in
MySQL and link to proof video were in my first letter. The links are also in
the description of the video, which I posted on Saturday on YouTube.

Aris haven't mentioned those links in his letter (he didn't quoted original
letter). And I was trying not to repeat the same links all the time.

So these links can be found in the list. But if you want, here they are - to
make things a bit easier.

Link to my 2009's post, where I described my conception of attack on example
of WordPress
(http://perishablepress.com/important-security-fix-for-wordpress/comment-page-5/#comment-71666)
and posted the same advisory at my site. Also read my answers on questions
there in comments.

Link to my 2012's article Attack via tables corruption in MySQL
(http://websecurity.com.ua/articles/attack-via-tables-corruption-in-mysql/).

Link to the video with my WordPress DoS exploit
(http://www.youtube.com/watch?v=kwv5ni_qxXs). A proof of this vulnerability
in WP and of the attack described in the article.

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

----- Original Message -----
From: "Harry Metcalfe" <harry@dxw.com>
To: "MustLive" <mustlive@websecurity.com.ua>
Cc: <full-disclosure@lists.grok.org.uk>
Sent: Wednesday, February 12, 2014 4:51 PM
Subject: Re: [Full-disclosure] DoS via tables corruption in WordPress


> Hi MustLive,
>
> Just to make things a bit easier, would you mind replying with links for
> the perishablepress.com article, the 2009 advisory and the 2012 article?
>
> Many thanks!
>
> Harry
>
>
> On 12/02/2014 14:44, MustLive wrote:
>> Hello Aris!
>>
>> First of all, I wrote all required information in my post in May 2009 at
>> perishablepress.com. And I answered on all questions (including lame ones
>> and scepsis) concerning attack on WordPress, which I proposed to owner of
>> that site as explanation why his site was hacked that time (via engine
>> reinstall). And since I developed conception of this attack yet in 2007
>> (for
>> IPB, because I have forum on this engine) and made advisories for
>> WordPress
>> and IPB concerning possibility of attacks via table corruption, so in
>> 2012 I
>> made detailed article "Attack via tables corruption in MySQL"
>> (http://websecurity.com.ua/articles/attack-via-tables-corruption-in-mysql/),
>> which I published at my site and in WASC mailing list.
>>
>> So all aspects of attacks were described and all questions were answered
>> by
>> me many years ago. Those who didn't read that information should read it,
>> those who have questions should read my 2009's advisory and 2012's
>> article -
>> AND THEY WILL HAVE NO QUESTIONS. And for those who have scepsis about
>> database corruption attacks - that it's not possible to make reliable
>> attack
>> with 100% chance to conduct attack on real web site - for those I made
>> exploit and video of its use on web site in Internet. So unbelievers
>> should
>> watch video and believe.
>>
>>> I have yet to determine if that was an accident or an attack.
>>
>> I'm sure that your case is an accident, not an attack. Since everyone
>> after
>> I proposed this attack from 2009 and till now didn't believe in
>> possibility
>> of this attack and considered it as "conceptual". I.e. that was "luck"
>> for
>> attackers to hack perishablepress.com with using of tables corruption
>> that
>> particular day and it'll not happen again for nobody as skeptics thought.
>> My
>> video should change their mind.
>>
>> First of all it's hard attack and I didn't release my exploit (and will
>> not
>> release it in near future) and not aware about anyone's exploit in the
>> public for 5 years after my 2009's advisory. So you have exact
>> combination
>> of hardware and software (MySQL and WordPress) that makes your site
>> vulnerable to this attack. Most of web sites on WordPress can sleep tight
>> until some day an attacker will test their site on "crashability" and
>> make
>> them vulnerable to this attack.
>>
>> For all nuances of attacking on tables in MySQL read my article to
>> understand your case and create scenario of possible attack on your site
>> to
>> trigger table crash, which leads to DoS. Concerning your case I'll write
>> more information to you privately. It's needed to you to find out the
>> exact
>> way of crashing tables at site to prevent "accident" turn into "attack".
>>
>> Note, that WP developers later in 2009, after reading that my publication
>> and thinking for 7 months, made a fix for this DoS in WP 2.9. But they
>> made
>> not automated tables repair, but manual, so it can't be considered as a
>> fix,
>> since tables can be crashed and site will be DoSed - until admin will
>> find
>> it and manually repair the tables. So WP developers made lame fix for
>> this
>> DoS attack, as I wrote in my 2012 advisory and WP is still vulnerable
>> (and
>> also I described DoS vulnerability in protection functionality against
>> this
>> DoS attack).
>>
>>> If Mustlive has any real and concrete information (URL, exploit code),
>>> please share with us.
>>
>> All real and concrete information is in my 2009's advisory and 2012's
>> article. With addition of my 2014's video (I was planning to make it in
>> 2012, but found time only this month). So reading and watching of them
>> will
>> help. For now I'll not release any exploits (don't need to create a risk
>> not
>> for that lame site in my video, nor for all other WordPress sites, since
>> WP
>> developers haven't fixed hole properly), but I'll do it in the future.
>>
>> Best wishes & regards,
>> MustLive
>> Administrator of Websecurity web site
>> http://websecurity.com.ua
>>
>> ----- Original Message ----- From: "Aris Adamantiadis"
>> <aris@0xbadc0de.be>
>> To: "Andrew Nacin" <nacin@wordpress.org>; "MustLive"
>> <mustlive@websecurity.com.ua>
>> Cc: <full-disclosure@lists.grok.org.uk>
>> Sent: Tuesday, February 11, 2014 3:46 PM
>> Subject: Re: [Full-disclosure] DoS via tables corruption in WordPress
>>
>>
>>
>> Le 11/02/14 09:34, Andrew Nacin a ?crit :
>>> 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).
>>>
>> This happened again last night. The mysql corruption was caused by an
>> OOM random kill (thanks linux) that chose mysql daemon as a victim. The
>> cause of the OOM was either wordpress or piwik, probably made possible
>> through apache misconfiguration (too many children). I have yet to
>> determine if that was an accident or an attack.
>>
>> If Mustlive has any real and concrete information (URL, exploit code),
>> please share with us.
>>
>> Aris
>>
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/


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

Hi MustLive,

I have read both of those carefully (the websecurity one, via Google
Translate) and watched the video.

I agree that someone who came across a WordPress site with crashed
tables might get an installer screen. That would be bad. But it is also
very unlikely to occur often. The nearest I can see to an actual attack
is that you could DoS a MySQL server, or WordPress itself, in the hope
that you might cause table corruption that would let you re-install,
thus siezing control. Again, though I suppose this is possible, it seems
fanciful.

I still can see no explanation, replication steps or proof of concept
code that would allow me to confirm that the attack shown in the video
-- denial of service via database unavailability on an arbitrary
WordPress site, irrespective of configuration -- is possible.

Obviously, the YouTube video by itself is not proof of anything.

Harry


On 12/02/2014 16:46, MustLive wrote:
> Hi Harry!
>
> The links to my advisories and article about attack via tables
> corruption in
> MySQL and link to proof video were in my first letter. The links are
> also in
> the description of the video, which I posted on Saturday on YouTube.
>
> Aris haven't mentioned those links in his letter (he didn't quoted
> original
> letter). And I was trying not to repeat the same links all the time.
>
> So these links can be found in the list. But if you want, here they
> are - to
> make things a bit easier.
>
> Link to my 2009's post, where I described my conception of attack on
> example
> of WordPress
> (http://perishablepress.com/important-security-fix-for-wordpress/comment-page-5/#comment-71666)
>
> and posted the same advisory at my site. Also read my answers on
> questions there in comments.
>
> Link to my 2012's article Attack via tables corruption in MySQL
> (http://websecurity.com.ua/articles/attack-via-tables-corruption-in-mysql/).
>
>
> Link to the video with my WordPress DoS exploit
> (http://www.youtube.com/watch?v=kwv5ni_qxXs). A proof of this
> vulnerability
> in WP and of the attack described in the article.
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua
>
> ----- Original Message ----- From: "Harry Metcalfe" <harry@dxw.com>
> To: "MustLive" <mustlive@websecurity.com.ua>
> Cc: <full-disclosure@lists.grok.org.uk>
> Sent: Wednesday, February 12, 2014 4:51 PM
> Subject: Re: [Full-disclosure] DoS via tables corruption in WordPress
>
>
>> Hi MustLive,
>>
>> Just to make things a bit easier, would you mind replying with links for
>> the perishablepress.com article, the 2009 advisory and the 2012 article?
>>
>> Many thanks!
>>
>> Harry
>>
>>
>> On 12/02/2014 14:44, MustLive wrote:
>>> Hello Aris!
>>>
>>> First of all, I wrote all required information in my post in May
>>> 2009 at
>>> perishablepress.com. And I answered on all questions (including lame
>>> ones
>>> and scepsis) concerning attack on WordPress, which I proposed to
>>> owner of
>>> that site as explanation why his site was hacked that time (via engine
>>> reinstall). And since I developed conception of this attack yet in 2007
>>> (for
>>> IPB, because I have forum on this engine) and made advisories for
>>> WordPress
>>> and IPB concerning possibility of attacks via table corruption, so in
>>> 2012 I
>>> made detailed article "Attack via tables corruption in MySQL"
>>> (http://websecurity.com.ua/articles/attack-via-tables-corruption-in-mysql/),
>>>
>>> which I published at my site and in WASC mailing list.
>>>
>>> So all aspects of attacks were described and all questions were
>>> answered
>>> by
>>> me many years ago. Those who didn't read that information should
>>> read it,
>>> those who have questions should read my 2009's advisory and 2012's
>>> article -
>>> AND THEY WILL HAVE NO QUESTIONS. And for those who have scepsis about
>>> database corruption attacks - that it's not possible to make reliable
>>> attack
>>> with 100% chance to conduct attack on real web site - for those I made
>>> exploit and video of its use on web site in Internet. So unbelievers
>>> should
>>> watch video and believe.
>>>
>>>> I have yet to determine if that was an accident or an attack.
>>>
>>> I'm sure that your case is an accident, not an attack. Since everyone
>>> after
>>> I proposed this attack from 2009 and till now didn't believe in
>>> possibility
>>> of this attack and considered it as "conceptual". I.e. that was "luck"
>>> for
>>> attackers to hack perishablepress.com with using of tables corruption
>>> that
>>> particular day and it'll not happen again for nobody as skeptics
>>> thought.
>>> My
>>> video should change their mind.
>>>
>>> First of all it's hard attack and I didn't release my exploit (and will
>>> not
>>> release it in near future) and not aware about anyone's exploit in the
>>> public for 5 years after my 2009's advisory. So you have exact
>>> combination
>>> of hardware and software (MySQL and WordPress) that makes your site
>>> vulnerable to this attack. Most of web sites on WordPress can sleep
>>> tight
>>> until some day an attacker will test their site on "crashability" and
>>> make
>>> them vulnerable to this attack.
>>>
>>> For all nuances of attacking on tables in MySQL read my article to
>>> understand your case and create scenario of possible attack on your
>>> site
>>> to
>>> trigger table crash, which leads to DoS. Concerning your case I'll
>>> write
>>> more information to you privately. It's needed to you to find out the
>>> exact
>>> way of crashing tables at site to prevent "accident" turn into
>>> "attack".
>>>
>>> Note, that WP developers later in 2009, after reading that my
>>> publication
>>> and thinking for 7 months, made a fix for this DoS in WP 2.9. But they
>>> made
>>> not automated tables repair, but manual, so it can't be considered as a
>>> fix,
>>> since tables can be crashed and site will be DoSed - until admin will
>>> find
>>> it and manually repair the tables. So WP developers made lame fix for
>>> this
>>> DoS attack, as I wrote in my 2012 advisory and WP is still vulnerable
>>> (and
>>> also I described DoS vulnerability in protection functionality against
>>> this
>>> DoS attack).
>>>
>>>> If Mustlive has any real and concrete information (URL, exploit code),
>>>> please share with us.
>>>
>>> All real and concrete information is in my 2009's advisory and 2012's
>>> article. With addition of my 2014's video (I was planning to make it in
>>> 2012, but found time only this month). So reading and watching of them
>>> will
>>> help. For now I'll not release any exploits (don't need to create a
>>> risk
>>> not
>>> for that lame site in my video, nor for all other WordPress sites,
>>> since
>>> WP
>>> developers haven't fixed hole properly), but I'll do it in the future.
>>>
>>> Best wishes & regards,
>>> MustLive
>>> Administrator of Websecurity web site
>>> http://websecurity.com.ua
>>>
>>> ----- Original Message ----- From: "Aris Adamantiadis"
>>> <aris@0xbadc0de.be>
>>> To: "Andrew Nacin" <nacin@wordpress.org>; "MustLive"
>>> <mustlive@websecurity.com.ua>
>>> Cc: <full-disclosure@lists.grok.org.uk>
>>> Sent: Tuesday, February 11, 2014 3:46 PM
>>> Subject: Re: [Full-disclosure] DoS via tables corruption in WordPress
>>>
>>>
>>>
>>> Le 11/02/14 09:34, Andrew Nacin a ?crit :
>>>> 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).
>>>>
>>> This happened again last night. The mysql corruption was caused by an
>>> OOM random kill (thanks linux) that chose mysql daemon as a victim. The
>>> cause of the OOM was either wordpress or piwik, probably made possible
>>> through apache misconfiguration (too many children). I have yet to
>>> determine if that was an accident or an attack.
>>>
>>> If Mustlive has any real and concrete information (URL, exploit code),
>>> please share with us.
>>>
>>> Aris
>>>
>>>
>>> _______________________________________________
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/
>
>

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

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@wordpress.org ; mustlive@websecurity.com.ua
Cc: full-disclosure@lists.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@wordpress.org>
Date:
To: MustLive <mustlive@websecurity.com.ua>
Cc: full-disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] DoS via tables corruption in WordPress



On Mon, Feb 10, 2014 at 8:02 AM, MustLive <mustlive@websecurity.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@wordpress.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/