From coley at mitre.org Fri Jan 4 00:14:01 2008 From: coley at mitre.org (Steven M. Christey) Date: Thu, 3 Jan 2008 19:14:01 -0500 (EST) Subject: [VIM] true: AGENCY4NET WEBFTP directory traversal; deletion possible Message-ID: <200801040014.m040E1IH019546@faron.mitre.org> (Happy New Year, all!) Ref: MILW0RM:4828 http://www.milw0rm.com/exploits/4828 Researcher: TrYaG-TeaM [Tryag.com/cc] (I guess) download.php invokes download2.php with a file parameter, so register_globals is assumed/required. $file is not checked in the "config.inc.php" that's included by download2.php. download2.php later calls: @readfile($file); unlink($file); So, the impact also appears to be file deletion when permissions allow. Deletion was not mentioned in the original disclosure. - Steve From theall at tenablesecurity.com Mon Jan 7 02:55:48 2008 From: theall at tenablesecurity.com (George A. Theall) Date: Sun, 6 Jan 2008 21:55:48 -0500 Subject: [VIM] Horde Web-Mail 3.x (go.php) Remote File Disclosure Vulnerability Message-ID: Isn't milw0rm 4850 just a repeat of the issue reported nearly two years ago by Paul Craig: http://www.securityfocus.com/archive/1/427710/30/0/threaded George -- theall at tenablesecurity.com From theall at tenablesecurity.com Mon Jan 7 17:49:11 2008 From: theall at tenablesecurity.com (George A. Theall) Date: Mon, 7 Jan 2008 12:49:11 -0500 Subject: [VIM] Uebimiau Web-Mail 2.7.10/2.7.2 Remote File Disclosure Vulnerability Message-ID: <78E083D7-23AE-4DFE-AA1E-6D0483AC1718@tenablesecurity.com> The remote file disclosure issue in milw0rm 4846 / Bugtraq 27154 seems like a repeat of one of the issues reported by Michal Majchrowicz last May: http://archives.neohapsis.com/archives/fulldisclosure/ 2007-05/0511.html and covered by Bugtraq 24210. Has anyone else looked into this yet? George -- theall at tenablesecurity.com From str0ke at milw0rm.com Tue Jan 8 16:57:35 2008 From: str0ke at milw0rm.com (str0ke) Date: Tue, 08 Jan 2008 10:57:35 -0600 Subject: [VIM] Horde Web-Mail 3.x (go.php) Remote File Disclosure Vulnerability In-Reply-To: References: Message-ID: <4783AB7F.9020305@milw0rm.com> George, Seems to be. I added the link below to 4850. Regards, /str0ke George A. Theall wrote: > Isn't milw0rm 4850 just a repeat of the issue reported nearly two > years ago by Paul Craig: > > http://www.securityfocus.com/archive/1/427710/30/0/threaded > > George > --theall at tenablesecurity.com > > > > From theall at tenablesecurity.com Tue Jan 8 17:35:01 2008 From: theall at tenablesecurity.com (George A. Theall) Date: Tue, 8 Jan 2008 12:35:01 -0500 Subject: [VIM] Wordpress Plugin Wp-FileManager 1.2 Remote Upload Vulnerability Message-ID: Has anyone looked at milw0rm 4844 yet? It supposedly involves the Wp- FileManager plugin for WordPress, yet the download file it points to does not contain the affected file. Nor does one downloaded from johannesries.de, which is the author's site. George -- theall at tenablesecurity.com From coley at linus.mitre.org Tue Jan 8 18:27:16 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 8 Jan 2008 13:27:16 -0500 (EST) Subject: [VIM] broken links for lists.grok.org.uk Full-Disclosure Message-ID: I'm sure that everyone will be as thrilled as I am that a ton of URLs for Full-Disclosure archives on lists.grok.org.uk are now completely broken. Examples: http://lists.grok.org.uk/pipermail/full-disclosure/2007-September/065902.html was: VMSA-2007-0006 Critical security updates for all ... URL should be: http://lists.grok.org.uk/pipermail/full-disclosure/2007-September/056849.html --- http://lists.grok.org.uk/pipermail/full-disclosure/2007-October/066744.html was: AST-2007-023: SQL Injection POC and details URL should be: http://lists.grok.org.uk/pipermail/full-disclosure/2007-October/057684.html I don't know how far back it goes and am currently miffed enough not to check. - Steve From str0ke at milw0rm.com Tue Jan 8 18:39:06 2008 From: str0ke at milw0rm.com (str0ke) Date: Tue, 08 Jan 2008 12:39:06 -0600 Subject: [VIM] Wordpress Plugin Wp-FileManager 1.2 Remote Upload Vulnerability In-Reply-To: References: Message-ID: <4783C34A.3080809@milw0rm.com> Seems the link is wrong on the site. developers url: johannesries.de/webwork/wp-filemanager/ You can check the link below for further info. http://thescrumbrandon.com/v1/wp-content/plugins/wp-filemanager/readme.txt /str0ke George A. Theall wrote: > Has anyone looked at milw0rm 4844 yet? It supposedly involves the > Wp-FileManager plugin for WordPress, yet the download file it points > to does not contain the affected file. Nor does one downloaded from > johannesries.de, which is the author's site. > > George > --theall at tenablesecurity.com > > > > From str0ke at milw0rm.com Tue Jan 8 18:55:06 2008 From: str0ke at milw0rm.com (str0ke) Date: Tue, 08 Jan 2008 12:55:06 -0600 Subject: [VIM] Wordpress Plugin Wp-FileManager 1.2 Remote Upload Vulnerability In-Reply-To: <4783C34A.3080809@milw0rm.com> References: <4783C34A.3080809@milw0rm.com> Message-ID: <4783C70A.4070705@milw0rm.com> Strip the email below, seems ajaxfilemanager is some sort of addon for wp-filemanager. Still looking George ;) /str0ke str0ke wrote: > Seems the link is wrong on the site. > > developers url: johannesries.de/webwork/wp-filemanager/ > > You can check the link below for further info. > > http://thescrumbrandon.com/v1/wp-content/plugins/wp-filemanager/readme.txt > > /str0ke > > George A. Theall wrote: > >> Has anyone looked at milw0rm 4844 yet? It supposedly involves the >> Wp-FileManager plugin for WordPress, yet the download file it points >> to does not contain the affected file. Nor does one downloaded from >> johannesries.de, which is the author's site. >> >> George >> --theall at tenablesecurity.com >> >> >> >> >> > > From coley at linus.mitre.org Tue Jan 8 21:50:26 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 8 Jan 2008 16:50:26 -0500 (EST) Subject: [VIM] Vendor ACK for CVE-2007-6551 (MailMachine Pro SQL injection) Message-ID: ---------- Forwarded message ---------- Date: Tue, 08 Jan 2008 13:02:05 -0800 From: MailMachinePRO Support To: cve at mitre.org Subject: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6551 To Whom This May Concern, Regarding the vulnerability expressed at: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6551 I have issued a new version of the program(2.2.6) and a patch to resolve this. Can you please make this information available on your website. From theall at tenablesecurity.com Wed Jan 9 13:44:32 2008 From: theall at tenablesecurity.com (George A. Theall) Date: Wed, 9 Jan 2008 08:44:32 -0500 Subject: [VIM] broken links for lists.grok.org.uk Full-Disclosure In-Reply-To: References: Message-ID: <89A69891-50F5-4F54-B2D2-07116CADA93A@tenablesecurity.com> On Jan 8, 2008, at 1:27 PM, Steven M. Christey wrote: > I'm sure that everyone will be as thrilled as I am that a ton of > URLs for > Full-Disclosure archives on lists.grok.org.uk are now completely > broken. I just finished searching link in the Nessus plugins. We fortunately had only 50+ such links and, of those, I found only two that were broken. I'd be happy to share what I found, just let me know. George -- theall at tenablesecurity.com From coley at linus.mitre.org Wed Jan 9 19:55:04 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 9 Jan 2008 14:55:04 -0500 (EST) Subject: [VIM] broken links for lists.grok.org.uk Full-Disclosure In-Reply-To: <89A69891-50F5-4F54-B2D2-07116CADA93A@tenablesecurity.com> References: <89A69891-50F5-4F54-B2D2-07116CADA93A@tenablesecurity.com> Message-ID: Thanks, George. We have 700+ links based on a quick search. CVE's reference style would make it slightly easy to re-map them since we include date and subject in the reference. Another item for the to-do list :) - Steve On Wed, 9 Jan 2008, George A. Theall wrote: > On Jan 8, 2008, at 1:27 PM, Steven M. Christey wrote: > > > I'm sure that everyone will be as thrilled as I am that a ton of > > URLs for > > Full-Disclosure archives on lists.grok.org.uk are now completely > > broken. > > I just finished searching link in the Nessus plugins. We fortunately > had only 50+ such links and, of those, I found only two that were > broken. I'd be happy to share what I found, just let me know. > > George > -- > theall at tenablesecurity.com > > > > From coley at mitre.org Thu Jan 10 21:18:35 2008 From: coley at mitre.org (Steven M. Christey) Date: Thu, 10 Jan 2008 16:18:35 -0500 (EST) Subject: [VIM] affected version update for PostgreSQL issues Message-ID: <200801102118.m0ALIZr4016133@faron.mitre.org> FYI, I heard from Red Hat: "Regular expression flaws (CVE-2007-4769, CVE-2007-4772, CVE-2007-6067) do not affect PostgreSQL versions prior to 7.4. So 7.3 branch is not affected. This was originally incorrectly described on PostgreSQL security page (http://www.postgresql.org/support/security.html), but the information is corrected now." The specified URL doesn't list 7.x for those 3 CVE's. - Steve From theall at tenablesecurity.com Sat Jan 12 12:57:43 2008 From: theall at tenablesecurity.com (George A. Theall) Date: Sat, 12 Jan 2008 07:57:43 -0500 Subject: [VIM] Question about CVE-2007-0012 Message-ID: <8B16C8C3-EEF2-4324-9E29-7BE535C41975@tenablesecurity.com> Has anyone found any confirmation from Sun about the DoS issue reported by Corsaire and covered by Bugtraq 27185 / CVE-2007-0012? I'm probably just missing something, but I don't find any mention of it in the release notes for JDK 5.0 Update 14 nor in bugs.sun.com (whether searching for bug id 6511363 or something like jpiexp32.dll). http://www.securityfocus.com/archive/1/485942/30/0/threaded http://java.sun.com/j2se/1.5.0/ReleaseNotes.html George -- theall at tenablesecurity.com From noamr at beyondsecurity.com Mon Jan 14 19:50:27 2008 From: noamr at beyondsecurity.com (Noam Rathaus) Date: Mon, 14 Jan 2008 21:50:27 +0200 Subject: [VIM] CVE published vs unpublished Message-ID: <200801142150.27475.noamr@beyondsecurity.com> Hi, Can someone from CVE administrator give me an estimate how many given CVEs have not materialized into "anything" (never been disclosed - remained under review)? -- Noam Rathaus CTO noamr at beyondsecurity.com http://www.beyondsecurity.com "Know that you are safe." Beyond Security Finalist for the "Red Herring 100 Global" Awards 2007 From mjc at redhat.com Tue Jan 15 09:39:06 2008 From: mjc at redhat.com (Mark J Cox) Date: Tue, 15 Jan 2008 09:39:06 +0000 (GMT) Subject: [VIM] vuldb confusion between OpenPegasus issues Message-ID: <0801150920490.10265@mjc.redhat.com> It seems that some vulndbs have got a bit confused by the OpenPegasus issues that were reported a couple of weeks ago. That misinformation is working it's way up into public reports. So, for the record: In December 2007, VMWare contacted the vendor-sec mailing list to let us know they'd found a pre-authentication buffer overflow in OpenPegasus versions prior to 2.7. This issue was credited as being discovered by Alexander Sotirov of VMware and allocated CVE-2007-5360. This overflow only affected OpenPegasus builds that had been compiled to use PAM and with the (optional) PEGASUS_USE_PAM_STANDALONE_PROC define. This issue affected the VMWare OpenPegasus builds, but not the Red Hat OpenPegasus builds. http://marc.info/?l=full-disclosure&m=119975801904357&w=2 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2007-5360 However, whilst investigating this issue, the Red Hat Security Response Team discovered that there was a similar pre-authentication buffer overflow affecting OpenPegasus versions prior to 2.7, but this time it affected servers that had been compiled with PAM but without the PEGASUS_USE_PAM_STANDALONE_PROC define, and was in a different piece of code to the CVE-2007-5360 flaw. This issue did affect the Red Hat OpenPegasus builds. We allocated CVE-2008-0003 to this issue. https://rhn.redhat.com/errata/RHSA-2008-0002.html https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2008-0003 Both of the issues were corrected upstream by a single patch, attached to OpenPegasus bug 7220, the patch was written by Roger Kumpf. Versions 2.7 were already not vulnerable as both bits of affected code had been refactored for that release. http://cvs.opengroup.org/bugzilla/show_bug.cgi?id=7220 Thanks, Mark -- Mark J Cox / Red Hat Security Response Team From coley at linus.mitre.org Wed Jan 16 22:16:44 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 16 Jan 2008 17:16:44 -0500 (EST) Subject: [VIM] Question about CVE-2007-0012 In-Reply-To: <8B16C8C3-EEF2-4324-9E29-7BE535C41975@tenablesecurity.com> References: <8B16C8C3-EEF2-4324-9E29-7BE535C41975@tenablesecurity.com> Message-ID: On Sat, 12 Jan 2008, George A. Theall wrote: > Has anyone found any confirmation from Sun about the DoS issue > reported by Corsaire and covered by Bugtraq 27185 / CVE-2007-0012? CVE hasn't, no... - Steve From theall at tenablesecurity.com Fri Jan 18 16:28:26 2008 From: theall at tenablesecurity.com (George A. Theall) Date: Fri, 18 Jan 2008 11:28:26 -0500 Subject: [VIM] Small Axe 0.3.1 (linkbar.php cfile) Remote File Inclusion Vulnerability Message-ID: Milw0rm 4937 / Bugtraq 27345 seems bogus to me, but I can't be sure because the distribution file for 0.3.1 referenced in the advisory is incomplete. At the start of the affected file we have: include_once("inc/config.inc.php"); include_once("inc/coreFX.inc.php"); include_once($cfile); inc/config.inc.php has this at the bottom: $cwd = getcwd(); $publicPath = str_replace(basename($_SERVER['PHP_SELF']),"", $_SERVER['REQUEST_URI']); $svrRoot = str_replace(basename($_SERVER ['PHP_SELF']),"",$cwd); $tmpldir = $svrRoot."/tmpl/"; $publicURL = "http://".$HTTP_HOST.$publicPath; $cfile = $svrRoot."/inc/".$CONFIG['backend']."/ connect.inc.php"; $ffile = $svrRoot."/inc/".$CONFIG['backend']."/ functions.inc.php"; $GLOBALS['q'] = 0; $plugin_dir = $svrRoot."/plugins/"; foreach (glob($plugin_dir."*/setup.php") as $plugin_init) { @include($plugin_init); } And coreFX.inc.php only has function definitions. I didn't see a 'plugins' directory in the distribution file so it seems like '$cfile' isn't directly controllable by an attacker, at least unless there's an additional plugin installed that does something stupid. I did try to set this up to see if plugins were somehow created dynamically, but the setup program in reality only supports a MySQL- based installation (at least in 0.3.1), fails miserably if you use a prefix in table names, and even then, doesn't create necessary config files. George -- theall at tenablesecurity.com From str0ke at milw0rm.com Fri Jan 18 16:41:28 2008 From: str0ke at milw0rm.com (str0ke) Date: Fri, 18 Jan 2008 10:41:28 -0600 Subject: [VIM] Small Axe 0.3.1 (linkbar.php cfile) Remote File Inclusion Vulnerability In-Reply-To: References: Message-ID: <4790D6B8.9090505@milw0rm.com> George, There isn't an inc directory in the inc directory. linkbar.php ######## include_once("inc/config.in.php"); << no file found include_once("inc/coreFX.inc.php"); << no file found include_once($cfile); Looks good to me. /str0ke George A. Theall wrote: > Milw0rm 4937 / Bugtraq 27345 seems bogus to me, but I can't be sure > because the distribution file for 0.3.1 referenced in the advisory is > incomplete. At the start of the affected file we have: > > include_once("inc/config.inc.php"); > include_once("inc/coreFX.inc.php"); > include_once($cfile); > > inc/config.inc.php has this at the bottom: > > $cwd = getcwd(); > $publicPath = > str_replace(basename($_SERVER['PHP_SELF']),"",$_SERVER['REQUEST_URI']); > $svrRoot = > str_replace(basename($_SERVER['PHP_SELF']),"",$cwd); > $tmpldir = $svrRoot."/tmpl/"; > $publicURL = "http://".$HTTP_HOST.$publicPath; > $cfile = > $svrRoot."/inc/".$CONFIG['backend']."/connect.inc.php"; > $ffile = > $svrRoot."/inc/".$CONFIG['backend']."/functions.inc.php"; > $GLOBALS['q'] = 0; > $plugin_dir = $svrRoot."/plugins/"; > foreach (glob($plugin_dir."*/setup.php") as $plugin_init) { > @include($plugin_init); > } > > And coreFX.inc.php only has function definitions. > > I didn't see a 'plugins' directory in the distribution file so it > seems like '$cfile' isn't directly controllable by an attacker, at > least unless there's an additional plugin installed that does > something stupid. > > I did try to set this up to see if plugins were somehow created > dynamically, but the setup program in reality only supports a > MySQL-based installation (at least in 0.3.1), fails miserably if you > use a prefix in table names, and even then, doesn't create necessary > config files. > > George > --theall at tenablesecurity.com > > > > From theall at tenablesecurity.com Fri Jan 18 16:46:12 2008 From: theall at tenablesecurity.com (George A. Theall) Date: Fri, 18 Jan 2008 11:46:12 -0500 Subject: [VIM] Small Axe 0.3.1 (linkbar.php cfile) Remote File Inclusion Vulnerability In-Reply-To: <4790D6B8.9090505@milw0rm.com> References: <4790D6B8.9090505@milw0rm.com> Message-ID: On Jan 18, 2008, at 11:41 AM, str0ke wrote: > There isn't an inc directory in the inc directory. > > linkbar.php > ######## > include_once("inc/config.in.php"); << no file found > include_once("inc/coreFX.inc.php"); << no file found > include_once($cfile); > > Looks good to me. Oh, you're right as usual, str0ke. George -- theall at tenablesecurity.com From str0ke at milw0rm.com Fri Jan 18 16:54:41 2008 From: str0ke at milw0rm.com (str0ke) Date: Fri, 18 Jan 2008 10:54:41 -0600 Subject: [VIM] Small Axe 0.3.1 (linkbar.php cfile) Remote File Inclusion Vulnerability In-Reply-To: References: <4790D6B8.9090505@milw0rm.com> Message-ID: <4790D9D1.5070400@milw0rm.com> We help each other out :) /str0ke George A. Theall wrote: > On Jan 18, 2008, at 11:41 AM, str0ke wrote: > >> There isn't an inc directory in the inc directory. >> >> linkbar.php >> ######## >> include_once("inc/config.in.php"); << no file found >> include_once("inc/coreFX.inc.php"); << no file found >> include_once($cfile); >> >> Looks good to me. > > Oh, you're right as usual, str0ke. > > George From str0ke at milw0rm.com Mon Jan 21 15:46:40 2008 From: str0ke at milw0rm.com (str0ke) Date: Mon, 21 Jan 2008 09:46:40 -0600 Subject: [VIM] Milw0rm [4875] Message-ID: <4794BE60.6050609@milw0rm.com> Will be removed from the database. The author stated the vulnerability was an error. /str0ke From coley at linus.mitre.org Wed Jan 23 20:23:26 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 23 Jan 2008 15:23:26 -0500 (EST) Subject: [VIM] Milw0rm [4875] In-Reply-To: <4794BE60.6050609@milw0rm.com> References: <4794BE60.6050609@milw0rm.com> Message-ID: > Will be removed from the database. The author stated the vulnerability > was an error. The foxcommand issue? That's kind of weird, since the author is shinnai and it's also documented in Secunia SA28417, which implies that they verified it themselves. Did you have a typo in the ID you mentioned? - Steve From str0ke at milw0rm.com Wed Jan 23 20:29:09 2008 From: str0ke at milw0rm.com (str0ke) Date: Wed, 23 Jan 2008 14:29:09 -0600 Subject: [VIM] Milw0rm [4875] In-Reply-To: References: <4794BE60.6050609@milw0rm.com> Message-ID: <4797A395.7010901@milw0rm.com> email from shinnai. It was a mistake and I would like to know if you could remove it from your site. I already remove it from my site. /str0ke Steven M. Christey wrote: >> Will be removed from the database. The author stated the vulnerability >> was an error. >> > > The foxcommand issue? That's kind of weird, since the author is shinnai > and it's also documented in Secunia SA28417, which implies that they > verified it themselves. > > Did you have a typo in the ID you mentioned? > > - Steve > > From coley at linus.mitre.org Wed Jan 23 21:12:51 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 23 Jan 2008 16:12:51 -0500 (EST) Subject: [VIM] CVE published vs unpublished In-Reply-To: <200801142150.27475.noamr@beyondsecurity.com> References: <200801142150.27475.noamr@beyondsecurity.com> Message-ID: > Can someone from CVE administrator give me an estimate how many given CVEs > have not materialized into "anything" (never been disclosed - remained under > review)? I can only give estimates, because I don't have any visibility into the status of CVE pools that were given to CNAs (Candidate Numbering Authorities). Also, I don't ping the people who reserved CVEs in order to check on their status. Some might have turned out to be false and the requester never notified us; in other cases, maybe a decision was made not to publish; some might still be in the middle of the resolution process. Also, we are inconsistent about handling vague vulnerability reports from auction / non-disclosure firms like WabiSabiLabi and Immunity, but generally don't include them. This includes the hash publications we're starting to see more of. Finally, sometimes somebody publishes a CVE to a source that's not monitored by Refined Vulnerability Information sources, and we don't notice that it's been published - but this is 5% at most, and probably more like 1 to 2%. I generated some stats based on how many CVE's still have the "** RESERVED **" text in the descriptions: ============================= Active Reserved ============================= 2001 28 2002 57 2003 79 2004 102 2005 203 2006 213 2007 337 2008 163 So, this is a maximum number. However, many of these are associated with CNA pools, and many of them might be lying around, not assigned to any specific issue. The following two tables are for CVE's that are definitely associated with CNA pools (findable from an inconsistently-used convention I have), plus "likely CNAs" - individuals who almost always reserve issues because they're CNAs: ============================= Definite CNA ============================= 2002 --> 9 2003 --> 40 2004 --> 51 2005 --> 61 2006 --> 68 2007 --> 72 2008 --> 46 ============================= Likely CNA ============================= 2001 --> 10 2002 --> 15 2003 --> 3 2004 --> 3 2005 --> 32 2006 --> 11 2007 --> 87 2008 --> 49 I could try to infer pools to clean up the likely CNA stats, but these stats are cheap, and unfortunately I don't have a lot of time for this. With definite and likely CNA pools, there's no way of knowing how many of those CVEs remain unassociated with any issue, versus those that were assigned to an issue, but never published. It's probably reasonably safe to assume that most of the CNA CVE's from 2006 and earlier are unassigned; I don't think that I've had more than 2 or 3 interactions in which it became clear that the CNA was going to intentionally keep an issue private, even after a CVE had been assigned. Then we have CVEs reserved by people who are definitely not CNAs (or very, very rarely have that role). These are likely to have been reserved for specific issues: ============================= Non-CNA ============================= 2001 18 2002 33 2003 36 2004 48 2005 110 2006 134 2007 178 2008 68 For each year, we have: Active Reserved = Non-CNA + Likely CNA + Definite CNA We can treat the Non-CNA values as a minimum estimate (which might still be higher than the real number), Active Reserved as a maximum estimate (probably also higher than the real number). I think I can safely estimate that 50% of reserved CVEs from definite CNAs, and 20% from likely CNAs, remain unsassigned (let's ignore the higher likelihood for 2006 and earlier). So, a more reasonable max. estimate would be: Non-CNA + (20% of Likely CNA) + (50% of Definite CNA) which leaves us with the final estimate: ============================= Estimated Min/Max ============================= 2001 min=18 ; max=20 2002 min=33 ; max=40 2003 min=36 ; max=56 2004 min=48 ; max=74 2005 min=110 ; max=146 2006 min=134 ; max=170 2007 min=178 ; max=231 2008 min=68 ; max=100 Note - these figures feel high, but on the other hand, CVE reservation is a daily task so I might not be conscious of how much remains unpublished. - Steve From str0ke at milw0rm.com Wed Jan 23 22:27:57 2008 From: str0ke at milw0rm.com (str0ke) Date: Wed, 23 Jan 2008 16:27:57 -0600 Subject: [VIM] Milw0rm [4875] In-Reply-To: <4797A395.7010901@milw0rm.com> References: <4794BE60.6050609@milw0rm.com> <4797A395.7010901@milw0rm.com> Message-ID: <4797BF6D.8080002@milw0rm.com> Shinnai has stated in another email that it was a mix up. It's a false vulnerability /str0ke str0ke wrote: > email from shinnai. > > It was a mistake and I would like to know if you could remove it from your > site. I already remove it from my site. > > > /str0ke > > Steven M. Christey wrote: > >>> Will be removed from the database. The author stated the vulnerability >>> was an error. >>> >>> >> The foxcommand issue? That's kind of weird, since the author is shinnai >> and it's also documented in Secunia SA28417, which implies that they >> verified it themselves. >> >> Did you have a typo in the ID you mentioned? >> >> - Steve >> >> >> > > From theall at tenablesecurity.com Thu Jan 24 15:56:14 2008 From: theall at tenablesecurity.com (George A. Theall) Date: Thu, 24 Jan 2008 10:56:14 -0500 Subject: [VIM] MoinMoin 1.5.x MOIND_ID cookie Bug Remote Exploit Message-ID: I haven't seen much coverage of this yet. The title of milw0rm 4957 isn't very suggestive. And SecurityFocus in Bugtraq 27404 calls it an authentication bypass vulnerability. At first blush, the PoC doesn't look that serious -- it creates an account in MoinMoin and stores the profile info in a specified file ("README"). But MoinMoin lets anyone create a user profile, right? And it uses the filename of that profile as the value for the MOIN_ID cookie when you login, doesn't it? So what's the problem? Actually, I think there are two: First, the value of the MOIN_ID can be anything as long as it points to an existing file that's writable by the web server user id. README likely works because it is included by default. Ditto "../edit-log". Even something like "../../../../../../../../../../var/www/html/ index.php" could work. Second, the value for the 'quicklinks' parameter is not sanitized. The PoC uses "podriamos-insertar-codigo-php-aqui-verdad-que-si", which loosely translates to "we could insert PHP code here". And indeed, something like "" suitably encoded goes through just fine. Combine the two issues and you've probably got a nice vector for remote code execution, as long as the remote web server supports PHP and you can figure out a path to a writable PHP file in the web directory root. Sweet! I've verified the issues in MoinMoin 1.5.8 (the latest in the 1.5 series). The patch only fixes the first. As for the second, the MoinMoin developers don't see that as their problem since you could just as easily put PHP code in a Wiki page. George -- theall at tenablesecurity.com From coley at mitre.org Tue Jan 29 19:02:11 2008 From: coley at mitre.org (Steven M. Christey) Date: Tue, 29 Jan 2008 14:02:11 -0500 (EST) Subject: [VIM] Seagull 0.6.3 Remote File Disclosure Vulnerability fixed Message-ID: <200801291902.m0TJ2BYY024370@faron.mitre.org> Refs: CVE-2008-0465, MILW0RM:4980 NVD received an email from the vendor, clarifying that only 0.6.3 is affected, and it's Seagull, not the "PHP Framework" (str0ke, you say "<= 0.6.3"). Acknowledgement is also here: http://seagullproject.org/publisher/articleview/action/view/frmArticleID/98/ - Steve From str0ke at milw0rm.com Tue Jan 29 19:13:27 2008 From: str0ke at milw0rm.com (str0ke) Date: Tue, 29 Jan 2008 13:13:27 -0600 Subject: [VIM] Seagull 0.6.3 Remote File Disclosure Vulnerability fixed In-Reply-To: <200801291902.m0TJ2BYY024370@faron.mitre.org> References: <200801291902.m0TJ2BYY024370@faron.mitre.org> Message-ID: <479F7AD7.50004@milw0rm.com> Steven M. Christey wrote: > Refs: CVE-2008-0465, MILW0RM:4980 > > > NVD received an email from the vendor, clarifying that only 0.6.3 is > affected, and it's Seagull, not the "PHP Framework" (str0ke, you say > "<= 0.6.3"). > Changed to just 0.6.3, 0.6.1 isn't affected and removed the php framework from the name. The main page states Seagull PHP Framework << reason for adding PHP framework to the product name. > Acknowledgement is also here: > > http://seagullproject.org/publisher/articleview/action/view/frmArticleID/98/ > > > - Steve > Thanks again Steve, /str0ke From theall at tenablesecurity.com Thu Jan 31 11:51:04 2008 From: theall at tenablesecurity.com (George A. Theall) Date: Thu, 31 Jan 2008 06:51:04 -0500 Subject: [VIM] What's the difference... Message-ID: <47A1B628.4020305@tenablesecurity.com> Str0ke, what's the difference between milw0rm 5013 and 5023? Both cover a SQL injection issue in AdServe's adclick.php script involving the id parameter. George -- theall at tenablesecurity.com From str0ke at milw0rm.com Thu Jan 31 14:26:15 2008 From: str0ke at milw0rm.com (str0ke) Date: Thu, 31 Jan 2008 08:26:15 -0600 Subject: [VIM] What's the difference... In-Reply-To: <47A1B628.4020305@tenablesecurity.com> References: <47A1B628.4020305@tenablesecurity.com> Message-ID: <47A1DA87.6080603@milw0rm.com> Not a single difference George, removing 5023. /str0ke George A. Theall wrote: > Str0ke, what's the difference between milw0rm 5013 and 5023? Both > cover a SQL injection issue in AdServe's adclick.php script involving > the id parameter. > > George From str0ke at milw0rm.com Thu Jan 31 15:05:07 2008 From: str0ke at milw0rm.com (str0ke) Date: Thu, 31 Jan 2008 09:05:07 -0600 Subject: [VIM] [Fwd: contactforms "cforms-css.php" Remote File Inclusion] Message-ID: <47A1E3A3.9040806@milw0rm.com> The only contactforms I can find with cforms-css.php is a wordpress plugin. The script dies on its first line of code line 7 because function load_plugin_textdomain could not be found. /str0ke -------------- next part -------------- An embedded message was scrubbed... From: Sw33t.h4cK3r at c13-ss-2-lb.cnet.com, com at securityfocus.com Subject: contactforms "cforms-css.php" Remote File Inclusion Date: 31 Jan 2008 03:14:03 -0000 Size: 1693 Url: http://www.attrition.org/pipermail/vim/attachments/20080131/1092b0ec/attachment.eml