Artikel getaggt mit ‘Security’
Security Update
We’re on 2.2.2 now
C ya,
Sascha
Update to 2.0.7
Yes, it’s true … just some days after upgrading to WordPress 2.0.6, the development team released a new version which fixes the RSS bug and some security holes.
Well, the next major release is scheduled for the end of this month so be prepared for some more updates soon
WP Update
Just to let you know … we’re on 2.0.5 now
Let Bugle secure your code
Bugle is a collection of search queries which can help to identify software security bugs in source code available on the web.
Not sure what to think about it…
Web Application Hacking Sandbox
Ever wanted to try out all these evil security threats everybody is talking about? Well, here’s your chance at the Web Application Hacking Sandbox.
This is a support site for listeners of the Mighty Seek Podcast – Hands On Series.
The Hands On Series is designed to give the step by step of Web App hacking as taught in classes that can cost as much as $3000 for a 3 day course. All for the low low price of… FREE.
Give it a go and learn something new every day
Google Tech Talks
Bunny pointed me to two interresting Google Tech Talks some days ago, I’d like to share with you.
The talks are simply videos of real presentations at the Google HQ. But enuff talked … on to the videos:
See Performance Tuning Best Practices for MySQL
See How To Break Web Software – A look at security vulnerabilities in web software
Be a great eBay Seller
Well, I’d say this guy really lost. He sold an old and broken laptop on eBay, charged way too much money for it and needed a lot of time to send it over … maybe too much time as he forgot to delete his pr0n collection and private files from the harddisk.
Laugh now at the broken laptop i sold on ebay.
This reminds me of having to shred the old HDD I recently replaced
PSYLock Reloaded
Do you remember our posting on PSYLock?
Well, in the meantime the guys there got an online demo up and running.
Check it out, it looks really promising … what’s left is of course the coffee cup problem
UnSecure Again
I just updated the WordPress 2.0.2 Security Release post. It seems like the XSS vulnerability isn’t as easy to fix as I thought. Read the edited thread for the whole story.
Sorry,
Sascha
WordPress 2.0.2 Security Release
Yesterday the WordPress team threw out the 2.0.2 Security Release and I have to say I’m more than just a bit disappointed. Here are some quotes from the release post:
Our latest version 2.0.2 contains several bugfixes and security fixes.
The problems addressed are unannounced XSS issues …
Remember: just because you read it on a mailing list doesn’t mean that it’s true. We’d be the first people to panic if there was an actual problem.
As always, when something serious crosses our desks we jump on it and get a well-tested release out as soon as possible.
I’m a lazy and slow guy, but even I managed to apply the small and easy security fixes suggested by the Neo Security Team within some days, so why wasn’t the WordPress team able to do so also?
Don’t get me wrong … I really like WordPress and am far away from disqualifying it as my weapon of choice, but as a developer I’d be very carefully when talking about irrelevant security issues. If you want to have some fun, write the following code as a comment in your WordPress blog.
<script>alert(document.cookie)</script>
This only shows the contents of your own cookie for your blog, but it may also send the current contents of your clipboard along with a lot of other stuff to an attacker.
By the way, this is something I just recently learned. Thanks fly out to MR
The Neo Security Team also provided some fixes for the problems wich I applied in my 2.0.1 installation. Now, as I’m a very trustful foolish user and though the patches were already in the 2.0.2 release they are all gone.
So I took this as a chance to improve the patches a bit and offer them to you, the interrested user
First there is the full path disclosure hole which shows the full script path in an error message. The best way to avoid this would be to disable error messages on a live system at all and log those message to a logfile, but hey, we’re all just humans. So the N.S.T. (Neo Security Team) suggests using the following code as a fix:
if (eregi('name_of_the_file.php', $_SERVER['PHP_SELF'])) die('You are not allowed to see this page directly');
This line should be added to all vulnerable files. There are two points I don’t like about this solution.
- You have to change the script file name for every single file
- There is a bracket missing
So I beautified the code a bit and added some functionality to fetch the current file name automatically. I ended up with this:
<?php if (eregi(basename(__FILE__), $_SERVER['PHP_SELF'])) { die('You are not allowed to see this page directly'); } ?>
For a list of files to add this line to, please check the Security Advisory.
While fixing all these files, I stumbled over a include file which lend me to the second improvement. The file is wp-include/kses.php. KSES is a PHP HTML/XHTML filter which is able to filter the bad tags out of a given string.
Edited 2006-03-13:
As the second problem addressed by the N.S.T is an XSS vulnerability, a functionality like KSES provides seems perfect. The Neo Security Team suggested to simply add htmlspecialchars() to the parameter fetching lines in the file wp-comments-post.php but I personally think the KSES approach is much sleeker. So here’s the second fix for you:
// Deny all tags by allowing nothing
$comment_author = wp_kses(trim($_POST['author']), array());
$comment_author_email = wp_kses(trim($_POST['email']), array());
$comment_author_url = wp_kses(trim($_POST['url']), array());
// Allow only some tags and attributes. See wp-includes/kses.php for details
$comment_content = wp_kses(trim($_POST['comment']), $allowedtags);
It looks like my idea of using the wp_kses function wasn’t as good as I thought. It seems like the function does a good job at filtering the invalid tags, but it also strips the attributes from valid tags. So we had some comments with links enclosed in nice a tags, but without any href attribute. As a quick fix I restored the original WordPress functionality. This should be no big problem as the vulnerability affects only logged in users.
I’ll update this post as soon as I find some working solution for this problem.
Edit end
If there’s a demand for this, I’m also willing to put up the already patched files. Just leave a comment if you’re interrested
Next I’ll try to contact the WordPress developers regarding this issues. Hopefully it’s possible to get the patches in the next release.
Until then, happy patching,
yours Sascha