From coley at linus.mitre.org Fri Dec 4 21:14:27 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 4 Dec 2009 16:14:27 -0500 (EST) Subject: [VIM] Yoono chrome-privileges issue (CVE-2009-4100) fixed in 6.1.1 Message-ID: A Yoono vendor representative e-mailed us to clarify a CVE description change. http://www.net-security.org/secworld.php?id=8527 implies that 6.1.1 is affected ("Yoono 6.1.1 and previous") but the vendor stated that 6.1.1 is actually fixed, and the fix was available in July. See the CVE below. - Steve ====================================================== Name: CVE-2009-4100 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4100 Reference: MISC:http://www.net-security.org/secworld.php?id=8527 Reference: CONFIRM:https://addons.mozilla.org/en-US/firefox/addons/versions/1833#version-6.1.1 Reference: BID:37123 Reference: URL:http://www.securityfocus.com/bid/37123 Reference: SECUNIA:37468 Reference: URL:http://secunia.com/advisories/37468 Reference: VUPEN:ADV-2009-3326 Reference: URL:http://www.vupen.com/english/advisories/2009/3326 Reference: XF:yoonoo-domevent-xss(54417) Reference: URL:http://xforce.iss.net/xforce/xfdb/54417 Yoono extension before 6.1.1 for Firefox performs certain operations with chrome privileges, which allows user-assisted remote attackers to execute arbitrary commands and perform cross-domain scripting attacks via DOM event handlers such as onload. From jkouns at opensecurityfoundation.org Sat Dec 5 05:59:47 2009 From: jkouns at opensecurityfoundation.org (Jake Kouns) Date: Sat, 5 Dec 2009 00:59:47 -0500 Subject: [VIM] Yoono chrome-privileges issue (CVE-2009-4100) fixed in 6.1.1 In-Reply-To: References: Message-ID: Thanks for sending. Updated OSVDB 60530 (http://osvdb.org/60530) with information as well. --Jake On Fri, Dec 4, 2009 at 4:14 PM, Steven M. Christey wrote: > > A Yoono vendor representative e-mailed us to clarify a CVE description > change. ?http://www.net-security.org/secworld.php?id=8527 implies that 6.1.1 > is affected ("Yoono 6.1.1 and previous") but the vendor stated that 6.1.1 is > actually fixed, and the fix was available in July. ?See the CVE below. > > - Steve > > ====================================================== > Name: CVE-2009-4100 > Status: Candidate > URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4100 > Reference: MISC:http://www.net-security.org/secworld.php?id=8527 > Reference: > CONFIRM:https://addons.mozilla.org/en-US/firefox/addons/versions/1833#version-6.1.1 > Reference: BID:37123 > Reference: URL:http://www.securityfocus.com/bid/37123 > Reference: SECUNIA:37468 > Reference: URL:http://secunia.com/advisories/37468 > Reference: VUPEN:ADV-2009-3326 > Reference: URL:http://www.vupen.com/english/advisories/2009/3326 > Reference: XF:yoonoo-domevent-xss(54417) > Reference: URL:http://xforce.iss.net/xforce/xfdb/54417 > > Yoono extension before 6.1.1 for Firefox performs certain operations > with chrome privileges, which allows user-assisted remote attackers to > execute arbitrary commands and perform cross-domain scripting attacks > via DOM event handlers such as onload. > > > From noamr at beyondsecurity.com Wed Dec 9 09:34:24 2009 From: noamr at beyondsecurity.com (Noam Rathaus) Date: Wed, 9 Dec 2009 11:34:24 +0200 Subject: [VIM] CVE-2009-4006 Message-ID: <6a2b811d0912090134h56dd1d17qb02b002180968c6c@mail.gmail.com> The text here: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-4006 Says: hexidecimal I believe the right word is hexadecimal Thanks, Noam. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.attrition.org/pipermail/vim/attachments/20091209/d1605a90/attachment.html From che at secunia.com Wed Dec 9 09:42:17 2009 From: che at secunia.com (Carsten H. Eiram) Date: Wed, 09 Dec 2009 10:42:17 +0100 Subject: [VIM] CVE-2009-4006 In-Reply-To: <6a2b811d0912090134h56dd1d17qb02b002180968c6c@mail.gmail.com> References: <6a2b811d0912090134h56dd1d17qb02b002180968c6c@mail.gmail.com> Message-ID: <1260351737.753.229.camel@ts-hq-1> I just noticed that the NVD CVSS2 score sets "Au:S". That is incorrect - no authentication is required. cheers, /Carsten On Wed, 2009-12-09 at 11:34 +0200, Noam Rathaus wrote: > The text here: > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-4006 > > Says: > hexidecimal > > I believe the right word is > hexadecimal > > Thanks, > Noam. > -- Med venlig hilsen / Kind regards Carsten H. Eiram Chief Security Specialist Secunia Weidekampsgade 14 A DK-2300 Copenhagen S Denmark Phone +45 7020 5144 Fax +45 7020 5145 From jericho at attrition.org Wed Dec 9 09:44:15 2009 From: jericho at attrition.org (security curmudgeon) Date: Wed, 9 Dec 2009 09:44:15 +0000 (UTC) Subject: [VIM] CVE-2009-4006 In-Reply-To: <1260351737.753.229.camel@ts-hq-1> References: <6a2b811d0912090134h56dd1d17qb02b002180968c6c@mail.gmail.com> <1260351737.753.229.camel@ts-hq-1> Message-ID: No one from nvd.gov currently subscribes to VIM. I am CC'ing them on this mail and making sure they are aware of this list =) In general, text issues should go to cve at mitre.org (or here, we know Steve reads) and anything CVSS related should go to nvd at nist.gov, as they calculate the scores. .b p.s. NVD: http://attrition.org/mailman/listinfo/vim On Wed, 9 Dec 2009, Carsten H. Eiram wrote: : I just noticed that the NVD CVSS2 score sets "Au:S". That is incorrect - : no authentication is required. : : cheers, : /Carsten : : : On Wed, 2009-12-09 at 11:34 +0200, Noam Rathaus wrote: : > The text here: : > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-4006 : > : > Says: : > hexidecimal : > : > I believe the right word is : > hexadecimal : > : > Thanks, : > Noam. : > : -- : : Med venlig hilsen / Kind regards : : : Carsten H. Eiram : Chief Security Specialist : : Secunia : Weidekampsgade 14 A : DK-2300 Copenhagen S : Denmark : : Phone +45 7020 5144 : Fax +45 7020 5145 : From jericho at attrition.org Wed Dec 9 09:47:24 2009 From: jericho at attrition.org (security curmudgeon) Date: Wed, 9 Dec 2009 09:47:24 +0000 (UTC) Subject: [VIM] CVE-2009-4006 In-Reply-To: References: <6a2b811d0912090134h56dd1d17qb02b002180968c6c@mail.gmail.com> <1260351737.753.229.camel@ts-hq-1> Message-ID: And by that, i meant nvd.nist.gov (wow, most traffic VIM has seen in weeks!) On Wed, 9 Dec 2009, security curmudgeon wrote: : : No one from nvd.gov currently subscribes to VIM. I am CC'ing them on this : mail and making sure they are aware of this list =) : : In general, text issues should go to cve at mitre.org (or here, we know Steve : reads) and anything CVSS related should go to nvd at nist.gov, as they : calculate the scores. : : .b : : p.s. NVD: http://attrition.org/mailman/listinfo/vim : : : : On Wed, 9 Dec 2009, Carsten H. Eiram wrote: : : : I just noticed that the NVD CVSS2 score sets "Au:S". That is incorrect - : : no authentication is required. : : : : cheers, : : /Carsten : : : : : : On Wed, 2009-12-09 at 11:34 +0200, Noam Rathaus wrote: : : > The text here: : : > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-4006 : : > : : > Says: : : > hexidecimal : : > : : > I believe the right word is : : > hexadecimal : : > : : > Thanks, : : > Noam. : : > : : -- : : : : Med venlig hilsen / Kind regards : : : : : : Carsten H. Eiram : : Chief Security Specialist : : : : Secunia : : Weidekampsgade 14 A : : DK-2300 Copenhagen S : : Denmark : : : : Phone +45 7020 5144 : : Fax +45 7020 5145 : : : From coley at linus.mitre.org Wed Dec 9 16:36:36 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 9 Dec 2009 11:36:36 -0500 (EST) Subject: [VIM] CVE-2009-4006 In-Reply-To: <6a2b811d0912090134h56dd1d17qb02b002180968c6c@mail.gmail.com> References: <6a2b811d0912090134h56dd1d17qb02b002180968c6c@mail.gmail.com> Message-ID: On Wed, 9 Dec 2009, Noam Rathaus wrote: > The text here: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-4006 > > Says: > hexidecimal > > I believe the right word is > hexadecimal Nice to know people care :) I fixed this. Looks like we had it in a couple other CVE descriptions over the years... So now it's on our bad-words list. - Steve From coley at linus.mitre.org Wed Dec 9 16:38:15 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 9 Dec 2009 11:38:15 -0500 (EST) Subject: [VIM] CVE-2009-4006 In-Reply-To: <1260351737.753.229.camel@ts-hq-1> References: <6a2b811d0912090134h56dd1d17qb02b002180968c6c@mail.gmail.com> <1260351737.753.229.camel@ts-hq-1> Message-ID: On Wed, 9 Dec 2009, Carsten H. Eiram wrote: > I just noticed that the NVD CVSS2 score sets "Au:S". That is incorrect - > no authentication is required. That means no change is necessary to the raw CVE description, although I'm starting to think it might be good for us to do a better job of distinguishing between "no auth required" versus "we don't know if auth is required or not." The term "remote attackers" could be used in either situation, CVE-wise. - Steve From jericho at attrition.org Sat Dec 12 00:45:45 2009 From: jericho at attrition.org (security curmudgeon) Date: Sat, 12 Dec 2009 00:45:45 +0000 (UTC) Subject: [VIM] iDefense Security Advisory 12.08.09: Microsoft WordPad Word97 Converter Integer Overflow Vulnerability In-Reply-To: <4B201783.4000509@idefense.com> References: <4B201783.4000509@idefense.com> Message-ID: Hi iDefense, On Wed, 9 Dec 2009, iDefense Labs wrote: : iDefense Security Advisory 12.08.09 : http://labs.idefense.com/intelligence/vulnerabilities/ : Dec 08, 2009 : VII. CVE INFORMATION : : The Common Vulnerabilities and Exposures (CVE) project has assigned the : name CVE-2009-2506 to this issue. This is a candidate for inclusion in : the CVE list (http://cve.mitre.org/), which standardizes names for : security problems. : VIII. DISCLOSURE TIMELINE : : 12/18/2009 Initial Vendor Notification : 12/19/2009 Initial Vendor Reply : 12/08/2009 Coordinated Public Disclosure Could you please clarify this timeline? Brian OSVDB.org From coley at linus.mitre.org Sat Dec 12 00:46:53 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 11 Dec 2009 19:46:53 -0500 (EST) Subject: [VIM] handling site-specific vuln reports Message-ID: All, CVE periodically gets reservation requests for site-specific issues. I want to redirect the requesters somewhere else, since CVE doesn't cover these. xssed.com hasn't updated in ages, but sla.ckers.org is as active as ever. Then there's Bugtraq and Full-Disclosure. Any other recommendations? Thanks, Steve From deapesh at gmail.com Mon Dec 14 21:57:32 2009 From: deapesh at gmail.com (Deapesh Misra) Date: Mon, 14 Dec 2009 16:57:32 -0500 Subject: [VIM] iDefense Security Advisory 12.08.09: Microsoft WordPad Word97 Converter Integer Overflow Vulnerability In-Reply-To: References: <4B201783.4000509@idefense.com> Message-ID: <22b0e07b0912141357g3581c919t9ad7f9b7b8f509a9@mail.gmail.com> That was a typo. Here is the correct version: : VIII. DISCLOSURE TIMELINE : : 12/18/2008 Initial Vendor Notification : 12/19/2008 Initial Vendor Reply : 12/08/2009 Coordinated Public Disclosure thanks, -Deapesh. From jericho at attrition.org Thu Dec 17 05:59:55 2009 From: jericho at attrition.org (security curmudgeon) Date: Thu, 17 Dec 2009 05:59:55 +0000 (UTC) Subject: [VIM] IBM DB2 9.5 FP5 clarification Message-ID: There are several IBM.com folks subscribed, hopefully they can answer on or offlist, or pass this on to the right department =) The latest advisory for DB2 9.5 FP5: http://www-01.ibm.com/support/docview.wss?uid=swg21412902 http://www-01.ibm.com/support/docview.wss?uid=swg24025421 These are covered by Secunia 37759 and OSVDB 61040. 21412902 currently says: The specifics of the Security APARs incorporated into the above DB2 fix packs can be found in the following table: However, the table lists nine issues that do not seem to have obvious security impacts. Could someone from IBM clarify / verify which are security related? Thanks, Brian OSVDB.org From amanion at cert.org Thu Dec 17 19:05:41 2009 From: amanion at cert.org (Art Manion) Date: Thu, 17 Dec 2009 14:05:41 -0500 Subject: [VIM] handling site-specific vuln reports In-Reply-To: References: Message-ID: <4B2A8105.9090509@cert.org> On 2009-12-11 19:46, Steven M. Christey wrote: > CVE periodically gets reservation requests for site-specific issues. I > want to redirect the requesters somewhere else, since CVE doesn't cover > these. xssed.com hasn't updated in ages, but sla.ckers.org is as active > as ever. Then there's Bugtraq and Full-Disclosure. Any other > recommendations? (Replied to Steve privately already...) While CERT by no means keeps up with every public vul anymore (we used to at least catalog them internally), we do accept private reports and will at least try to get the report to the vendor. We consider a web site to be software (even if it is single-instance software) and we'll try to notify the owner ("vendor") of the site. Sometimes what appears to be a site-specific issue is actually in some more general component (like a search engine), then that becomes a more typical product vulnerability. That said, we don't have the resources to coordinate all the XSS and CSRFs that turn up, so we may have to be selective about which reports we spend time on. - Art From jericho at attrition.org Fri Dec 18 04:23:46 2009 From: jericho at attrition.org (security curmudgeon) Date: Fri, 18 Dec 2009 04:23:46 +0000 (UTC) Subject: [VIM] it's 2009, vendor's really think ROT13 is good? Message-ID: http://archives.neohapsis.com/archives/fulldisclosure/2009-12/0385.html IV. PROOF OF CONCEPT ------------------------- Using URL http://intranet published on internal server (not accessible from home page): 1. Convert string to ROT13: uggc://vagenarg 2. Change ASCII chars to HEX: 756767633a2f2f766167656e617267 3. Append string to Cisco VPN SSL: https://[CISCOVPNSSL]/+CSCO+00756767633a2f2f766167656e617267++ From jericho at attrition.org Mon Dec 21 03:30:40 2009 From: jericho at attrition.org (security curmudgeon) Date: Mon, 21 Dec 2009 03:30:40 +0000 (UTC) Subject: [VIM] Older advisory question (EMC AlphaStor Server Agent / 702) Message-ID: Hi iDefense, In regards to advisory 702, http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=702, could you clarify something please? IX. CREDIT Three of these vulnerabilities were reported to iDefense by Stephen Fewer of Harmony Security (www.harmonysecurity.com). Two were discovered by Sean Larsson, iDefense Labs. Does this mean there were five distinct vulnerabilities, or that there were three and Fewer / Larsson both discovered two of the three independently? Thanks, Brian OSVDB.org From theall at tenablesecurity.com Tue Dec 22 19:33:29 2009 From: theall at tenablesecurity.com (George A. Theall) Date: Tue, 22 Dec 2009 14:33:29 -0500 Subject: [VIM] 60cycleCMS <= 2.5.0 Remote File Include Exploit Message-ID: <9414BB41-D38C-4049-8231-A91242A67CC5@tenablesecurity.com> With a bit of encouragement from Steve... Exploit DB's #10551 looks bogus to me. PoC is: [60cycleCMS_path]/common/sqlConnect.php?DOCUMENT_ROOT=[SHELL DIRECTORY]/something Code snippet from 2.5.0, which is supposedly affected: // include your sql info file here $root = $_SERVER['DOCUMENT_ROOT']; require "$root/../config.php"; $_SERVER is one of those predefined variables in PHP and contains server and execution environment info. As far as I know, a remote attacker can't override it, least not by passing in something through a 'DOCUMENT_ROOT' parameter. George -- theall at tenablesecurity.com From theall at tenablesecurity.com Tue Dec 22 19:45:49 2009 From: theall at tenablesecurity.com (George A. Theall) Date: Tue, 22 Dec 2009 14:45:49 -0500 Subject: [VIM] Ptag <= 4.0.0 Multiple RFI Exploit Message-ID: <32F0C3BF-80EF-4100-8257-CBC5A770F886@tenablesecurity.com> Exploit-DB #10562 also looks bogus to me. One of the PoCs is: [Ptag_path]/lib/session.php?ptag_dir=[Shell] cr4wl3r helpfully includes a snippet of the affected code: A bit of clarification about the advisory ISecAuditors made in their advisory about PHP-Calendar, as covered by CVE-2009-3702... The ISecAuditors advisory includes a code snippet from update08.php as distributed with version 1.1: 36 } elseif(!empty($_GET['configfile'])) { 37 if(file_exists($_GET['configfile'])) { 38 require_once($_GET['configfile']); Looks pretty bad, doesn't it? Now look at an expanded code snippet from that same file: $phpc_root_path = './'; require_once($phpc_root_path . "includes/calendar.php"); require_once('adodb/adodb.inc.php'); $have_config = false; if(file_exists($phpc_root_path . 'config.php')) { require_once($phpc_root_path . 'config.php'); $have_config = true; } elseif(file_exists($phpc_root_path . 'config.inc.php')) { require_once($phpc_root_path . 'config.inc.php'); $have_config = true; } elseif(!empty($_GET['configfile'])) { if(file_exists($_GET['configfile'])) { require_once($_GET['configfile']); $have_config = true; Now you can see you only reach the vulnerable code if two conditions are unmet, each of which checks for a config file, presumably from an earlier install of some version or another. In other words, the vulnerability is only exploitable if the software has not been already installed or the installation was broken by having its config file(s) removed. George -- theall at tenablesecurity.com From coley at linus.mitre.org Tue Dec 22 20:41:11 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 22 Dec 2009 15:41:11 -0500 (EST) Subject: [VIM] 60cycleCMS <= 2.5.0 Remote File Include Exploit In-Reply-To: <9414BB41-D38C-4049-8231-A91242A67CC5@tenablesecurity.com> References: <9414BB41-D38C-4049-8231-A91242A67CC5@tenablesecurity.com> Message-ID: On Tue, 22 Dec 2009, George A. Theall wrote: > With a bit of encouragement from Steve... oh, great, blame me ;-) > Exploit DB's #10551 looks bogus to me. PoC is: > > [60cycleCMS_path]/common/sqlConnect.php?DOCUMENT_ROOT=[SHELL > DIRECTORY]/something So I wish I had the direct reference at hand, but I'm pretty sure that older PHPs allowed overwriting of $_SERVER variables. How old, I'm not sure... I think Stefan Esser did some writeup on this. But now I've dug up a 2006 post to VIM where I said the same thing and apparently never followed up... There's always the risk of somebody implementing their own version of register_globals and poisoning $_SERVER that way, but the code snippet doesn't give enough context. Ah yes, Stefan saves the day on this last angle: http://www.suspekt.org/2009/02/06/some-facts-about-the-phplist-vulnerability-and-the-phpbbcom-hack/ > Code snippet from 2.5.0, which is supposedly affected: > > // include your sql info file here > $root = $_SERVER['DOCUMENT_ROOT']; > require "$root/../config.php"; Yeah, I can see how this would raise questions. Code inspection would be needed. In CVE, we've been somewhat agnostic on this general point because of my vague recollection that older PHP's allowed $_SERVER to be directly modified. - Steve From theall at tenablesecurity.com Tue Dec 22 21:05:33 2009 From: theall at tenablesecurity.com (George A. Theall) Date: Tue, 22 Dec 2009 16:05:33 -0500 Subject: [VIM] 60cycleCMS <= 2.5.0 Remote File Include Exploit In-Reply-To: References: <9414BB41-D38C-4049-8231-A91242A67CC5@tenablesecurity.com> Message-ID: <2C0D6CB9-CCA2-45C3-B5B4-905A4885E12B@tenablesecurity.com> On Dec 22, 2009, at 3:41 PM, Steven M. Christey wrote: > So I wish I had the direct reference at hand, but I'm pretty sure > that older PHPs allowed overwriting of $_SERVER variables. How old, > I'm not sure... I think Stefan Esser did some writeup on this. But > now I've dug up a 2006 post to VIM where I said the same thing and > apparently never followed up... > > There's always the risk of somebody implementing their own version > of register_globals and poisoning $_SERVER that way, but the code > snippet doesn't give enough context. > > Ah yes, Stefan saves the day on this last angle: > > http://www.suspekt.org/2009/02/06/some-facts-about-the-phplist-vulnerability-and-the-phpbbcom-hack/ To be clear, the problem Esser wrote about involves code that explicitly copies request parameter values into PHP variables to emulate PHP's register_globals when that's off: if (!ini_get("register_globals") || ini_get("register_globals") == "off") { # fix register globals, for now, should be phased out gradually # sure, this gets around the entire reason that register globals # should be off, but going through three years of code takes a long time.... foreach ($_REQUEST as $key => $val) { $$key = $val; } } >> Code snippet from 2.5.0, which is supposedly affected: >> >> // include your sql info file here >> $root = $_SERVER['DOCUMENT_ROOT']; >> require "$root/../config.php"; > > Yeah, I can see how this would raise questions. Code inspection > would be needed. Indeed. There's nothing of the sort going on in the code snippet from 60cycleCMS. George -- theall at tenablesecurity.com From theall at tenablesecurity.com Tue Dec 29 01:44:32 2009 From: theall at tenablesecurity.com (George A. Theall) Date: Mon, 28 Dec 2009 20:44:32 -0500 Subject: [VIM] Joomla Component com_intuit LFI Vulnerability Message-ID: <44F7C454-03D1-4B83-AB64-6A63AA77BDBD@tenablesecurity.com> I just looked at the supposed local file include vulnerability in the Intuit Payment Gateway Component for Joomla, covered by Exploit-DB 10730 / Bugtraq 37494. The code snippet doesn't even _look_ like a local file include attack: *************************************************************************************************************** [++] ERR0R CODE: if ($response["approval"] != "") { //print_r($intuit_fields['succ_msg2']['g_value']); **************************************************************************************************************** Exploit DB helpfully includes a link to download the vulnerable app. If you look at it, one of the things you'll probably notice is that the first line of executable code in the affected file is: defined( '_JEXEC' ) or die( 'Restricted access' ); meaning if you try the PoC in the advisory -- and replace "component" with "components" -- you'll see "Restricted access" as the script fails right at the start. Another thing you'll likely notice is that the supposedly affected code snippet lies in a class definition and indeed the entire file consists of the class definition so the PoC can't be used to access the supposedly vulnerable code even if the initial check for _JEXEC wasn't there. George -- theall at tenablesecurity.com From theall at tenablesecurity.com Wed Dec 30 02:29:46 2009 From: theall at tenablesecurity.com (George A. Theall) Date: Tue, 29 Dec 2009 21:29:46 -0500 Subject: [VIM] Joomla Component com_morfeoshow RFI Vulnerability Message-ID: <70EB91D2-C0EB-4680-8235-4B98A56F50AF@tenablesecurity.com> Exploit DB #10724 concerns a supposed file inclusion vulnerability in the MorfeoShow component for Joomla. FloriX calls it a remote file inclusion in the title but suggests it's a local file include in the PoC. The PoC definitely won't work as the first executable line in morfeoshow.html.php is: defined( '_JEXEC' ) or die( 'Restricted access' ); meaning if you try the PoC in the advisory you'll see "Restricted access" as the script fails right at the start. Also, the file defines a class and doesn't otherwise offer a way itself to access the member functions. Finally, a quick egrep of the files included in the distribution file associated with the Exploit DB advisory failed to turn up any calls where an attacker could control arguments to an include / require / include_once / require_once. George -- theall at tenablesecurity.com From coley at linus.mitre.org Wed Dec 30 19:29:26 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 30 Dec 2009 14:29:26 -0500 (EST) Subject: [VIM] Joomla Vulnerable Extensions List Message-ID: Wow, check THIS out! http://docs.joomla.org/Vulnerable_Extensions_List http://forum.joomla.org/viewtopic.php?t=455746 Think I found a way to contact Jeff Channell, one of the main contributors, so let's see what happens. - Steve From coley at linus.mitre.org Wed Dec 30 19:40:39 2009 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 30 Dec 2009 14:40:39 -0500 (EST) Subject: [VIM] com_schools schoolid issue Message-ID: Joining George in the fun... http://www.exploit-db.com/exploits/10640 is for "com_schools" and the "schoolid" parameter, but Google searches suggest only one site using this. However, many results for just inurl:option=com_schools show usage of a "school" parameter. Many results also use an Itemid parameter. Many other hits don't use "school" or "Itemid" at all, which may be still more site-specific implementations. Now if you change to "com_school" (no trailing "s"), you also see lots of usage of an Itemid parameter. Has anyone investigated whether (1) com_school and com_schools are the same, and (2) whether these are site-specific? - Steve