From coley at mitre.org  Sun Apr  2 16:16:22 2006
From: coley at mitre.org (Steven M. Christey)
Date: Sun, 2 Apr 2006 16:16:22 -0400 (EDT)
Subject: [VIM] Warcraft III Replay Parser - accuracy problems
Message-ID: <200604022016.k32KGMoF003527@cairo.mitre.org>


Ref:

  BUGTRAQ:20060331 Warcraft III Replay Parser Script Remote Command Exucetion Vulnerability And Cross-Site Scripting Attacking
  URL:http://www.securityfocus.com/archive/1/archive/1/429535/100/0/threaded

The researcher, botan, provides example URLs:

  http://www.site.com/[path]/index.php?page=evilcode.txt?&cmd=uname -a

  http://www.site.com/[path]/index.php?page=evilcode.txt?&cmd=uname -a

FYI, the report is for 1.8c, but 2.2 is the most recent version, and
it has been available since 2005.

Issues:

1) grep of source for versions 1.0, 1.8c, and 2.2 shows no use of
   "page" anywhere.

2) Default distribution of 1.8c doesn't even include an index.php.  In
   1.8c and 2.2, vendor provides an "example.php" that appears to be
   used by some live sites; maybe some live sites rename example.php
   to index.php.

3) The id parameter ($id variable) in example.php (1.8c) does appear
   to have XSS:

      <div id="top">'.$id.' details</div>

   as well as here:

        if ($id) {
          echo('<br /><br />
          <a class="function" href="'.$w3g_path.$id.'.w3g">&#187; download</a>('.round(filesize($w3g_path.$id.'.w3g')/1024).' KB)');

   And also appears to be subject to local fopen:

      if (file_exists($txt_path.$id.'.txt')) {
        $txt_file = fopen($txt_path.$id.'.txt', 'r');

   ... although it assumes serialized data so there's a possibility
   that this is not cleanly exploitable for directory traversal.

4) Researcher's example  "code execution" URL is:

  http://www.site.com/[path]/index.php?page=evilcode.txt?&cmd=uname -a

  Besides the mystery of the "page" parameter, there are no
  attacker-controllable include or require statements in any of the
  examined versions.

  Some fopen statements are used.  The "new replay" statements use the
  replay function in the replay class in w3g-julas.php, which gets a
  filename argument and does an fopen.

But at this point, I've spent too much time on this analysis so have
to back off in figuring out what's really going on.

- Steve

From coley at mitre.org  Mon Apr  3 00:32:07 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 3 Apr 2006 00:32:07 -0400 (EDT)
Subject: [VIM] Neohapsis links broken for March
Message-ID: <200604030432.k334W7Tc010598@cairo.mitre.org>


FYI, from the Neohapsis front page:

  Mar 20, 2006 - There was an error in the archive rotation process at
  the beginning of March. Posts destined for a 2006-03 March archive
  were instead added to the existing 2006-02 February archive. All
  month-based lists were affected. We have corrected the problem by
  regenerating the 2006-02 archives and moving all March posts to
  2006-03 archives. However, the March posts have been shuffled to a
  new location, which means external/third-party links to the
  erroneous February archive locations may no longer work. We
  apologize for this inconvenience.

- Steve

From jericho at attrition.org  Mon Apr  3 00:37:03 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 3 Apr 2006 00:37:03 -0400 (EDT)
Subject: [VIM] Neohapsis links broken for March
In-Reply-To: <200604030432.k334W7Tc010598@cairo.mitre.org>
References: <200604030432.k334W7Tc010598@cairo.mitre.org>
Message-ID: <Pine.LNX.4.64.0604030036080.5422@forced.attrition.org>


: FYI, from the Neohapsis front page:
: 
:   Mar 20, 2006 - There was an error in the archive rotation process at
:   the beginning of March. Posts destined for a 2006-03 March archive
:   were instead added to the existing 2006-02 February archive. All
:   month-based lists were affected. We have corrected the problem by
:   regenerating the 2006-02 archives and moving all March posts to
:   2006-03 archives. However, the March posts have been shuffled to a
:   new location, which means external/third-party links to the
:   erroneous February archive locations may no longer work. We
:   apologize for this inconvenience.

This hurt us pretty bad since OSVDB uses them heavily. The real 
unfortunate part is that I mailed them on the 7th to notify them the 
rotation hadn't occured. 13 days later they fixed it, causing a big mess 
of links to go bad.

From jericho at attrition.org  Mon Apr  3 14:41:31 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 3 Apr 2006 14:41:31 -0400 (EDT)
Subject: [VIM] reasons for not disclosing
Message-ID: <Pine.LNX.4.64.0604031441060.5422@forced.attrition.org>


http://archives.neohapsis.com/archives/fulldisclosure/2006-03/1907.html

4) Fix
======

No fix.

Developers have not been contacted for the following reason:

Zdaemon has some problems with its license, it is based on many open 
source code (mainly Zdoom) and it was open source till version 1.06 (the 
old website was http://www.zdaemon.info, you can still find the cache on 
some search engines). Then the developers decided to close the source code 
because some cheaters created an aimbot (a tool/patch for killing enemies 
more easily) for this game but IMHO, and this is the same opinion of many 
people, what they have done is not compatible with the GPL license (the id 
Software Doom engine is GPLed) and with the strong philosophy behind the 
open source movement.

Personal comment: closing the source code is not a solution, will never 
stop cheaters (they do only what the server allows to do) and has not 
stopped me to find these security vulnerabilities.

From coley at mitre.org  Mon Apr  3 23:08:59 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 3 Apr 2006 23:08:59 -0400 (EDT)
Subject: [VIM] Vendor ACK for VWar issue - VWar used by PhpNuke Clan
Message-ID: <200604040308.k3438xO6026234@cairo.mitre.org>



Vendor has provided ACK and fix for CVE-2006-1503.

The front page of the VWar web site (http://www.vwar.de/) says:

  31.03.2006 18:07

  ATTENTION: MAJOR SECURITY UPDATE

  This vulnerability has been reported on securityfocus.com.  We
  recommend to replace the file functions_install.php as soon as
  possible.

  fixed: XSS bug in functions_install.php which could allow malicious
  users to include a (remote) file and eg. execute php commands on the
  server hosting vwar

Obviously, the developer is referring to file inclusion and not "XSS"

Also, for those who care, the following PhpNuke Clan web announcement
shows that it uses VWar as a module:

  http://www.codezwiz.com/article492-phpnuke-clan-210-has-been-released.html

  "PHPNUKE-CLAN.COM Release the new version of PNC! The version 2.1.0
  With VWAR & Server Viewer installed on it! The installation are
  simplified, more block for VWAR and JAG Online for the User Info
  blocks! "

This could be relevant for this Bugtraq post:

  BUGTRAQ:20060401 PHPNuke-Clan 3.0.1 Remote File Inclusion Exploit
  http://www.securityfocus.com/archive/1/archive/1/429615/100/0/threaded

since the demonstration URL here shows the VWar relationship:

  modules/vWar_Account/includes/functions_common.php?vwar_root2=


HOWEVER: since the include file and parameter name are different than
original reported vectors for VWar, this could be a separate issue.

PHPNuke Clan requires registration to download, and so does vWar, so I
didn't investigate any further.

- Steve

From coley at mitre.org  Tue Apr  4 00:59:30 2006
From: coley at mitre.org (Steven M. Christey)
Date: Tue, 4 Apr 2006 00:59:30 -0400 (EDT)
Subject: [VIM] FleXiBle Development Script Remote Command Exucetion And
	XSS Attacking
Message-ID: <200604040459.k344xUvj027165@cairo.mitre.org>


botan at linuxmail has been posting a lot of barely-usable advisories,
including this one and the recent Warcraft III replay parser.  Anybody
with any ideas?

>FleXiBle Development (FXB)

Is this a web site, product, or service?  A Google search yields very
little information, except for the original Bugtraq post.  I cannot
find any information on this.

>Web: http://www.ahbruinsma.nl

As of April 3, you cannot read the front page.  The web site requires
authentication.


>require('php/messages.php');
>//require base-file
>//require_once('php/base.php');
>include_once "baseconfig.inc.php";

None of these statements use variables, or attacker-controlled input.


> http://www.site.com/[path]/evilcode.txt?&cmd=uname -a

It is difficult to see what kind of issue is being talked about here.

The use of a "cmd" parameter is consistent with exploits for file
inclusion, but based on the source code that was listed, there isn't
any way to control any variable.

Or maybe they mean that the site (or product) allows people to upload
files that contain PHP code, then access them later?

Or another kind of problem altogether?

Also, the title includes "XSS Attacking" but there aren't any examples
for where the XSS might be.


- Steve

From coley at mitre.org  Fri Apr  7 01:43:08 2006
From: coley at mitre.org (Steven M. Christey)
Date: Fri, 7 Apr 2006 01:43:08 -0400 (EDT)
Subject: [VIM] Crafted vs. malformed: a terminology issue
Message-ID: <200604070543.k375h8l6016242@cairo.mitre.org>


I like this advisory:

http://www.cisco.com/warp/public/707/cisco-sa-20060405-ons.shtml

 CSCsc51390: "Control card resets with crafted IP packet."

 CSCsd04168: "Control card resets with crafted IP packet."

 CSCsc54558: "Malformed OSPF packets cause control cards to reset."


So - were the "crafted" IP packets actually well-formed, but just not
expected?  Or was this just a different person writing a different
portion of the advisory who just happened to use a different word?

I've been wrestling with good terminology to distinguish "malformed"
inputs from "well, it's syntactically well-formed but the values
aren't actually correct" from "well, it's all technically allowed by
the specification but dang, we didn't see THAT one coming!"

The issue stems back to the original source, as we see above.  You
don't know what someone means when they refer to "crafted" or
"malformed" or "certain" inputs.  I've tried to make this distinction
in CVE descriptions - if it's syntactically wrong, then it's
"malformed".  If it's syntactically valid, then I use some other
phrasing to say what's wrong with it.  But (a) I still don't have good
terminology and (b) good terminology doesn't matter when your raw
sources are vague :)

I've also been thinking about what Gary McGraw (I think it was him)
and others have referred to as "syntactic" and "semantic" validity.
I'm still a little fuzzy on this, but: if an input is well-formed
(syntactically) but still causes an issue, then maybe it's a semantic
problem.  Then again, if you have a protocol spec that allows a "USER"
command with an arbitrary length username, but an application has a
buffer overflow after 256 characters - then it's syntactically valid
and, effectively, semantically valid.  A Google search led me to a
paper by Alan A. Jorgensen "Testing with Hostile Data Streams" that
also introduces lexical validity, and then "Guns and Butter:Towards
Formal Axioms of Input Validation" which was apparently presented at
Black Hat.

Anybody else think of this stuff when they should be doing REAL work
instead? ;-)

- Steve

From sullo at cirt.net  Mon Apr 10 01:29:38 2006
From: sullo at cirt.net (Sullo)
Date: Mon, 10 Apr 2006 01:29:38 -0400
Subject: [VIM] VEndor ACK: Simple Machines Forum Register.php
	X-Forwarded-For XSS
Message-ID: <4439ED42.7070501@cirt.net>

Vendor ACK for OSVDB-23480 & fixed version.


-------- Original Message --------

Hello,

The X-Forward-For exploit that was in SMF has now been patched, we
recommend all users update to SMF 1.0.7 to fix this issue.

SMF Announcement and Download:
http://www.simplemachines.org/community/index.php?topic=78841.0

Thanks.



From coley at mitre.org  Mon Apr 10 18:27:29 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 10 Apr 2006 18:27:29 -0400 (EDT)
Subject: [VIM] apt-webshop-system issue
Message-ID: <200604102227.k3AMRTOO003035@cairo.mitre.org>


FYI, some vuln DBs are skipping this item from r0t's advisory:

  http://pridels.blogspot.com/2006/04/apt-webshop-system-vuln.html

  Bonnus:

  /modules.php?warp=File


This smells like directory traversal or some related issue.  I did not
investigate extensively since the vendor site is in German and the
source does not appear to be available; however, a simple modification
of the warp value in one of the "demo-shops" generated a verbose error
message that suggested a problem in pathname construction.

- Steve

From coley at mitre.org  Mon Apr 10 22:40:12 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 10 Apr 2006 22:40:12 -0400 (EDT)
Subject: [VIM] r0t FAQ
Message-ID: <200604110240.k3B2eCGs005139@cairo.mitre.org>


Here's an interesting read :)

http://pridels.blogspot.com/2006/04/r0t-faq-edition-09-alfa.html

By the way, a look at his profile also suggests that he turned 15, for
those of you who frequently talk about software that can be easily
hacked by a 14 year old :)

- Steve

From sullo at cirt.net  Mon Apr 10 23:21:03 2006
From: sullo at cirt.net (Sullo)
Date: Mon, 10 Apr 2006 23:21:03 -0400
Subject: [VIM] r0t FAQ
In-Reply-To: <200604110240.k3B2eCGs005139@cairo.mitre.org>
References: <200604110240.k3B2eCGs005139@cairo.mitre.org>
Message-ID: <443B209F.3000704@cirt.net>

Steven M. Christey wrote:
> Here's an interesting read :)
>
> http://pridels.blogspot.com/2006/04/r0t-faq-edition-09-alfa.html
>
>   

4)Give me live example.
4. If you arent from Secunia,frsirt,osvdb or vendor i will not provide
you with any live examples or HowTo?s.


I feel so... loved.

Thanks Steve, that was the most interesting thing I read all day.  Yes,
my day was that slow.

-Sullo

-- 

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


From jericho at attrition.org  Mon Apr 10 23:23:47 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 10 Apr 2006 23:23:47 -0400 (EDT)
Subject: [VIM] r0t FAQ
In-Reply-To: <443B209F.3000704@cirt.net>
References: <200604110240.k3B2eCGs005139@cairo.mitre.org>
	<443B209F.3000704@cirt.net>
Message-ID: <Pine.LNX.4.64.0604102323150.10461@forced.attrition.org>


: > Here's an interesting read :)
: >
: > http://pridels.blogspot.com/2006/04/r0t-faq-edition-09-alfa.html
: 
: 4)Give me live example.
: 4. If you arent from Secunia,frsirt,osvdb or vendor i will not provide
: you with any live examples or HowTo?s.

It's interesting as he doesn't provide working SQL injection attacks, 
ever. Just XSS.

From jericho at attrition.org  Tue Apr 11 15:02:53 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 11 Apr 2006 15:02:53 -0400 (EDT)
Subject: [VIM] ZixForum vendor ack/fix
Message-ID: <Pine.LNX.4.64.0604111502320.10461@forced.attrition.org>



---------- Forwarded message ----------
From: John Andersson
To: moderators at osvdb.org
Date: Tue, 11 Apr 2006 15:33:41 +0200
Subject: [OSVDB Mods] [Change Request] 22096: ZixForum forum.asp H-ID Variable
     SQL Injection

Hi, its fixed now.

New homepage: www.zixforum.com

Thanx

Team Zix

From jericho at attrition.org  Tue Apr 11 18:30:57 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 11 Apr 2006 18:30:57 -0400 (EDT)
Subject: [VIM] Interesting Oracle FUBAR..
Message-ID: <Pine.LNX.4.64.0604111830310.10461@forced.attrition.org>



---------- Forwarded message ----------
From: "Kornbrust, Alexander" <ak at red-database-security.com>
To: full-disclosure at lists.grok.org.uk
Date: Mon, 10 Apr 2006 14:11:38 +0200
Subject: [Full-disclosure] Oracle read-only user can insert/update/delete data
     via specially crafted views

Hello Full Disclosure

Last Thursday 6th April 2006, Oracle released a note on the Oracle 
knowledgebase Metalink with details about an unfixed security 
vulnerability (=0day) and a working test case (=exploit code) which 
effects all versions of Oracle from 9.2.0.0 to 10.2.0.3. This note 
"363848.1 - A User with SELECT Object Privilege on Base Tables Can Delete 
Rows from a View" was available last week to Metalink customers. The note 
was also displayed in the daily headlines section of the Metalink.

That's why this information can be assumed as public knowledge and 
DBAs/Developers which missed the note on Metalink should know this 
vulnerability in order to avoid/mitigate the risk (if possible) whilst 
waiting for a patch from Oracle.

After noticing the note, I informed Oracle secalert that releasing such 
information on Metalink is not a wise idea. Oracle normally criticises 
individuals and/or companies for releasing information about Oracle 
vulnerabilities (like David Litchfield from NGSSoftware for releasing 
information an ever not fixed bug in mod_plsql gateway). In this case, not 
only Oracle released detailed information on the vulnerability; they also 
included the working exploit code on the Metalink.

In an interview few months ago, the Oracle CSO stated:  "I've known 
customers to terminate contracts ... for releasing exploit code... you 
might get applause from hackers... but business will not pay you to slit 
their throats. With knowledge comes responsibility."

After my email, Oracle removed the note from Metalink.

[..]

From coley at mitre.org  Tue Apr 11 19:18:27 2006
From: coley at mitre.org (Steven M. Christey)
Date: Tue, 11 Apr 2006 19:18:27 -0400 (EDT)
Subject: [VIM] MS06-015 addresses older issue
Message-ID: <200604112318.k3BNIRaW015244@cairo.mitre.org>


FYI, the FAQ section for MS06-015 says: "Note The update for this
vulnerability also addresses a publicly disclosed variation that has
been assigned Common Vulnerability and Exposure number CVE-2004-2289."
This stems from a Bugtraq post in May 2004.

- Steve

From mattmurphy at kc.rr.com  Tue Apr 11 20:04:59 2006
From: mattmurphy at kc.rr.com (Matthew Murphy)
Date: Tue, 11 Apr 2006 19:04:59 -0500
Subject: [VIM] MS06-015 addresses older issue
In-Reply-To: <200604112318.k3BNIRaW015244@cairo.mitre.org>
References: <200604112318.k3BNIRaW015244@cairo.mitre.org>
Message-ID: <443C442B.4040802@kc.rr.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Steven M. Christey wrote:
> FYI, the FAQ section for MS06-015 says: "Note The update for this
> vulnerability also addresses a publicly disclosed variation that has
> been assigned Common Vulnerability and Exposure number CVE-2004-2289."
> This stems from a Bugtraq post in May 2004.
> 
> - Steve
> 

Also interesting is this:

"This security update includes a Defense in Depth change which ensures
that prompting occurs consistently in Internet zone drag and drop
scenarios."

Sounds like a smooth-over of CVE-2005-3240.  My MSRC contact indicated
that they were treating this vulnerability as a Shell issue, so this
would not surprise me.

- --
"Social Darwinism: Try to make something idiot-proof,
nature will provide you with a better idiot."

                                -- Michael Holstein

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB5444D38

iD8DBQFEPEQrfp4vUrVETTgRA8koAJ4mK2UeiiYG+AaVBl6R15BCgehWfwCcDpNp
jxKePZqrB0GyWYVnVycKiE8=
=3cdM
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3436 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.attrition.org/pipermail/vim/attachments/20060411/633d5bb5/attachment.bin 

From coley at linus.mitre.org  Wed Apr 12 20:04:15 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 12 Apr 2006 20:04:15 -0400 (EDT)
Subject: [VIM] Multiple vulnerabilities in Blur6ex (fwd)
Message-ID: <Pine.GSO.4.51.0604122002400.5019@faron.mitre.org>


FYI.  I'll be notifying the developer of the issues.

---------- Forwarded message ----------
Date: Wed, 12 Apr 2006 20:02:18 -0400 (EDT)
From: Steven M. Christey <coley at mitre.org>
To: crasher at kecoak.or.id
Cc: bugtraq at securityfocus.com
Subject: Re: Multiple vulnerabilities in Blur6ex


The XSS issue in the shard parameter appears to be resultant from a
more serious file inclusion vulnerability.  This is the kind of
diagnosis error that I have mentioned in the past [1].

Notice that the error message shows that it took the "shard" parameter
and directly inserted it into a filename that it then tried to open.
In addition, the "/" is not being filtered - otherwise the </h1> would
not be there:

>Warning: main(): Failed opening 'engine/shards/<h1>just test your
>web</h1>.php'
>for inclusion
>(include_path='.:/usr/lib/php/:/usr/share/pear/') in
>/var/www/html/blur/index.php on line 108


Looking at the source for index.php in blur6ex 0.3.462, we have:

>        $shard = $_REQUEST["shard"];
>...
>    		include('engine/shards/' . $shard .'.php');
>...
>            include('engine/shards/' . $shard . '.php');


There is not any apparent cleansing of the $shard variable (based on
grep test).

So, this looks like a directory traversal issue in a PHP include
statement, so arbitrary PHP files might be included and executed using
"../" sequences.  And without any apparent cleansing, it seems likely
that null character injection could be used to access files of any
extension.

NOTE - the errormsg parameter appears to be primary XSS.  From
engine/shards/login.php:

>    case "g_error":
>    $errormsg = $_REQUEST['errormsg'];
>...
>    	$thisContentObj->primaryContent = "Error: " . $errormsg;


This is all based on source code inspection only - I have not
installed and tested the product.

- Steve


References:

[1] Mis-diagnosed XSS bugs hiding worse issues due to PHP feature
    Bugtraq, April 1, 2006
    http://marc.theaimsgroup.com/?l=bugtraq&m=114392753509966&w=2

From coley at linus.mitre.org  Thu Apr 13 13:34:50 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 13 Apr 2006 13:34:50 -0400 (EDT)
Subject: [VIM] Security Vulnerabilities reported in blur6ex (fwd)
Message-ID: <Pine.GSO.4.51.0604131334150.7048@faron.mitre.org>



---------- Forwarded message ----------
Date: Thu, 13 Apr 2006 10:45:44 -0400
From: brian
To: Steven M. Christey <coley at mitre.org>
Subject: Re: Security Vulnerabilities reported in blur6ex

Steven,

Thank you for alerting us about these issues.  We're working on a fix
right now.

Thanks,

Brian
www.blursoft.com

Steven M. Christey wrote:
> Hello,
>
> I am a computer security professional and the editor for the Common
> Vulnerabilities and Exposures (CVE) project.  CVE is a list of
> software vulnerabilities, and it is widely used in the computer
> security industry.  It is sponsored by the US Department of Homeland
> Security.  (http://www.us-cert.gov/cve/, http://cve.mitre.org/)
>
> Recently, some vulnerabilities in your product were reported to public
> sources.  References include:
>
>  http://www.securityfocus.com/archive/1/archive/1/430607/100/0/threaded
>  http://www.securityfocus.com/bid/17465
>
> I downloaded the product and checked for these issues.  The reports
> look legitimate.
>
> The problem with the "shard" variable looks very serious.  It looks
> like an attacker could use "../" sequences to access any file on the
> system, and use a null character so that extensions other than .php
> can be accessed.  This could then be used to execute arbitrary code.
>
> Can you confirm the existence of these issues?  Will a fix be made
> available?
>
>
> Thank you,
> Steve Christey
> Principal Information Security Engineer
> CVE Editor
> The MITRE Corporation
>
>

From jericho at attrition.org  Fri Apr 14 05:19:47 2006
From: jericho at attrition.org (security curmudgeon)
Date: Fri, 14 Apr 2006 05:19:47 -0400 (EDT)
Subject: [VIM] Helm Control Panel followup
In-Reply-To: <Pine.GSO.4.51.0603280236260.2265@faron.mitre.org>
References: <Pine.LNX.4.64.0603271122180.5422@forced.attrition.org>
	<Pine.GSO.4.51.0603280236260.2265@faron.mitre.org>
Message-ID: <Pine.LNX.4.64.0604140516390.10461@forced.attrition.org>


: > http://www.webhostautomation.com/webhost-301
: 
: CVE missed it the first time around, and it looks like some other vdbs
: have, but the entry for 3.2.9 has fairly clear acknowledgement of
: CVE-2006-0211:
: 
:   3.2.9
:   -------
:   ...
:   Fixed XSS issue in password reminder page

been on my to-do list, I dug up the following from the Helm changelog a 
while back but just now got around to adding entries. I didn't make an 
entry for the 3.1.9 'overflow error with account limits' because something 
just doesn't sound right about it. sounds like *maybe* a crash at best, 
but its just a hunch on the limited wording. i also couldn't dig up dates 
for the 3.1.14 (or prior) stuff, only figuring out they are all from 
before Mar 2004. Also note, the "default page xss" from below is different 
than the 2006-03-27 one (OSVDB 24126).

--

http://www.webhostautomation.com/webhost-301
3.2.6   (2005-08-30)
Fixed XSS entry in default page


http://www.webhostautomation.com/webhost-393

3.1.14
Fixed security issue: Reseller plan and package access

3.1.9
Fixed overflow error with account limits

3.1.2
Fixed FTP issue where users were able to take over

3.1
Fixed integer overflow error in statistics

From jericho at attrition.org  Fri Apr 14 05:29:00 2006
From: jericho at attrition.org (security curmudgeon)
Date: Fri, 14 Apr 2006 05:29:00 -0400 (EDT)
Subject: [VIM] "PHP Script Index" a site-specific issue?
In-Reply-To: <200603310741.k2V7fWLD013528@cairo.mitre.org>
References: <200603310741.k2V7fWLD013528@cairo.mitre.org>
Message-ID: <Pine.LNX.4.64.0604140526250.10461@forced.attrition.org>


: Refs: BID:17297, FRSIRT:ADV-2006-1158, SECUNIA:19443
: 
: None of these refs had the original raw report, but OSVDB:24243 did:
: 
:   http://osvdb.org/ref/24/24243-script_index.txt
: 
: from this raw report, Preddy discusses "PHP Script Index", but I can't 
: find any information on a product by this name.  Preddy's demonstration 
: URL is site-specific - to a web site that just happens to be an index of 
: many PHP scripts.  Searching for "PHP Script Index" on this phpmaniacs 
: web site finds nothing.  Searching for "<abc>" yields a message 
: containing an unquoted <abc>.

Despite having the original disclosure, I spent extra time digging on this 
one for the same reason you did. Checking the vendor URL provided at the 
time didn't sit right with me.

However, by the end of my limited searching, all I came up with was a 
hunch it may be site specific, but nothing conclusive to prove one way or 
another. With a lack of details, I added it to OSVDB until more details 
could be dug up. It's rare that things are this murky but in the few cases 
it happens, the OSVDB unwritten policy is to include to be safe.

From jericho at attrition.org  Fri Apr 14 05:53:52 2006
From: jericho at attrition.org (security curmudgeon)
Date: Fri, 14 Apr 2006 05:53:52 -0400 (EDT)
Subject: [VIM] FleXiBle Development Script Remote Command Exucetion And
 XSS Attacking
In-Reply-To: <200604040459.k344xUvj027165@cairo.mitre.org>
References: <200604040459.k344xUvj027165@cairo.mitre.org>
Message-ID: <Pine.LNX.4.64.0604140550200.10461@forced.attrition.org>


: >FleXiBle Development (FXB)
: 
: Is this a web site, product, or service?  A Google search yields very
: little information, except for the original Bugtraq post.  I cannot
: find any information on this.
: 
: >Web: http://www.ahbruinsma.nl
: 
: As of April 3, you cannot read the front page.  The web site requires
: authentication.

http://web.archive.org/web/20040929211941/http://www.ahbruinsma.nl/

This shows some content, but also makes calls back to the original site 
asking for auth =) So escape past auth requests and you start to see the 
original page it looks like. Nothing on this page looks to be downloadable 
software which is our criteria for a VDB entry.

http://web.archive.org/web/20040613035139/http://www.ahbruinsma.nl/

Tons more auth requests, no more help.

http://web.archive.org/web/20031223232848/http://www.ahbruinsma.nl/

Not in Archive.

The page you requested has not been archived.

http://web.archive.org/web/20031021045653/http://www.ahbruinsma.nl/

Not in Archive.

The page you requested has not been archived. 

--

Those are the only 4 entries in archive.org, none of which give an obvious 
link, but I honestly didn't dig much. This is already adding up to way too 
circumstancial to spend more time on.


From coley at mitre.org  Fri Apr 14 16:33:09 2006
From: coley at mitre.org (Steven M. Christey)
Date: Fri, 14 Apr 2006 16:33:09 -0400 (EDT)
Subject: [VIM] Vendor dispute of Lighthouse CMS XSS (CVE-2005-4780)
Message-ID: <200604142033.k3EKX9Pg011131@cairo.mitre.org>


Issue reported by r0t.

I concur with the vendor.  Interestingly, the vendor says how OSVDB
also reported this issue, but it doesn't seem like they contacted
OSVDB...

- Steve

======================================================
Name: CVE-2005-4780
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4780
Acknowledged: no disputed
Announced: 20051218
Flaw: XSS
Reference: MISC:http://pridels.blogspot.com/2005/12/lighthouse-cms-xss-vuln.html
Reference: MISC:http://www.lighthouse-cms.de/en/news/
Reference: BID:15952
Reference: URL:http://www.securityfocus.com/bid/15952
Reference: OSVDB:21852
Reference: URL:http://www.osvdb.org/21852
Reference: XF:lighthousecms-search-xss(23668)
Reference: URL:http://xforce.iss.net/xforce/xfdb/23668

** DISPUTED **

Cross-site scripting (XSS) vulnerability in Fidra Lighthouse CMS 1.1.0
and earlier allows remote attackers to inject arbitrary web script or
HTML via the search parameter in a query_string to the home page.
NOTE: The vendor disputes this issue, saying "Lighthouse does not in
any way make use of the PHP technology.  [It] is an application server
... A technology like this cannot be susceptible to client-side
cross-site-scripting-attacks on its own, but only applications created
based on such a technology. This does not only apply to Lighthouse,
but also to Perl, PHP or web applications based on Java Servlet
technology."  Since the original researcher is known to test demo
pages and is sometimes inaccurate, it is likely that this issue will
be REJECTED.


Analysis:

ACKNOWLEDGEMENT: Disputed.  The vendor has made a dispute, asserting
that the vulnerability does not exist. The vendor News page refers to
the lighthouse-cms-xss-vuln advisory and says "it is being claimed
that Lighthouse is supposedly susceptible to client-side
cross-site-scripting-attacks ... The Lighthouse Content Management
System is not, and never has been, susceptible to attacks like this
and does not exhibit any known security issues in this or any other
way."

ACCURACY: The researcher is well-known to test demo pages.  This error
might have arisen from a demo test; however, this cannot be confirmed.



From coley at linus.mitre.org  Fri Apr 14 18:04:41 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Fri, 14 Apr 2006 18:04:41 -0400 (EDT)
Subject: [VIM] QuickBlogger v1.4 Cross-Site Scripting (fwd)
Message-ID: <Pine.GSO.4.51.0604141802340.4885@faron.mitre.org>


Another botan issue, but this time he gave enough info to investigate
further :)

---------- Forwarded message ----------
Date: Fri, 14 Apr 2006 18:01:21 -0400 (EDT)
From: Steven M. Christey <coley at mitre.org>
To: bugtraq at securityfocus.com
Subject: Re: QuickBlogger v1.4 Cross-Site Scripting


This is yet another case where XSS is resultant from a more serious
issue.  The primary issue here involves local file inclusion.
retrogod-style attacks might be feasible by injecting PHP code into
text-based data files within the application, then including those
text files using this issue; however, I did not explore it that
deeply.

Based on a download of the 1.4 source from another location, we have
the following code from acc.php:

   if ($_GET['request'] == "") {
   $page = "actions/main.php";
   }
   else {
   $page = "actions/" . $_GET['request'] . ".php";
   }
   include $page;

I can use ".." sequences to include arbitrary PHP files, and null
character injection for arbitrary files of other types:

   acc.php?request=../../../abcdef.txt%00

So - what happens when I use the original XSS manipulation provided by
botan?

  acc.php?request=<script>alert(document.cookie)</script>

If my PHP errors are set up properly, and if I've got a version of PHP
that allows XSS in error messages, I get:

  Warning: main(): Failed opening
  'actions/<script>alert(document.cookie)</script>.php' for inclusion
  (include_path='[PATH HERE]') in acc.php on line 220

This was tested on QuickBlogger 1.4 under PHP 4.

- Steve

From coley at mitre.org  Fri Apr 14 23:31:10 2006
From: coley at mitre.org (Steven M. Christey)
Date: Fri, 14 Apr 2006 23:31:10 -0400 (EDT)
Subject: [VIM] Provable vendor ACK for gcards issues
Message-ID: <200604150331.k3F3VAep016373@cairo.mitre.org>


hey OSVDB - look what happens when I accidentally click on one of your
generic vendor URLs :)

Another rgod production - CVE-2006-1348, CVE-2006-1347, CVE-2006-1346

http://www.gregphoto.net/gcards/index.php

The note for Version 1.46 says "Fixed several critical security
issues."

This is not sufficient proof for CVE purposes, so let's do a diff
between 1.46 and 1.31 (note - < and > may be switched).

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

CVE-2006-1347 - SQL injection - admin/loginfunction.php

37,39c37
<               $pass = md5($userpass);
<               $uname = checkAddSlashes($username);
<               $sqlstmt = "SELECT role FROM ".$tablePrefix."cardusers
WHERE username='$uname' AND userpass='$pass'";
---
>               $sqlstmt = "SELECT role FROM ".$tablePrefix."cardusers
>               WHERE username='$username' AND
>               userpass=password('$userpass')";


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

CVE-2006-1346 - Directory traversal... love the attitude - "NO!"

diff `find . -name setLang.php`

2,6c2,4
<       if(isset($_REQUEST['lang'])) exit("NO!");
<       if ($page->languageredirect == $_SERVER['PHP_SELF']) {
<               if (isset($_GET['setLang']) &&
array_key_exists($_GET['setLang'],$lang)) {
<                       $_SESSION['setLang'] = $_GET['setLang'];
<               }
---
>       if ($page->languageredirect == $_SERVER['PHP_SELF'])
>       {
>               if (isset($_GET['setLang'])) $_SESSION['setLang'] =
>       $_GET['setLang'];
8,16c6,7
<
<       $langFile =
>       $page->relpath.'inc/lang/'.$lang[$_SESSION['setLang']]['file'];
<
<       if (file_exists($langFile)) {
<               include_once($langFile);
<       } else {
<               echo "Could not find language file $langFile";
<       }
< ?>
\ No newline at end of file

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

XSS - ummmmmmm


The fix was not immediately identifiable based on source code
inspection.  A closer look suggests that it might be resultant XSS
from the directory traversal issue, but this is not certain.

- Steve

From coley at mitre.org  Sat Apr 15 01:40:40 2006
From: coley at mitre.org (Steven M. Christey)
Date: Sat, 15 Apr 2006 01:40:40 -0400 (EDT)
Subject: [VIM] Rehash: Vendor ACK for NeuSecure/Netcool issues
Message-ID: <200604150540.k3F5eeuD017364@cairo.mitre.org>


Just noticed that some vdb's didn't notice when I reported the vendor
ack for various neusecure/netcool - assuming those vdb's have a policy
of trusting me when I claim the vendor ack'ed :)


[VIM] Vendor ACK for NeuSecure/Netcool issues
http://attrition.org/pipermail/vim/2006-March/000604.html


- Steve

From coley at mitre.org  Sat Apr 15 13:55:54 2006
From: coley at mitre.org (Steven M. Christey)
Date: Sat, 15 Apr 2006 13:55:54 -0400 (EDT)
Subject: [VIM] Vendor ACK for aoblogger 2.3 issues
Message-ID: <200604151755.k3FHts1a023051@cairo.mitre.org>


(hey osvdb - another victory for generic URLs!)

Researcher: alex at evuln

Issues: CVE-2006-0310, CVE-2006-0311, CVE-2006-0312

Forum post:

  http://mikeheltonisawesome.com/viewcomments.php?idd=46

  Date: Feb 27th 2006 | Subject: Security Fixes!

  I googled aoblogger, and managed to find several websites with info on
  three major security holes, all of which have been fixed in the newest
  version available for download on sourceforge or hotscripts.


In the download, the vendor changelog says:

  Changes in 2.4
  __________________

  Fixed three major security holes. Source is fully secure as of this
  release
  1) XSS attack in create.php
  2) sql injection in BB Code and in login.php


CAVEAT:

These descriptions are slightly inconsistent with CVE's descriptions,
so I took a casual look at the source code, which makes it unclear
whether the issues were properly fixed.  Hard to tell on the surface.

- Steve

From jericho at attrition.org  Mon Apr 17 18:54:01 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 17 Apr 2006 18:54:01 -0400 (EDT)
Subject: [VIM] missing MFSA?
Message-ID: <Pine.LNX.4.64.0604171852390.10461@forced.attrition.org>


>From http://secunia.com/advisories/19631/:

[..]
http://www.mozilla.org/security/announce/2006/mfsa2006-19.html
http://www.mozilla.org/security/announce/2006/mfsa2006-20.html
http://www.mozilla.org/security/announce/2006/mfsa2006-22.html
http://www.mozilla.org/security/announce/2006/mfsa2006-23.html
http://www.mozilla.org/security/announce/2006/mfsa2006-24.html
http://www.mozilla.org/security/announce/2006/mfsa2006-25.html
http://www.mozilla.org/security/announce/2006/mfsa2006-28.html
http://www.mozilla.org/security/announce/2006/mfsa2006-29.html


21 and 27 are giving a 404 error message. 26 is there, but on this list.

From coley at mitre.org  Mon Apr 17 21:13:01 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 17 Apr 2006 21:13:01 -0400 (EDT)
Subject: [VIM] Lifetype "XSS" issue might be file inclusion?
Message-ID: <200604180113.k3I1D1OK016383@cairo.mitre.org>


OK, so these days I'm probably seeing these issues even when they
don't exist :)

Refs: CVE-2006-1808 and CVE-2006-1809

Lifetype has source available, but a grep-style check didn't find
proof right away.

- op paramater is "Template" which suggests use of templates, which
  are frequently files...

- attacker uses XSS manipulation in a Template op

- and even with the XSS manipulation, you get full path disclosure


So - this could be an application-controlled XSS/full path disclosure
("hey, I couldn't find the template using this filename: [XYZ]") or
maybe it's a PHP-level inclusion/path traversal error by actually
trying to access the file and failing.

Either way I dunno, just figured someone out there with more a
extensive PHP testing environment might be curious to investigate.

- Steve

======================================================
Name: CVE-2006-1808
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1808
Reference: BUGTRAQ:20060414 Vulnerabilities in lifetype
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/431008/100/0/threaded
Reference: FRSIRT:ADV-2006-1367
Reference: URL:http://www.frsirt.com/english/advisories/2006/1367
Reference: SECTRACK:1015941
Reference: URL:http://securitytracker.com/id?1015941
Reference: SECUNIA:19646
Reference: URL:http://secunia.com/advisories/19646

Cross-site scripting (XSS) vulnerability in index.php in Lifetype
1.0.3 allows remote attackers to inject arbitrary web script or HTML
via the show parameter in a Template operation.


======================================================
Name: CVE-2006-1809
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1809
Reference: BUGTRAQ:20060414 Vulnerabilities in lifetype
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/431008/100/0/threaded
Reference: SECTRACK:1015941
Reference: URL:http://securitytracker.com/id?1015941

index.php in Lifetype 1.0.3 allows remote attackers to obtain
sensitive information via an invalid show parameter, which reveals the
path in an error message.



From theall at tenablesecurity.com  Mon Apr 17 22:31:07 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Mon, 17 Apr 2006 22:31:07 -0400
Subject: [VIM] Lifetype "XSS" issue might be file inclusion?
In-Reply-To: <200604180113.k3I1D1OK016383@cairo.mitre.org>
References: <200604180113.k3I1D1OK016383@cairo.mitre.org>
Message-ID: <44444F6B.10606@tenablesecurity.com>

> Lifetype has source available, but a grep-style check didn't find
> proof right away.
> 
> - op paramater is "Template" which suggests use of templates, which
>   are frequently files...
> 
> - attacker uses XSS manipulation in a Template op
> 
> - and even with the XSS manipulation, you get full path disclosure
> 
> 
> So - this could be an application-controlled XSS/full path disclosure
> ("hey, I couldn't find the template using this filename: [XYZ]") or
> maybe it's a PHP-level inclusion/path traversal error by actually
> trying to access the file and failing.

Here's what I see (minus HTML formatting) when I run an exploit against 
1.0.3:

                              ----  snip, snip, snip ----
Exception message: Smarty error: unable to read resource: 
"standard/[XSS_here].template"
Error code: 512
-- Backtrace --
/var/www/localhost/htdocs/lifetype/class/template/smarty/Smarty.class.php(1108): 
trigger_error
/var/www/localhost/htdocs/lifetype/class/template/smarty/Smarty.class.php(1604): 
cachedtemplate.trigger_error
/var/www/localhost/htdocs/lifetype/class/template/smarty/Smarty.class.php(1433): 
cachedtemplate._fetch_resource_info
/var/www/localhost/htdocs/lifetype/class/template/smarty/Smarty.class.php(1279): 
cachedtemplate._compile_resource
/var/www/localhost/htdocs/lifetype/class/template/cachedtemplate.class.php(48): 
smarty.fetch
/var/www/localhost/htdocs/lifetype/class/view/smartyview.class.php(207): 
cachedtemplate.fetch
/var/www/localhost/htdocs/lifetype/class/view/blogview.class.php(224): 
smartyview.render
/var/www/localhost/htdocs/lifetype/class/controller/controller.class.php(329): 
templateview.render
/var/www/localhost/htdocs/lifetype/index.php(42): blogcontroller.process
                              ----  snip, snip, snip ----

A comment in class/template/smarty/Smarty.class.php suggests it's 
slightly modified version.

I tried passing in a couple of directory traversal sequences, but Smarty 
seems to cache files locally and uses its own name so directory 
traversal sequences are ignored.

George
--
theall at tenablesecurity.com

From jericho at attrition.org  Mon Apr 17 23:50:45 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 17 Apr 2006 23:50:45 -0400 (EDT)
Subject: [VIM] Vendor dispute of Lighthouse CMS XSS (CVE-2005-4780)
In-Reply-To: <200604142033.k3EKX9Pg011131@cairo.mitre.org>
References: <200604142033.k3EKX9Pg011131@cairo.mitre.org>
Message-ID: <Pine.LNX.4.64.0604172350160.10461@forced.attrition.org>


: I concur with the vendor.  Interestingly, the vendor says how OSVDB also 
: reported this issue, but it doesn't seem like they contacted OSVDB...

They did not contact us as far as I can see from my mail archives.


From jericho at attrition.org  Mon Apr 17 23:53:33 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 17 Apr 2006 23:53:33 -0400 (EDT)
Subject: [VIM] Vendor dispute of Lighthouse CMS XSS (CVE-2005-4780)
In-Reply-To: <200604142033.k3EKX9Pg011131@cairo.mitre.org>
References: <200604142033.k3EKX9Pg011131@cairo.mitre.org>
Message-ID: <Pine.LNX.4.64.0604172352590.10461@forced.attrition.org>


: I concur with the vendor.  Interestingly, the vendor says how OSVDB also 
: reported this issue, but it doesn't seem like they contacted OSVDB...

: Name: CVE-2005-4780
: URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4780

: Reference: MISC:http://www.lighthouse-cms.de/en/news/

Hah, this is amusing. Copying here for archiving =)

--

Alleged Security Issue in Lighthouse
On February 10, 2006 it has been brought to our attention that the web 
page pridels.blogspot.com claims to have found a security issue regarding 
Lighthouse on December 18, 2005. Under 
http://pridels.blogspot.com/2005/12/lighthouse-cms-xss-vuln.html it is 
being claimed that Lighthouse is supposedly susceptible to client-side 
cross-site-scripting-attacks.

We wish to inform you that this notification is false: The allegation is 
lacking any basis. The Lighthouse Content Management System is not, and 
never has been, susceptible to attacks like this and does not exhibit any 
known security issues in this or any other way. In our opinion, security 
warnings concerning software products have to be taken very seriously; 
this, however, requires that security warnings are verified diligently 
before being made public.

We regret how carelessly this has been handled by pridels.blogspot.com and 
wish to point out the following:

    * We have not, neither before nor after the publication mentioned 
above, been informed of this alleged security issue.
    * Other web pages, e.g. 
http://www.osvdb.org/displayvuln.php?osvdb_id=21852, have copied the false 
statement without further verification and describe the alleged issue like 
this: "This flaw exists because the application does not validate the 
'search' variable upon submission to the 'index.php' script." This 
statement is absurd, because Lighthouse does not in any way make use of 
the PHP technology.
    * The Lighthouse Content Management System is an application server, 
providing the user with powerful functionality to create, program and 
manage web-based applications. A technology like this cannot be 
susceptible to client-side cross-site-scripting-attacks on its own, but 
only applications created based on such a technology. This does not only 
apply to Lighthouse, but also to Perl, PHP or web applications based on 
Java Servlet technology.


From sullo at cirt.net  Wed Apr 19 12:58:11 2006
From: sullo at cirt.net (Sullo)
Date: Wed, 19 Apr 2006 12:58:11 -0400
Subject: [VIM] CVE-2006-1780
Message-ID: <20060419125811.azzu2l15hhwokckc@www.cirt.net>

I know this is a long-shot, but does anyone have any information as to how this
is exploited?  All the statements are pretty vague about whether this allows a
single user to DoS other users, or if it's just their own processes...

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1780
http://sunsolve.sun.com/search/document.do?assetkey=1-26-102282-1
http://osvdb.org/24553
  The Bourne shell (sh) in Solaris 8, 9, and 10 allows local users to cause a
denial of service (sh crash) via an unspecified attack vector that causes sh
processes to crash during creation of temporary files.




-- 

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

From coley at mitre.org  Thu Apr 20 02:07:38 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 20 Apr 2006 02:07:38 -0400 (EDT)
Subject: [VIM] Is betaboard vuln site-specific?
Message-ID: <200604200607.k3K67cxK015309@cairo.mitre.org>


Ref:

  BUGTRAQ:20060416 BetaBoard Cross Site Scripting vulnerability
  URL:http://www.securityfocus.com/archive/1/archive/1/431116/100/0/threaded
  
I couldn't find any information on betaboard after a few minutes of
looking on the (German language) web site, but this is in various DBs.
Is this a site-specific vuln or is there a distributable product
somewhere?

- Steve

From coley at mitre.org  Thu Apr 20 02:11:07 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 20 Apr 2006 02:11:07 -0400 (EDT)
Subject: [VIM] Is betaboard vuln site-specific?
Message-ID: <200604200611.k3K6B7x4015336@cairo.mitre.org>


*sigh* don't all jump in now, Google showed me the way to the truth :)
One need merely look hard enough to find all the answers (and
questions) that one desires...

- Steve

From coley at mitre.org  Thu Apr 20 12:10:19 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 20 Apr 2006 12:10:19 -0400 (EDT)
Subject: [VIM] LinPHA provenance/acknowledgement
Message-ID: <200604201610.k3KGAJQG020799@cairo.mitre.org>


A ChangeLog URL for LinPHA 1.1.1 seems to be hanging, so I downloaded
the entier 1.1.1 package  and found this stuff in the ChangeLog:

2006-04-10  Tadashi Jokagi <elf2000 AT users DOT sourceforge DOT net>
 * DOCS/INSTALL.html updated.
 * security reason, escape(htmlspecialchars, urlencode) is added to
some charact
er strings.
 * ftp/index.php: fixed string containing '%' cannot be processed
correctly.
 * RSS/RSS.php: fixed multiple XSSs.
 * functions/db_api.php: fixed SQL injection.
 * update Japanese translation.



- Steve

From coley at mitre.org  Thu Apr 20 12:36:08 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 20 Apr 2006 12:36:08 -0400 (EDT)
Subject: [VIM] CuteNews 1.4.1 <= Cross Site Scripting
Message-ID: <200604201636.k3KGa8Nw021011@cairo.mitre.org>


>Exploit:
>http://www.example.com/index.php?mod=editnews&action=editnews&id=1145397112&source=[XSS]


This XSS is likely resultant from a more serious issue in which the
$source variable is not being validated, so it is subject to attacks
such as directory traversal.  Given the program's assumption of the
file format, it is possible that only portions of certain files could
be read.  The "doeditnews" action does overwrite this same file, so it
could also be used at least for file corruption.  However, this is all
based on source analysis; I did not test this.


from inc/editnews.mdu in CuteNews 1.4.1:

  elseif($action == "editnews")
  {
  // Show The Article for Editing
      if($source == ""){ $all_db = file("./data/news.txt"); }
      elseif($source == "postponed"){ $all_db = file("./data/postponed_news.txt"); }
      elseif($source == "unapproved"){ $all_db = file("./data/unapproved_news.txt"); }
      else{ $all_db = file("./data/archives/$source.news.arch"); }
          $found = FALSE;
          foreach ($all_db as $line)
      {
                $item_db=explode("|",$line);
                if ($id == $item_db[0]){ $found = TRUE; break;}
        }//foreach news line

and later:

  elseif($action == "doeditnews")
  {
  [SNIP]
    else{ $news_file = "./data/archives/$source.news.arch"; $com_file = "./data/archives/$source.comments.arch";}

        $old_db = file("$news_file");
        $new_db = fopen("$news_file", w);


- Steve

From smoore at securityglobal.net  Thu Apr 20 13:09:33 2006
From: smoore at securityglobal.net (Stuart Moore)
Date: Thu, 20 Apr 2006 13:09:33 -0400
Subject: [VIM] CVE-2006-0527 SecurityTracker duplicates
Message-ID: <4447C04D.4090507@securityglobal.net>

Re: CVE-2006-0527

For some reason, we issued duplicate SecurityTracker alerts for the same 
vulnerability (Tru64 DNS BIND, HP advisory HPSBTU02095), as picked up in 
the CVE references and OSVDB (22888) references.  Sorry about that!

The first alert was 1015551 and the second was 1015606.  The first 
(1015551) will be retained, with some modifications, and the second will 
eventually be deleted.

Stuart



From coley at mitre.org  Fri Apr 21 02:51:21 2006
From: coley at mitre.org (Steven M. Christey)
Date: Fri, 21 Apr 2006 02:51:21 -0400 (EDT)
Subject: [VIM] Wingnut EasyGallery XSS smells like more
Message-ID: <200604210651.k3L6pLeI028006@cairo.mitre.org>


Ref: CVE-2006-1972

EasyGallery is apparently by some developer named wingnut.  Source for
version 2 is available at wingnut.net.ms and maybe elsewhere.

I do not have sufficient proof, and have already recently posted a
correction to a botan post... but here's an extract from
EasyGallery.php that make me think it's more than XSS.  (Note - there
might be other vectors involving $ordner, besides the reported one.)


  if (!isset($all)&&!isset($thumbnails)&&!isset($tplus)&&!isset($tminus)&&!isset($tminus_x)&&!isset($tplus_x))
  {
    // --begin comments
    extract($_POST);
    $comment = $ordner."/comments.txt";
    if(file_exists($comment))
    {    
    ...
	      $file = file($comment);
	      $whandle = fopen($comment,"w+");
    ...
		    $msg = stripslashes($msg);
		    fputs($whandle, "$temp|$author|$msg \n");



======================================================
Name: CVE-2006-1972
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1972
Reference: BUGTRAQ:20060419 EasyGallery Cross-Site Scripting
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/431430/100/0/threaded
Reference: MISC:http://advisory.patriotichackers.com/index.php?itemid=5

Cross-site scripting (XSS) vulnerability in EasyGallery.php in Wingnut
EasyGallery allows remote attackers to inject arbitrary web script or
HTML via the ordner parameter.



From jericho at attrition.org  Sun Apr 23 06:07:55 2006
From: jericho at attrition.org (security curmudgeon)
Date: Sun, 23 Apr 2006 06:07:55 -0400 (EDT)
Subject: [VIM] rwAuction Pro vendor ack/fix
Message-ID: <Pine.LNX.4.64.0604230607150.23687@forced.attrition.org>



---------- Forwarded message ----------
From: Steve / RainWorx
To: security curmudgeon <jericho at attrition.org>
Date: Thu, 20 Apr 2006 11:09:25 -0400
Subject: RE: [OSVDB Mods] [Change Request] 21475: rwAuction Pro search.asp
     searchtxt Variable XSS

It's an ASP change so there isn't any build associated with it... The
release package is updated and we are making the updated files available
to our customers.

Steve Gorman
RainWorx Software
www.rainworx.com


-----Original Message-----
From: security curmudgeon [mailto:jericho at attrition.org]
Sent: Wednesday, April 19, 2006 5:32 PM
To: Steve / RainWorx
Cc: moderators at osvdb.org
Subject: Re: [OSVDB Mods] [Change Request] 21475: rwAuction Pro
search.asp searchtxt Variable XSS


Hi Steve,

: We have fixed this issue in our latest build.  Please let me know how we
: can update your database with this information.

Is there a version associated with the latest build? ie: Is this
available as a patch, upgrade or something else?

Brian
OSVDB.org

From jericho at attrition.org  Sun Apr 23 06:13:42 2006
From: jericho at attrition.org (security curmudgeon)
Date: Sun, 23 Apr 2006 06:13:42 -0400 (EDT)
Subject: [VIM] LinPHA provenance/acknowledgement
In-Reply-To: <200604201610.k3KGAJQG020799@cairo.mitre.org>
References: <200604201610.k3KGAJQG020799@cairo.mitre.org>
Message-ID: <Pine.LNX.4.64.0604230612500.23687@forced.attrition.org>


: A ChangeLog URL for LinPHA 1.1.1 seems to be hanging, so I downloaded 
: the entier 1.1.1 package and found this stuff in the ChangeLog:

Good stuff. I sat on this all weekend before making entries on OSVDB. 
Each and every time I tried to access the online CVS repository, it would 
time out. Pretty discouraging.

From coley at mitre.org  Mon Apr 24 20:04:33 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 24 Apr 2006 20:04:33 -0400 (EDT)
Subject: [VIM] CVE-2006-1525 only affects Linux kernel 2.6.x
Message-ID: <200604250004.k3P04XtL009358@cairo.mitre.org>


Marcus Meissner of SUSE e-mailed me on Friday to say that he
investigated CVE-2006-1525 more, and it only affects 2.6 kernels.

- Steve

From coley at mitre.org  Tue Apr 25 01:10:45 2006
From: coley at mitre.org (Steven M. Christey)
Date: Tue, 25 Apr 2006 01:10:45 -0400 (EDT)
Subject: [VIM] Interesting Scry stuff
Message-ID: <200604250510.k3P5Ajjs011739@cairo.mitre.org>


Issues:

 various issues in Scry 1.1, index.php p parameter

Note - the package hasn't been updated since 2004.

Refs:

  BUGTRAQ:20060421 Scry Gallery Directory Traversal & Full Path
  Disclosure Vulnerabilites
  http://www.securityfocus.com/archive/1/archive/1/431716/100/0/threaded

  BUGTRAQ:20060424 Scry Gallery XSS Vulnerability
  http://www.securityfocus.com/archive/1/archive/1/431853/100/0/threaded


With the index.php/p vector, the above 2 disclosures covered these bug
types:

 - directory traversal
 - path disclosure
 - XSS

Since I'm on my XSS-hides-other-bugs kick, I grabbed the source code
to take a look.

First, I noticed that the XSS is not exclusively resultant from a
failed directory traversal, thanks to verbose unfiltered error
messages:

  if ($VIEW == 'list') {
    $IMAGE_DIR = $_GET['p'];
  } else {
  ...
  ...
  $PATH         = "$CFG_path_images/$IMAGE_DIR/$IMAGE_FILE";
  $PATH_BASEDIR = "$CFG_path_images/$IMAGE_DIR";
  ...
  if (!is_readable($PATH)) { // FS READ
  die("$PATH does not exist or is not readable by the webserver - please verify settings in setup.php");

So we have application-controlled XSS, which is good enough in CVE's
book for a separate item.

But, before we got to the XSS above, we skipped over the following
code:

  path_security_check($PATH, $CFG_path_images);

That sounds interesting enough, especially since the developer's front
page says that the code was designed with security in mind.

I can see how the XSS got through, if it's just checking for paths
under an expected web root.  But what about the directory traversal?

  // function path_security_check(string $victim, string $test)
  //
  // the resolved path of $victim must be below $test on the filesystem
  //
  function path_security_check($victim, $test) {
    
    if (eregi("^" . rtrim('/', $test) . ".*", rtrim('/', realpath($victim)))) {
      return true;
    } 
  
    die("path security check failed: $victim - $test");
  } // function path_security_check

Well, we see here with the "die" command another vector for
application-controlled XSS.

But that eregi() call seems to be looking for "/" characters and,
presumably, would barf if certain substrings don't match.

It's even using realpath(), which you'd like to see for directory
traversal tests.

Looking up rtrim() in the PHP online manual, we see that it's intended
to strip all whitespace at the end of the string.  An optional
argument allows you to specify any bag of characters to strip.  So,
this code is apparently trying to strip a "/" from the end of the
string.

Except the attacker probably could provide pathname arguments that
don't end in a string.

And - much more relevant to this situation - the PHP manual says that
the characters to trim are specified in the *second* argument, not the
first - like we see in the code above.

So, because of the switched arguments, the rtrim('/', $test)
expression would likely return "", which means we get a regexp of:

  ^.*

which sounds very likely indeed to match whatever comes back from the
realpath argument, thus most any inputs would pass the sanity check.

... except, for some reason, when you go to the developer's web site
and click on the "1.1 demo album link", you get a verbose error
message that generates a failed path_security_check - but prints out
$victim and $test variables that appear to be equal!


- Steve

From coley at mitre.org  Tue Apr 25 01:25:17 2006
From: coley at mitre.org (Steven M. Christey)
Date: Tue, 25 Apr 2006 01:25:17 -0400 (EDT)
Subject: [VIM] bloggage != RIblog
Message-ID: <200604250525.k3P5PHka011885@cairo.mitre.org>


Due to cut-and-paste errors, "Omnipresent" apparently released two
advisories that mentioned bloggage.  These are not the same products,
however...

http://colander.altervista.org/advisory/riblog.txt
http://colander.altervista.org/advisory/bloggage.txt

The source code referenced in the RIblog advisory appears to come from
./blog/admin/default.asp based on the source version as of early Apr
25.

- Steve

From coley at linus.mitre.org  Tue Apr 25 02:58:30 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 25 Apr 2006 02:58:30 -0400 (EDT)
Subject: [VIM] Security Vulnerability reported in vBulletin 3.0.x (fwd)
Message-ID: <Pine.GSO.4.51.0604250251080.9057@faron.mitre.org>


inquiry sent to vBulletin sales people... wish they didn't require
registration just to send an email to support.

Basic question is: CVE-2004-0036 was reported in January 2004 in
calendar.php with the eventid parameter, but it appeared to have been
fixed in 2.3.4.  Now we have 3.0.x with the same vectors.  3.0.3 was
released in July 2004 according to this:

  http://www.vbulletin.com/forum/showthread.php?t=109435

but I can't seem to find any older threads.

So, this could be a regression issue where they re-introduced the bug, or
they just didn't fix that issue.

---------- Forwarded message ----------
Date: Tue, 25 Apr 2006 02:50:52 -0400 (EDT)
From: Steven M. Christey <coley at mitre.org>
To: sales   vbulletin.com
Subject: Security Vulnerability reported in vBulletin 3.0.x


Hello,

I am a computer security professional and the editor for the Common
Vulnerabilities and Exposures (CVE) project.  CVE is a list of
software vulnerabilities, and it is widely used in the computer
security industry.  It is sponsored by the US Department of Homeland
Security.  (http://www.us-cert.gov/cve/, http://cve.mitre.org/)

Recently, a vulnerability in your product was reported to public
sources.  References and a description are included below:

  BUGTRAQ:20060423 vbulletin<--3.0.x SQL Injection
  URL:http://www.securityfocus.com/archive/1/431901

This sounds very similar to an issue that was discovered and fixed in
vBulletin 2.3.4, as reported here:

  http://www.vbulletin.com/forum/showthread.php?postid=588825

Is this new vulnerability report accurate?  Is there a different
issue, or did the old issue reappear?

For your convenience, I will share your response with other
vulnerability information sources unless you request otherwise.


Thank you,
Steve Christey
Principal Information Security Engineer
CVE Editor
The MITRE Corporation

From coley at linus.mitre.org  Tue Apr 25 03:31:14 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 25 Apr 2006 03:31:14 -0400 (EDT)
Subject: [VIM] Security Vulnerability reported in vBulletin 3.0.x -
 vBulletin Issue (fwd)
Message-ID: <Pine.GSO.4.51.0604250329520.9057@faron.mitre.org>


vBulletin got back to me within 5 or 10 minutes, saying that 3.0.x
versions were never affected, only pre-2.3.4...

---------- Forwarded message ----------
Date: Tue, 25 Apr 2006 01:59:57 -0500
From: vBulletin Support Team
To: coley at mitre.org
Subject: Re: Security Vulnerability reported in vBulletin 3.0.x - vBulletin Issue

Hi Steve,

Thanks for contacting us. We were made aware of this report on a different
site, and it is not valid. This issue was in fact fixed in vBulletin 2.3.4
and never affected vBulletin 3.0.x

Let me know if you require any further assistance.


Best Regards,
Colin Frei
vBulletin Support Team

From coley at linus.mitre.org  Tue Apr 25 12:48:00 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 25 Apr 2006 12:48:00 -0400 (EDT)
Subject: [VIM] NISCC DNS/PROTOS vendor information
Message-ID: <Pine.GSO.4.51.0604251245220.13897@faron.mitre.org>


For those of you scratching your heads about why there's no vendor
information in this main advisory:

  http://www.niscc.gov.uk/niscc/docs/br-20060425-00311.html?lang=en

I can't answer that, but some semi-random clicking somehow got me to this:

  http://www.niscc.gov.uk/niscc/docs/re-20060425-00312.pdf?lang=en


I'll be working on CVEs for this shortly, but I'm considering doing
another generic CVE for the suite, then implementation-specific CVEs for
each individual product.  Still feels a little wrong to do that, but with
suite-based testing and its simultaneous flood/dearth of information,
there seems little else to do :(

- Steve

From coley at linus.mitre.org  Tue Apr 25 14:33:17 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 25 Apr 2006 14:33:17 -0400 (EDT)
Subject: [VIM] CVE-2006-1780
In-Reply-To: <20060419125811.azzu2l15hhwokckc@www.cirt.net>
References: <20060419125811.azzu2l15hhwokckc@www.cirt.net>
Message-ID: <Pine.GSO.4.51.0604251430110.3145@faron.mitre.org>


On Wed, 19 Apr 2006, Sullo wrote:

> I know this is a long-shot, but does anyone have any information as to
> how this is exploited?  All the statements are pretty vague about
> whether this allows a single user to DoS other users, or if it's just
> their own processes...

If it's a self-DoS, I wouldn't expect it to be labeled a security issue.

Unfortunately, I don't know any more than what's in the Sun advisory.  I
suspect that it might involve temporary files that are created to support
pipes or some other form of IPC.  Maybe another user can kill a file while
it's being used, but I wouldn't expect that to happen in a directory with
the sticky bit set.  So, I'm at a loss here...

- Steve

From jericho at attrition.org  Tue Apr 25 16:12:17 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 25 Apr 2006 16:12:17 -0400 (EDT)
Subject: [VIM] (ethereal)  Re: advisory solution question (fwd)
Message-ID: <Pine.LNX.4.64.0604251611460.4821@forced.attrition.org>



---------- Forwarded message ----------
From: Gerald Combs < @ethereal.com>
To: security curmudgeon <jericho at attrition.org>
Date: Tue, 25 Apr 2006 08:30:20 -0500
Subject: Re: advisory solution question

The text has been changed to "Upgrade to 0.99.0."

security curmudgeon wrote:
>
> http://www.ethereal.com/appnotes/enpa-sa-00023.html
>
> Resolution:
> Upgrade to 0.10.14.
>
>
> --
>
> However, many of the entries above say "0.8.5 - 0.10.14" affected for
> example. So does this mean 0.10.14 is affected, if downloaded before a
> certain date? Or the various 'affected' version lists mean up to but not
> including?

From jericho at attrition.org  Tue Apr 25 17:59:01 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 25 Apr 2006 17:59:01 -0400 (EDT)
Subject: [VIM] VDB nightmare day?   (humor)
Message-ID: <Pine.LNX.4.64.0604251758200.4821@forced.attrition.org>


Microsoft, Apple, Oracle and Ethereal all release advisories on the same 
day. Who else would add to the nightmare?

From coley at linus.mitre.org  Tue Apr 25 18:34:13 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 25 Apr 2006 18:34:13 -0400 (EDT)
Subject: [VIM] VDB nightmare day?   (humor)
In-Reply-To: <Pine.LNX.4.64.0604251758200.4821@forced.attrition.org>
References: <Pine.LNX.4.64.0604251758200.4821@forced.attrition.org>
Message-ID: <Pine.GSO.4.51.0604251825510.3145@faron.mitre.org>


> Microsoft, Apple, Oracle and Ethereal all release advisories on the same
> day.

We came quite close to that recently, didn't we? :)

> Who else would add to the nightmare?

Mozilla.

Any new PROTOS project.

r0t re-energized after a vacation.

Any of the thousands of people who could produce on r0t's level if only
they realized how easy it is to be 75% correct and generate big vuln
counts in most software.

- Steve

From jericho at attrition.org  Tue Apr 25 18:44:06 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 25 Apr 2006 18:44:06 -0400 (EDT)
Subject: [VIM] VDB nightmare day?   (humor)
In-Reply-To: <Pine.GSO.4.51.0604251825510.3145@faron.mitre.org>
References: <Pine.LNX.4.64.0604251758200.4821@forced.attrition.org>
	<Pine.GSO.4.51.0604251825510.3145@faron.mitre.org>
Message-ID: <Pine.LNX.4.64.0604251841440.4821@forced.attrition.org>


: > Microsoft, Apple, Oracle and Ethereal all release advisories on the same
: > day.
: 
: We came quite close to that recently, didn't we? :)

Very close yes =) That is impetus behind this post actually.

: > Who else would add to the nightmare?
: 
: Mozilla.

This last batch yes.. before that has been pretty tame.

: Any new PROTOS project.

True, but a nightmare on a different level (for OSVDB anyway). Less that 
it generates a lot of entries, more that it is a pain trying to track what 
is affected.

: r0t re-energized after a vacation.
: 
: Any of the thousands of people who could produce on r0t's level if only 
: they realized how easy it is to be 75% correct and generate big vuln 
: counts in most software.

I've thought about this the last couple of weeks as well. Your term of 
"grep and gripe" vuln research stuck in my head, and I was trying to come 
up with an equally amusing and accurate term for the XSS cut/paste and ' 
testing that leads to so many reports these days.

From coley at linus.mitre.org  Tue Apr 25 18:53:37 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 25 Apr 2006 18:53:37 -0400 (EDT)
Subject: [VIM] VDB nightmare day?   (humor)
In-Reply-To: <Pine.LNX.4.64.0604251841440.4821@forced.attrition.org>
References: <Pine.LNX.4.64.0604251758200.4821@forced.attrition.org>
	<Pine.GSO.4.51.0604251825510.3145@faron.mitre.org>
	<Pine.LNX.4.64.0604251841440.4821@forced.attrition.org>
Message-ID: <Pine.GSO.4.51.0604251852250.3145@faron.mitre.org>


On Tue, 25 Apr 2006, security curmudgeon wrote:

> I've thought about this the last couple of weeks as well. Your term of
> "grep and gripe" vuln research stuck in my head, and I was trying to come
> up with an equally amusing and accurate term for the XSS cut/paste and '
> testing that leads to so many reports these days.

peach fuzz?

- Steve

From jericho at attrition.org  Wed Apr 26 08:11:20 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 26 Apr 2006 08:11:20 -0400 (EDT)
Subject: [VIM] NISCC DNS/PROTOS vendor information
In-Reply-To: <Pine.GSO.4.51.0604251245220.13897@faron.mitre.org>
References: <Pine.GSO.4.51.0604251245220.13897@faron.mitre.org>
Message-ID: <Pine.LNX.4.64.0604260808451.31702@forced.attrition.org>


: For those of you scratching your heads about why there's no vendor
: information in this main advisory:
: 
:   http://www.niscc.gov.uk/niscc/docs/br-20060425-00311.html?lang=en
: 
: I can't answer that, but some semi-random clicking somehow got me to this:
: 
:   http://www.niscc.gov.uk/niscc/docs/re-20060425-00312.pdf?lang=en
: 
: I'll be working on CVEs for this shortly, but I'm considering doing 
: another generic CVE for the suite, then implementation-specific CVEs for 
: each individual product.  Still feels a little wrong to do that, but 
: with suite-based testing and its simultaneous flood/dearth of 
: information, there seems little else to do :(

Teach me to blindly create entries! After two DNS related vulns I figured 
something was up. That said, looks like Secunia is digging up some more 
details about the PROTOS findings. Looking at their entries:

http://secunia.com/advisories/19808/

  The vulnerability is caused due to an error within the handling of the 
  TSIG in the second or subsequent messages in a zone transfer. This can 
  be exploited to crash "named" via a malformed TSIG in the messages.

http://secunia.com/advisories/19831/

  The vulnerability is caused due to an error in the recursor when parsing 
  certain DNS packets. This can be exploited to crash the recursor via a 
  malformed EDNS0 packet.

http://secunia.com/advisories/19835/

  The vulnerability is caused due to a memory leak error within the 
  handling of the QTYPE and QCLASS DNS queries.


So it appears we have three vectors for the denial of service, but 
obviously don't know if each method effects each product.

From coley at mitre.org  Wed Apr 26 15:48:49 2006
From: coley at mitre.org (Steven M. Christey)
Date: Wed, 26 Apr 2006 15:48:49 -0400 (EDT)
Subject: [VIM] Leadhound has distributable version
Message-ID: <200604261948.k3QJmn8j004145@cairo.mitre.org>


Ref:

  http://pridels.blogspot.com/2006/04/leadhound-multiple-vuln.html

At first (and second) glance, the product seems to be managed
exclusively by the vendor.  However, the vendor's home page at
http://www.leadhound.com/ includes information on:

  Network Version - Your Hardware

  The Network Version "Full Version" is the full source code of the
  system which is managed and run from your server hardware

While this was not referenced in the original r0t advisory, it seems
likely to be affected as well.

- Steve

From jericho at attrition.org  Wed Apr 26 16:53:09 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 26 Apr 2006 16:53:09 -0400 (EDT)
Subject: [VIM] Leadhound has distributable version
In-Reply-To: <200604261948.k3QJmn8j004145@cairo.mitre.org>
References: <200604261948.k3QJmn8j004145@cairo.mitre.org>
Message-ID: <Pine.LNX.4.64.0604261651240.31702@forced.attrition.org>


:   http://pridels.blogspot.com/2006/04/leadhound-multiple-vuln.html
: 
: At first (and second) glance, the product seems to be managed
: exclusively by the vendor.  However, the vendor's home page at
: http://www.leadhound.com/ includes information on:
: 
:   Network Version - Your Hardware
: 
:   The Network Version "Full Version" is the full source code of the
:   system which is managed and run from your server hardware
: 
: While this was not referenced in the original r0t advisory, it seems 
: likely to be affected as well.

Yep, this is in my queue to make entries for. My first thought was site 
specific but I started reading the fine print. They offer a managed 
version on their servers as well as a copy you can install on your own.

The managed version on their servers really blurs the line on inclusion 
in the database or labeling it site specific.

From coley at mitre.org  Thu Apr 27 00:57:10 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 27 Apr 2006 00:57:10 -0400 (EDT)
Subject: [VIM] DevBB vs. MyBB
Message-ID: <200604270457.k3R4vAGG011919@cairo.mitre.org>


For those of you who care about codebase relationships, here's yet one
more bit of information to make DevBB/MyBB vuln reports fun:

  http://community.mybboard.net/showthread.php?tid=4072

The most relevant post seems to come from TemplatesForAll, and a later
post by the developer does not contradict that post.

In this case, it sounds like it's the same developer, but distinct
codebases.

XMB is also mentioned.

- Steve

From coley at mitre.org  Thu Apr 27 16:48:14 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 27 Apr 2006 16:48:14 -0400 (EDT)
Subject: [VIM] pdnsd - buffer overflow, not just memory leak
Message-ID: <200604272048.k3RKmEcP024432@cairo.mitre.org>


Some VDB's have been concentrating on the memory leak in pdnsd as
reported with the PROTOS DNS stuff, but note that the developer's
front page at http://www.phys.uu.nl/~rombouts/pdnsd.html says:

  A memory leak and a minor buffer-overflow problem have been fixed.

The statement in the NISCC document only seems to cover the memory
leak, so it's not clear whether the overflow is PROTOS-related or not.

- Steve

From coley at linus.mitre.org  Thu Apr 27 18:08:38 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 27 Apr 2006 18:08:38 -0400 (EDT)
Subject: [VIM] Copy of: Security issues in IPG (fwd)
Message-ID: <Pine.GSO.4.51.0604271807340.10317@faron.mitre.org>


filled out the web form... clarification post to bugtraq awaiting
approval.

---------- Forwarded message ----------
Date: Thu, 27 Apr 2006 18:05:05 -0400
From: Instant Photo Gallery
To: coley at mitre.org
Subject: Copy of: Security issues in IPG

This is a copy of the following message you sent to Ed Verosky via Instant
Photo Gallery

This is an enquiry e-mail via http://www.instantphotogallery.com from:
Steve Christey <coley at mitre.org>

Hello,

I am a computer security professional for the CVE project, which is
sponsored by the Department of Homeland Security to assign standard
identifiers for security vulnerabilities (http://www.us-cert.gov/cve/,
http://cve.mitre.org/)

Recently, some security vulnerability information about your product
was posted here:

  http://www.securityfocus.com/archive/1/432024/100/0/threaded

and here:

  http://www.securityfocus.com/archive/1/432022/100/0/threaded

It seems that the portfolio.php/cat_id issue might have been fixed in
1.0.2, but portfolio_photo_popup.php/id seems to be related to SQL
injection when count_click() is called.

I couldn't see anything about "viewpro" in the code anywhere - was that
report entirely wrong?

I would appreciate any information and fixes you might have.


Thank you,
Steve Christey
Principal Information Security Engineer
CVE Editor
The MITRE Corporation


From coley at linus.mitre.org  Thu Apr 27 18:14:08 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 27 Apr 2006 18:14:08 -0400 (EDT)
Subject: [VIM] Instant Photo Gallery <= Multiple XSS (fwd)
Message-ID: <Pine.GSO.4.51.0604271813100.10317@faron.mitre.org>


here's the Bugtraq post.  basically I concur with Secunia's interpretation
as referenced by Jericho in his Bugtraq followup.

---------- Forwarded message ----------
Date: Thu, 27 Apr 2006 18:00:59 -0400 (EDT)
From: Steven M. Christey <coley at mitre.org>
To: bugtraq at securityfocus.com
Subject: Re: Instant Photo Gallery <= Multiple XSS


security curmudgeon mentioned:

>  /portfolio.php?cat_id=[XSS]

Based on source inspection of 1.0.2, this parameter is cleansed.

line 31 of portfolio.php says:

  $catId = $dbFilter->db_clean_input($_GET['cat_id'], 'integer');

which looks like it's going to do input validation as an integer.

BUT... did it do this properly?

Let's go to the definition for db_clean_input...

includes/classes/class_db_input_filter.php:

> class db_input_filter{
>
>...
>
>    function db_clean_input($input, $inputType, $quoteValue=1){
>
>        $this->input = $input;
>        $this->inputType = $inputType;
>
>...
>
>        switch($this->inputType) {
>            case 'integer':
>                if(ereg("^[0-9]+$", $this->input)) {
>                    $this->input = (int)$this->input;
>                } else {
>                    $this->errorMsg = "Input does not match specified type (integer).";
>                    return false;
>                }


Notice the ereg() call.  It cleanses the input ONLY if it consists of
all digits.  Otherwise, the function returns 'false'.  The program
doesn't check if a bad value was provided, but still, this would have
the effect of setting the $catId variable to a blank value.

In February 2006, the developer also offered a "IPG Security Patch
1.0.1" which includes the portfolio.php file that is now in 1.0.2, so
maybe the portfolio.php/cat_id vector only applies to versions of
Instant Photo Gallery BEFORE 1.0.2.


portfolio_photo_popup.php / id is more clear:

>$image_id = isset($_POST['id'])?$_POST['id']:$_GET['id'];
>
>count_click($image_id);

and in includes/functions/fns_std.php:

>function count_click($image_id){
> db_connect();
>	$sql = "SELECT * FROM " . PDB_PREFIX . "image_ratings WHERE id = " . $image_id;

So, we have direct SQL injection using the "id" parameter, which
produces resultant XSS if the SQL query is malformed in an
XSS-friendly fashion.

- Steve

From coley at mitre.org  Thu Apr 27 18:56:08 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 27 Apr 2006 18:56:08 -0400 (EDT)
Subject: [VIM] Recent Oracle exploit is _actually_ an 0day with no patch
Message-ID: <200604272256.k3RMu8Br001679@cairo.mitre.org>


[sent to Bugtraq]


>The recent Oracle exploit posted to Bugtraq
>(http://www.securityfocus.com/archive/1/431353) is actually an 0day
>and has no patch.

The referenced exploit seems to use GET_DOMAIN_INDEX_METADATA with a
TYPE_NAME that references an attacker-defined package with a
(modified?) ODCIIndexGetMeta function.

Your last example uses GET_V2_DOMAIN_INDEX_TABLES, with arguments that
reference an attacker-defined package with a (modified?)
ODCIIndexUtilGetTableNames function.

Is this a surface-level discrepancy, or is your vector substantively
different than the one in the exploit?  If these are different, then
is it possible that last week's exploit was actually fixed?

- Steve

P.S. For those of you who are paying attention at this excruciating
level of detail, it seems that David's original use of
GET_DOMAIN_INDEX_METADATA in 2004 directly included the code in the
NEWBLOCK argument, whereas last week's exploit was performed through
an indirect reference to the code in the TYPE_NAME argument.

From coley at mitre.org  Thu Apr 27 21:22:22 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 27 Apr 2006 21:22:22 -0400 (EDT)
Subject: [VIM] Old DNS issues from May 2005 missed by most
Message-ID: <200604280122.k3S1MMxx002879@cairo.mitre.org>


The following CVE's were only just updated, even though they're almost
a year old.  Most vuln DB's didn't catch the details, and no wonder...

The original disclosure was by NISCC and had no vendor/product details
at all.  I had left the CVEs blank, waiting for more public
information, and it must have just fallen off my plate.  While dealing
with the recent DNS issues, I ran across these old ones.  A Google
search for "CAN-2005-0036" (0ld sk00l r0x!) and whattaya know, there's
a PDF floating around.  Nothing like using Google to find out what
your own identifier is actually about :)

Major nit: NISCC really needs to make a clearer link between the HTML
and PDF files.  Like, actually linking to the PDF from the HTML.

- Steve

======================================================
Name: CVE-2005-0036
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0036
Reference: MISC:http://www.niscc.gov.uk/niscc/docs/re-20050524-00432.pdf?lang=en
Reference: MISC:http://www.niscc.gov.uk/niscc/docs/al-20050524-00433.html
Reference: BID:13729
Reference: URL:http://www.securityfocus.com/bid/13729

The DNS implementation in DeleGate 8.10.2 and earlier allows remote
attackers to cause a denial of service via a compressed DNS packet
with a label length byte with an incorrect offset, which could trigger
an infinite loop.


======================================================
Name: CVE-2005-0037
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0037
Reference: MISC:http://www.niscc.gov.uk/niscc/docs/re-20050524-00432.pdf?lang=en
Reference: MISC:http://www.niscc.gov.uk/niscc/docs/al-20050524-00433.html
Reference: BID:13729
Reference: URL:http://www.securityfocus.com/bid/13729

The DNS implementation of DNRD before 2.10 allows remote attackers to
cause a denial of service via a compressed DNS packet with a label
length byte with an incorrect offset, which could trigger an infinite
loop.


======================================================
Name: CVE-2005-0038
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0038
Reference: MISC:http://www.niscc.gov.uk/niscc/docs/re-20050524-00432.pdf?lang=en
Reference: MISC:http://www.niscc.gov.uk/niscc/docs/al-20050524-00433.html
Reference: BID:13729
Reference: URL:http://www.securityfocus.com/bid/13729

The DNS implementation of PowerDNS 2.9.16 and earlier allows remote
attackers to cause a denial of service via a compressed DNS packet
with a label length byte with an incorrect offset, which could trigger
an infinite loop.



From jericho at attrition.org  Sun Apr 30 05:13:12 2006
From: jericho at attrition.org (security curmudgeon)
Date: Sun, 30 Apr 2006 05:13:12 -0400 (EDT)
Subject: [VIM] IBM changing significant details?
In-Reply-To: <Pine.GSO.4.51.0603240306520.1292@faron.mitre.org>
References: <Pine.LNX.4.64.0603230850410.18190@forced.attrition.org>
	<Pine.GSO.4.51.0603232109380.25850@faron.mitre.org>
	<Pine.LNX.4.64.0603232115270.18190@forced.attrition.org>
	<44235F36.50502@securityglobal.net>
	<Pine.LNX.4.64.0603232155060.18190@forced.attrition.org>
	<Pine.GSO.4.51.0603240306520.1292@faron.mitre.org>
Message-ID: <Pine.LNX.4.64.0604300511470.1835@forced.attrition.org>


At long last..

: On Thu, 23 Mar 2006, security curmudgeon wrote:
: 
: > I am 99% sure the APAR said 'mklvcopy'. I created the OSVDB entry within
: > hours of Secunia's entry and couldn't find any more info than they had.
: 
: This is one more aspect of the provenance problem: who knew what when, 
: and how confident are we that they were right in the first place, and if 
: there was an original source, where is it and barring that, how 
: confident are we that the original source was interpreted correctly by a 
: third party?  I don't know if this kind of problem is getting more 
: pronounced, or if I'm just getting more sensitive to it now.

http://archives.neohapsis.com/archives/bugtraq/2006-04/0481.html
NSFOCUS SA2006-02 : IBM AIX mklvcopy Local Privilege Escalation Vulnerability

NSFOCUS Security Advisory (SA2006-02)
IBM AIX mklvcopy Local Privilege Escalation Vulnerability
Release Date: 2006-04-24
CVE ID: CVE-2006-1246

The vendor has released Patch APAR IY82739 to fix the vulnerability. The 
related 
link is:
http://www-1.ibm.com/support/docview.wss?uid=isg1IY82739

--

So the bos.rte.lvm vs mklvcopy issue comes to light. Same thing it appears 
=)