Forum Moderators: rogerd
Seriously, it's scary. Upgrade to 2.5.1 immediately.
Version 2.5.1 of WordPress is now available. It includes a number of bug fixes, performance enhancements, and one very important security fix. We recommend everyone update immediately, particularly if your blog has open registration. The vulnerability is not public but it will be shortly.
[wordpress.org...]
Is WordPress's code so complex that security issues are difficult to discern or are the WP core coders simply "security incompetent"?
Is WordPress the new Microsoft when it comes to widespread security headaches?
It seems every significant WP version release is followed by news of the need to patch a security vulnerability.Is WordPress's code so complex that security issues are difficult to discern or are the WP core coders simply "security incompetent"?
Is WordPress the new Microsoft when it comes to widespread security headaches?
The same thing happens with just about every viewable source php program. Vbulletin, phpbb, cubecart, etc.
A new version comes out after weeks/months of testing and when it is released "into the wild" (public) the general public of 1000's of code savvy people obviously test the product is ways that their 100's of beta testers never imagined.
I don't think it's something specific to WP at all.
These security issues are kind of good for Web developers. These issues are a great reason to charge nice maintenance fees to Web site owners.
I've checked quite a few CMS packages...
The developers of WordPress and Drupal have an excellent approach to easy of use. So no matter the security flaws, I'll keep recommending both software packages.
[edited by: zafile at 6:01 pm (utc) on April 26, 2008]
1000's of code savvy people obviously test the product is ways that their 100's of beta testers never imagined
I'm no coder but I've looked at open source code builds, including the WP build: the number of constituent files, the lines of code, the functions they perform, the functions performed by updates, and what is updated versus what remains unchanged.
Is WP's level of code complexity really that great that "targets of penetration" are really that difficult to discern or to focus upon as potential issues? Are there really that many "points of attack" to WP?
Is it in the nature of the latest vulnerability that a particularly high level of security savvy was required to identify and exploit the vulnerability? In other words, is the 2.5 exploit a new form of exploit OR, given the functionality that was added by the new code, should someone familiar with exploits associated the newly added, but not unpopular functionality been able to spot the issue?
I don't mean to knock the work or the product but - given the intended user market (average folks, easy installation, widespread use) - and add to that the WP team's assertion that they limit changes to the core functions - it seems to me that WP will suffer a slow erosion of its popularity if every new verion exposes users to hacks attributable to added or altered functions that are nice but not essential.
Was the change that lead to this latest vulnerability a matter of importance? How were WP users able to get by without it?
Can't we have simplicity and functionality and security in an opensource publishing platform?
Wouldn't you expect that the public - those who wish to publish their thoughts and images on the WWW and enterain a degree of interaction - would be satisfied with a platform that fulfilled the K.I.S.S. mandate? (Keep It Simple Stupid/Silly/Son)
[edited by: Webwork at 6:14 pm (utc) on April 26, 2008]
I'm not a WP user, can these upgrades be forced somehow on those "unattended" WP installations?
We need a good reason to charge maintenance fees. So...
1. Simplicity
The Web site owner needs it. The more the simplicity, the less maintenance is required.
2. Functionality
This one is kind of ambiguous. However, the more the functionality, the more maintenance is required.
3. Security
This one is the best reason to obtain maintenance fees.
CMS software packages eventually will become more robust. Then, we'll have to find other sources of income.
WP's design elegance included a minimum "code package", a limited need for upgrades since the core code "gets the job done", and lastly, but most importantly - WP's essential design beauty - a plugin friendly architecture as the means of adding functionality, particularly functionality that may not have universal appeal.
What is driving WP versioning IF WP isn't suffering from core code design obsolescence as a personal publishing platform?
Maybe there is a need for a breakaway WP project dedicated to WP as a K.I.S.S. project? Isn't that how open source goes?
Conceptually, WP was pretty cool as a "grow by plugin" product. I'm not convinced that the continued "versioning of WP" will improve WP's position as the personal publishing tool of choice. I'm beginning to have my doubts.
[edited by: Webwork at 6:51 pm (utc) on April 26, 2008]
It would certainly stop the negative reputation circus that happens every time another upgrade alert happens and it would make sure that sites aren't hacked just because you took the weekend off or something.
What I find amazing is that WP just doesn't silently upgrade itself like most other applications these days.
That in itself is a vulnerability, the user that wordpress runs as should not be able to overwrite its own files.
The vulnerability is not exactly a secret, anyone who knows it is fixing CVE-2008-1930 and knows what a search engine is can find full details.
If you cannot upgrade, preventing users from registering is a workaround until you can.
The problem lies when developers extend the functionality and make changes to the core system.
"There is a fundamental flaw with the current systems, however, in that in order to extend the functionality, you have to have some knowledge of PHP [4]. The more extensible you want to get, the more grief that you cause yourself at the time of upgrades..."
[edited by: rogerd at 2:38 am (utc) on April 27, 2008]
[edit reason] link [/edit]
That in itself is a vulnerability, the user that wordpress runs as should not be able to overwrite its own files.
There are ways of accomplishing this without it being a vulnerability. Besides, considering the frequency of WP vulnerabilities I'm not sure how one more will make a difference.
The problem lies when developers extend the functionality and make changes to the core system.
I know what you're saying but I can't sympathize with the problem.
@incrdiBIll
I do the same as you blog wise. The auto update feature is nice, but WP has a problem, if they did that they would break all kinds of blogs that depend on plug in xyz. One of the big reasons that a lot of big name sites running WP are on 2.1, or 2.2 is simply that they have a lot of functionality coming from hacks or plugins that aren't gonna work on the latest and (greatest?). Users would leave en masse.
I agree the net might be better off in general if these vulnerable sites were auto patched. Sounds easy enough for a rogue good guy to do given the sheer size of the holes.
It's almost as if after the big link selling fiasco Matt and company got beat about the head and shoulders with made them switch to just leaving holes for the spammers to do their own work.
Wordpress needs to mature in a lot of ways. A big one is porting patches to older versions. It's insane to combine new features and versions with security patches and leave older installs to the wolves.
Pick two.
Essentially the bug was caused by a major change in how the cookies work - ironically meant to increase security. The problem is they didn't completely implement the design specified by the original researcher. The way they (accidentally) did it allowed a specially crafted cookie to give any user admin rights.
I'd rather have a million eyeballs looking for problems on a popular program than a few long-term security issues hidden by obscurity on a less popular package that a hacker can take advantage of immediately at will.
Oh and I'd never want WordPress or programs like it to auto-upgrade,
though I want a huge alert about any new releases.
I would however like to see them do changed-file-only downloads for each new update. I can figure it out through their TRAC svn system but it takes awhile to lookup the version numbers and make a diff patch.
Speaking of SVN, it's the ultimate way to keep up with projects like WordPress. When there's a new/interm release you can just type "svn up" and in a half-second flat your site is up to date. Check it out if you run your own server/VPS.
[edited by: amznVibe at 4:14 am (utc) on April 27, 2008]
They probably got better since, but compared to vbulletin, I think the WP holes are much larger. The vb holes are almost all cross scripting in nature.
[edited by: encyclo at 8:46 pm (utc) on April 27, 2008]
You can fix this by replacing two files:
[trac.wordpress.org...]
It will even make a mini-zip of them for you:
[trac.wordpress.org...]
Just moved three sites from WP 2.3.3 to 2.5.1 yesterday.
I must say, I don't always get along with the folks at WP, but their code is really good. The upgrade took five minutes. No kidding.
1. Backs up files and DB
2. Puts site into maintenance mode
3. Deactivates plugins
4. downloads new files and unzips
5. runs the upgrade and tells you if you need to run the DB upgrade
6. reactivates plugins.
All steps done by clicking a link. Pretty impressive... though of course I ended up with a dead plugin that hasn't been upgraded to 2.5
[wordpress.org...]
BTW, one of the reasons that so many of these packages seem to have similar problems, is that a certain amount of code is shared. Lots of the problems are based on xmlrpc vulnerabilites or the April 2 KSES vulnerabilities [securityfocus.com].
I would love to see a feature freeze that would not get lifted until some threshold is met (no security reports for a month/quarter/year) but the problem is that all of these blog/CMS platforms all have hooks systems and as often as not the plugins are what open the security holes.
Call me foolish, but I think things will improve over the next couple of years. Drupal is putting together a unit testing suite for Drupal 7 and there is a Google SOC project to incorporate a security audits [groups.drupal.org] into the Drupal Unit testing.
As more projects adopt that approach and the unit testing software gets better, the obvious holes should get plugged pre-release. Ultimately, there will need to be some similar process for plugins and such.
