From theall at tenablesecurity.com  Wed Aug  2 11:58:55 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Wed, 02 Aug 2006 11:58:55 -0400
Subject: [VIM] Help Center Live
Message-ID: <44D0CBBF.1040709@tenablesecurity.com>

I don't know if anyone's looked into this yet, but the flaw in Help
Center Live reported by Dr. Google (see BID 19256) is a local file
include flaw, not just a directory traversal. It is also closely related
to an earlier flaw, covered by BID 15404. To fix that issue, the code in
'templates/*/module.tpl' was changed from:

  include_once(dirname(__FILE__).'/../../..'.addslashes($_GET['file']));

to this:

  if (!strpos($_GET['file'], '..')) {
    include_once(dirname(__FILE__).'/../../..'.addslashes($_GET['file']));
  ...

Trouble is, strpos() returns 0 if 'file' starts with ".." so the code
change only partially resolved the earlier issue.

George
-- 
theall at tenablesecurity.com

From jericho at attrition.org  Mon Aug  7 03:19:40 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 7 Aug 2006 03:19:40 -0400 (EDT)
Subject: [VIM] site specific influx
Message-ID: <Pine.LNX.4.64.0608070319020.29462@forced.attrition.org>


http://www.securitylab.ru/blog/tecklord/?category=19

wide range of XSS in security sites mainly

From jericho at attrition.org  Wed Aug  9 05:12:51 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 9 Aug 2006 05:12:51 -0400 (EDT)
Subject: [VIM] SYM06-013 Symantec On-Demand Protection Encrypted Data
 Exposure (fwd)
Message-ID: <Pine.LNX.4.64.0608090511460.7344@forced.attrition.org>


Chris beat me to the punch on this one. We're seeing the same thing on 
Full-Disclosure, but being an unmoderated list I don't expect otherwise. 
With Bugtraq though.. having all the details posted to the list allow the 
advisory to be archived all over now. @stake is only one of many sites 
that have since had their advisory archive disappear.

---------- Forwarded message ----------
From: Chris Wysopal <weld at vulnwatch.org>
To: secure at symantec.com
Cc: bugtraq at securityfocus.com
Date: Tue, 1 Aug 2006 22:22:02 -0500 (EST)
Subject: Re: SYM06-013 Symantec On-Demand Protection Encrypted Data Exposure



On Tue, 1 Aug 2006 secure at symantec.com wrote:

> Symantec has posted a Security Advisory for Symantec On-Demand Protection.
> PLease see the advisory for complete information:
>
> http://www.symantec.com/avcenter/security/Content/2006.08.01a.html

This Symantec posting contains minimal security information.  In December
2000[1] @stake modified their Bugtraq postings to include a small amount
of security information and a link back to the @stake website where the
full advisory resided.  The intention was to have a bit more control over
the way people viewed the advisories.  They would be viewed on the @stake
website only and not serve as content for for-profit advertising supported
websites.  The advisory could also be updated if there were errors or
updates and it would serve as the canonical reference.

Elias Levy, the Bugtraq moderator at the time, rejected the posting on the
grounds that it contained minimal security information.  His reasoning was
that forcing people to go to an additional website was inconvenient and
that if the advisory website ever went away the original advisory would be
lost.  He had a good point and @stake changed back to the old format.

One of the ironies of the security world is Symantec purchased
SecurityFocus and then later @stake.  After purchasing @stake, Symantec
removed the @stake advisory archive, thus bringing Elias' fear to reality.

Elias' reasoning still holds true today.  Companies come and go, are
acquired or change course.  Symantec should post its full advisories to
the list and so should everyone else.

-Chris

1. Bugtraq: Administrivia & AOL IM Advisory,
    http://seclists.org/bugtraq/2000/Dec/0197.html

From theall at tenablesecurity.com  Wed Aug  9 10:53:54 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Wed, 09 Aug 2006 10:53:54 -0400
Subject: [VIM] Revisiting The Past
Message-ID: <44D9F702.7070801@tenablesecurity.com>

Can anyone tell me the difference between:

  http://echo.or.id/adv/adv16-theday-2005.txt (the 1st SQL injection)
  http://archives.neohapsis.com/archives/bugtraq/2005-07/0521.html

The first seems to be reflected in CVE-2005-1967, and OSVDB 17329; the
latter in CVE-2005-2445, OSVDB 18508. And to further muddy things, BID
13881 credits Dedi Dwianto but provides a reference to Dcrab's advisory.

Unless I'm missing something, both appear to cover the same app /
version / script / parameter / issue. [NB: Bugtraq and OSVDB do say
Product Cart 2.7 is affected, but Dwianto's advisory states "version : <
2.7", at least as I look at it right now.]

George
-- 
theall at tenablesecurity.com

From coley at linus.mitre.org  Wed Aug  9 16:15:12 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 9 Aug 2006 16:15:12 -0400 (EDT)
Subject: [VIM] Revisiting The Past
In-Reply-To: <44D9F702.7070801@tenablesecurity.com>
References: <44D9F702.7070801@tenablesecurity.com>
Message-ID: <Pine.GSO.4.51.0608091611030.3042@faron.mitre.org>


My gut reaction is that this was a dupe/rediscovery that wasn't caught due
to different spellings of "ProductCart" and "Product Cart" (though we
should have caught it on the script or parameter name...)  These days, I
would update the original CVE to mention the new version that is also
affected.

I hate duplicates due to alternate spellings :(  In CVE, we don't have a
normalized vendor or product name field, which might make this issue worse
- or do other DBs have the same problem?

- Steve


On Wed, 9 Aug 2006, George A. Theall wrote:

> Can anyone tell me the difference between:
>
>   http://echo.or.id/adv/adv16-theday-2005.txt (the 1st SQL injection)
>   http://archives.neohapsis.com/archives/bugtraq/2005-07/0521.html
>
> The first seems to be reflected in CVE-2005-1967, and OSVDB 17329; the
> latter in CVE-2005-2445, OSVDB 18508. And to further muddy things, BID
> 13881 credits Dedi Dwianto but provides a reference to Dcrab's advisory.
>
> Unless I'm missing something, both appear to cover the same app /
> version / script / parameter / issue. [NB: Bugtraq and OSVDB do say
> Product Cart 2.7 is affected, but Dwianto's advisory states "version : <
> 2.7", at least as I look at it right now.]
>
> George
> --
> theall at tenablesecurity.com
>

From coley at mitre.org  Thu Aug 10 21:38:21 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 10 Aug 2006 21:38:21 -0400 (EDT)
Subject: [VIM] "user-assisted"
Message-ID: <200608110138.k7B1cLbw016566@faron.mitre.org>


I forgot to tell VIM that CVE is now using the "user-assisted" term to
handle the (usually client-side) cases in which the victim must
manuually or non-automatically receive a malicious payload and
activate it.  This is much better than the crude "user-complicit" term
we were using before.

Note that since I've started thinking more heavily about this, there
are still cases in which the typical attack vectors would be remote or
local; e.g. if the application is a chat client and the victim has to
approve an "add friend" request from the attacker, the channel is
still remote.  I'm still figuring things out, though.

Some CVE analysts have tried to use the term to account for cases in
which because the user must be "tricked" into visiting a web page or
clicking on a link, especially for web browser vulns.  However, I'm
currently of the opinion that these do *not* fall under the
"user-assisted" label because in the Internet environment, most
web-based attack scenarios can be automated (e.g. through XSS/HTML
injection), and/or the simple act of clicking on a link is so
fundamental to web browsing.  On the other hand, an exploit that
requires the victim to drag-and-drop certain icons to activate a
payload would be user-assisted in my book.

In conclusion, this eases the terminological pain, but it doesn't fix
everything :)

- Steve

P.S. credit to Gadi Evron for suggesting the term.

From coley at linus.mitre.org  Fri Aug 11 16:10:21 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Fri, 11 Aug 2006 16:10:21 -0400 (EDT)
Subject: [VIM] QaTraq multiple cross-site scripting vulnerabilities (fwd)
Message-ID: <Pine.GSO.4.51.0608111610030.14369@faron.mitre.org>



vendor ack...

---------- Forwarded message ----------
Date: Fri, 11 Aug 2006 14:25:18 +0100
From: William Echlin
To: cve at mitre.org
Subject: QaTraq multiple cross-site scripting vulnerabilities

The multiple cross-site scripting vulnerabilities identified in

http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-3312

have been fixed with the latest 6.8 RC release of QaTraq. For more
information please see our web site at www.testmanagement.com.

If you could update your database to reflect this I would be grateful

Kind regards

Bill Echlin
QaTraq Team
www.testmanagement.com

From coley at mitre.org  Fri Aug 11 16:46:41 2006
From: coley at mitre.org (Steven M. Christey)
Date: Fri, 11 Aug 2006 16:46:41 -0400 (EDT)
Subject: [VIM] SquirrelMail issue is dynamic variable evaluation
Message-ID: <200608112046.k7BKkfFi015192@faron.mitre.org>


FYI.  The MISC reference below is for the patch, which removes the
following code:

-        foreach ($session_expired_post as $postvar => $val) {
-            if (isset($val)) {
-                $$postvar = $val;
-            } else {
-                $$postvar = '';


So, the $$postvar is obviously dynamic variable evaluation.

SquirrelMail and FrSIRT refer to this as "variable overwrite," and
maybe that's a better term than what I use :)

- Steve


======================================================
Name: CVE-2006-4019
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4019
Reference: CONFIRM:http://www.squirrelmail.org/security/issue/2006-08-11
Reference: MISC:http://www.squirrelmail.org/patches/sqm1.4.7-expired-post-fix-full.patch
Reference: FRSIRT:ADV-2006-3271
Reference: URL:http://www.frsirt.com/english/advisories/2006/3271
Reference: SECUNIA:21354
Reference: URL:http://secunia.com/advisories/21354

Dynamic variable evaluation vulnerability in compose.php in
SquirrelMail 1.4.0 to 1.4.7 allows remote attackers to overwriute
arbitrary program variables and read or write the attachments and
preferences of other users.



From jericho at attrition.org  Mon Aug 14 00:23:16 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 14 Aug 2006 00:23:16 -0400 (EDT)
Subject: [VIM] vendor dispute: 21687: Jamit Job Board index.php cat Variable
 SQL Injection (fwd)
Message-ID: <Pine.LNX.4.64.0608140022050.19192@forced.attrition.org>


CVE-2005-4232
BID 15848
FrSIRT ADV-2005-2879
Secunia 18007
http://pridels.blogspot.com/2005/12/jamit-job-board-24x-sql-inj.html
http://packetstormsecurity.org/0512-advisories/sa18007.txt

---------- Forwarded message ----------
From: Adam M.
To: moderators at osvdb.org
Date: Mon, 14 Aug 2006 12:17:45 +0800
Reply-To: moderators at osvdb.org
Subject: [OSVDB Mods] [Change Request] 21687: Jamit Job Board index.php cat
     Variable SQL Injection

Hello,

Can you please remove the following page from your website:

http://www.osvdb.org/21687

The vulnerability is without any basis and did not actually work.

The vulnerability first appeared on Secuina, however they failed to verify that it was actually correct. The exploit does not work at all.


Regards,

Adam

From coley at linus.mitre.org  Mon Aug 14 16:24:33 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 14 Aug 2006 16:24:33 -0400 (EDT)
Subject: [VIM] vendor dispute: 21687: Jamit Job Board index.php cat
 Variable SQL Injection (fwd)
In-Reply-To: <Pine.LNX.4.64.0608140022050.19192@forced.attrition.org>
References: <Pine.LNX.4.64.0608140022050.19192@forced.attrition.org>
Message-ID: <Pine.GSO.4.51.0608141623270.6105@faron.mitre.org>


Y'all might appreciate the text.  I don't see any other way of handling
these things with our limited resources.

- Steve


======================================================
Name: CVE-2005-4232
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4232
Reference: MISC:http://pridels.blogspot.com/2005/12/jamit-job-board-24x-sql-inj.html
Reference: MLIST:[VIM] 20060814 vendor dispute: 21687: Jamit Job Board index.php cat Variable SQL Injection (fwd)
Reference: URL:
Reference: BID:15848
Reference: URL:http://www.securityfocus.com/bid/15848
Reference: FRSIRT:ADV-2005-2879
Reference: URL:http://www.frsirt.com/english/advisories/2005/2879
Reference: OSVDB:21687
Reference: URL:http://www.osvdb.org/21687
Reference: SECUNIA:18007
Reference: URL:http://secunia.com/advisories/18007


** DISPUTED **

SQL injection vulnerability in index.php in Jamit Job Board 2.4.1 and
earlier allows remote attackers to execute arbitrary SQL commands via
the cat parameter.  NOTE: the vendor has disputed this issue, saying
"The vulnerability is without any basis and did not actually work."
CVE has not verified either the vendor or researcher statements, but
the original researcher is known to make frequent mistakes when
reporting SQL injection.



From coley at mitre.org  Mon Aug 14 16:25:06 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 14 Aug 2006 16:25:06 -0400 (EDT)
Subject: [VIM] Ruby on Rails - incomplete fix for 1.1.5
Message-ID: <200608142025.k7EKP6M0011288@faron.mitre.org>


For those who split their entries based on versions and bug variants,
notice the following text from the announcement for Ruby on Rails
1.1.6:

  http://weblog.rubyonrails.org/2006/8/10/rails-1-1-6-backports-and-full-disclosure

  "Unfortunately, the 1.1.5 update from yesterday only partly closed
  the hole (getting rid of the worst data loss trigger). After
  learning more about the extent of the problem, we.ve now put
  together a 1.1.6 release that completely closes all elements of the
  hole (using the same technique as the backports above).

  So if you upgraded to 1.1.5 yesterday, you need to upgrade again."


So, 1.1.6 is the complete fix, and 1.1.5 only had a partial fix, as
originally reported in:

  http://weblog.rubyonrails.com/2006/8/9/rails-1-1-5-mandatory-security-patch-and-other-tidbits

Also, the Gentoo bug report states that at least one of the issues is
related to the handling of LOAD_PATH, and points to this comment on
the upgrade to 1.1.5:

  http://blog.koehntopp.de/archives/1367-Ruby-On-Rails-Mandatory-Mystery-Patch.html


- Steve

From coley at mitre.org  Mon Aug 14 16:35:37 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 14 Aug 2006 16:35:37 -0400 (EDT)
Subject: [VIM] SUNALERT:102554 "drain_squeue" is probably really squeue_drain
Message-ID: <200608142035.k7EKZbJb011505@faron.mitre.org>


An alert CVE analyst spotted this...

  ACCURACY: The text of the advisory says "drain_squeue" but the stack
  trace says "<trap>ip:squeue_drain+0x114." It seems likely that all
  instances of drain_squeue are wrong. Running nm on
  /kernel/strmod/sparcv9/ip on a Solaris 10 system locates an
  squeue_drain function but no drain_squeue function.


- Steve

From coley at mitre.org  Mon Aug 14 17:55:57 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 14 Aug 2006 17:55:57 -0400 (EDT)
Subject: [VIM] Calendarix <= 0.7 (calpath) Remote File Inclusion
	Vulnerability
Message-ID: <200608142155.k7ELtvIF013078@faron.mitre.org>


[sent to Bugtraq]


Carsten Eilers said:

> Take a look at the top of cal_config.inc.php:
> 
> # adjust the '$calpath'.
> # hardcode it if detection does not work and comment out the remaining
> # code.
> #
> # $calpath = "C:\\PHP\\calendarix\\demo\\" ;
> 
> $calpath = dirname(__FILE__) ;

When doing post-disclosure analysis on "grep-and-gripe" research like
this, you need to make sure that after this initialization, that the
variable doesn't get overwritten before the affected require
statement, e.g. if dynamic variable evaluation is used a la "$$varname
= $_GET[input]".  That means looking within cal_config.inc.php, as
well as any other files that are included/required, before we get to
the vulnerable require statement.  See [1] for an example where this
occurred in the real world (although it still seems to be rare).

There are no such constructs in 0.7.20060401, so this still looks like
an invalid report.  I also checked 3 other versions, all the way back
to the first beta release (0.1.20020905), and $calpath is initialized
to a constant value with no possible modifications before the affected
require statement.

One thing to note is the developer's comment "hardcode [$calpath] if
detection does not work and comment out the remaining code."  The
README also makes it clear that some manual modification of this file
might occur.

So, it's possible that some Calendarix administrators manually changed
cal_config.inc.php in a way that would allow $calpath to be modified
externally.  But then that would be a vulnerability in the site's own
configuration, not the product.

- Steve

[1] BUGTRAQ:20060626 Re: [ECHO_ADV_34$2006] W-Agora (Web-Agora) <=
    4.2.0 (inc_dir) Remote File Inclusion
    http://seclists.org/bugtraq/2006/Jun/0679.html

From jericho at attrition.org  Thu Aug 17 14:05:45 2006
From: jericho at attrition.org (security curmudgeon)
Date: Thu, 17 Aug 2006 14:05:45 -0400 (EDT)
Subject: [VIM] SYM06-16 Symantec NetBackup PureDisk Remote Office
 Edition Elevation of Privilege
In-Reply-To: <43FB1967D03EC7449A77FA91322E364802540780@SVL1XCHCLUPIN01.enterprise.veritas.com>
References: <43FB1967D03EC7449A77FA91322E364802540780@SVL1XCHCLUPIN01.enterprise.veritas.com>
Message-ID: <Pine.LNX.4.64.0608171403000.30874@forced.attrition.org>


Hey Mike!

: Symantec Security Advisory
: 
: SYM06-015

Two things:

1. Can you verify if this is SYM06-15 or SYM06-16?

2. Any chance Symantec could include the URL to the copy hosted on the web 
site on their mail list postings?

Thanks!

Brian


From secure at symantec.com  Thu Aug 17 14:10:44 2006
From: secure at symantec.com (secure at symantec.com)
Date: 17 Aug 2006 18:10:44 -0000
Subject: [VIM] SYM06-16 Symantec NetBackup PureDisk Remote Office
 Edition Elevation of Privilege
Message-ID: <20060817181044.2839.qmail@securityfocus.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://www.attrition.org/pipermail/vim/attachments/20060817/132f93c4/attachment.ksh 

From coley at mitre.org  Thu Aug 17 18:48:56 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 17 Aug 2006 18:48:56 -0400 (EDT)
Subject: [VIM] 04WebServer security page ACK's various vulns
Message-ID: <200608172248.k7HMmuwB016902@faron.mitre.org>


The page:

http://www.soft3304.net/04WebServer/Security.html

(thanks to whichever VDB we got this from, assuming we didn't find it
ourselves; I wasn't personally involved in handling these).

Below are detailed notes on which CVE's are addressed, along with
rough Google translations of the associated items (the site is
Japanese).

Disclosure dates for some older vulns had to be estimated since we
couldn't readily find these details.

- Steve


======================================================
Name: CVE-2002-2216
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-2216
Acknowledged: yes changelog
Announced: 20020602
Flaw: unk
Reference: CONFIRM:http://www.soft3304.net/04WebServer/Security.html

Soft3304 04WebServer before 1.20 does not properly process URL
strings, which allows remote attackers to obtain unspecified sensitive
information.


Analysis:
ACKNOWLEDGEMENT: An automated translation of the CONFIRM says "The
version which is related ... Before v1.20 ... With the coding mistake
of URL character string processing ... access to the optional file is
permitted ... there is a possibility private information ... flowing
out outside."

ACCURACY: the announcement date is unknown, but a download of 1.20
shows the most recent file being Jun 2, 2002.


======================================================
Name: CVE-2004-1512
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1512
Acknowledged: yes changelog
Announced: 20041110
Flaw: XSS
Reference: BUGTRAQ:20041110 04WebServer Three Vulnerabilities
Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=110012542615484&w=2
Reference: BUGTRAQ:20041115 Re: 04WebServer Three Vulnerabilities
Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=110054395311823&w=2
Reference: MISC:http://www.security.org.sg/vuln/04webserver142.html
Reference: CONFIRM:http://www.soft3304.net/04WebServer/Security.html
Reference: BID:11652
Reference: URL:http://www.securityfocus.com/bid/11652
Reference: SECUNIA:13159
Reference: URL:http://secunia.com/advisories/13159/
Reference: XF:04webserver-error-xss(18033)
Reference: URL:http://xforce.iss.net/xforce/xfdb/18033

Cross-site scripting (XSS) vulnerability in Response_default.html in
04WebServer 1.42 allows remote attackers to execute arbitrary web
script or HTML via script code in the URL, which is not quoted in the
resulting default error page.


Analysis:
ACKNOWLEDGEMENT: An automated translation of the CONFIRM says "The
version which is related ... Before v1.43 ... The vulnerability by the
cross script of the error page ... By the fact that it works in
URL...."

ACKNOWLEDGEMENT: The three "Before v1.43" entries in this changelog
appear to match "BUGTRAQ:20041110 04WebServer Three Vulnerabilities."
The translated wording for each individual one may be marginal, but
when they are taken together, it is much more clear that the vendor is
acknowledging all of the publicly reported vulnerabilities in this
version.


======================================================
Name: CVE-2004-1513
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1513
Acknowledged: yes changelog
Announced: 20041110
Flaw: other
Reference: BUGTRAQ:20041110 04WebServer Three Vulnerabilities
Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=110012542615484&w=2
Reference: BUGTRAQ:20041115 Re: 04WebServer Three Vulnerabilities
Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=110054395311823&w=2
Reference: MISC:http://www.security.org.sg/vuln/04webserver142.html
Reference: CONFIRM:http://www.soft3304.net/04WebServer/Security.html
Reference: BID:11652
Reference: URL:http://www.securityfocus.com/bid/11652
Reference: SECUNIA:13159
Reference: URL:http://secunia.com/advisories/13159/
Reference: XF:04webserver-web-log-spoofing(18034)
Reference: URL:http://xforce.iss.net/xforce/xfdb/18034

04WebServer 1.42 does not adequately filter data that is written to
log files, which could allow remote attackers to inject carriage
return characters into the log file and spoof log entries.


Analysis:
ACKNOWLEDGEMENT: An automated translation of the CONFIRM says "The
version which is related ... Before v1.43 ... The vulnerability which
can disguise the log ... By the fact that it works in URL...."

ACKNOWLEDGEMENT: The three "Before v1.43" entries in this changelog
appear to match "BUGTRAQ:20041110 04WebServer Three Vulnerabilities."
The translated wording for each individual one may be marginal, but
when they are taken together, it is much more clear that the vendor is
acknowledging all of the publicly reported vulnerabilities in this
version.


======================================================
Name: CVE-2004-1514
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1514
Acknowledged: yes changelog
Announced: 20041110
Flaw: msdos-device
Reference: BUGTRAQ:20041110 04WebServer Three Vulnerabilities
Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=110012542615484&w=2
Reference: BUGTRAQ:20041115 Re: 04WebServer Three Vulnerabilities
Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=110054395311823&w=2
Reference: MISC:http://www.security.org.sg/vuln/04webserver142.html
Reference: CONFIRM:http://www.soft3304.net/04WebServer/Security.html
Reference: BID:11652
Reference: URL:http://www.securityfocus.com/bid/11652
Reference: SECUNIA:13159
Reference: URL:http://secunia.com/advisories/13159/
Reference: XF:04webserver-dos-devices-dos(18036)
Reference: URL:http://xforce.iss.net/xforce/xfdb/18036

04WebServer 1.42 allows remote attackers to cause a denial of service
(fail to restart properly) via an HTTP request for an MS-DOS device
name such as COM2.


Analysis:
ACKNOWLEDGEMENT: An automated translation of the CONFIRM says "The
version which is related ... Before v1.43 ... The vulnerability which
opens the MS-DOS system device ... when MS-DOS system device name is
appointed ...  Depending on operation ... there is a possibility of
being operated from outside."

ACKNOWLEDGEMENT: The three "Before v1.43" entries in this changelog
appear to match "BUGTRAQ:20041110 04WebServer Three Vulnerabilities."
The translated wording for each individual one may be marginal, but
when they are taken together, it is much more clear that the vendor is
acknowledging all of the publicly reported vulnerabilities in this
version.


======================================================
Name: CVE-2004-2661
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2661
Acknowledged: yes changelog
Announced: 20040313
Flaw: unk
Reference: CONFIRM:http://www.soft3304.net/04WebServer/Security.html

Soft3304 04WebServer before 1.41 does not properly check file names,
which allows remote attackers to obtain sensitive information (CGI
source code).


Analysis:
ACKNOWLEDGEMENT: An automated translation of the CONFIRM says "The
version which is related ... Before v1.41 ... By the trouble of file
name check, the source code of CGI is indicated under condition ...."

ACCURACY: the announcement date is unknown, but a download of 1.41
shows the most recent file to be Mar 13, 2004, so this was used as the
ANNOUNCE.


======================================================
Name: CVE-2004-2662
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2662
Acknowledged: yes changelog
Announced: 20040313
Flaw: dos-flood
Reference: CONFIRM:http://www.soft3304.net/04WebServer/Security.html

Soft3304 04WebServer before 1.41 allows remote attackers to cause a
denial of service (resource consumption or crash) via certain data
related to OpenSSL, which causes a thread to terminate but continue to
hold resources.


Analysis:
ACKNOWLEDGEMENT: An automated translation of the CONFIRM says "The
version which is related ... Before v1.41 ... With the vulnerability
of OpenSSL, when the data of specification is received, the server
thread forces ends. When the server thread forces ends, because the
resource which that thread has utilized is not released, when it
continues to reecive attack, you use the system resources and exhaust
and there is a possibility the knocking server down."

ACCURACY: the announcement date is unknown, but a download of 1.41
shows the most recent file to be Mar 13, 2004, so this was used as the
ANNOUNCE.


======================================================
Name: CVE-2005-1416
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1416
Acknowledged: yes changelog
Announced: 20050503
Flaw: dot
Reference: MISC:http://osvdb.org/ref/16/16067-04webserver.txt
Reference: CONFIRM:http://www.soft3304.net/04WebServer/Security.html
Reference: FRSIRT:ADV-2005-0448
Reference: URL:http://www.frsirt.com/english/advisories/2005/0448
Reference: OSVDB:16067
Reference: URL:http://www.osvdb.org/16067
Reference: SECUNIA:15230
Reference: URL:http://secunia.com/advisories/15230

Directory traversal vulnerability in 04WebServer 1.81 allows remote
attackers to read files outside of the web root but within the
installation folder.


Analysis:
ACKNOWLEDGEMENT: An automated translation of the CONFIRM says "The
version which is related ... Before v1.81 ... From the document route
the vulnerability which can be accessed the superior file/the folder
...  Depending upon the trouble of request processing, being able to
access the directory with respect to one than the document route ...."


======================================================
Name: CVE-2006-4199
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4199
Acknowledged: yes changelog
Announced: 20060814
Flaw: XSS
Reference: CONFIRM:http://www.soft3304.net/04WebServer/Security.html
Reference: BID:19496
Reference: URL:http://www.securityfocus.com/bid/19496
Reference: SECUNIA:21504
Reference: URL:http://secunia.com/advisories/21504
Reference: XF:04webserver-error-page-xss(28354)
Reference: URL:http://xforce.iss.net/xforce/xfdb/28354

Cross-site scripting (XSS) vulnerability in Soft3304 04WebServer 1.83
and earlier allows remote attackers to inject arbitrary web script or
HTML via the URL, which is not properly sanitized before it is
returned in an error page, a different vulnerability than
CVE-2004-1512.


Analysis:
ACKNOWLEDGEMENT: The original 04WebServer security posting is not in
English; however, a Google translation states: "The vulnerability by
the cross sight script of the error page...By the fact that it works
in URL, there is a possibility of making the dangerous script the user
execute which is accessed."


======================================================
Name: CVE-2006-4200
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4200
Acknowledged: yes changelog
Announced: 20060814
Flaw: unk
Reference: CONFIRM:http://www.soft3304.net/04WebServer/Security.html
Reference: BID:19496
Reference: URL:http://www.securityfocus.com/bid/19496
Reference: SECUNIA:21504
Reference: URL:http://secunia.com/advisories/21504
Reference: XF:04webserver-user-id-bypass(28355)
Reference: URL:http://xforce.iss.net/xforce/xfdb/28355

Unspecified vulnerability in 04WebServer 1.83 and earlier allows
remote attackers to bypass user authentication via unspecified vectors
related to request processing.


Analysis:
ACKNOWLEDGEMENT: The original 04WebServer security posting is not in
English; however, a Google translation states: "The vulnerability
which can evade user identification...Depending upon the trouble of
request processing, being able to evade user identification there is a
possibility of finishing."



From smoore at securityglobal.net  Sun Aug 20 00:45:53 2006
From: smoore at securityglobal.net (Stuart Moore)
Date: Sun, 20 Aug 2006 00:45:53 -0400
Subject: [VIM] SPAW Editor (bid 19603)
Message-ID: <44E7E901.6040207@securityglobal.net>

Hi,

Botan's posting says that 'spaw_dir' is vulnerable to remote file 
inclusion, but ... the supposedly affected scripts include this prior to 
referencing the parameter:

include '../config/spaw_control.config.php';

And, for older version such as 1.0.7 and 1.1, the 
spaw_control.default.config.php (which the readme says to rename to 
spaw_control.config.php) says:

$spaw_dir = '/spaw/';

For version 1.2beta 2, the config says:

$spaw_root = realpath(dirname(__FILE__)."/..");
if (!ereg('/$', $spaw_root))
   $spaw_root = $spaw_root."/";

// directory where spaw files are located
$spaw_dir = str_replace($_spawsrvvars['DOCUMENT_ROOT'],'',$spaw_root);
if (!ereg('^/', $spaw_dir))
   $spaw_dir = "/".$spaw_dir;

So, it appears that the spaw_dir should not be vulnerable to file 
inclusion unless a site is improperly configured.  Right?  Maybe the 
config file renaming is confusing to some admins.

Stuart



From coley at linus.mitre.org  Mon Aug 21 13:19:34 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 21 Aug 2006 13:19:34 -0400 (EDT)
Subject: [VIM] CVE-2006-2490 (Mobotix) vendor ACK
Message-ID: <Pine.GSO.4.51.0608211318310.17478@faron.mitre.org>


---------- Forwarded message ----------
Date: Mon, 21 Aug 2006 17:04:09 +0200
From: Daniel Kabs
To: nvd at nist.gov
Cc: cve at mitre.org
Subject: CVE-2006-2490: Vendor Statement

Hello!

In your vulnerability summary CVE-2006-2490 you report multiple cross-site
scripting (XSS) vulnerabilities in MOBOTIX IP Network Cameras.

I'd like to write an official vendor statement about this CVE entry. I am
a developer at MOBOTIX AG and responsible for fixing the security
issue you report in your advisory.

I'd like to inform you that we have resolved this problem as of
2006-06-27.

MOBOTIX provides new software versions that include a security patch that
prevents cross site scripting flaws. Customers are encouraged to upgrade
to at least software version
- V2.2.3.18 (for camera models M10/D10) and
- V3.0.3.31 (for camera model M12)
or higher (if available). The software is available for download from our
website http://www.mobotix.com/services/software_downloads

Please include this information in your CVE entry. Thank you very much.

Sincerely,
Daniel Kabs
Internet: http://www.mobotix.com/

From coley at mitre.org  Mon Aug 21 13:53:55 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 21 Aug 2006 13:53:55 -0400 (EDT)
Subject: [VIM] CVE-2006-3958 (Taskjitsu) more details
Message-ID: <200608211753.k7LHrtau020070@faron.mitre.org>


The vendor sent us a URL with more details:

  https://www.pkrinternet.com/taskjitsu/task/3477


- Steve

From coley at linus.mitre.org  Tue Aug 22 20:28:17 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 22 Aug 2006 20:28:17 -0400 (EDT)
Subject: [VIM] CVE-2006-2490: Vendor Statement (fwd)
Message-ID: <Pine.GSO.4.51.0608222027570.3500@faron.mitre.org>



---------- Forwarded message ----------
Date: Tue, 22 Aug 2006 11:49:26 +0200
From: Daniel Kabs

Dear Steve,

thanks for forwarding our information. I really appreciate your help and
effort you put into your work.

Unfortunately a typing error has creeped into the text that I've sent to
nvd at nist.gov. In the vendor statement, I erroneously wrote *M12* instead
of the correct *M22* camera model. I kindly have to ask you for a
correction to the vendor statement.

Please see the corrected text as follows:
---------- Vendor Statement -----------------
MOBOTIX provides new software versions that include a security patch that
prevents cross site scripting flaws. Customers are encouraged to upgrade
to at least software version
- V2.2.3.18 (for camera models M10/D10) and
- V3.0.3.31 (for camera model M22)
or higher (if available). The software is available for download from our
website
  http://www.mobotix.com/services/software_downloads
---------------------------------------------


- Steve

From coley at linus.mitre.org  Wed Aug 23 13:57:23 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 23 Aug 2006 13:57:23 -0400 (EDT)
Subject: [VIM] Vendor ACK - CVE-2006-3038 (fwd)
Message-ID: <Pine.GSO.4.51.0608231357000.24690@faron.mitre.org>



---------- Forwarded message ----------
Date: Wed, 23 Aug 2006 10:55:08 -0700
From: The Cute Group
To: cve at mitre.org
Subject: CVE-2006-3038

Hello,



RE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3038



All issues concerning this script and others at cescripts.com have been
addressed and fixed. Files have been re-distributed to customers. A patch is
available for download for members. All current versions have been updated.


Please update/delete your listing.



 <http://www.securityfocus.com/archive/1/436805>
http://www.securityfocus.com/archive/1/436805





Thanks



Support:  <http://www.thecutegroup.com/support/>
http://www.thecutegroup.com/support/ <http://www.thecutegroup.com/support/>

From coley at mitre.org  Wed Aug 23 19:53:26 2006
From: coley at mitre.org (Steven M. Christey)
Date: Wed, 23 Aug 2006 19:53:26 -0400 (EDT)
Subject: [VIM] bad report for EstateAgent?
Message-ID: <200608232353.k7NNrQiQ008277@faron.mitre.org>


BUGTRAQ:20060820 Mambo Component - EstateAgent Remote File Inclusion
URL:http://www.securityfocus.com/archive/1/archive/1/443911/100/0/threaded


Outlaw from Aria Security includes the following source code extract:

># Don't allow direct linking
>
>defined( '_VALID_MOS' ) or die( 'Direct Access to this location is not
>allowed.' );
>
>require_once( $mainframe->getPath( 'front_html' ) );
>
>require($mosConfig_absolute_path."/administrator/components/com_estateag
>ent/configuration.php");


Um - isn't this the recommended fix that Mambo told all component
developers to use?  I don't have that URL on me at the moment.

Anyway, I can't get any source code to check - I couldn't find it on
the site after a cursory look - but I'm not sure this report is
correct, based on the above.

- Steve

From jericho at attrition.org  Wed Aug 23 20:04:54 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 23 Aug 2006 20:04:54 -0400 (EDT)
Subject: [VIM] bad report for EstateAgent?
In-Reply-To: <200608232353.k7NNrQiQ008277@faron.mitre.org>
References: <200608232353.k7NNrQiQ008277@faron.mitre.org>
Message-ID: <Pine.LNX.4.64.0608232003560.26627@forced.attrition.org>


: BUGTRAQ:20060820 Mambo Component - EstateAgent Remote File Inclusion
: URL:http://www.securityfocus.com/archive/1/archive/1/443911/100/0/threaded
: 
: Outlaw from Aria Security includes the following source code extract:
: 
: ># Don't allow direct linking
: >
: >defined( '_VALID_MOS' ) or die( 'Direct Access to this location is not
: >allowed.' );
: >
: >require_once( $mainframe->getPath( 'front_html' ) );
: >
: >require($mosConfig_absolute_path."/administrator/components/com_estateag
: >ent/configuration.php");
: 
: 
: Um - isn't this the recommended fix that Mambo told all component
: developers to use?  I don't have that URL on me at the moment.
: 
: Anyway, I can't get any source code to check - I couldn't find it on
: the site after a cursory look - but I'm not sure this report is
: correct, based on the above.

Without looking, there is a high probability. Check out the recent rash 
of Mambo/Joomla related vulns:

http://osvdb.org/blog/?p=132

Specifically, several from this person were found to be inaccurate, so 
seeing this turn up wrong wouldn't be a shock.

From coley at mitre.org  Wed Aug 23 20:32:57 2006
From: coley at mitre.org (Steven M. Christey)
Date: Wed, 23 Aug 2006 20:32:57 -0400 (EDT)
Subject: [VIM] source VERIFY of Shadows Rising RPG file include
Message-ID: <200608240032.k7O0Wv2c011013@faron.mitre.org>


MISC:http://www.milw0rm.com/exploits/2229

I verified this issue by source inspection.

The first PHP statement in each of the four referenced files has
something like the following:

  require_once("$CONFIG[gameroot]/qlib/thirdparty/kses/kses.php");

(this one was from core/includes/security.inc.php)

- Steve

From jericho at attrition.org  Thu Aug 24 05:42:11 2006
From: jericho at attrition.org (security curmudgeon)
Date: Thu, 24 Aug 2006 05:42:11 -0400 (EDT)
Subject: [VIM] vendor ack for "mambo-phphop Product Scroller Module R.F.I"
Message-ID: <Pine.LNX.4.64.0608240537430.26627@forced.attrition.org>


Disclosure:
http://archives.neohapsis.com/archives/bugtraq/2006-08/0363.html

Dispute:
http://archives.neohapsis.com/archives/bugtraq/2006-08/0436.html

Vendor:
http://www.mambo-phpshop.net/
which became
http://virtuemart.net/

Confirm:
http://virtuemart.net/index.php?option=com_content&task=view&id=209&Itemid=57

  mambo-phpShop Security Alert
Monday, 21 August 2006

This is a security alert for all mambo-phpShop users. If you are still 
using mambo-phpShop at an older version than "mambo-phpShop 1.2-stable", 
your webshop is at a security risk.

Versions affected: mambo-phpShop 1.1 - 1.2 RC2.
Versions NOT affected: mambo-phpShop 1.2 stable (all patch levels).

Please note that VirtueMart is not affected by this security issue.

What's my mambo-phpShop version?

You can find out which version of mambo-phpShop you have installed by 
looking at the file /administrator/components/com_phpshop/version.php of 
your Mambo/Joomla installation.


Am I at risk?

The security hole  can only be exploited if PHP on your server is running 
with "register_globals=on". You can check this setting in Mambo by either 
clicking on "System" => "Help" => "System Info", or "System" => "System 
Info".

[..]

From jericho at attrition.org  Thu Aug 24 05:50:56 2006
From: jericho at attrition.org (security curmudgeon)
Date: Thu, 24 Aug 2006 05:50:56 -0400 (EDT)
Subject: [VIM] vendor ack for "mambo-phphop Product Scroller Module
	R.F.I"
In-Reply-To: <Pine.LNX.4.64.0608240537430.26627@forced.attrition.org>
References: <Pine.LNX.4.64.0608240537430.26627@forced.attrition.org>
Message-ID: <Pine.LNX.4.64.0608240546000.26627@forced.attrition.org>


: Disclosure:
: http://archives.neohapsis.com/archives/bugtraq/2006-08/0363.html
: 
: Dispute:
: http://archives.neohapsis.com/archives/bugtraq/2006-08/0436.html
: 
: Vendor:
: http://www.mambo-phpshop.net/
: which became
: http://virtuemart.net/
: 
: Confirm:
: http://virtuemart.net/index.php?option=com_content&task=view&id=209&Itemid=57

Maybe I jumped the gun here =)

First, looking at the files listed in the disclosure vs the files 
available in the full VirtueMart package:
http://forge.joomla.org/sf/frs/do/viewRelease/projects.virtuemart/frs.virtuemart.virtuemart_1_0_6

We see the files from the advisory in the various sub packages. So looks 
like we have the product in question. Now..

:  mambo-phpShop Security Alert
: Monday, 21 August 2006
: 
: This is a security alert for all mambo-phpShop users. If you are still using
: mambo-phpShop at an older version than "mambo-phpShop 1.2-stable", your
: webshop is at a security risk.

: Please note that VirtueMart is not affected by this security issue.

and farther down that i didnt quote originally:

  There's an easy fix for this problem:
 
  Find the file 
  /administrator/components/com_phpshop/toolbar.phpshop.html.php and add

  defined( '_VALID_MOS' ) or die( 'Direct Access to this location is not 
  allowed.' );

and throw in this part:

  This security issue is was first discovered by mambo-phpShop users on 
  August 19 / 20 and is still not made public, so you have still time to 
  fix your installation.

so it appears this is a seperate issue completely

From jericho at attrition.org  Thu Aug 24 06:11:26 2006
From: jericho at attrition.org (security curmudgeon)
Date: Thu, 24 Aug 2006 06:11:26 -0400 (EDT)
Subject: [VIM] vendor ack for "mambo-phphop Product Scroller Module
	R.F.I"
In-Reply-To: <Pine.LNX.4.64.0608240546000.26627@forced.attrition.org>
References: <Pine.LNX.4.64.0608240537430.26627@forced.attrition.org>
	<Pine.LNX.4.64.0608240546000.26627@forced.attrition.org>
Message-ID: <Pine.LNX.4.64.0608240559410.26627@forced.attrition.org>


Man i'm on a roll. 

: First, looking at the files listed in the disclosure vs the files 
: available in the full VirtueMart package:
: http://forge.joomla.org/sf/frs/do/viewRelease/projects.virtuemart/frs.virtuemart.virtuemart_1_0_6
: 
: We see the files from the advisory in the various sub packages. So looks 
: like we have the product in question. Now..

Most are there, but not all. So maybe this affects an older version of 
mambo-phpShop and the derived VirtueMart, but not for each file. First the 
list of files declared vulnerable, second the subpackage in VirtueMart 
that contains it.

    mod_phpshop.php			[4]
    mod_phpshop_allinone.php		[3]
    mod_phpshop_cart.php		[5]
    mod_phpshop_featureprod.php		[2]
    mod_phpshop_latestprod.php		[1]
    mod_product_categories.php		mod_product_categories_1.0.6.tar.gz
    mod_productscroller.php		mod_productscroller_1.0.6.tar.gz
    mosproductsnap.php			modproductsnap_1.0.6.tar.gz


[1] mod_virtuemart_latestprod.php in mod_virtuemart_latestprod_1.0.6.tar.gz
[2] mod_virtuemart_featureprod.php in mod_virtuemart_featureprod_1.0.6.tar.gz
[3] mod_virtuemart_allinone.php in mod_virtuemart_allinone_1.0.6.tar.gz
[4] mod_virtuemart.php in mod_virtuemart_1.0.6.tar.gz
[5] mod_virtuemart_cart.php in mod_virtuemart_cart_1.0.6.tar.gz


So the first three files I looked at were in there verbatim and I made the 
assumption it was the same package. In reality, 3 of 8 were in there, but 
everything suggests the derived product may be vulnerable and even have 
more components that could be affected.

From theall at tenablesecurity.com  Thu Aug 24 06:47:36 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Thu, 24 Aug 2006 06:47:36 -0400
Subject: [VIM] vendor ack for "mambo-phphop Product Scroller
	Module	R.F.I"
In-Reply-To: <Pine.LNX.4.64.0608240546000.26627@forced.attrition.org>
References: <Pine.LNX.4.64.0608240537430.26627@forced.attrition.org>
	<Pine.LNX.4.64.0608240546000.26627@forced.attrition.org>
Message-ID: <44ED83C8.3020903@tenablesecurity.com>

security curmudgeon wrote:

> so it appears this is a seperate issue completely

Probably. :-(

I did find a copy of  mambo-phpShop 1.2 RC2b here:

 
http://82.165.28.69/mportal/uploadfiles/451/mambo-phpShop_1.2_RC2b_COMPLETE__PACKAGE.zip

[Note: not the author's site.] After installing it, I didn't see any of 
the files mentioned in the original advisory, but in 
administrator/components/com_phpshop/toolbar.phpshop.html.php you have 
the following code (comments removed) at the start:

   define( '_PSHOP_ADMIN', '1' );
   if (!file_exists( 
$mosConfig_absolute_path.'/administrator/components/com_phpshop/install.php' 
)) {
     require_once( 
$mosConfig_absolute_path."/components/com_phpshop/phpshop_parser.php");
   }

which appears to be what the author was addressing in his advisory on 
August 21.


George
-- 
theall at tenablesecurity.com

From f.riphagen at nsec.nl  Thu Aug 24 12:54:19 2006
From: f.riphagen at nsec.nl (Ferdy Riphagen)
Date: Thu, 24 Aug 2006 18:54:19 +0200
Subject: [VIM] bad report for EstateAgent?
In-Reply-To: <Pine.LNX.4.64.0608232003560.26627@forced.attrition.org>
References: <200608232353.k7NNrQiQ008277@faron.mitre.org>
	<Pine.LNX.4.64.0608232003560.26627@forced.attrition.org>
Message-ID: <44EDD9BB.9010900@nsec.nl>

security curmudgeon wrote:
> : BUGTRAQ:20060820 Mambo Component - EstateAgent Remote File Inclusion
> : URL:http://www.securityfocus.com/archive/1/archive/1/443911/100/0/threaded
>
> http://osvdb.org/blog/?p=132
>
>   
Another one (almost the same) from the osvdb blog list
http://seclists.org/bugtraq/2006/Aug/0376.html

I Could only find version 1.0 dated 22-04-2005 (version info would be nice)
http://mamboxchange.com/frs/?group_id=704&release_id=3974

Source is:

*snip*

defined( '_VALID_MOS' ) or die( 'Direct Access to this location is not 
allowed.' );

global $my, $mosConfig_live_site, $mosConfig_lang;

if 
(file_exists($mosConfig_absolute_path.'/components/com_contentpublisher/languages/'.$mosConfig_lang.'.php')) 
{
    
include($mosConfig_absolute_path.'/components/com_contentpublisher/languages/'.$mosConfig_lang.'.php');
} else {
    
include($mosConfig_absolute_path.'/components/com_contentpublisher/languages/english.php');
}

*snip*

-- Ferdy






From coley at mitre.org  Thu Aug 24 16:01:26 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 24 Aug 2006 16:01:26 -0400 (EDT)
Subject: [VIM] CVE-2006-4264 (mtg_myhomepage) - dispute followup
Message-ID: <200608242001.k7OK1QdQ003127@faron.mitre.org>


I "conditionally' concur with the dispute to CVE-2006-4264, originally
announced by Outlaw of Aria.  Source code inspection agrees with the
Bugtraq post by Carsten Eilers.  Specifically, the
$mosConfig_absolute_path is used in the install.lmtg_homepage.php
script, but it's part of a function definition, i.e.:

  function com_install() 
  {
  global $database;
  global $mosConfig_dbprefix;
  global $mosConfig_absolute_path;

  if (file_exists($mosConfig_absolute_path.'/administrator/components/com_lmtg_myhomepage/language/'.$mosConfig_lang.'.php')) 
  	include_once ($mosConfig_absolute_path.'/administrator/components/com_lmtg_myhomepage/language/'.$mosConfig_lang.'.php');
  else
  	include_once ($mosConfig_absolute_path.'/administrator/components/com_lmtg_myhomepage/language/english.php');


Based on a grep, com_install is not called *anywhere* in the PHP.

Why is my concurrence conditional?  Since com_install isn't directly
called anywhere, *how* is it getting called?  I looked for "$$" and
"${" constructs (not an exhaustive list of possibilities), since maybe
the function name is being stored in a variable or something, but no
go.

So, maybe com_install() is part of the whole Mambo/Joomla component
architecture or something, and if so, it's probably being called
outside of the source code scope of com_lmtg_myhomepage - in which
case I can't be SURE that there's not an issue.

I definitely concur with Carsten's dispute of the second attack on
lmtg_myhomepage.php, since the first line of the script is:

  defined( '_VALID_MOS' ) or die( 'Direct Access to this location is not allowed.' );


- Steve

From coley at mitre.org  Fri Aug 25 19:45:12 2006
From: coley at mitre.org (Steven M. Christey)
Date: Fri, 25 Aug 2006 19:45:12 -0400 (EDT)
Subject: [VIM] Source VERIFY of pSlash 0.7 file include
Message-ID: <200608252345.k7PNjC5n002330@faron.mitre.org>


http://www.milw0rm.com/exploits/2249

I downloaded 0.70 from SourceForge.  It's dated June 2001, by the way.

Anyway, the first PHP statements in the file
modules/visitors2/include/config.inc.php are:

    // language
    if (!$ignore_messages)
    {
        include($lvc_include_dir.'lang/english.inc.php');
    }

    // database abstraction
    require($lvc_include_dir.'db/db_mysql.inc.php');


so the issue is legit.

- Steve

From coley at mitre.org  Mon Aug 28 17:21:00 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 28 Aug 2006 17:21:00 -0400 (EDT)
Subject: [VIM] Provable vendor ACK for CVE-2006-4204 (PHProjekt)
Message-ID: <200608282121.k7SLL0mT012625@faron.mitre.org>


http://phprojekt.com/modules.php?op=modload&name=News&file=article&sid=257&mode=thread&order=0

ACKNOWLEDGEMENT: vendor news item on 20060816 titled "Security fix for
library scripts -> please update to PHProjekt 5.1.1" links to
SECUNIA:21526.


- Steve

From coley at mitre.org  Mon Aug 28 17:28:54 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 28 Aug 2006 17:28:54 -0400 (EDT)
Subject: [VIM] CVE-2006-4159 (Chaussette) provenance for
	Event_for_month_per_day.php
Message-ID: <200608282128.k7SLSsoM012905@faron.mitre.org>


Just in case CVE wasn't the only one to miss this, we had originally
assigned a separate CVE for the Event_for_month_per_day.php. vector,
treating it as an unknown-provenance issue.  What happened was, during
analysis of CVE-2006-4159, the analyst must have focused on the
exploit section, which did not list this program; however, the
"vulnerable scripts" section *did* mention this program.

CVE-2006-4159 has since been updated, and the now-duplicate
CVE-2006-4216 has been deleted.

- Steve

From coley at mitre.org  Mon Aug 28 18:33:56 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 28 Aug 2006 18:33:56 -0400 (EDT)
Subject: [VIM] Jupiter CMS file include - CVE dispute
Message-ID: <200608282233.k7SMXuOj015206@faron.mitre.org>


Researcher: "D3nGeR"

Ref: BUGTRAQ:20060825 Jupiter CMS 1.1.5 index.php Remote File Include
http://www.securityfocus.com/archive/1/archive/1/444421/100/0/threaded


D3nGeR includes the following code snippet:

  $template = "default";
  include "templates/$template/id.php";

Looks like the good ol' grep-and-gripe.

I downloaded the code, and while $template is used heavily, it's set
to constant values or (probably) admin-controlled configuration
values.

So, CVE disputes this.

- Steve

From heinbockel at mitre.org  Tue Aug 29 14:07:16 2006
From: heinbockel at mitre.org (Heinbockel, Bill)
Date: Tue, 29 Aug 2006 14:07:16 -0400
Subject: [VIM] Jetbox CMS file include - CVE dispute
Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC01201118@IMCSRV5.MITRE.ORG>

Since this has appeared on BUGTRAQ from two different researchers
over the span of the past couple of days:

Researcher: D3nGeR
BUGTRAQ:20060825 Jetbox CMS search_function.php Remote File
http://www.securityfocus.com/archive/1/archive/1/444422/100/0/threaded

Researcher: CarcaBot
BUGTRAQ:20060828 JetBox cms (search_function.php) Remote File Include
http://www.securityfocus.com/archive/1/archive/1/444527/100/0/threaded

Source code analysis of includes/phpdig/libs/search_function.php in 
Jetbox CMS 2.1.SR1 shows the line(s) being referenced
> Line 423:   <?php include
$relative_script_path.'/libs/htmlheader.php' ?>
> Line 426:   <?php include $relative_script_path.'/libs/htmlmetas.php'
?>

However, these lines are included within the following function,
declared
at the top of the file: (Lines 18-21)
>	function phpdigSearch($id_connect, $query_string,
$option='start', $refine=0,
>		$refine_url='', $lim_start=0, $limite=10, $browse=0,
>		$site=0, $path='', $relative_script_path = '.',
$template='',
>		$template_links='')


This function is called from line 46 in search.php, with the
$relative_script_path
variable, which is statically declared on line 26:
>  $relative_script_path='includes/phpdig';

We see no way to exploit this, so CVE is marking as DISPUTED.


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 Aug 29 16:09:59 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 29 Aug 2006 16:09:59 -0400 (EDT)
Subject: [VIM] Vendor ACK for CVE-2006-3003 (Easy Ad-Manager)
Message-ID: <Pine.GSO.4.51.0608291609010.26107@faron.mitre.org>


FYI.  Sorry Brian, that's all the info there is.

- Steve

---------- Forwarded message ----------
Date: Tue, 29 Aug 2006 23:21:01 +0500
From: scriptsez.net
To: cve at mitre.org
Subject: BUGTRAQ:20060608 Easy Ad-Manager

Hi,
Security issue in easy ad-manager has been resolved.
it should be removed from your listings now.


From coley at linus.mitre.org  Tue Aug 29 16:20:43 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 29 Aug 2006 16:20:43 -0400 (EDT)
Subject: [VIM] Sendmail vendor dispute - CVE-2006-4434 (fwd)
Message-ID: <Pine.GSO.4.51.0608291617270.26107@faron.mitre.org>


FYI, forwarded with approval.  Given this info, I'd say that CVE concurs -
at least until the researchers figure out how to reliably exploit
"use-after-free" bugs (which BTW is going to be CVE/CWE are going to call
these bugs).

I gave the standard response to the criticism in the last paragraph, with
the observation that we vdb's had reported it because OpenBSD did.

- Steve

---------- Forwarded message ----------
Date: Tue, 29 Aug 2006 10:24:58 -0700
From: Claus Assmann
To: cve at mitre.org
Subject: CVE-2006-4434

Is there anything beyond a crash that is referenced in CVE-2006-4434?
The only denial of service that is possible here is to fill up the
disk with core dumps if the OS actually generates different core
dumps (which is unlikely, as sendmail is by default set-group-ID
and hence most OS do not generate a core unless explicitly configured).

Note: the bug is in the shutdown code (finis()) which leads directly
to exit(3), i.e., the process would terminate anyway, no mail delivery
or receiption is affected. If you have other information, then please
let me know.

Please note that I asked OpenBSD about this and the answer from
Theo de Raadt was:
"The problem is tiny."
"it is TOTALLY irrelevant"

The problem should not have been mentioned on their website.  Please
review the report and discard it or change it as explained above.

BTW: it would be nice if your process of creating a candidate for
inclusion in the CVE list makes sure that the security contact for
the software is informed, so we don't have to rely on some 3rd
party to hear about this "DoS" for the software that we maintain.
http://www.sendmail.org/security/

Regards,

Claus Assmann
(current maintainer of sendmail)

From coley at mitre.org  Tue Aug 29 18:23:32 2006
From: coley at mitre.org (Steven M. Christey)
Date: Tue, 29 Aug 2006 18:23:32 -0400 (EDT)
Subject: [VIM] CuteNews 1.3.* Remote File Include Vulnerability
Message-ID: <200608292223.k7TMNWqu009756@faron.mitre.org>


I was going to send this to Bugtraq, but does anybody else have ideas?

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


I can't see where the vulnerability is.

At the very least, the source code being referenced does not have the
problem, although the real problem might be somewhere else.

from search.php, this source code was quoted:

>$cutepath = __FILE__;

__FILE__ is a constant, set to the script's pathname.  It does not
include the query string.  So, it's not controlled by the attacker at
all.

>$cutepath = preg_replace( "'\\\search\.php'", "", $cutepath);
>$cutepath = preg_replace( "'/search\.php'", "", $cutepath);

The preg_replace() use constant values, just to strip the filename
from the end, to get the base pathname.

>require_once("$cutepath/inc/functions.inc.php");

Since $cutepath is a constant, uncontrolled value, this statement will
only look in the expected place for inc/functions.inc.php - so the
vulnerability can't be here.

>--------------PoC/Exploit----------------------
>
>search.php?cutepath=http://host/evil.txt?
>

So - given the above situation, how could this attack work?

Later in search.php, there are other calls to file() and and require()
that use $cutepath, so maybe $cutepath got overwritten somewhere.

Well, let's look at inc/functions.inc.php, since that's what's being
required:

>// bad practice, i know
>[snip]
>if ($_GET)              {extract($_GET, EXTR_SKIP);}

OK - so, maybe the "cutepath" parameter would be overwritten.

But - the EXTR_SKIP says "If there is a collision, don't overwrite the
existing variable."  So, since $cutepath already exists, it shouldn't
be overwritten... right?  (I tested this on my local PHP 4.x, and
EXTR_SKIP is honored even when it's in an include file and the
variable was defined in the original file).


- Steve

From smoore at securityglobal.net  Tue Aug 29 18:34:57 2006
From: smoore at securityglobal.net (Stuart Moore)
Date: Tue, 29 Aug 2006 18:34:57 -0400
Subject: [VIM] my dispute: Submit ( ToendaCMS<= ( Remote File Include
 Vulnerabilities )
Message-ID: <44F4C111.7020109@securityglobal.net>

VIM,

In the bugtraq message "Submit ( ToendaCMS<= ( Remote File Include 
Vulnerabilities )" by "h4ck3riran at yahoo.com", the report claims several 
include file issues.

One is:

 > < #CodE:  include($site.'.php');
 >
 >
 > < # Expolit :
 >
 > < # http://Www.Site.coM/[path]/setup/index.php?site=Sh3ll


But, in '/setup/index.php' the code actually says:

 > 		switch($site){
 > 			case 'language':
 > 				include($site.'.php');
 > 				break;
 > 			
 > 			default:
 > 				include('inc/'.$site.'.php');
 > 				break;
 > 		}


So, yes the code includes [$site].php, but only if case 'language'.  In 
any other situation, it includes 'inc/[$site].php'.  So, no it can't be 
exploited to point to a remote URL.  But, interestingly, this appears as 
if it can be used to traverse the directory and include other files with 
a ".php" extension on the local system.  This being a setup script, I 
don't know if you'd leave it up on an active system.


The report also claims:

 > < # CodE :   require($tcms_administer_site.'/tcms_global/database.php')
 >
 >
 > < #Expolit :
 >
 > < #http://Www.Site.coM/[path]/media.php?tcms_administer_site=Sh3ll

but the '/media.php' code says:

 > $tcms_administer_site = 'data';
 > require($tcms_administer_site.'/tcms_global/database.php');


The other claims are relate to 'tcms_administer_site' (which, for 
'index.php', was debunked by Carsten Eilers on Aug 24th).  I didn't 
check all of these out, but if I had to guess ...

Stuart



From smoore at securityglobal.net  Tue Aug 29 19:04:03 2006
From: smoore at securityglobal.net (Stuart Moore)
Date: Tue, 29 Aug 2006 19:04:03 -0400
Subject: [VIM] my dispute: Submit ( b2evolution<= 1.8 Remote File Include
 Vulnerabilities )
Message-ID: <44F4C7E3.4070903@securityglobal.net>

The bugtraq message "Submit ( b2evolution<= 1.8 Remote File Include 
Vulnerabilities )" by "h4ck3riran at yahoo.com" makes invalid claims.

All of the mentioned files include this statement up front:

   require_once dirname(__FILE__).'/conf/_config.php';

The _config.php file in turn includes this:

   require_once  dirname(__FILE__).'/_advanced.php';

The _advanced.php file specifies constant values and/or local paths for 
the underlying components of inc_path and misc_inc_path.

Stuart


From coley at linus.mitre.org  Tue Aug 29 19:57:37 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 29 Aug 2006 19:57:37 -0400 (EDT)
Subject: [VIM] Jetbox CMS file include - CVE dispute
In-Reply-To: <224FBC6B814DBD4E9B9E293BE33A10DC01201118@IMCSRV5.MITRE.ORG>
References: <224FBC6B814DBD4E9B9E293BE33A10DC01201118@IMCSRV5.MITRE.ORG>
Message-ID: <Pine.GSO.4.51.0608291936140.26107@faron.mitre.org>


I have to put up a retraction - the issue looks real.

Bill said:

> > Line 423:   <?php include
> $relative_script_path.'/libs/htmlheader.php' ?>
> > Line 426:   <?php include $relative_script_path.'/libs/htmlmetas.php'
> ?>
>
> However, these lines are included within the following function,
> declared
> at the top of the file: (Lines 18-21)


FYI, someone else disputed this, too.

I don't know how I wound up down this rabbit hole after Bill analyzed it,
but I think we missed something.

1) if there's a "<?php" in the function definition, then that means there
are nested <?php tags - not sure if that's even allowed.  My PHP 4.x gives
a parse error.

2) So - maybe, despite appearances, this is being done *outside* the
function definition, in which case the <?php> is executed as soon as it's
parsed, which means there's a vuln.

  And in fact, we have this:

    else {
    ?>
    <?php include $relative_script_path.'/libs/htmlheader.php' ?>

So, I think that's what's going on.

3) Note - the path to the search_function.php suggested a third party
   product, phpdig.  I downloaded the source code for phpdig, and 1.8.8
   has the "search_function.php" file, and the most recent version renamed
   this to "search_functions.php".


- Steve

From coley at linus.mitre.org  Tue Aug 29 20:03:48 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 29 Aug 2006 20:03:48 -0400 (EDT)
Subject: [VIM] Jetbox CMS file include - CVE dispute
In-Reply-To: <Pine.GSO.4.51.0608291936140.26107@faron.mitre.org>
References: <224FBC6B814DBD4E9B9E293BE33A10DC01201118@IMCSRV5.MITRE.ORG>
	<Pine.GSO.4.51.0608291936140.26107@faron.mitre.org>
Message-ID: <Pine.GSO.4.51.0608292002220.26107@faron.mitre.org>


On Tue, 29 Aug 2006, Steven M. Christey wrote:

>   And in fact, we have this:
>
>     else {
>     ?>
>     <?php include $relative_script_path.'/libs/htmlheader.php' ?>

Sorry, I should have been more clear.  Notice the closing "?>" after the
else.  Why the developer did this when they just open a new "<?php" tag is
unknown, but the key is the "?>"

- Steve

From smoore at securityglobal.net  Wed Aug 30 01:42:55 2006
From: smoore at securityglobal.net (Stuart Moore)
Date: Wed, 30 Aug 2006 01:42:55 -0400
Subject: [VIM] Jetbox CMS file include - CVE dispute
In-Reply-To: <Pine.GSO.4.51.0608292002220.26107@faron.mitre.org>
References: <224FBC6B814DBD4E9B9E293BE33A10DC01201118@IMCSRV5.MITRE.ORG>	<Pine.GSO.4.51.0608291936140.26107@faron.mitre.org>
	<Pine.GSO.4.51.0608292002220.26107@faron.mitre.org>
Message-ID: <44F5255F.60506@securityglobal.net>

Steve,

I'm confused.  The PHP tags are awkward, but not nested.  It seems that 
all of the include statements are fully within the phpdigSearch() 
function, but the function is not actually called within that file, and 
so it cannot be exploited.  The function *is* called from search.php 
(and that is the only calling script), but the $relative_script_path 
parameter is defined right before the call.

Stuart


Steven M. Christey wrote:
> On Tue, 29 Aug 2006, Steven M. Christey wrote:
> 
>>   And in fact, we have this:
>>
>>     else {
>>     ?>
>>     <?php include $relative_script_path.'/libs/htmlheader.php' ?>
> 
> Sorry, I should have been more clear.  Notice the closing "?>" after the
> else.  Why the developer did this when they just open a new "<?php" tag is
> unknown, but the key is the "?>"
> 
> - Steve
> 

-- 
Stuart Moore
SecurityTracker.com
SecurityGlobal.net LLC
smoore at securityglobal.net
+1 301 495 5930 voice
+1 413 691 4346 fax




From heinbockel at mitre.org  Wed Aug 30 08:50:55 2006
From: heinbockel at mitre.org (Heinbockel, Bill)
Date: Wed, 30 Aug 2006 08:50:55 -0400
Subject: [VIM] Jetbox CMS file include - CVE dispute
In-Reply-To: <44F5255F.60506@securityglobal.net>
Message-ID: <224FBC6B814DBD4E9B9E293BE33A10DC0120122C@IMCSRV5.MITRE.ORG>



>-----Original Message-----
>From: vim-bounces at attrition.org 
>[mailto:vim-bounces at attrition.org] On Behalf Of Stuart Moore
>Sent: Mittwoch, 30. August 2006 01:43
>To: Vulnerability Information Managers
>Subject: Re: [VIM] Jetbox CMS file include - CVE dispute
>
>Steve,
>
>I'm confused.  The PHP tags are awkward, but not nested.  It 
>seems that 
>all of the include statements are fully within the phpdigSearch() 
>function, but the function is not actually called within that 
>file, and 
>so it cannot be exploited.  The function *is* called from search.php 
>(and that is the only calling script), but the $relative_script_path 
>parameter is defined right before the call.
>
>Stuart
>


Yes, this is what I saw... PHP will accept some seemingly weird stuff.
In this case the code was similar to:

<?php function foo($relative_script_path='.') { ?>
... some HTML and php ...
<?php include $relative_script_path/file.php ?>
... some more HTML ...
<?php }  // <-- end of function foo() ?>

I think that Steve missed this fact, especially not evident since 
the "function" is 400+ lines long and the include is burried in the 
center of it all.

BTW, this is CVE-2006-4422.

From coley at linus.mitre.org  Wed Aug 30 18:46:51 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 30 Aug 2006 18:46:51 -0400 (EDT)
Subject: [VIM] Jetbox CMS file include - CVE dispute
In-Reply-To: <44F5255F.60506@securityglobal.net>
References: <224FBC6B814DBD4E9B9E293BE33A10DC01201118@IMCSRV5.MITRE.ORG>
	<Pine.GSO.4.51.0608291936140.26107@faron.mitre.org>
	<Pine.GSO.4.51.0608292002220.26107@faron.mitre.org>
	<44F5255F.60506@securityglobal.net>
Message-ID: <Pine.GSO.4.51.0608301809440.26107@faron.mitre.org>


On Wed, 30 Aug 2006, Stuart Moore wrote:

> I'm confused.  The PHP tags are awkward, but not nested.

Yes.  My mention of nesting is probably a hold-over from the early stages
when I was confused about why the include started with a "<?php" when I
thought it was already in an open "?php".

> It seems that all of the include statements are fully within the
> phpdigSearch()  function, but the function is not actually called within
> that file

OK, now I see this.  What confused me was, the function definition was
split across multiple "php" tags, with the HTML interspersed throughout
even the function definition.  The length of the function also made things
more difficult.

- Steve

From jericho at attrition.org  Wed Aug 30 22:48:53 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 30 Aug 2006 22:48:53 -0400 (EDT)
Subject: [VIM] 22068: Speartek Search Module XSS  (fwd)
Message-ID: <Pine.LNX.4.64.0608302248420.17495@forced.attrition.org>



---------- Forwarded message ----------
From: Danny DuVal
To: moderators at osvdb.org
Date: Wed, 30 Aug 2006 16:57:23 -0400
Reply-To: moderators at osvdb.org
Subject: [OSVDB Mods] [Change Request] 22068: Speartek Search Module XSS

To whom it may concern:

    Regarding http://www.osvdb.org/22068, we are in the process of addressing 
this and closing the hole that is claimed.  While XSS can be executed on 
certain things suck as search pages, things such as login scripts are not 
susceptible to XSS injections.  Even though cookies don't store any user 
pertinent information we do desire to not have links such as the one above 
appear immediately after our search results.
   If someone could connect me with someone I could coordinate with once a 
working solution is up and running so that a solution can be verified I would 
very much appreciate it.

Thank you,
Danny DuVal
Application Developer
Speartek, Inc

From jericho at attrition.org  Thu Aug 31 05:54:20 2006
From: jericho at attrition.org (security curmudgeon)
Date: Thu, 31 Aug 2006 05:54:20 -0400 (EDT)
Subject: [VIM] Revisiting The Past
In-Reply-To: <Pine.GSO.4.51.0608091611030.3042@faron.mitre.org>
References: <44D9F702.7070801@tenablesecurity.com>
	<Pine.GSO.4.51.0608091611030.3042@faron.mitre.org>
Message-ID: <Pine.LNX.4.64.0608310553150.3842@forced.attrition.org>


: My gut reaction is that this was a dupe/rediscovery that wasn't caught 
: due to different spellings of "ProductCart" and "Product Cart" (though 
: we should have caught it on the script or parameter name...)  These 
: days, I would update the original CVE to mention the new version that is 
: also affected.
: 
: I hate duplicates due to alternate spellings :( In CVE, we don't have a 
: normalized vendor or product name field, which might make this issue 
: worse - or do other DBs have the same problem?

Belated reply but, OSVDB ran into the same thing. 17329 and 18508 are the 
same issue, but due to the space in the vendor name it wasn't caught. In 
my attempts to refine searches, I'll use "ProductCart" or "Product Cart" 
(in this example obviously), which would exclude each other if I specify 
'exact phrase'. 

From jericho at attrition.org  Thu Aug 31 06:06:56 2006
From: jericho at attrition.org (security curmudgeon)
Date: Thu, 31 Aug 2006 06:06:56 -0400 (EDT)
Subject: [VIM] SUNALERT:102554 "drain_squeue" is probably really
	squeue_drain
In-Reply-To: <200608142035.k7EKZbJb011505@faron.mitre.org>
References: <200608142035.k7EKZbJb011505@faron.mitre.org>
Message-ID: <Pine.LNX.4.64.0608310606060.3842@forced.attrition.org>


: An alert CVE analyst spotted this...

Very alert..

:   ACCURACY: The text of the advisory says "drain_squeue" but the stack
:   trace says "<trap>ip:squeue_drain+0x114." It seems likely that all
:   instances of drain_squeue are wrong. Running nm on
:   /kernel/strmod/sparcv9/ip on a Solaris 10 system locates an
:   squeue_drain function but no drain_squeue function.

Given the Sun advisory specifically says 'drain_squeue'.

Outstanding observation!

From jericho at attrition.org  Thu Aug 31 08:25:46 2006
From: jericho at attrition.org (security curmudgeon)
Date: Thu, 31 Aug 2006 08:25:46 -0400 (EDT)
Subject: [VIM] Sendmail vendor dispute - CVE-2006-4434 (fwd)
In-Reply-To: <Pine.GSO.4.51.0608291617270.26107@faron.mitre.org>
References: <Pine.GSO.4.51.0608291617270.26107@faron.mitre.org>
Message-ID: <Pine.LNX.4.64.0608310820250.3842@forced.attrition.org>


: I gave the standard response to the criticism in the last paragraph, 
: with the observation that we vdb's had reported it because OpenBSD did.

Since i'm not paid to work on a VDB and not doing this in any official 
capacity, i'll respond to this paragraph!

: BTW: it would be nice if your process of creating a candidate for 
: inclusion in the CVE list makes sure that the security contact for the 
: software is informed, so we don't have to rely on some 3rd party to hear 
: about this "DoS" for the software that we maintain. 
: http://www.sendmail.org/security/
: 
: Claus Assmann
: (current maintainer of sendmail)

There is a phrase about choosing who you sleep with because you may get 
fleas or some such. Claus, Sendmail as a program/group/whatever lost *all* 
rights to bitch about any vulnerability disclosure. In this case, that 
"3rd party" (you can hear him spitting as he typed that) is someone with 
OpenBSD, likely Theo, who definitely knows security when it comes to 
coding. If that isn't good enough, Sendmail (collectively) can shut their 
pie hole lest they choke on their own words:

SENDMAIL RELEASE NOTES
8.7.6/8.7.3     96/09/17
        SECURITY: fix some buffer overruns; in at least one case this allows
                a local user to get root.  This is not known to be exploitable
                from off-site.  The workaround is to disable chfn(1) commands.


# Hrm... and Eric Allman told me to my face that there were *no* buffer
# overflows in 8.7.5 -- .mudge
# This works on systems that have the chpass program runable by
# users. Tested on FreeBSD, though the vulnerability exists in all
# Sendmail8.7.5. Granted you need to be able to change your gecos field ;-)
#
# The problem is in buildfnam() which lives in util.c - it treats
# the static allocated array nbuf[MAXSIZE+1], from recipient.c, in
# an unbounded fashion.
#
# mudge at l0pht.com

[working exploit snipped]