Full Disclosure mailing list archives
Re: DoS via tables corruption in WordPress
From: Timothy Goddard <tim () goddard net nz>
Date: Wed, 12 Feb 2014 09:03:57 +1300
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/
Current thread:
- DoS via tables corruption in WordPress MustLive (Feb 10)
- Re: DoS via tables corruption in WordPress Aris Adamantiadis (Feb 10)
- Re: DoS via tables corruption in WordPress Harry Metcalfe (Feb 10)
- Re: DoS via tables corruption in WordPress Andrew Nacin (Feb 11)
- Re: DoS via tables corruption in WordPress Aris Adamantiadis (Feb 11)
- Re: DoS via tables corruption in WordPress MustLive (Feb 12)
- Re: DoS via tables corruption in WordPress Harry Metcalfe (Feb 12)
- Re: DoS via tables corruption in WordPress Aris Adamantiadis (Feb 12)
- Re: DoS via tables corruption in WordPress MustLive (Feb 12)
- Re: DoS via tables corruption in WordPress Harry Metcalfe (Feb 17)
- Re: DoS via tables corruption in WordPress Aris Adamantiadis (Feb 11)
- Re: DoS via tables corruption in WordPress Aris Adamantiadis (Feb 10)
- <Possible follow-ups>
- Re: DoS via tables corruption in WordPress Timothy Goddard (Feb 12)
- Re: DoS via tables corruption in WordPress MustLive (Feb 21)
- Re: DoS via tables corruption in WordPress jen140 (Feb 12)