Honestly, you'll be doing a favour to everyone in the universe and yourself if you learned (to write) some proper English.
On Fri, Apr 20, 2012 at 10:50 PM, MustLive <[email protected]>wrote: > Hello Kurt! > > First off all, WordPress developers lay that they made automatic database > repair against the vulnerability, which allowed two attacks - DoS and full > site takeover (at presence of the installer). Since WP 2.9 (in December > 2009) it's still not automatic, so still all versions of WordPress are > vulnerable to Tables Corruption Attacks, which I've described in May 2009 > (turning 'WP_ALLOW_REPAIR' will not make it automatic). > > Second, such functionality as in repair.php, which overloads the DBMS (and > so every site on the server which uses this DBMS), must be under > authorization (and not to every logged in user, but admin only). WP > developers haven't did it, but they decided to make such silly method of > protection against attacks on this functionality. By default it's off, so > admins and their sites protected from attacks on it (and have no advantage > from this security functionality). > > When admins will decide to turn it on, like when the problem with DB occurs > or just for testing of this functionality or because they believe in > developers words that it's "automatic database optimization" (including > repairing of the tables), so for reliability they turned it on, they will > receive new vulnerability at their sites. Admins could left this option on > for different reasons: forgot to turn off, was busy and decided to turn it > off later, have tables crash all the time, so it's easier to turn it on one > time and other reasons. > > For example, besides WordPress I've wrote about analogical vulnerabilities > in IBP 1, 2, 3 (which could lead to DoS). And since IPB 2 there is a > functionality - not "protection against tables crashes", nor "automatic > database optimization", but just functionality in admin panel for repairing > DB - which can be used to quickly recover forum after tables crashes. It's > accessible only to authorized admins - how it should be made. > > Best wishes & regards, > MustLive > Administrator of Websecurity web site > http://websecurity.com.ua > > ----- Original Message ----- > From: "Kurt Seifried" <[email protected]> > To: "MustLive" <[email protected]> > Cc: <[email protected]>; > <[email protected]> > Sent: Monday, April 16, 2012 10:11 PM > Subject: Re: [Full-disclosure] DoS vulnerability in WordPress > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 04/15/2012 02:55 PM, MustLive wrote: > >> DoS (WASC-10): > >> > >> By constantly sending requests to script > >> http://site/wp-admin/maint/repair.php (functions "Repair Database" > >> and "Repair and Optimize Database") it's possible to create > >> overload at the site (and the whole server). And the more data in > >> site's DB, the more load from every request. > >> > >> http://site/wp-admin/maint/repair.php?repair=1&_wpnonce=a4ca36d5ff > >> > >> http://site/wp-admin/maint/repair.php?repair=2&_wpnonce=a4ca36d5ff > >> > >> The attack will work at turned on WP_ALLOW_REPAIR in > >> wp-config.php. Protection against CSRF (tokens) is bypassing, > >> because for using of this functionality the authorization isn't > >> required. So it's possible to get _wpnonce remotely and to conduct > >> DoS attack. > > > > This appears to be intended functionality, by default I get: > > > > "To allow use of this page to automatically repair database problems, > > please add the following line to your wp-config.php file. Once this > > line is added to your config, reload this page. > > define('WP_ALLOW_REPAIR', true);" > > > > So either an admin has to specifically configure this to allow it > > anonymously, or exploitation requires administrative access. I don't > > see any trust boundary being violated here. > > > > > > - -- > > Kurt Seifried Red Hat Security Response Team (SRT) > > PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.12 (GNU/Linux) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > > iQIcBAEBAgAGBQJPjG77AAoJEBYNRVNeJnmTKWUQAIE5a0yRHp3AZMKhc1aCWYKb > > BgCvGp6qD+54kNvjYcGqfGh6LalZJeYm/1zYMtWyrXFptlCElCobDfWvVS5EUx3X > > gSwyIgrh630Iy1IEpwdmAZzBGQ/wiHx3E+00zvNrbyeGzrHdiem6+zT1A/EbElum > > d5wga4iyctFFkdCCIfbE9YfLzGyZG0CGjNNyR9EuURQ2RPJV9ldfrCjtjD4jIqI3 > > PBIcMzfysDMIqLRXB8Tf+462Ux4iHW/FieXOaoG0N+1+Gq+P3/spBJlMOG6AWGzl > > h7/yQbsCbFzYTL5mFWaZu18BGXx6MjzW0IliZ/Q70T6AHsuaEiEqKmEVbbbd/Com > > JyayQu7NyA8fuBhq1KRCrA3WjrAEfsV/yLQXVMsSdtbWodHpZ5RjFqhX95aBE9Ld > > CWtheuTm1xSuVVYq92VaJlT2aHlE/LK/nfSMPMqx1xBOHl1VbhuOvFVON6UIIYXg > > mPuYjmWXLIaEGYn6k8ZRcXCbZIvnPYPF3T1Jkp03m7RCCbMiQ1C7FQ65vmFwKtEi > > MqdoCcNWQIn4dM6Tb4/AwFDCj6Du+mJSusZvOCfMQt38GDES+iqndZAtXJ0YRUJG > > tES9pMq9NzeqtqyExROQFaoecLNHeJeWGQWLCrusUT5mdEHpjnl+WOkq+skUC1EJ > > khftjrd8KsbyNfGWN7/H > > =yegM > > -----END PGP SIGNATURE----- > > > _______________________________________________ > 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/
