© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
.Solution
No vendor patch is available.
No timeline for a vendor patch has been announced.
Workarounds:
- Protect the Wordpress database, and do not allow backups to be
released.
- Keep your Wordpress installation up to date. This should reduce the
risk that your database will be compromised.
- Do not share passwords across different sites.
- If you suspect a database to be compromised, change all passwords
to different ones. It is not adequate to change the passwords to
the same ones, since Wordpress does not "salt" [1] the password
database.
- Remove write permissions on the Wordpress files for the system
account that the webserver runs as. This will disable the theme
editor, but make it more difficult to escalate Wordpress
administrator access into the capability to execute arbitrary code
- Configure the webserver to not execute files in any directory
writable by the webserver system account (e.g. the upload
directory).
Potential fixes:
The problem occurs because it is easy to go from the password hash
in the database to a cookie (i.e the application of MD5 is the wrong
way around). The simplest fix is to store MD5(MD5(password)) in the
database, and make the cookie MD5(password). This still makes it
infeasible to retrieve the password from a cookie, but means that it
is also infeasible to generate a valid cookie from the database
entry.
However, there are other vulnerabilities in the Wordpress cookie and
password handling, which should be resolved too:
- Passwords are unsalted [2], leaving them open to brute force, rainbow
table and other attacks [3].
- It is impossible to revoke a cookie without changing the user's
password.
- Cookies do not contain an expiry time, so are always valid (until
the user's password changes)
- There ought to be an option to limit cookies to a particular
IP address or range.
References:
[1] http://
[2] http://
[3] http://