From jericho at attrition.org Tue Jul 5 02:29:55 2005 From: jericho at attrition.org (security curmudgeon) Date: Tue Jul 5 02:29:57 2005 Subject: [VIM] Differences between ASPNuke (ASP Nuke? ASP-Nuke?) and aspnuke? In-Reply-To: <200506291757.j5THvacJ014111@linus.mitre.org> References: <200506291757.j5THvacJ014111@linus.mitre.org> Message-ID: : Also use "www.aspnuke.com" as the vendor. But a completely different : spelling. : : Then there's "asp-nuke.com," which appears to be the "asp-nuke" that is : referred to in the first post. : : Anybody know what's going on? Are there 2 "ASP Nuke" products or three? : Which bug report goes with which product? Not sure with certainty, but I thought we've seen this before and it ended up being the same product.. From jericho at attrition.org Tue Jul 5 08:19:18 2005 From: jericho at attrition.org (security curmudgeon) Date: Tue Jul 5 08:19:20 2005 Subject: [VIM] [OSVDB Mods] [Change Request] 2015549: Ariadne CMS loader.php Remote File (fwd) Message-ID: ---------- Forwarded message ---------- From: Gijsbert te Riet To: moderators@osvdb.org Date: Mon, 4 Jul 2005 13:16:17 +0200 (CEST) Subject: [OSVDB Mods] [Change Request] 2015549: Ariadne CMS loader.php Remote File Dear reader, The vulnerability report on your site, titled 'Ariadne Include File Flaw Lets Remote Users Execute Arbitrary Commands', is inaccurate. The report states that, by passing the variable 'ariadne' to the system, "A remote user can execute arbitrary commands on the target system". This is flawed, since on each request, the first thing that is done, is setting the 'ariadne' variable to a admin configed string. This is done by loading the configuration file 'ariadne.inc'. After that, the 'ariadne' variable will not contain any information entered via web. We regret it that we were not informed about this 'flaw' before you published it on your site, and had to find it by accident. It would have been more appropriate to contact the developer of the system before letting lose this kind of critical information. That way a fix (or in this case, an counter argument) could have been made in a day, instead of 4 months. We hope you will update your entry with this information, and inform us the next time an issue about one of our project arises. With kind regards, Gijsbert te Riet. Muze/ Ariadne. From jericho at attrition.org Tue Jul 5 08:19:22 2005 From: jericho at attrition.org (security curmudgeon) Date: Tue Jul 5 08:19:23 2005 Subject: [VIM] [OSVDB Mods] Re: [Change Request] 15549: Ariadne CMS loader.php Remote File (fwd) Message-ID: ---------- Forwarded message ---------- From: security curmudgeon To: Gijsbert te Riet Cc: Mods Date: Tue, 5 Jul 2005 08:04:49 -0400 (EDT) Subject: [OSVDB Mods] Re: [Change Request] 15549: Ariadne CMS loader.php Remote File Hi Gijsbert, : The vulnerability report on your site, titled 'Ariadne Include File Flaw : Lets Remote Users Execute Arbitrary Commands', is inaccurate. : : The report states that, by passing the variable 'ariadne' to the system, : "A remote user can execute arbitrary commands on the target system". : This is flawed, since on each request, the first thing that is done, is : setting the 'ariadne' variable to a admin configed string. This is done : by loading the configuration file 'ariadne.inc'. After that, the : 'ariadne' variable will not contain any information entered via web. : : We regret it that we were not informed about this 'flaw' before you : published it on your site, and had to find it by accident. It would have : been more appropriate to contact the developer of the system before : letting lose this kind of critical information. That way a fix (or in : this case, an counter argument) could have been made in a day, instead : of 4 months. First, we did not publish this information originally. If you look at our entry for this issue, there are several external references for this vulnerability. Checking them, the SecurityTracker (ST) listing shows the original point of disclosure: someone mailed ST with the vulnerability information. You can see their entry at: http://securitytracker.com/alerts/2005/Apr/1013721.html. From this, we see "Fidel Costa reported a vulnerability in Ariadne." Second, you say this is not an issue because the data is sanitized and does not come from the user. Then you say you wish we had informed you of this "critical information". If this is not an issue and the information is inaccurate.. why exactly do you call this critical in the next paragraph? : We hope you will update your entry with this information, and inform us : the next time an issue about one of our project arises. At this point, I am not sure how serious of an issue this really is. The original vulnerability reporter says this is an issue, you call this "critical", then you also say this is "inaccurate". OSVDB strives to have accurate information and will do everything we can to achieve this. When the vendor sends conflicting statements, it is usually difficult to gauge the severity of the problem. When a vendor sends in conflicting statements within their own reply.. it is twice as difficult. Again, i'd like to point out that OSVDB did not research or publish this information originally. We only cataloged it from another source. If any of our staff find vulnerabilities in Ariadne, we will certainly notify the vendor first. Brian OSVDB.org From coley at linus.mitre.org Tue Jul 5 13:55:53 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue Jul 5 17:04:38 2005 Subject: [VIM] Vendor dispute for CAN-2005-1181 (Ariadne PHP file include) Message-ID: Vendor dispute for CAN-2005-1181. I downloaded the source code - still 2.4 - and verified that both "ariadne.inc-unix" and "ariadne.inc-win" in the www directory - presumably one of them is renamed to ariadne.inc on install - sets the $ariadne variable before any require/includes occur in loader.php. The original research was probably a grep-and-gripe. Suddenly I feel like writing an editorial on the apparent rise of grep-and-gripe vulnerability reporting... - Steve ---------- Forwarded message ---------- Date: Mon, 04 Jul 2005 13:16:54 +0200 (CEST) From: Gijsbert te Riet To: cve@mitre.org Subject: CVE id: CAN-2005-1181 Dear reader, The vulnerability report on your site, titled 'Ariadne Include File Flaw Lets Remote Users Execute Arbitrary Commands', is inaccurate. The report states that, by passing the variable 'ariadne' to the system, "A remote user can execute arbitrary commands on the target system". This is flawed, since on each request, the first thing that is done, is setting the 'ariadne' variable to a admin configed string. This is done by loading the configuration file 'ariadne.inc'. After that, the 'ariadne' variable will not contain any information entered via web. We regret it that we were not informed about this 'flaw' before you published it on your site, and had to find it by accident. It would have been more appropriate to contact the developer of the system before letting lose this kind of critical information. That way a fix (or in this case, an counter argument) could have been made in a day, instead of 4 months. We hope you will update your entry with this information, and inform us the next time an issue about one of our project arises. With kind regards, Gijsbert te Riet. Muze/ Ariadne. From jericho at attrition.org Tue Jul 5 17:21:10 2005 From: jericho at attrition.org (security curmudgeon) Date: Tue Jul 5 17:21:12 2005 Subject: [VIM] Vendor dispute for CAN-2005-1181 (Ariadne PHP file include) In-Reply-To: References: Message-ID: : Vendor dispute for CAN-2005-1181. : : I downloaded the source code - still 2.4 - and verified that both : "ariadne.inc-unix" and "ariadne.inc-win" in the www directory - : presumably one of them is renamed to ariadne.inc on install - sets the : $ariadne variable before any require/includes occur in loader.php. : : The original research was probably a grep-and-gripe. Suddenly I feel : like writing an editorial on the apparent rise of grep-and-gripe : vulnerability reporting... Well, i'm glad you checked this as the mail from the vendor to me was very confusing and conflicting in his wording. I'll remove it from OSVDB today, or update it as myth/fake, and contact the vendor as well. Thanks! From coley at linus.mitre.org Tue Jul 5 14:00:14 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue Jul 5 18:04:04 2005 Subject: [VIM] Re: CVE id: CAN-2005-1181 In-Reply-To: References: Message-ID: I suppose the 10 million comment will bite me someday, but it seems to be a reasonable estimate. - Steve On Tue, 5 Jul 2005, Steven M. Christey wrote: > > On Mon, 4 Jul 2005, Gijsbert te Riet wrote: > > > Dear reader, > > > > The vulnerability report on your site, titled 'Ariadne Include File Flaw > > Lets Remote Users Execute Arbitrary Commands', is inaccurate. > > We have modified the > > > We regret it that we were not informed about this 'flaw' before you > > published it on your site, and had to find it by accident. > > Approximately 100 vulnerabilities per week are publicly reported, and it > is estimated that full verification of each and every vulnerability report > would likely cost in excess of 10 million dollars per year. Therefore it > is not possible for us to verify every report. > > To see how difficult it is to find vendor acknowledgement for large > numbers of vulnerabilities, please read the following report: > > "An informal analysis of vendor acknowledgement of vulnerabilities" > Steve Christey, Barbara Pease > http://cert.uni-stuttgart.de/archive/bugtraq/2001/03/msg00153.html > > However, we are always willing to post vendor disputes for inaccurate > vulnerability information. > > I will forward your email to other vulnerability information sources so > that they can make corrections. You might wish to send a post to the > Bugtraq mailing list, which will reach a wide audience. > > I have modified the CVE candidate accordingly; see below. This will be on > the CVE web site later today. > > > We hope you will update your entry with this information, and inform us the > > next time an issue about one of our project arises. > > We are working on an automated capability to help us do this. I will add > your email address and the keyword "ariadne" to this capability. > > I apologize for the inconvenience and hope that our quick response is > satisfactory. > > > > Regards, > Steve Christey > CVE Editor > > ====================================================== > Candidate: CAN-2005-1181 > URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1181 > Reference: OSVDB:15549 > Reference: URL:http://www.osvdb.org/15549 > Reference: SECTRACK:1013721 > Reference: URL:http://securitytracker.com/id?1013721 > Reference: XF:ariadne-loaderphp-file-include(20611) > Reference: URL:http://xforce.iss.net/xforce/xfdb/20611 > > ** DISPUTED ** > > NOTE: this issue has been disputed by the vendor. PHP remote code > injection vulnerability in loader.php for Ariadne CMS 2.4 allows > remote attackers to execute arbitrary PHP code by modifying the > ariadne parameter to reference a URL on a remote web server that > contains the code. NOTE: the vendor has disputed this issue, saying > that loader.php first requires the "ariadne.inc" file, which defines > the $ariadne variable, and thus it cannot be modified by an attacker. > > > From jericho at attrition.org Thu Jul 7 04:49:30 2005 From: jericho at attrition.org (security curmudgeon) Date: Thu Jul 7 04:49:32 2005 Subject: [VIM] Quick.Cart - sql injections? (fwd) Message-ID: ---------- Forwarded message ---------- From: OpenSolution.org To: moderators@osvdb.org Date: Thu, 07 Jul 2005 10:44:32 +0200 Subject: [OSVDB Mods] Quick.Cart - sql injections? Welcome How You create SQL queries ? Quick.Cart have no SQL database then no sql queries. Please dont LIE!!! http://www.osvdb.org/16331 This is fixed in Quick.Cart v0.3.1 version http://www.osvdb.org/16330 -- email: info@opensolution.org www: http://opensolution.org From coley at mitre.org Thu Jul 7 14:30:52 2005 From: coley at mitre.org (Steven M. Christey) Date: Thu Jul 7 14:32:45 2005 Subject: [VIM] Vendor ACK for Quick.cart XSS (CAN-2005-1587) Message-ID: <200507071830.j67IUq1n006407@linus.mitre.org> While wandering the Quick.Cart site looking for a way to download without registering, just to try to figure out what lostmon got when he claimed the SQL injection vuln, I ran across this: http://opensolution.org/forum/?p=readTopic&nr=948 Quick.Cart v0.3.1 beta - please test it 2005-07-06 18:30:30 Changes: ... security changes: -- sWord variable used to find products is now parsed by htmlspecialchars( ) function -- checking order status in order print window - Steve From jericho at attrition.org Thu Jul 7 18:19:11 2005 From: jericho at attrition.org (security curmudgeon) Date: Thu Jul 7 18:19:14 2005 Subject: [VIM] Old Cisco vulnerability question.. (fwd) Message-ID: ---------- Forwarded message ---------- From: security curmudgeon To: tac@cisco.com Date: Thu, 7 Jul 2005 18:06:03 -0400 (EDT) Subject: Old Cisco vulnerability question.. I'm digging into some old vulnerabilities and ran across an old Cisco issue (http://www.cisco.com/warp/public/707/2.html) dated Jun 1 16:27:08 PDT 1995. Looking back through the CERT advisories, I found one (http://www.cert.org/advisories/CA-1992-20.html) that appears to cover the same issue, but dated December 10, 1992. The obvious difference here is the versions affected (10.0 - 10.3 on the Cisco advisory and 8.3 - 9.1 on the CERT advisory). Is this the same vulnerability that got re-introduced to the code base, or are there subtle differences that make these different vulnerabilities? Thanks for any help you can provide! Brian OSVDB.org From jericho at attrition.org Thu Jul 7 18:19:16 2005 From: jericho at attrition.org (security curmudgeon) Date: Thu Jul 7 18:19:19 2005 Subject: [VIM] Old Cisco vulnerability question.. (fwd) Message-ID: ---------- Forwarded message ---------- From: tac@cisco.com To: jericho@attrition.org Date: Fri, 08 Jul 2005 03:42:51 +0530 Subject: Old Cisco vulnerability question.. Please include the following line in all replies. Tracking number: CT20050707_0000002505 Dear Brian, Thank you for your email to tac@cisco.com Unfortunately we did not receive enough information to process your technical support request. If you have access to the internet, we recommend that you open your service request using our online TAC Service Request Tool located at http://www.cisco.com/TAC . The TAC Service Request Tool prompts you for all of the information that is required to open a service request. The tool's questions, fields, and drop-down menu options quickly give Cisco engineers the information they need to assist you. It typically takes less than two minutes to open a service request online. In order to use the TAC Service Request Tool, you will need to have a valid Cisco service contract associated with your ID. For information regarding Cisco.com registration, please see http://www.cisco.com/register/ If you choose to continue to request support on this issue by email, please make sure that your original email remains attached below by using the reply function on your email to respond. Please complete and validate all of the required fields highlighted with * on the following form. We are unable to open a case without this information. REQUIRED INFORMATION * CONTACT NAME: * CONTACT PHONE NUMBER: * CONTACT CISCO.COM USERID (if one exists): * CONTACT EMAIL ADDRESS: * CONTRACT #: * SERIAL #: * PRODUCT TYPE (Model Number): * SOFTWARE VERSION: * COMPANY NAME: * EQUIPMENT LOCATION (Address): * BRIEF PROBLEM DESCRIPTION: You may also wish to include some of the following additional information - ADDITIONAL INFORMATION (if applicable) ALTERNATE CONTACT NAME: ALTERNATE CONTACT PHONE: PICA I.D.: ON SITE PHONE: PAGER #: MOBILE #: BUSINESS IMPACT (Low/Medium/High): Best Regards, Sumod Mathews Cherian Cisco Systems, Inc. > -----Original Message----- > From: security curmudgeon > Sent: Jul 8, 2005 3:36:03 AM IST > To: tac@cisco.com > > > I'm digging into some old vulnerabilities and ran across an old Cisco > issue (http://www.cisco.com/warp/public/707/2.html) dated Jun 1 16:27:08 > PDT 1995. Looking back through the CERT advisories, I found one > (http://www.cert.org/advisories/CA-1992-20.html) that appears to cover the > same issue, but dated December 10, 1992. > > The obvious difference here is the versions affected (10.0 - 10.3 on the > Cisco advisory and 8.3 - 9.1 on the CERT advisory). Is this the same > vulnerability that got re-introduced to the code base, or are there subtle > differences that make these different vulnerabilities? > > Thanks for any help you can provide! > > Brian > OSVDB.org > From jericho at attrition.org Thu Jul 7 18:19:24 2005 From: jericho at attrition.org (security curmudgeon) Date: Thu Jul 7 18:19:26 2005 Subject: [VIM] Re: Old Cisco vulnerability question.. (fwd) Message-ID: ---------- Forwarded message ---------- From: security curmudgeon To: tac@cisco.com Date: Thu, 7 Jul 2005 18:19:06 -0400 (EDT) Subject: Re: Old Cisco vulnerability question.. : Please include the following line in all replies. : Tracking number: CT20050707_0000002505 : If you have access to the internet, we recommend that you open your : service request using our online TAC Service Request Tool located at : http://www.cisco.com/TAC . The TAC Service Request Tool prompts you for : all of the information that is required to open a service request. The : tool's questions, fields, and drop-down menu options quickly give Cisco : engineers the information they need to assist you. It typically takes : less than two minutes to open a service request online. In order to use : the : : TAC Service Request Tool, you will need to have a valid Cisco service : contract associated with your ID. : If you choose to continue to request support on this issue by email, : please make sure that your original email remains attached below by : using the reply function on your email to respond. Please complete and : validate all of the required fields highlighted with * on the following : form. We are unable to open a case without this information. I do not have a valid Cisco contract. Is there any way to receive an answer to this question without such a contract? Brian : REQUIRED INFORMATION : : * CONTACT NAME: : * CONTACT PHONE NUMBER: : * CONTACT CISCO.COM USERID (if one exists): : * CONTACT EMAIL ADDRESS: : * CONTRACT #: : * SERIAL #: : * PRODUCT TYPE (Model Number): : * SOFTWARE VERSION: : * COMPANY NAME: : * EQUIPMENT LOCATION (Address): : * BRIEF PROBLEM DESCRIPTION: : : You may also wish to include some of the following additional information : - : : ADDITIONAL INFORMATION (if applicable) : ALTERNATE CONTACT NAME: : ALTERNATE CONTACT PHONE: : PICA I.D.: : ON SITE PHONE: : PAGER #: : MOBILE #: : BUSINESS IMPACT (Low/Medium/High): : : Best Regards, : Sumod Mathews Cherian : Cisco Systems, Inc. : : : > -----Original Message----- : > From: security curmudgeon : > Sent: Jul 8, 2005 3:36:03 AM IST : > To: tac@cisco.com : > : > : > I'm digging into some old vulnerabilities and ran across an old Cisco : > issue (http://www.cisco.com/warp/public/707/2.html) dated Jun 1 16:27:08 : > PDT 1995. Looking back through the CERT advisories, I found one : > (http://www.cert.org/advisories/CA-1992-20.html) that appears to cover the : > same issue, but dated December 10, 1992. : > : > The obvious difference here is the versions affected (10.0 - 10.3 on the : > Cisco advisory and 8.3 - 9.1 on the CERT advisory). Is this the same : > vulnerability that got re-introduced to the code base, or are there subtle : > differences that make these different vulnerabilities? : > : > Thanks for any help you can provide! : > : > Brian : > OSVDB.org : > : From jericho at attrition.org Fri Jul 8 00:32:23 2005 From: jericho at attrition.org (security curmudgeon) Date: Fri Jul 8 00:32:25 2005 Subject: [VIM] [OSVDB Mods] [Change Request] 17460: Whois.Cart language Variable Traversal Arbitrary File Access (fwd) Message-ID: ---------- Forwarded message ---------- From: S. Alexandre M. Lemaire To: moderators@osvdb.org Date: Fri, 8 Jul 2005 00:27:57 -0400 Subject: [OSVDB Mods] [Change Request] 17460: Whois.Cart language Variable Traversal Arbitrary File Access Dear OSVDB, I'm writing to report that this vulnerability is false and it would be appreciated if it could be removed immediately. We're willing to provide you with a test environment on which you can confirm our claim if the links below do not satisfy. Note that the script's nature, being PHP, is subject to it's environments security as well. Further, the reportedly affected components are subject to user modification, and could have been compromised by an uncautious customization on behalf of an unknowing user, if not a poorly configured operating platform. I can ensure that user input, using the script in default form, is properly sanitized. Your "manual testing notes" on even our online demo, fail outright: http://[victim]/whoiscart/?language=../../../../../../../../../../../../../etc/passwd%00 replace with the url of our demo: http://demo.whoiscart.net/?language=../../../../../../../../../../../../../etc/passwd%00 Achieves no result whatsoever. The demo is running a publically released version. Should you refuse to comply however, kindly provide your mailing address and legal contact that our counsel may contact you appropriately; loss of business incurred by such falsifications posted in public mediums could be severe and should be remedied. We've recently received blackmail threats from a certain individual - it is all too coincidental that these would appear just now after the latter threat. We believe these to be malicious acts by this same wrongdoer, your assistance in the matter is appreciated. I hope you can agree, that businesses should not be subject to the whims of anonymous wrongdoers. Careful examination of the link above will hopefully display that your posting, is just such a maliciously intended act. Regards. S. Alexandre Lemaire, President, saeven.net saeven@saeven.net From jericho at attrition.org Fri Jul 8 01:24:26 2005 From: jericho at attrition.org (security curmudgeon) Date: Fri Jul 8 01:24:28 2005 Subject: [VIM] Re: [Change Request] 17460: Whois.Cart language Variable Traversal Arbitrary File Access (fwd) Message-ID: Removed attachment per his request, but both Whois.Cart vulnerabilities are being disputed. I am editing the OSVDB entries shortly to reflect this. ---------- Forwarded message ---------- From: S. Alexandre M. Lemaire To: security curmudgeon Date: Fri, 8 Jul 2005 01:11:25 -0400 Subject: Re: [Change Request] 17460: Whois.Cart language Variable Traversal Arbitrary File Access [..] Thank you also for having pointed out the second listed vulnerability - I'd missed that one entirely! Please find an unencoded profile.php (sent with all trust that it shant be disclosed) attached to this email as sign of good will, you will see between lines 69-72 that the input is well-sanitized, removing all but alphanumericals and underscores with : if( postAssert( 'page' ) ) $template = ereg_replace( "[^[:alnum:]_]", "", $_POST['page'] ); else if( isset( $_GET['page'] ) ) $template = ereg_replace( "[^[:alnum:]_]", "", $_GET['page'] ); The architecture was left open as such, in order to leave users the ability to call other pages from the template directory directly (profile.php is a driving page for client profiles in whois.cart) - the sanitization prevents the obvious. [..] From jericho at attrition.org Fri Jul 8 08:40:59 2005 From: jericho at attrition.org (security curmudgeon) Date: Fri Jul 8 08:41:01 2005 Subject: [VIM] Re: A few more apps vulnerable to PHP XML-RPC exploits (fwd) Message-ID: ---------- Forwarded message ---------- From: security curmudgeon To: GulfTech Security Research Cc: OSVDB Date: Fri, 8 Jul 2005 07:39:59 -0400 (EDT) Subject: [OSVDB Mods] Re: A few more apps vulnerable to PHP XML-RPC exploits Hey James, I haven't had time to dig into the details of this, but the amount of applications vulnerable due to this flaw is pretty amazing. Based on your extensive research, how do you see these vulnerabilities as they relate to each other? Is this truly a single vulnerability affecting many products because they use the same vulnerable code? Or are these slightly different because each product implements the routines differently? We're still debating on whether this gets one entry in OSVDB, or gets broken out (like CVE appears to be doing). Thanks for any insight! Brian OSVDB.org From jericho at attrition.org Fri Jul 8 08:41:14 2005 From: jericho at attrition.org (security curmudgeon) Date: Fri Jul 8 08:41:15 2005 Subject: [VIM] Re: A few more apps vulnerable to PHP XML-RPC exploits (fwd) Message-ID: ---------- Forwarded message ---------- From: GulfTech Security Research To: security curmudgeon Date: Fri, 08 Jul 2005 07:33:55 -0500 Subject: Re: A few more apps vulnerable to PHP XML-RPC exploits Hi Brian, I have actually wanted to post this info on my website for some time now, but have been too busy, but feel free to share this info as a lot of sources have the wrong information. 1) If an application is using the vulnerable phpxmlrpc then it is vulnerable regardless of how they implement it really. This is because the vulnerability occurs as the incoming data is being parsed by the xmlrpc server. For example, exploit code released for the PostNuke or Drupal xmlrpc issues will easily work on anything else vulnerable to the issue. I would say the only difference is that some applications that are vulnerable did not name the file xmlrpc.php, but otherwise it is all the same. 2) XOOPS as far as I know NEVER used any type of the vulnerable phpxmlrpc libraries. I did find a vulnerability in their xmlrpc interface, but it was an sql injection issue, and not remote code execution. 3) The vulnerabilities I reported in WordPress that prompted the release of 1.5.1.3 were NOT related to the phpxmlrpc issues, but instead were like the XOOPS issues, and just a standard case of highly exploitable SQL Injection. However, it has been confirmed by a WordPress team member that people using WordPress version earlier than 1.5 ARE vulnerable to the phpxmlrpc vulnerability. So, they used to use it but do not use it anymore :) I hope this helps as even CERT has the wrong info it seems. Kind Regards, James security curmudgeon wrote: > Hey James, > > I haven't had time to dig into the details of this, but the amount of > applications vulnerable due to this flaw is pretty amazing. > > Based on your extensive research, how do you see these vulnerabilities as > they relate to each other? Is this truly a single vulnerability affecting > many products because they use the same vulnerable code? Or are these > slightly different because each product implements the routines differently? > > We're still debating on whether this gets one entry in OSVDB, or gets broken > out (like CVE appears to be doing). > > Thanks for any insight! > > Brian > OSVDB.org > > From coley at linus.mitre.org Fri Jul 8 13:23:05 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri Jul 8 13:25:44 2005 Subject: [VIM] Re: A few more apps vulnerable to PHP XML-RPC exploits (fwd) In-Reply-To: References: Message-ID: On Fri, 8 Jul 2005, security curmudgeon wrote: > We're still debating on whether this gets one entry in OSVDB, or gets > broken out (like CVE appears to be doing). CVE is doing this by accident because certain applications aren't directly saying that they're vulnerable to this particular problem, and we've only just become aware of how much this is being used. The normal approach in CVE is to assign one identifier per codebase, regardless of how many applications use it. This obviously has its own difficulties, especially for people who use CVE to track vulnerabilities in specific deployed applications in their enterprise. On the other hand, if someone asks "hey, I've been hearing about this XML-RPC bug, does product X have it?" they have a better chance of answering that question. This is one example why CVE is an 80% solution for everybody but not a 100% solution for anybody. zlib is another good example of a library that's heavily used across many products. - Steve From jericho at attrition.org Fri Jul 8 19:10:39 2005 From: jericho at attrition.org (security curmudgeon) Date: Fri Jul 8 19:10:41 2005 Subject: [VIM] Re: A few more apps vulnerable to PHP XML-RPC exploits (fwd) In-Reply-To: References: Message-ID: : > We're still debating on whether this gets one entry in OSVDB, or gets : > broken out (like CVE appears to be doing). : : CVE is doing this by accident because certain applications aren't : directly saying that they're vulnerable to this particular problem, and : we've only just become aware of how much this is being used. : : The normal approach in CVE is to assign one identifier per codebase, : regardless of how many applications use it. This obviously has its own : difficulties, especially for people who use CVE to track vulnerabilities : in specific deployed applications in their enterprise. On the other : hand, if someone asks "hey, I've been hearing about this XML-RPC bug, : does product X have it?" they have a better chance of answering that : question. This is one example why CVE is an 80% solution for everybody : but not a 100% solution for anybody. Right. I certainly see value in breaking it out by product, especially when implementations may vary a bit or there are other mitigating circumstances that are product/vendor specific. : zlib is another good example of a library that's heavily used across : many products. Yah, these two vulns (zlib/xmlrpc) are fairly nasty due to that alone. From coley at mitre.org Mon Jul 11 17:04:13 2005 From: coley at mitre.org (Steven M. Christey) Date: Mon Jul 11 17:06:27 2005 Subject: [VIM] Provable ACK for SPiD lang.php file include Message-ID: <200507112104.j6BL4Duw029570@linus.mitre.org> Ref: SECTRACK:1014437 (CAN-2005-2198 forthcoming) Changelog: http://spid.adnx.net/index_en.html#log The changelog for 1.3.1, which was updated on 2005/07/11, says "Fix vulnerability in lang.php (For those using 1.3.0, you just have to copy the new lang/lang.php file over)." A look at lang.php shows that it exits if $lang_path is set by an HTTP request. - Steve From jericho at attrition.org Tue Jul 12 04:18:30 2005 From: jericho at attrition.org (security curmudgeon) Date: Tue Jul 12 04:18:38 2005 Subject: [VIM] Re: [badroot security] probe.cgi: Remote Command Execution In-Reply-To: <42CB0712.9020002@mybox.it> References: <42CB0712.9020002@mybox.it> Message-ID: Hi Mozako, : BADROOT SECURITY GROUP : Security Advisory 2005 - #0x06 : Product ....... probe.cgi After a brief search on Google, I can't find the vendor home page or distribution point for this software. Do you happen to remember where it can be found? Thanks Brian From coley at linus.mitre.org Tue Jul 12 13:58:35 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue Jul 12 14:00:41 2005 Subject: [VIM] Re: [badroot security] probe.cgi: Remote Command Execution In-Reply-To: References: <42CB0712.9020002@mybox.it> Message-ID: On Tue, 12 Jul 2005, security curmudgeon wrote: > : Product ....... probe.cgi I did a lot of looking for this myself yesterday. The closest I got was some product for grid/cluster software monitoring developed in Thailand, but I couldn't find a usable download, gave up, and forgot to write down a summary of what I had found. I have no idea if I was even barking up the right tree since I couldn't find a usable probe.cgi from that product. Oh wait, here it is - OpenSCE SCMSWeb was the product I was *GUESSING* at. No idea if it has a probe.cgi. There's a probe.cgi in scmsweb-3.0.10.tar.gz from here: ftp://osl.cpe.ku.ac.th/pub/sce/current/src/ But probe.cgi doesn't seem to have anything related to "olddat", and in fact a grep through all the files yields nothing. So, it's not SCMSWeb. - Steve From coley at mitre.org Wed Jul 13 02:32:25 2005 From: coley at mitre.org (Steven M. Christey) Date: Wed Jul 13 02:34:36 2005 Subject: [VIM] Likely errors in PhpAuction report Message-ID: <200507130632.j6D6WPio002421@linus.mitre.org> Regarding Diabolic Crab's report on PhpAuction vulns, archived here: SECTRACK:1014423 URL:http://securitytracker.com/id?1014423 (CAN-2005-2252, CAN-2005-2253, and CAN-2005-2254 forthcoming) has a couple oddnesses about them. Specifically, some URLs contain "/phpauction-gpl-2.5/" whereas others don't. There is further evidence from the raw error outputs that some, or all, of these results were obtained by testing on a live web site. Given this, there is some evidence that the "viewnews.php" and "login.php" errors are specific to the live web site and *not* the PhpAuction product; however the PhpAuction source code isn't available so I can't be sure. Normally I might not comment on this but if I'm right, then a lot of DB's didn't catch this. - Steve From jericho at attrition.org Wed Jul 13 02:45:48 2005 From: jericho at attrition.org (security curmudgeon) Date: Wed Jul 13 02:45:50 2005 Subject: [VIM] Likely errors in PhpAuction report In-Reply-To: <200507130632.j6D6WPio002421@linus.mitre.org> References: <200507130632.j6D6WPio002421@linus.mitre.org> Message-ID: : Regarding Diabolic Crab's report on PhpAuction vulns, archived here: : : SECTRACK:1014423 : URL:http://securitytracker.com/id?1014423 : : (CAN-2005-2252, CAN-2005-2253, and CAN-2005-2254 forthcoming) : : has a couple oddnesses about them. Specifically, some URLs contain : "/phpauction-gpl-2.5/" whereas others don't. : : There is further evidence from the raw error outputs that some, or all, : of these results were obtained by testing on a live web site. He has tested live sites to find many of his previous vulnerabilities. I have called him on it in private mails and even got into a small spat with him with a vendor CC'd. =) Some of his previous reports were just unclear. Others screamed 'live site only'. Some of them were redundant or had been previously disclosed. : Given this, there is some evidence that the "viewnews.php" and : "login.php" errors are specific to the live web site and *not* the : PhpAuction product; however the PhpAuction source code isn't available : so I can't be sure. : : Normally I might not comment on this but if I'm right, then a lot of : DB's didn't catch this. I haven't created entries for these because I haven't had time to look at his info closely, something we learned is a must based on his past vulnerability disclosures. From coley at mitre.org Wed Jul 13 14:15:24 2005 From: coley at mitre.org (Steven M. Christey) Date: Wed Jul 13 14:17:34 2005 Subject: [VIM] Typo in "RCP/Encoded" ASP.NET DoS Message-ID: <200507131815.j6DIFOGm011774@linus.mitre.org> Ref: CAN-2005-2224 The SPI Dynamics advisory on "RCP/Encoded" in ASP.NET contained a typo. In fact it should be "RPC" and not "RCP". I've confirmed the correction with them. Thanks to Kurt Seifried for pointing this out to me. I thought it looked odd when I wrote up the description, but I didn't do the 10-second Google search to make sure :) - Steve From jericho at attrition.org Wed Jul 13 17:56:58 2005 From: jericho at attrition.org (security curmudgeon) Date: Wed Jul 13 17:57:00 2005 Subject: [VIM] Re: Secunia published adviso without respectingrelease date ! (fwd) Message-ID: Interesting. His /adviso/ folder is public I take it, and previous advisories were disclosed there. Seems like it is fair game if there are no restrictions put in place to stop people from accessing the content. ---------- Forwarded message ---------- From: ad@class101.org To: exploits@zataz.net Cc: full-disclosure@lists.grok.org.uk Date: Wed, 13 Jul 2005 23:45:23 +0200 Subject: Re: [Full-disclosure] Secunia published adviso without respectingrelease date ! -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Then don't send to Secunia b4 the rls date ! HUH - -----Message d'origine----- De : full-disclosure-bounces@lists.grok.org.uk [mailto:full-disclosure-bounces@lists.grok.org.uk] De la part de Eric Romang Envoy? : mardi 12 juillet 2005 21:09 ? : support@secunia.com Cc : full-disclosure@lists.grok.org.uk; Eric Romang Objet : [Full-disclosure] Secunia published adviso without respectingrelease date ! Hello, This adviso are published on your website, but the patch are not already ok. I have contact upstream today, before you release the adviso, so they could react. As you can see in the adviso, the release date was not given !!!! http://secunia.com/advisories/16040/ http://secunia.com/advisories/16040/ http://secunia.com/advisories/16038/ You release adviso without respect the normal process to publish adviso. This guy is monitoring my /adviso/ folder. 80.161.200.182 I think this guy is working for you. So please say to him to respect the normal process in a security process. Regards. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2rc2 (MingW32) iQIVAwUBQtWLU6+LRXunxpxfAQL+1w/+IE947ec5TVHTUox8RC5JCSSAkk+C3GTf wAvkTzYoN7p0LLgFOGmf0oZUQytxQ1QKjgRSv0WeHM3sh/ZX3E33l6z+1aPwLOsO asJDVVYHoxJMTbxccO01dM724UvANPvfO68Y3YHOIcZupJQhzuIqIR8u+clUwwpc M7bToYBMaQbyGKCPuBpVdUqK8DVuXj9Q/+Fz8G+2kvEfM/leGhkOh55AWqcQyyJ0 YMEYFz4pxoR7HnYvMbxh3GLdRda0YhQj12uNw29VacLDmlYJ9JEIp2skfuk/nMM/ CMoVGMHz+HbOhBJTOYoLvqVUcPB9rahXNxgRHas/z8gydFUYzY8IXF5oWlAnw6UQ XrAYR9EvEJaXFO+FqDAoppEnvfv7NNm+dzs5yZCZM1cKel028Zg95sKkzjoAnqZA CfVke2I7/0nFX3gnq/Ka54reKKKk0U732zwV1RFqanmaVueCsmoj8IhbL+3Gc1So fwuhG5uGXskTqVh0qr3FMxXgf9dHDJqzZyTIS2Wi2St8SZzAQSOfIpZ8tuOA4YQO QK3hIOExKFDzZXSidlZzR0455YQKEyzjuylctWRcZwx51a/E6u1/ZDty/DRgO37S d4YFiD0za38qE7Etu5nEG1CZIhlU5mroKCqE00ld97eu9rv2tUeYC/aN4W+wnOTm S6Q77U46E8A= =VbS3 -----END PGP SIGNATURE----- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ From coley at linus.mitre.org Wed Jul 13 18:06:39 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed Jul 13 18:08:51 2005 Subject: [VIM] Re: Secunia published adviso without respectingrelease date ! (fwd) In-Reply-To: References: Message-ID: On Wed, 13 Jul 2005, security curmudgeon wrote: > Interesting. His /adviso/ folder is public I take it, and previous > advisories were disclosed there. Seems like it is fair game if there are > no restrictions put in place to stop people from accessing the content. Agreed. If vuln DB's are going to be complete, they're going to monitor these kinds of things anyway. How could Secunia or any other organization know when it's been really "published" or not? If it's on a public site then that's that. On a side note... so THAT'S where Secunia got the Romang advisories that I couldn't find anywhere else! I had to create some CAN's with only the Secunia advisory as a reference, but I like to point to the original researcher advisory whenever possible. - Steve From jericho at attrition.org Wed Jul 13 18:10:08 2005 From: jericho at attrition.org (security curmudgeon) Date: Wed Jul 13 18:10:10 2005 Subject: [VIM] Re: Secunia published adviso without respectingrelease date ! (fwd) In-Reply-To: References: Message-ID: : > Interesting. His /adviso/ folder is public I take it, and previous : > advisories were disclosed there. Seems like it is fair game if there are : > no restrictions put in place to stop people from accessing the content. : : Agreed. If vuln DB's are going to be complete, they're going to monitor : these kinds of things anyway. How could Secunia or any other : organization know when it's been really "published" or not? If it's on : a public site then that's that. : : On a side note... so THAT'S where Secunia got the Romang advisories that : I couldn't find anywhere else! I had to create some CAN's with only the : Secunia advisory as a reference, but I like to point to the original : researcher advisory whenever possible. Likewise! They still manage to dig up some stuff that I can't find reference to anywhere else. I have a feeling they keep a comprehensive list of these types of URLs to check. OSVDB does too, but I just don't have time to check them near as frequently as i'd like. From jericho at attrition.org Thu Jul 14 05:14:28 2005 From: jericho at attrition.org (security curmudgeon) Date: Thu Jul 14 05:14:31 2005 Subject: [VIM] Re: Quick.Cart - sql injections? (fwd) Message-ID: ---------- Forwarded message ---------- From: Lostmon To: security curmudgeon Date: Thu, 14 Jul 2005 11:11:04 +0200 Subject: Re: [OSVDB Mods] Quick.Cart - sql injections? (fwd) De: Lostmon Responder a: Lostmon Para: "OpenSolution.org" Fecha: 14-jul-2005 11:09 Asunto: Re: Quick.Cart - sql injections? hiz : yes this is true , in a few days a go to update my advisore and send to security list the update , this is a simple variable injection , not a SQL injection. thnx for your time !! 2005/7/7, OpenSolution.org : - Mostrar texto citado - > Welcome > > How You create SQL queries ? > There is: > NO SQL DATABASE = NO SQL QUERIES = NO SQL INJECTION > > Please dont LIE!!! > > http://lostmon.blogspot.com/2005/05/quickcart-sword-variable-xss-and.html > > "Quick.cart 'sWord' variable XSS" -> This is fixed in Quick.Cart v0.3.1 > version > > -- > email: info@opensolution.org > www: http://opensolution.org > > > -- atentamente: Lostmon (lostmon@gmail.com) Web-Blog: http://lostmon.blogspot.com/ -- La curiosidad es lo que hace mover la mente.... 2005/7/7, security curmudgeon : > > > ---------- Forwarded message ---------- > From: OpenSolution.org > To: moderators@osvdb.org > Date: Thu, 07 Jul 2005 10:44:32 +0200 > Subject: [OSVDB Mods] Quick.Cart - sql injections? > > Welcome > > How You create SQL queries ? Quick.Cart have no SQL database then no sql > queries. > Please dont LIE!!! > > http://www.osvdb.org/16331 > > This is fixed in Quick.Cart v0.3.1 version > http://www.osvdb.org/16330 > > -- > email: info@opensolution.org > www: http://opensolution.org > -- atentamente: Lostmon (lostmon@gmail.com) Web-Blog: http://lostmon.blogspot.com/ -- La curiosidad es lo que hace mover la mente.... From jericho at attrition.org Thu Jul 14 14:58:29 2005 From: jericho at attrition.org (security curmudgeon) Date: Thu Jul 14 14:58:31 2005 Subject: [VIM] Re: [Full-disclosure] Secunia published adviso without respectingrelease date ! (fwd) Message-ID: ---------- Forwarded message ---------- From: Xavier Beaudouin To: "" Cc: full-disclosure@lists.grok.org.uk Date: Thu, 14 Jul 2005 12:59:49 +0200 Subject: Re: [Full-disclosure] Secunia published adviso without respectingrelease date ! This is usual with secunia.. I had at "bug" in a beta version of software and they "release" a vulnerability to *all* version of this software without even inform the maintainer (me) of this "pseudo advisory". My thought with this guys are now : don't even trust them... They push advisory without testing and respect the usual way to inform developper as it should. My 0,02? /xavier From jericho at attrition.org Thu Jul 14 18:52:10 2005 From: jericho at attrition.org (security curmudgeon) Date: Thu Jul 14 18:52:12 2005 Subject: [VIM] Re: [badroot security] probe.cgi: Remote Command Execution In-Reply-To: References: <42CB0712.9020002@mybox.it> Message-ID: : > : Product ....... probe.cgi : : I did a lot of looking for this myself yesterday. The closest I got was : some product for grid/cluster software monitoring developed in Thailand, : but I couldn't find a usable download, gave up, and forgot to write down : a summary of what I had found. I have no idea if I was even barking up : the right tree since I couldn't find a usable probe.cgi from that : product. [..] As an update.. no reply to my mail asking about the vendor. From jericho at attrition.org Fri Jul 15 06:13:46 2005 From: jericho at attrition.org (security curmudgeon) Date: Fri Jul 15 06:13:47 2005 Subject: [VIM] Typo in "RCP/Encoded" ASP.NET DoS In-Reply-To: <200507131815.j6DIFOGm011774@linus.mitre.org> References: <200507131815.j6DIFOGm011774@linus.mitre.org> Message-ID: : Ref: CAN-2005-2224 : : The SPI Dynamics advisory on "RCP/Encoded" in ASP.NET contained a typo. : In fact it should be "RPC" and not "RCP". I've confirmed the correction : with them. : : Thanks to Kurt Seifried for pointing this out to me. I thought it : looked odd when I wrote up the description, but I didn't do the : 10-second Google search to make sure :) http://www.secunia.com/advisories/16005/ ASP.NET RCP/encoded Mode DoS ^^^ Most days I would have caught this. This week however, I almost let this fly by but your mail stopped me =) While creating the entry I kept it in mind that you had mailed about that, and checked it in time. From coley at mitre.org Fri Jul 15 14:35:52 2005 From: coley at mitre.org (Steven M. Christey) Date: Fri Jul 15 14:38:10 2005 Subject: [VIM] Why Vulnerability Databases can't do everything Message-ID: <200507151835.j6FIZqxu007856@linus.mitre.org> Regarding a particular vulnerability database, Xavier Beaudouin said: >They push advisory without testing and respect the usual way to inform >developper as it should. (name omitted simply because it could have been about any vuln database.) No doubt a lot of what I'm about to say was covered by Brian Martin at CanSecWest this year, however... Vulnerability databases and notification services have to pore through approximately 100 new public vulnerability reports a week. Correction: that's HUNDREDS of reports, from diverse and often unproven sources, for about 100 unique vulnerabilities per week. A LARGE number of vendors and maintainers either: (1) are unresponsive to email inquiries (about half my emails go unanswered, about 20% of the ones that do answer, don't answer my questions) (2) make you register or require you to be a customer to access their product "support" (3) don't have good contact information in the first place (4) don't want to tell you anything about whether they've fixed a publicly reported vuln or not, for fear of giving out too much information. (5) sometimes require hand-holding if they don't understand the vuln report In addition, vulnerability databases and notification services have to: (1) navigate through large numbers of poorly written researcher advisories that are riddled with mistakes, which often were not coordinated with the vendor in the first place (possibly due to the own researcher's troubles contacting the vendors). (2) somehow refine and present this stuff in a usable format for the consumer (3) where possible, obtain better information either by researching the issue themselves or contacting the vendor Most advisories, whether they come from researchers, vendors, or third parties, suffer from one or more of the "Four I's" problems: - Incomplete - Inaccurate - Inconsistent - Incomprehensible And think about what would be required for testing every claim - 100 vulnerabilities per week, many of them in commercial software, across every conceivable platform, OS, and execution environment. Who has the labs and the resources to cover all that? Nobody. Absolutely nobody. You're talking a 10 million dollar investment AT LEAST just for a lab that would cover major versions of the most popular software, and that probably excludes the labor for coordinating with vendors or performing verification. And this is happening in a context where: - consumers want perfect information - they want it the moment an issue becomes public - they don't want to pay a lot for it (which makes me think of the sign on my office door: "Vulnerabiltiy information: fast, cheap, or good. Pick any two.") In other words, it's just not possible to fully evaluate and verify every single public vulnerability report. So, you prioritize and do what you can with the available information. Every VDB and notification service that I'm aware of absolutely HATES having bad information. They will GLADLY post corrections when they are notified. And, hopefully, they can share this information with other VDB's. OSVDB and CVE have begun to do just that, and the result is an improvement in the quality of both databases and, consequently, better information for all their consumers. Despite all the criticism of VDB's and notification services, they do a lot of work behind the scenes that few people seem to fully appreciate. By no means are they perfect, but you can't create perfection out of chaos. - Steve From jericho at attrition.org Fri Jul 15 15:01:19 2005 From: jericho at attrition.org (security curmudgeon) Date: Fri Jul 15 15:01:21 2005 Subject: [VIM] On classifying attacks (fwd) Message-ID: ---------- Forwarded message ---------- From: Derek Martin To: bugtraq@securityfocus.com Date: Thu, 14 Jul 2005 22:39:30 -0400 Subject: On classifying attacks The issue has come up on bugtraq before, but I think it is worth raising it again. The question is how to classify attacks against users' client programs which come from the Internet, e.g. an e-mail carrying a malicious trojan horse payload. The reason this is important is because we judge how serious a particular vulnerability is based on how it is classified. We normally ask two main questions: - Is this a root vulnerability, i.e. does it have the potential grant the attacker the privileges of the system management account? - Is the vulnerability remotely exploitable? The latter is a question which, when an answer is attempted, sometimes raises debate. The case of the trojan e-mail is a prime example of this. Some are tempted to call this a remote exploit. The payload finds its way to the attacker's machine via a network, after all... The attacker isn't logged in to the victim's machine. Security researchers are also eager to publish remotely exploitable vulnerabilities, perhaps because such a vulnerability is generally considered to be much more severe than one that is not, and thus more notariety comes with publishing such a vulnerability. This kind of attack has a name already: it is a trojan horse. A malicious payload is disguised as an innocuous e-mail, usually with an attachment. Once the user views the e-mail, or possibly even when the mail client tries to display headers in the message index, a bug is triggered which unleashes the payload on the poor unsuspecting user. But is this a remote exploit? Examine what is happening when the exploit is executing. The payload is already on the user's system. It was delivered via some MTA (possibly the same program the user uses to read mail, possibly not) onto the user's filesystem. This is the remote part. But, usually, at this point there has been no exploit. Only after the user opens the mail, or looks at it in the message index, does the exploit happen. The payload is already local to the machine, and it is the action of a local user which triggers the exploit. It is a passive attack, launched by an attacker who can only HOPE that the user will fall into his trap, even if he knows the user is using vulnerable code. Nothing the attacker can do remotely will force the exploit to be triggered. Only once the user has acted will the payload become an exploit. This is not truly a remote exploit. By contrast, look at a remote exploit against BIND. An attacker launches the attack, which is an active attack... The attacker sends data directly to the running named daemon, in order to exploit some bug in the program. The actions of the attacker, if he is successful, are the direct cause of the compromise. Once the DNS server software has been started, no intervention is required by a user on the local system to effect the exploit. This is a true remote exploit. What is clear is that e-mail trojans, and other kinds of attacks which are similar in nature, ARE more of a threat than what we normally think of as local exploits, and should be treated as such. They have some similar characteristics to remotely exploitable vulnerabilities: they can allow an attacker who normally would not have authorized access, or even physical access, to gain access to the system. But they are not as severe as truly remote exploits, because often (if not most of the time) careful users can avoid the affects of such an attack, even though they may be running vulnerable code. So let's return to the questions we ask, when deciding how severe an attack may be. Perhaps what we need is not to call these remote exploits, but to ask a new question: Does the vulnerability make my system susceptible to trojan horse attacks? These vulnerabilities really should answer "no" to the remote exploit question, but "yes" to this new question. A yes answer here clearly indicates a more severe threat than a local exploit, but somewhat less of a threat than a truly remote exploit. Assessing the threat properly helps everyone. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D From coley at linus.mitre.org Fri Jul 15 15:07:07 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri Jul 15 15:09:25 2005 Subject: [VIM] On classifying attacks (fwd) In-Reply-To: References: Message-ID: Interesting. I *just* answered an e-mail from someone who asked why a vulnerability in an image processor was "remote" when he didn't process images by using networks. I think this example stretches the "Trojan horse" concept slightly, but it's definitely thinking in the right direction. But what would the adjective version of "remote attacker" and "local user" be in a Trojaned context? - Steve From jericho at attrition.org Fri Jul 15 15:11:37 2005 From: jericho at attrition.org (security curmudgeon) Date: Fri Jul 15 15:11:38 2005 Subject: [VIM] On classifying attacks (fwd) In-Reply-To: References: Message-ID: : Interesting. : : I *just* answered an e-mail from someone who asked why a vulnerability : in an image processor was "remote" when he didn't process images by : using networks. : : I think this example stretches the "Trojan horse" concept slightly, but : it's definitely thinking in the right direction. : : But what would the adjective version of "remote attacker" and "local : user" be in a Trojaned context? I'm on site with a client so I can't dive into this post this second (but i want to!). I plan to give it more thought and probably reply tonight since this is a) a core issue with VDBs b) heavily discussed among the OSVDB mods and c) a major shortcoming of most classification systems including our own and CVSS. So, more tonight =) From coley at linus.mitre.org Fri Jul 15 15:12:13 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri Jul 15 15:14:43 2005 Subject: [VIM] On classifying attacks (fwd) In-Reply-To: References: Message-ID: The main problem is, we know what we're all talking about but we don't know what to call it! - Steve From coley at mitre.org Fri Jul 15 17:25:06 2005 From: coley at mitre.org (Steven M. Christey) Date: Fri Jul 15 17:27:24 2005 Subject: [VIM] Errors and oddities in Phorum 5.0.11 XSS/SQl injection Message-ID: <200507152125.j6FLP6Pu015037@linus.mitre.org> CVE's forthcoming. OSVDB:11129 read.php SQL injection SECUNIA:12980 - generic XSS and SQL injection BID:11538 - generic XSS and SQL injection SECTRACK:1011921 - read.php SQL injection and XSS Looks like every VDB has a different spin on the details. Here's my take: - Positive Technologies releases report on SQL injection in read.php query string for Phorum 5.0.11 MISC:http://www.maxpatrol.com/advdetails.asp?id=15 MISC:http://www.maxpatrol.com/mp_advisory.asp Researcher claims issue is fixed in CVS. - Phorum releases 5.0.12. Changelog says "XSS really gone now" and "two instances of "fixed sql-injection issue" http://phorum.org/changelog-5.txt Not enough detail for me to be sure they fixed the SQL injection issue. - I search through CVS to try and find relevant diffs, but give up after a few minutes. - CVS changelog is more informative: http://phorum.org/cvs-changelog-5.txt * shows SQL injection in read.php *AND* file.php * lists XSS is in search.php For CVE, "mutual consistency" of researcher ("fixed in CVS") and vendor (fixed associated file in next version) is sufficient for acknowledgement of the read.php issue. Somewhere along the line: - VDB's linked the XSS to Positive Technologies - but they never report XSS - some VDB's only had the vendor changelog and so didn't know it was readphp - all/most VDB's missed that there are 2 SQL injections, one for read.php and one for file.php - some VDB's said the XSS was for read.php but there's no evidence of it. - Steve From jericho at attrition.org Sat Jul 16 05:25:02 2005 From: jericho at attrition.org (security curmudgeon) Date: Sat Jul 16 05:25:04 2005 Subject: [VIM] Re: [Full-disclosure] Secunia published adviso withoutrespectingrelease date ! (fwd) Message-ID: ---------- Forwarded message ---------- From: Xavier Beaudouin To: Jerome Athias Cc: full-disclosure@lists.grok.org.uk Date: Sat, 16 Jul 2005 11:17:50 +0200 Subject: Re: [Full-disclosure] Secunia published adviso withoutrespectingrelease date ! Le 16 juil. 05 ? 03:59, Jerome Athias a ?crit : > 2 things i remind myself... > > 1) http://seclists.org/lists/vulndiscuss/2004/Dec/0006.html Yes. I received this one. But I still don't agree that Secunia didn't take the time to inform The Caudium Group *before* sending this "advisory" to security lists. This is _not_ fair and positivement a bad way to be *respected* on security advisory. This also the reason why we decided (we = caudium group) to close bug tracker at sourceforge to avoid false information to be sent. Usualy the idea is : bug/security problems found -> draft of advisory is sent to developpers to get more accurate information -> time to make a fix -> advisory is sent Secunia has just taken a bug from our tracker *without* telling the Caudium Group that are taking this for makeing a advisory, and just sent it to security lists with _false_ information. I still consider that this is half done work and they are not nice people when they make advisory. So because of that half done work, all Caudium Group developpers now don't trust anymore Secunia. I am sorry for them, but this is the way they make the advisory without contacting authors that give us this situation. > 2) This is an answer of Thomas before a disclosure of some vuln that Secunia > found "at the same time" : > > 10/09/2004 19:40 > > Re: OpenOffice World-Readable Temporary Files Disclose Files to Local Users > > Hi J?r?me, > > This issue was originally discovered by Secunia on 16th August and > reported to the vendors. > > Please do not forward to anyone else. The various vendors well release > updates on Wednesday in a co-ordinated disclosure. > > Kind regards, They didn't get so smarter with us. We still don't accept this fact. If they where so smart we still trust them. They were not so they are their own victim of their half work for Caudium group advisory. /Xavier _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ From coley at mitre.org Sun Jul 17 14:28:36 2005 From: coley at mitre.org (Steven M. Christey) Date: Sun Jul 17 14:31:01 2005 Subject: [VIM] Vendor ACK for SurgeLDAP issues Message-ID: <200507171828.j6HISaZ4013982@linus.mitre.org> Various SurgeLDAP issues are clearly acknowledged in the vendor's changelog here: http://netwinsite.com/surgeldap/updates.htm e.g. 1.0h acknowledges BID:10294 / SECTRACK:1010068 and 1.0e lists a slew of cross-references to VDB's. I didn't see any mention of the directory traversal issue reported in 2004 (page parameter in show command), however. - Steve From coley at mitre.org Sun Jul 17 17:33:18 2005 From: coley at mitre.org (Steven M. Christey) Date: Sun Jul 17 17:35:47 2005 Subject: [VIM] Dragonfly Commerce disputes reports Message-ID: <200507172133.j6HLXI0s021601@linus.mitre.org> Dragonfly Commerce has notified CVE of a dispute over some recent Diabolic Crab posts on price modification and SQL injection. Refs CAN-2005-2220 and CAN-2005-2221 below. >Recently, we found numerous but identical reports by >http://www.dbtech.org who claims to have found security holes in >Dragonfly Commerce. This report is unfounded. The text shown in this >report are results of error messages from the author typing in invalid >category and product numbers which do not exist in the database >therefore creating an error message from the server. Dragonfly >Commerce does not allow for editing prices nor does it allow for >viewing information about clients stored in the database except by the >store owner and authorized staff as appointed in the store >administration. > >We have not received nor have had any contact with the author of >these "security reports". We have no knowledge of any hidden pricing >and SQL vulnerablilties in our software. Had our clients experienced >any security vulnerabilities, they would have reported them to us >giving us the opportunity to update the software. We handle work >with each of our clients individually and quickly. Anyone finding >any discrepencies should contact info@incredibleinteractive.com - Steve ====================================================== Candidate: CAN-2005-2220 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2220 Reference: BUGTRAQ:20050712 Dragonfly Shopping Cart Multiple vulnerabilities Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=112121930328341&w=2 Reference: MISC:http://www.digitalparadox.org/viewadvisories.ah?view=46 Reference: SECTRACK:1014451 Reference: URL:http://securitytracker.com/id?1014451 ** DISPUTED ** Dragonfly Commerce allows remote attackers to change a product price by modifying the x_DragonflyCartProductPrice hidden field to (1) dc_Categorieslist.asp, (2) dc_Categoriesview.asp, (3) dc_productslist.asp, and (4) dc_productslist_Clearance.asp. NOTE: the vendor has disputed this issue, saying that "Dragonfly Commerce does not allow for editing prices nor does it allow for viewing information about clients stored in the database except by the store owner and authorized staff as appointed in the store administration." ====================================================== Candidate: CAN-2005-2221 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2221 Reference: BUGTRAQ:20050712 Dragonfly Shopping Cart Multiple vulnerabilities Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=112121930328341&w=2 Reference: MISC:http://www.digitalparadox.org/viewadvisories.ah?view=46 Reference: SECTRACK:1014451 Reference: URL:http://securitytracker.com/id?1014451 ** DISPUTED ** Multiple SQL injection vulnerabilities in Dragonfly Commerce allows remote attackers to modify SQL statements and possibly execute arbitrary SQL commands via the (1) key parameter to dc_Categoriesview.asp, (2) dc_productslist_Clearance.asp, (3) PID parameter to ratings.asp, (4) dc_Productsview.asp, (5) start, (6) key_mp, (7) searchtype, or (8) psearch parameters to dc_forum_Postslist.asp. NOTE: the vendor has disputed this issue, saying that the error messages arise from invalid category and product numbers. From jericho at attrition.org Sun Jul 17 19:23:29 2005 From: jericho at attrition.org (security curmudgeon) Date: Sun Jul 17 19:23:31 2005 Subject: [VIM] Dragonfly Commerce disputes reports In-Reply-To: <200507172133.j6HLXI0s021601@linus.mitre.org> References: <200507172133.j6HLXI0s021601@linus.mitre.org> Message-ID: : Dragonfly Commerce has notified CVE of a dispute over some recent : Diabolic Crab posts on price modification and SQL injection. : >Recently, we found numerous but identical reports by : >http://www.dbtech.org who claims to have found security holes in : >Dragonfly Commerce. This report is unfounded. The text shown in this : >report are results of error messages from the author typing in invalid : >category and product numbers which do not exist in the database : >therefore creating an error message from the server. Right.. merely inputting invalid content doesn't mean the product isn't vulnerable though. : >Dragonfly : >Commerce does not allow for editing prices nor does it allow for : >viewing information about clients stored in the database except by the : >store owner and authorized staff as appointed in the store : >administration. So far this is a he said, she said issue. Historically many vendors have said "we're not vulnerable" and offered little beyond that, only to find from subsequent examination that it was indeed vulnerable. : >We have not received nor have had any contact with the author of : >these "security reports". We have no knowledge of any hidden pricing : >and SQL vulnerablilties in our software. Except the dcrab advisory supposedly.. : >Had our clients experienced : >any security vulnerabilities, they would have reported them to us : >giving us the opportunity to update the software. We handle work : >with each of our clients individually and quickly. Anyone finding : >any discrepencies should contact info@incredibleinteractive.com Assuming the customer *noticed* it .. *and* diagnosed it .. *and* reported it. I really hate these types of disputes. From jericho at attrition.org Sun Jul 17 19:25:41 2005 From: jericho at attrition.org (security curmudgeon) Date: Sun Jul 17 19:25:43 2005 Subject: [VIM] vendor ack on PHPCounter Message-ID: ---------- Forwarded message ---------- From: Pierre Far X-Originating-IP: 131.111.234.246 To: moderators@osvdb.org Date: Sun, 17 Jul 2005 23:50:24 +0100 Subject: [OSVDB Mods] [OSVDB] New Vulnerability Hello I am the author of PHPCounter. Recently, 2 vulnerabilities we disclosed relating to PHPCounter 7.2. The details are at http://marc.theaimsgroup.com/?l=bugtraq&m=112129495128834&w=2 . I have now updated PHPCounter to version 7.3 to fix both problems. The problems don't seem to be major due to other security measures already in place. Still an upgrade is recommended. All the best, Pierre -- http://ekstreme.com Donate: http://ekstreme.com/paypal.php Link back: http://www.ekstreme.com/linkback.php From jericho at attrition.org Mon Jul 18 01:34:25 2005 From: jericho at attrition.org (security curmudgeon) Date: Mon Jul 18 01:34:27 2005 Subject: [VIM] Likely errors in PhpAuction report In-Reply-To: <200507130632.j6D6WPio002421@linus.mitre.org> References: <200507130632.j6D6WPio002421@linus.mitre.org> Message-ID: : (CAN-2005-2252, CAN-2005-2253, and CAN-2005-2254 forthcoming) : : has a couple oddnesses about them. Specifically, some URLs contain : "/phpauction-gpl-2.5/" whereas others don't. : : There is further evidence from the raw error outputs that some, or all, : of these results were obtained by testing on a live web site. : : Given this, there is some evidence that the "viewnews.php" and : "login.php" errors are specific to the live web site and *not* the : PhpAuction product; however the PhpAuction source code isn't available : so I can't be sure. Have you mailed the vendor about this? If not, I will. From coley at linus.mitre.org Mon Jul 18 02:00:51 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Mon Jul 18 02:03:21 2005 Subject: [VIM] Likely errors in PhpAuction report In-Reply-To: References: <200507130632.j6D6WPio002421@linus.mitre.org> Message-ID: On Mon, 18 Jul 2005, security curmudgeon wrote: > Have you mailed the vendor about this? If not, I will. I haven't asked them yet, so go ahead... - Steve From jericho at attrition.org Mon Jul 18 02:04:46 2005 From: jericho at attrition.org (security curmudgeon) Date: Mon Jul 18 02:04:48 2005 Subject: [VIM] Likely errors in PhpAuction report In-Reply-To: References: <200507130632.j6D6WPio002421@linus.mitre.org> Message-ID: : > Have you mailed the vendor about this? If not, I will. : : I haven't asked them yet, so go ahead... will do. given that the software costs money and i didn't see a free download link, your assumption seems dead on. regardless of his history of testing live sites =) From coley at linus.mitre.org Mon Jul 18 02:06:56 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Mon Jul 18 02:09:25 2005 Subject: [VIM] Dragonfly Commerce disputes reports In-Reply-To: References: <200507172133.j6HLXI0s021601@linus.mitre.org> Message-ID: On Sun, 17 Jul 2005, security curmudgeon wrote: > I really hate these types of disputes. Yes, the only way to really deal with them is to verify ourselves. Whichever side is true, I suspect that in general we'll see a lot of these "invalid input" SQL problems being labeled as SQL injection. Only makes sense for a SQL query to barf if it's given an non-numeric argument for a numeric field, and quoting the input might stop injection but it won't stop the query from failing. - Steve From jericho at attrition.org Mon Jul 18 02:16:59 2005 From: jericho at attrition.org (security curmudgeon) Date: Mon Jul 18 02:17:01 2005 Subject: [VIM] Dragonfly Commerce disputes reports In-Reply-To: References: <200507172133.j6HLXI0s021601@linus.mitre.org> Message-ID: : Yes, the only way to really deal with them is to verify ourselves. : : Whichever side is true, I suspect that in general we'll see a lot of : these "invalid input" SQL problems being labeled as SQL injection. : Only makes sense for a SQL query to barf if it's given an non-numeric : argument for a numeric field, and quoting the input might stop injection : but it won't stop the query from failing. It would be nice if someone respected on F-D or Bugtraq would make a post regarding 'vulnerability research' and touch on some of these issues. Mainly a) testing live sites isn't indicative of a vuln in the distributed product and b) throwing a ' in a field and getting an SQL error message isn't confirmation of an injection vulnerability. I'm sure there are other things that are common, but those two come to mind first. From jericho at attrition.org Mon Jul 18 02:57:25 2005 From: jericho at attrition.org (security curmudgeon) Date: Mon Jul 18 02:57:39 2005 Subject: [VIM] Phpauction GPL security vulnerability question Message-ID: Hello, On July 08, 2005, a security researched named Diabolic Crab posted a security advisory related to the Phpauction GPL product. You can find the full advisory and various vulnerability database entries at the following: http://digitalparadox.org/viewadvisories.ah?view=41 http://securitytracker.com/id?1014423 http://www.secunia.com/advisories/15967/ Based on the original report, it appears that some of these issues may not be accurate. The main two that stand out from this advisory are: /login.php?username= Cross Site Scripting /viewnews.php?id= Cross Site Scripting The login.php appears to be the PHPAUCTION web site client login, and not necessarily part of the Phpauction software package. The viewnews.php script appears to be the PHPAUCTION web site news links for clients as well, and likely not part of the Phpauction package. Can you confirm these two scripts are not part of the Phpauction software? Can you also confirm the other vulnerabilities listed in the advisory? Thank you! Brian OSVDB.org From jericho at attrition.org Mon Jul 18 05:51:16 2005 From: jericho at attrition.org (security curmudgeon) Date: Mon Jul 18 05:51:18 2005 Subject: [VIM] Vendor ACK for SurgeLDAP issues In-Reply-To: <200507171828.j6HISaZ4013982@linus.mitre.org> References: <200507171828.j6HISaZ4013982@linus.mitre.org> Message-ID: : Various SurgeLDAP issues are clearly acknowledged in the vendor's : changelog here: : : http://netwinsite.com/surgeldap/updates.htm : : e.g. 1.0h acknowledges BID:10294 / SECTRACK:1010068 : : and 1.0e lists a slew of cross-references to VDB's. : : I didn't see any mention of the directory traversal issue reported in : 2004 (page parameter in show command), however. Yep, I was able to match all of the security warnings to entries we had with two exceptions: 1. like you notice, no mention of the user.cgi traversal (osvdb 5169) 2. on 2004-11-29 it lists: Security Fixes. (Denial of Service attacks) i couldn't match this against any entry we had, so creating one for it From jericho at attrition.org Tue Jul 19 02:02:45 2005 From: jericho at attrition.org (security curmudgeon) Date: Tue Jul 19 02:02:47 2005 Subject: [VIM] Oracle Critical Patch - Cliff Notes Message-ID: Not sure if this will help you Steve, but cliff notes =) The Oracle ID on the left, OSVDB title on the right. We break them out as best as possible and use the very little info they provide to distinguish them, thus the somewhat odd wording. DB01 Oracle Express Server Unauthenticated Trivial Remote DoS DB02 Oracle OLAP olapsys SQL DoS DB03 Oracle Component Registry dbms_registry Issue DB04 Oracle utl_file Unspecified Issue DB05 Oracle Database Link Creation Unspecified Issue DB06 Oracle XML Database HTTP Limited Information Disclosure DB07 Oracle XML Databaes FTP Unspecified Issue DB08 Oracle iSQL*Plus HTTP Unspecified Trivial DoS DB09 Oracle iSQL*Plus Unspecified Trivial Database Content Disclosure DB10 Oracle Single Sign-On HTTP Unspecified Information Disclosure DB11 Oracle HTTP Server (mod_ssl) HTTPS Multiple Unspecified Issue AS07 DB12 AS08 AS01 Oracle Containers for J2EE Unspecified Remote Information Disclosure AS02 Oracle Application Server Forms Local Unspecified Integrity Issue AS03 Oracle Application Server Forms Multiple Unspecified Local Information Disclosure AS04 AS05 Oracle Application Server Forms HTTP Unspecified Remote DoS AS06 Oracle Application Server Forms HTTP Unspecified Issue AS09 Oracle Application Server JDeveloper Unspecified Local Limited Impact Issue AS10 Oracle Application Server JDeveloper Unspecified Local Wide Impact Issue AS11 Oracle Reports Developer HTTP Unspecified Issue AS12 Oracle Application Server JInitiator HTTP Unspecified Issue OCS01 Oracle Email Server SMTP Unspecified Limited Impact DoS OCS02 Oracle Email Server SMTP Unspecified Wide Impact DoS OCS03 Oracle Email Server IMAP Unspecified Issue OCS04 Oracle Email Server HTTP Authenticated User Unspecified DoS OCS05 Oracle Web Conferencing HTTP Unspecified Information Disclosure OCS06 APPS01 Oracle E-Business Suite HTTP Unspecified Issue APPS03 APPS02 Oracle E-Business Suite HTTP Unspecified Information Disclosure APPS04 Oracle E-Business Suite SQL x Unspecified Issue portal.wpg_session or owf_mgr.wf_event_html APPS05 Oracle E-Business Suite HTTP Authenticated Trivial Information Disclosure APPS11 Oracle E-Business Suite HTTP Unauthenticated Trivial Information Disclosure APPS12 APPS13 APPS14 APPS17 APPS06 Oracle E-Business Suite HTTP Authenticated Multiple Unspecified Issue APPS07 APPS08 APPS09 APPS10 APPS16 APPS15 Oracle E-Business Suite HTTP Unauthenticated Multiple Unspecified Issue EM01 Oracle Enterprise Manager Instance Management Unspecified Issue EM02 Oracle Enterprise Manager CORE:SDK Unspecified Remote DoS Also these to match up next: http://archives.neohapsis.com/archives/bugtraq/2005-07/0182.html http://www.integrigy.com/analysis.htm details not public http://www.red-database-security.com/advisory/oracle_jdeveloper_passes_plaintext_password.html http://archives.neohapsis.com/archives/bugtraq/2005-07/0212.html http://www.red-database-security.com/advisory/oracle_jdeveloper_plaintext_password.html http://archives.neohapsis.com/archives/bugtraq/2005-07/0213.html http://www.red-database-security.com/advisory/oracle_formsbuilder_temp_file_issue.html http://archives.neohapsis.com/archives/bugtraq/2005-07/0217.html http://www.red-database-security.com/advisory/oracle_forms_unsecure_temp_file_handling.html http://archives.neohapsis.com/archives/bugtraq/2005-07/0216.html http://archives.neohapsis.com/archives/bugtraq/2005-07/0240.html http://archives.neohapsis.com/archives/bugtraq/2005-07/0248.html 2576249 - /DAV_PUBLIC IS NOT PROTECTED BY DEFAULT ENABLING MALITIOUS USER TO FILL IT UP 2544464 - ORAALTPASSWORD SHOULD BE ENCRYPTED AND NOT JUST OBFUSCATED From jericho at attrition.org Tue Jul 19 03:39:44 2005 From: jericho at attrition.org (security curmudgeon) Date: Tue Jul 19 03:39:46 2005 Subject: [VIM] phpPgAdmin ACK Message-ID: OSVDB 17758 >From the freshmeat announce list: [060] - phpPgAdmin 3.5.4 by Christopher Kings-Lynne (http://freshmeat.net/users/chriskl/) Mon, Jul 18th 2005 04:42 [..] Changes: This release fixed a critical security hole. Some other minor bugs were also fixed. From coley at mitre.org Tue Jul 19 15:44:40 2005 From: coley at mitre.org (Steven M. Christey) Date: Tue Jul 19 15:47:15 2005 Subject: [VIM] Source code verification of DVBBS XSS in showerr.asp/action Message-ID: <200507191944.j6JJie16001982@linus.mitre.org> Refs: CAN-2005-2318, BID:14223 Issue: XSS in DVBBS 7.1 via action parameter of showerr.asp While trying to find more information on this issue, I accidentally ran across a couple showerr.asp source files that were being served unparsed on various sites. Source code review shows that the action parameter is not quoted. I haven't done a live test. [5] action=Request("action") ... [14]Select Case action [15] Case "stop"'???????? [56] Case "iplock"'IP???? [65] Case "limitedonline"'???????? [71] Case "OtherErr" [90] Case "readonly" [132] Case "lock" [142] Case "plus" ... [158] Case Else ... [165] template.html(0)=Replace(template.html(0),"{$action}",action) If the action parameter has XSS in it, then the code would fall through to the "Case Else" and its value would be directly inserted into the template. A quick glance suggests that there may be some other XSS issues as well. - Steve From coley at linus.mitre.org Tue Jul 19 17:53:43 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue Jul 19 17:56:19 2005 Subject: [VIM] phpPgAdmin ACK In-Reply-To: References: Message-ID: Thanks. Also, the changelog at: http://sourceforge.net/project/shownotes.php?release_id=342261 specifically links to SECUNIA:15941 - Steve From coley at mitre.org Tue Jul 19 19:40:19 2005 From: coley at mitre.org (Steven M. Christey) Date: Tue Jul 19 19:42:54 2005 Subject: [VIM] Vendor ACK for CaLogic PHP file include Message-ID: <200507192340.j6JNeJUY025039@linus.mitre.org> Refs: CAN-2005-2321, SECUNIA:16090 Issue: PHP file include in CaLogic via CLPATH Under the forum post "Code injection security issue? Site hacked!" which details various successful hacks using this issue, the vendor posts a response "I have addressed this security issue, and have already released a patch. To patch your CaLogic, download the 1.2.2 distribution zip file... you can also stop the security leak by deleting these 4 files from your CaLogic root folder: mcconfig.php clmcpreload.php mcpi-demo.php cl_minical.php" http://www.calogic.de/modules/newbb/viewtopic.php?topic_id=333&forum=7&viewmode=flat&order=ASC&start=10 - Steve From jericho at attrition.org Wed Jul 20 23:02:37 2005 From: jericho at attrition.org (security curmudgeon) Date: Wed Jul 20 23:02:39 2005 Subject: [VIM] Source code verification of DVBBS XSS in showerr.asp/action In-Reply-To: <200507191944.j6JJie16001982@linus.mitre.org> References: <200507191944.j6JJie16001982@linus.mitre.org> Message-ID: : Refs: CAN-2005-2318, BID:14223 The only BID reference has no info, hate that =) : Issue: XSS in DVBBS 7.1 via action parameter of showerr.asp : : If the action parameter has XSS in it, then the code would fall through : to the "Case Else" and its value would be directly inserted into the : template. : : A quick glance suggests that there may be some other XSS issues as well. I'll post to the mangler list, see if anyone has time to check. From jericho at attrition.org Fri Jul 22 17:54:08 2005 From: jericho at attrition.org (security curmudgeon) Date: Fri Jul 22 17:54:10 2005 Subject: [VIM] EasyPHPCalendar header.inc.php serverPath Variable Remote File Inclusion (fwd) Message-ID: ---------- Forwarded message ---------- From: Brian E. Nash To: moderators@osvdb.org Date: Fri, 22 Jul 2005 10:38:21 -0400 Subject: [OSVDB Mods] [Change Request] 17732: EasyPHPCalendar header.inc.php serverPath Variable Remote File Inclusion The vulnerabilities have been addressed. Can you update your records that Version 6.2.8 and above are not at risk? Best Regards, Brian -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.2/52 - Release Date: 7/19/2005 From jericho at attrition.org Fri Jul 22 20:13:36 2005 From: jericho at attrition.org (security curmudgeon) Date: Fri Jul 22 20:13:38 2005 Subject: [VIM] Xerox, redundancy and being vague.. Message-ID: XRX05-006 http://www.xerox.com/downloads/usa/en/c/cert_XRX05_006.pdf Background There are multiple vulnerabilities in the web server code that could allow unauthorized access to the web server including: - Vulnerabilities that could bypass authentication. - Specially constructed HTTP requests can cause denial of service or allow unauthorized file access on an attacked machine. - Cross-site scripting allowing contents of web pages to be modified in an unauthorized manner. WorkCentre Pro Color 2128/2636/3545 version 0.001.04.044 through 0.001.04.504 XRX05-007 http://www.xerox.com/downloads/usa/en/c/cert_XRX05_007.pdf Background There are multiple vulnerabilities in the web server code that could allow unauthorized access to the web server including: - Vulnerabilities that could bypass authentication. - Specially constructed HTTP requests can cause denial of service or allow unauthorized file access on an attacked machine. - Cross-site scripting allowing contents of web pages to be modified in an unauthorized manner. WorkCentre M35/M45/M55 version 2.028.11.000 through 2.97.20.050 or version 4.84.16.000 through 4.97.20.050 WorkCentre Pro 35/45/55 version 3.028.11.000 through 3.97.20.050 WorkCentre Pro 65/75/90 version 1.001.00.060 through 1.001.02.706 WorkCentre Pro 32/40 Color version 0.001.00.060 through 0.001.02.707 WorkCentre M165/M175 version 6.47.30.000 through 6.57.32.008 or version 8.47.30.000 through 8.57.32.008 WorkCentre Pro 165/175 version 7.47.30.000 though 7.57.32.008 Wonder if they are cut and paste happy or if an identical set of vulns was found a month later? Based on the version info, i'd hazard a guess that the 006 vulns were found in the Color 2128/2636/3545 version, then subsequently found in other products. Thoughts? From jericho at attrition.org Mon Jul 25 04:32:27 2005 From: jericho at attrition.org (security curmudgeon) Date: Mon Jul 25 04:34:56 2005 Subject: [VIM] Vuln info from public sources and VDB rules? Message-ID: (original has links to relevant material) http://www.osvdb.org/blog/?p=26 Vuln info from public sources and VDB rules? This has come up in the past, and again more recently. Is information found on a vendor website, such as a changelog or bugzilla entry, fair game for inclusion in a vulnerability database? Some vendors seem to think this material is off limits. If a person keeps a directory of material regarding vulnerabilities, and it is not password protected or restricted in any way, are we to assume it may be private in some fashion? The recent complaint does bring up another issue though; assigning vulnerable versions to the database entry. In this case, Secunia apparently listed 1.x when it was a specific release. SecurityFocus BID database tends to do this on many entries, listing all prior releases of a product as vulnerable when it hasnt necessarily been tested. That may be a safe assumption with some software, but not always. As new features are added to a software package, so are new bugs and vulnerabilities. VDBs using public information such as bugtrackers and changelogs may have a long term negative impact though. The Caudium Group has closed its bugtracker to the public in response to Secunias vulnerability listing. If more vendors follow suit, this will make more detailed information unavailable to VDBs and impact the quality of the information we can provide. From jericho at attrition.org Mon Jul 25 05:06:33 2005 From: jericho at attrition.org (security curmudgeon) Date: Mon Jul 25 05:06:36 2005 Subject: [VIM] 15756: bBlog index.php postid Variable SQL Injection (fwd) Message-ID: ---------- Forwarded message ---------- From: Eric Johnson To: moderators@osvdb.org Date: Mon, 25 Jul 2005 01:47:46 -0700 Subject: [OSVDB Mods] [Change Request] 15756: bBlog index.php postid Variable SQL Injection Hello I am a bBlog user and an admin on the wiki for it and the developers have recently patched this exploit in the latest version. Tracking bug: http://bblog.com/bugs/index.php?do=details &id=67 Change log: http://www.bblog.com/wiki/index.php/Change_Log From coley at linus.mitre.org Mon Jul 25 17:50:09 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Mon Jul 25 17:53:14 2005 Subject: [VIM] Xerox, redundancy and being vague.. In-Reply-To: References: Message-ID: On Fri, 22 Jul 2005, security curmudgeon wrote: > Wonder if they are cut and paste happy or if an identical set of vulns was > found a month later? Based on the version info, i'd hazard a guess that > the 006 vulns were found in the Color 2128/2636/3545 version, then > subsequently found in other products. Thoughts? That would be my guess. In CVE, if we come across two vague - but distinct - advisories from the same vendor, without any cross-references or indications that they are fixing the same issues, we use different identifiers and make sure to flag them as vague. - Steve From coley at linus.mitre.org Mon Jul 25 17:57:15 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Mon Jul 25 18:00:15 2005 Subject: [VIM] Vendor ACK for EasyPHPCalendar issues Message-ID: FYI. I'm behind on email so apologies if someone else already sent this out. - Steve ---------- Forwarded message ---------- Date: Fri, 22 Jul 2005 10:47:42 -0400 From: Brian E. Nash To: cve@mitre.org Subject: EasyPHPCalendar Updated HYPERLINK "http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1143"http://cve.mitr e.org/cgi-bin/cvename.cgi?name=CAN-2005-1143 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1144 The vulnerabilities have been addressed. Can you update your records that Version 6.2.8 and above are not at risk? Best Regards, Brian -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.2/52 - Release Date: 7/19/2005 From coley at linus.mitre.org Mon Jul 25 18:02:07 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Mon Jul 25 18:05:06 2005 Subject: [VIM] EasyPHPCalendar header.inc.php serverPath Variable Remote File Inclusion (fwd) In-Reply-To: References: Message-ID: On Fri, 22 Jul 2005, security curmudgeon wrote: > ---------- Forwarded message ---------- > From: Brian E. Nash > To: moderators@osvdb.org > Date: Fri, 22 Jul 2005 10:38:21 -0400 > Subject: [OSVDB Mods] [Change Request] 17732: EasyPHPCalendar header.inc.php > serverPath Variable Remote File Inclusion > > The vulnerabilities have been addressed. Can you update your records that > Version 6.2.8 and above are not at risk? Interesting - he didn't include the CAN for this issue when he notified CVE that he fixed CAN-2005-1144 and CAN-2005-1143. I'll follow up. - Steve From coley at linus.mitre.org Tue Jul 26 15:40:47 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue Jul 26 15:43:57 2005 Subject: [VIM] EasyPHPCalendar header.inc.php serverPath Variable Remote File Inclusion (fwd) In-Reply-To: References: Message-ID: On Mon, 25 Jul 2005, Steven M. Christey wrote: > Interesting - he didn't include the CAN for this issue when he notified > CVE that he fixed CAN-2005-1144 and CAN-2005-1143. I'll follow up. He confirmed that all 3 issues are fixed. - Steve From coley at linus.mitre.org Tue Jul 26 16:15:57 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue Jul 26 16:18:59 2005 Subject: [VIM] Vuln info from public sources and VDB rules? In-Reply-To: References: Message-ID: On Mon, 25 Jul 2005, security curmudgeon wrote: > This has come up in the past, and again more recently. Is information > found on a vendor website, such as a changelog or bugzilla entry, fair > game for inclusion in a vulnerability database? Some vendors seem to think > this material is off limits. I can understand the argument for bugzilla entries, as they could be regarded as part of a largely internal process. When developers ask us for CVE ID's for issues that haven't been put in public advisories yet, CVE considers Bugzilla entries "not sufficiently public" although some vendors don't seem to mind. As a side note, I suspect that open bug reports are one of the causes of bias in open source vs. closed source comparisons, as all open source bugs are public to one degree or another. But a changelog is meant to be read by consumers, isn't it? They're telling their consumers that there's a vuln. A related ethical question is the followup research that we occasionally do to figure out specific details of a vuln, e.g. the affected executable or the bug type. > If a person keeps a directory of material > regarding vulnerabilities, and it is not password protected or restricted > in any way, are we to assume it may be private in some fashion? Well... if it can be linked to from the front page or obtained by reading a download ZIP archive, that's public to me. > The recent complaint does bring up another issue though; assigning > vulnerable versions to the database entry. This is extremely difficult. First and foremost, sometimes even the VENDORS don't know which versions are vulnerable, at least which versions the bugs were introduced in. Add the usual "Four I's" problems of inaccuracy, incompleteness, inconsistency, and incomprehensibility in advisories, and there's a lot of guesswork. This is just a guess, but I suspect that some VDB's are designed in ways to support highly customized notification to customers. So if you're a customer who says "notify me about problems in version 1.34 of product X," then version completeness in the VDB is required, and it's probably safer to notify a customer of a possible vuln in their version. > VDBs using public information such as bugtrackers and changelogs may have > a long term negative impact though. The Caudium Group has closed its > bugtracker to the public in response to Secunias vulnerability listing. If > more vendors follow suit, this will make more detailed information > unavailable to VDBs and impact the quality of the information we can > provide. This is already a big problem with many vendors, though, and I don't think it's solvable. We encountered a lot of difficulties in early CVE because we made certain content decisions that required perfect and complete information, but the reality is that it's rarely available - whether by intentional or accidental omission. And it's a damned-if-we-do damned-if-we-don't problem. Either way we don't get good coverage. Good point, though - I should have added it to my "why VDB's don't do everything" rant :) - Steve From coley at mitre.org Tue Jul 26 18:58:37 2005 From: coley at mitre.org (Steven M. Christey) Date: Tue Jul 26 19:01:40 2005 Subject: [VIM] Vendor ACK clarification for PHpNews auth.php / user Message-ID: <200507262258.j6QMwba5005535@linus.mitre.org> reference: (CVE pending) BUGTRAQ:20050720 PHPNews SQL injection vulnerability URL:http://marc.theaimsgroup.com/?l=bugtraq&m=112189453304389&w=2 CONFIRM:http://newsphp.sourceforge.net/changelog/changelog_1.30.txt The changelog for 1.3.0 says "Possible SQL injection vulnerability." However, a diff of auth.php between 1.2.6 and 1.3.0 shows the relevant fixes: 74,83c74,75 < if (!get_magic_quotes_gpc()) < { < $in_user = addslashes($_POST['user']); < $in_password = addslashes($_POST['password']); < } < else < { < $in_user = $_POST['user']; < $in_password = $_POST['password']; < } --- > $in_user = $_POST['user']; > $in_password = $_POST['password']; - Steve From jericho at attrition.org Tue Jul 26 19:22:29 2005 From: jericho at attrition.org (security curmudgeon) Date: Tue Jul 26 19:22:31 2005 Subject: [VIM] Vuln info from public sources and VDB rules? In-Reply-To: References: Message-ID: : > This has come up in the past, and again more recently. Is information : > found on a vendor website, such as a changelog or bugzilla entry, fair : > game for inclusion in a vulnerability database? Some vendors seem to think : > this material is off limits. : : I can understand the argument for bugzilla entries, as they could be : regarded as part of a largely internal process. When developers ask us If the bugzilla is open to anyone, doesn't require authentication, and is linked off the vendor page as 'Bug Tracker', this doesn't feel like an internal process. : for CVE ID's for issues that haven't been put in public advisories yet, : CVE considers Bugzilla entries "not sufficiently public" although some : vendors don't seem to mind. When looking at a bugzilla entry, I take note of time of disclosure and if there is any followup. Not only if there is any, but the time that has passed. Specifically, has a vendor had time to examine it? Are there comments confirming the bug? Comments saying they can't reproduce? That will weigh heavily on if I include it immediately. : But a changelog is meant to be read by consumers, isn't it? They're : telling their consumers that there's a vuln. I think a public changelog is just that, public. : > If a person keeps a directory of material : > regarding vulnerabilities, and it is not password protected or restricted : > in any way, are we to assume it may be private in some fashion? : : Well... if it can be linked to from the front page or obtained by reading : a download ZIP archive, that's public to me. How about if it is a directory with no auth required, but not linked off the public pages? ie: I send CVE http://blah/vulns/issue1.txt. A month later, you check the /vulns/ directory and notice issue2.txt which is not published anywhere. Is that fair game? From sullo at cirt.net Tue Jul 26 21:16:48 2005 From: sullo at cirt.net (Sullo) Date: Tue Jul 26 21:19:54 2005 Subject: [VIM] Vuln info from public sources and VDB rules? In-Reply-To: References: Message-ID: <42E6E080.6010301@cirt.net> >: > If a person keeps a directory of material >: > regarding vulnerabilities, and it is not password protected or restricted >: > in any way, are we to assume it may be private in some fashion? >: >: Well... if it can be linked to from the front page or obtained by reading >: a download ZIP archive, that's public to me. > >How about if it is a directory with no auth required, but not linked off >the public pages? ie: I send CVE http://blah/vulns/issue1.txt. A month >later, you check the /vulns/ directory and notice issue2.txt which is not >published anywhere. Is that fair game? > > > If you put something on a web site, without authentication, then it is without any doubt public. (Incidentally, this includes directories without indexing enabled, pages that aren't linked to, etc.). In short, if it's meant to be kept out of the public sphere don't put it on a web site (or at least put some auth on it). In the case of bugzilla, it has the ability to mark bugs as private so no one can see them... so there really should be no excuse. -Sullo -- http://www.cirt.net/ | http://www.osvdb.org/ From sullo at cirt.net Tue Jul 26 21:29:30 2005 From: sullo at cirt.net (Sullo) Date: Tue Jul 26 21:32:35 2005 Subject: [VIM] CVE-2005-2335 (fetchmail) Message-ID: <42E6E37A.7000700@cirt.net> Steve, secunia is referencing CVE-2005-2335 regarding a fetchmail vuln, but that one doesn't seem to exist. I don't see it via search, either... someone missing something? Thanks Sullo -- http://www.cirt.net/ | http://www.osvdb.org/ From coley at linus.mitre.org Wed Jul 27 00:09:45 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed Jul 27 00:12:53 2005 Subject: [VIM] CVE-2005-2335 (fetchmail) In-Reply-To: <42E6E37A.7000700@cirt.net> References: <42E6E37A.7000700@cirt.net> Message-ID: On Tue, 26 Jul 2005, Sullo wrote: > Steve, > > secunia is referencing CVE-2005-2335 regarding a fetchmail vuln, but > that one doesn't seem to exist. I don't see it via search, either... > someone missing something? It should have been CAN-2005-2335 (not CVE), which a Google search will produce a couple examples. This kind of inconsistency is one of the main reasons why we're getting rid of the dual naming scheme and just sticking with the CVE prefix (status codes will say whether they're CANs or CVEs.) By the way, Fedora introduced a typo for the same issue - CAN-2005-2355 - but that will be heavily flagged by CVE as being the wrong number. See below. - Steve ====================================================== Candidate: CAN-2005-2335 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2335 Reference: CONFIRM:http://fetchmail.berlios.de/fetchmail-SA-2005-01.txt Reference: CONFIRM:http://developer.berlios.de/project/shownotes.php?release_id=6617 Reference: FEDORA:FEDORA-2005-613 Reference: URL:http://www.redhat.com/archives/fedora-announce-list/2005-July/msg00088.html Reference: FEDORA:FEDORA-2005-614 Reference: URL:http://www.redhat.com/archives/fedora-announce-list/2005-July/msg00089.html Reference: BID:14349 Reference: URL:http://www.securityfocus.com/bid/14349 Reference: FRSIRT:ADV-2005-1171 Reference: URL:http://www.frsirt.com/english/advisories/2005/1171 Reference: SECUNIA:16176 Reference: URL:http://secunia.com/advisories/16176 Buffer overflow in the POP3 client in Fetchmail before 6.2.5.2 allows remote POP3 servers to cause a denial of service and possibly execute arbitrary code via long UIDL responses. NOTE: a typo in an advisory accidentally used the wrong CVE identifier for the Fetchmail issue. This is the correct identifier. ====================================================== Candidate: CAN-2005-2355 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2355 Reference: MISC:http://www.redhat.com/archives/fedora-announce-list/2005-July/msg00104.html ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CAN-2005-2335, CAN-2005-2356. Reason: due to a typo in an advisory, this candidate was accidentally referenced. Notes: All CVE users should consult CAN-2005-2335 and CAN-2005-2356 to determine the appropriate identifier for the issue. From sullo at cirt.net Wed Jul 27 00:21:29 2005 From: sullo at cirt.net (Sullo) Date: Wed Jul 27 00:24:34 2005 Subject: [VIM] CVE-2005-2335 (fetchmail) In-Reply-To: References: <42E6E37A.7000700@cirt.net> Message-ID: <42E70BC9.7080109@cirt.net> I think maybe I misspoke, sorta. Secunia references CAN-2005-2335... but the link doesn't seem to work: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2335 The original advisory lists CAN-2005-2335... http://fetchmail.berlios.de/fetchmail-SA-2005-01.txt Something just isn't right, or it's too late in the night for me to figure it out :-) Steven M. Christey wrote: >On Tue, 26 Jul 2005, Sullo wrote: > > > >>Steve, >> >>secunia is referencing CVE-2005-2335 regarding a fetchmail vuln, but >>that one doesn't seem to exist. I don't see it via search, either... >>someone missing something? >> >> > >It should have been CAN-2005-2335 (not CVE), which a Google search will >produce a couple examples. > >This kind of inconsistency is one of the main reasons why we're getting >rid of the dual naming scheme and just sticking with the CVE prefix >(status codes will say whether they're CANs or CVEs.) > >By the way, Fedora introduced a typo for the same issue - CAN-2005-2355 - >but that will be heavily flagged by CVE as being the wrong number. > >See below. > >- Steve > > >====================================================== >Candidate: CAN-2005-2335 >URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2335 >Reference: CONFIRM:http://fetchmail.berlios.de/fetchmail-SA-2005-01.txt >Reference: CONFIRM:http://developer.berlios.de/project/shownotes.php?release_id=6617 >Reference: FEDORA:FEDORA-2005-613 >Reference: URL:http://www.redhat.com/archives/fedora-announce-list/2005-July/msg00088.html >Reference: FEDORA:FEDORA-2005-614 >Reference: URL:http://www.redhat.com/archives/fedora-announce-list/2005-July/msg00089.html >Reference: BID:14349 >Reference: URL:http://www.securityfocus.com/bid/14349 >Reference: FRSIRT:ADV-2005-1171 >Reference: URL:http://www.frsirt.com/english/advisories/2005/1171 >Reference: SECUNIA:16176 >Reference: URL:http://secunia.com/advisories/16176 > >Buffer overflow in the POP3 client in Fetchmail before 6.2.5.2 allows >remote POP3 servers to cause a denial of service and possibly execute >arbitrary code via long UIDL responses. NOTE: a typo in an advisory >accidentally used the wrong CVE identifier for the Fetchmail issue. >This is the correct identifier. > > >====================================================== >Candidate: CAN-2005-2355 >URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2355 >Reference: MISC:http://www.redhat.com/archives/fedora-announce-list/2005-July/msg00104.html > >** REJECT ** > >DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CAN-2005-2335, >CAN-2005-2356. Reason: due to a typo in an advisory, this candidate >was accidentally referenced. Notes: All CVE users should consult >CAN-2005-2335 and CAN-2005-2356 to determine the appropriate >identifier for the issue. > > > > > > > -- http://www.cirt.net/ | http://www.osvdb.org/ From coley at linus.mitre.org Wed Jul 27 00:29:07 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed Jul 27 00:32:12 2005 Subject: [VIM] CVE-2005-2335 (fetchmail) In-Reply-To: <42E70BC9.7080109@cirt.net> References: <42E6E37A.7000700@cirt.net> <42E70BC9.7080109@cirt.net> Message-ID: On Wed, 27 Jul 2005, Sullo wrote: > I think maybe I misspoke, sorta. Secunia references CAN-2005-2335... but > the link doesn't seem to work: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2335 Oh, I see. This happens sometimes when a number is assigned to an issue pre-disclosure, but the CVE web site isn't updated before it becomes public. In this case it means I haven't updated the web site in a few days :-/ but funny thing, I'm doing that right now - Steve From jericho at attrition.org Fri Jul 29 17:36:14 2005 From: jericho at attrition.org (security curmudgeon) Date: Fri Jul 29 17:36:17 2005 Subject: [VIM] Re: [OSVDB Mods] XSS flaws and data disclosure in Easyxp41 In-Reply-To: References: Message-ID: : ################################################ : information disclosure in /forum/ folder: : ######################################### : : http://[victim]/modules/forum/cfg/ : http://[victim]/modules/forum/db/ : http://[victim]/modules/forum/msg/ : http://[victim]/modules/forum/admin/index.php : http://[victim]/modules/forum/msg/1103495330.dat : : ############# : information disclosure in /login/ folder: : ############# : : http://[victim]/modules/login/ : http://[victim]/modules/login/login.php : http://[victim]/modules/login/admin/option.php : http://[victim]/modules/login/cfg/modules.cfg : http://[victim]/cfg/config.cfg : http://[victim]/mesdocuments/ : http://[victim]/modules/news/ Hi FalconDeOro, Can you clarify what kind of information disclosure this is? I am guessing path disclosure? Brian OSVDB.org