lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  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]
Message-ID: <4FE3A7AA.6020408@security-assessment.com>
Date: Fri, 22 Jun 2012 11:00:58 +1200
From: Denis Andzakovic <denis.andzakovic@...urity-assessment.com>
To: Greg Knaddison <greg.knaddison@...uia.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: WordPress Authenticated File Upload
 Authorisation Bypass


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Say a wordpress install has been configured as such that the user
running the web server does not have write access to wp-content/plugins.
A wordpress admin then attempts to upload a plugin, they get prompted
for ftp credentials to be able to install. Wordpress does this to ensure
everything has the right permissions.
(http://codex.wordpress.org/Managing_Plugins#Installing_Plugins)

*Before* getting prompted for these creds, the uploaded file is staged
into the uploads directory, which lives under the web-root. The issue
here is that files, regardless of installation status and type, are
thrown into the uploads directory.

I see one potential scenario as; a sysadmin would lock down the file
permissions on the wp-content/plugins directory to stop Wordpress
users/admins from uploading potentially malicious code. Admittedly,
config define( 'DISALLOW_FILE_MODS', TRUE), is the correct way of doing
this, however that doesn't make the former scenario completely implausible.

Regards,
Denis

On 22/06/12 2:42 AM, Greg Knaddison wrote:
> On Wed, Jun 20, 2012 at 8:04 PM, Denis Andzakovic
<denis.andzakovic@...urity-assessment.com
<mailto:denis.andzakovic@...urity-assessment.com>> wrote:
>
> Exploitation of this vulnerability requires a malicious user with
> access to the admin panel to use the
> "/wp-admin/plugin-install.php?tab=upload" page to upload a malicious
> file.
>
>
> That tool is meant to allow an admin to upload arbitrary php plugins.
You can argue that this feature is insecure by design, but there are two
solutions from the WordPress perspective:
>
> 1) "Don't grant malicious users the permission to install plugins."
> 2) If you don't want this feature on your site at all, this feature can
be disabled in the config define( 'DISALLOW_FILE_MODS', TRUE);
>
> By the way, two more "vulnerabilities" the theme installer has this
same issue and the upgrade tool could also be abused if you can poison
the DNS of the server.
>
> Regards,
> Greg

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP46eqAAoJED9OsznShNuRuekH/2zmzIOEkvCK+K8CtS/WgJER
jU/A0nVLUlFpvI5hPo5tx7Ago7TCxXmQbohsy6bHuUBehk2qT8VAPIox4mqs6RQk
9qtuBUBoCCJhiEO+HITpTvrqd4cskTgEY87KzCE6BkbhDq46PCNwSckceBIruEY7
PPkNCkabNXgyRQj6uvJqlg8eoe4FfXDujFBcTxVcWZEciJAxYDVGUe7V3mkekmZ2
E7ixd5tCNs9sZ60LUQ5huj4and5JaBFHiQTj8pwJ73yuFoFwoNwtFSBZ7r8qGzjl
J99IxBfgP/pDcioEi43j9CBfIJTElgwhH3guu4FneiGa5lEKwdirPBgEI9LKYA8=
=bQkR
-----END PGP SIGNATURE-----


Content of type "text/html" skipped

_______________________________________________
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