lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Apr 2012 23:50:35 +0300
From: "MustLive" <mustlive@...security.com.ua>
To: "Kurt Seifried" <kseifried@...hat.com>
Cc: full-disclosure@...ts.grok.org.uk, submissions@...ketstormsecurity.org
Subject: Re: DoS vulnerability in WordPress

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" <kseifried@...hat.com>
To: "MustLive" <mustlive@...security.com.ua>
Cc: <submissions@...ketstormsecurity.org>;
<full-disclosure@...ts.grok.org.uk>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ