From steve at vitriol.net Thu May 1 22:14:48 2008 From: steve at vitriol.net (Steve Tornio) Date: Thu, 01 May 2008 17:14:48 -0500 Subject: [VIM] Open redirects - yes or no? In-Reply-To: References: <200804301449.m3UEnPZm003600@faron.mitre.org> Message-ID: <481A40D8.8000608@vitriol.net> security curmudgeon wrote: > : But, I've noticed that other VDBs aren't necessarily covering these. > > OSVDB typically adds these. I would prefer we didn't. > > The phishing vector is what warrants inclusion in my mind. When doing > application tests, we ding clients for this as well, especially financial > groups. In this same vein, an RTF document from the IRS with an embedded EXE would be considered a software vulnerability. It's not. It's simply having the functionality used in unexpected ways. Redirects should only work for the same site, any external > redirects should go to a logout/splash page indicating the user/customer > is leaving the legitimate site. If that is in place, we don't ding the > client at work, and we don't add it to OSVDB. > A subjective, case-by-case judgment. That's why I would prefer we didn't count them. Steve osvdb.org From jericho at attrition.org Thu May 1 22:51:51 2008 From: jericho at attrition.org (security curmudgeon) Date: Thu, 1 May 2008 22:51:51 +0000 (UTC) Subject: [VIM] Open redirects - yes or no? In-Reply-To: <481A40D8.8000608@vitriol.net> References: <200804301449.m3UEnPZm003600@faron.mitre.org> <481A40D8.8000608@vitriol.net> Message-ID: : > OSVDB typically adds these. : : I would prefer we didn't. : > redirects should go to a logout/splash page indicating the user/customer is : > leaving the legitimate site. If that is in place, we don't ding the client : > at work, and we don't add it to OSVDB. : : A subjective, case-by-case judgment. That's why I would prefer we : didn't count them. How is that subjective? Either the app allows one click redirection to arbitrary sites w/o warning, or it gives you a warning that you are leaving the site and going to X in some fashion (logout page, leaving site splash page). From steve at vitriol.net Thu May 1 22:59:19 2008 From: steve at vitriol.net (Steve Tornio) Date: Thu, 01 May 2008 17:59:19 -0500 Subject: [VIM] Open redirects - yes or no? In-Reply-To: References: <200804301449.m3UEnPZm003600@faron.mitre.org> <481A40D8.8000608@vitriol.net> Message-ID: <481A4B47.9010104@vitriol.net> security curmudgeon wrote: > : > OSVDB typically adds these. > : > : I would prefer we didn't. > > : > redirects should go to a logout/splash page indicating the user/customer is > : > leaving the legitimate site. If that is in place, we don't ding the client > : > at work, and we don't add it to OSVDB. > : > : A subjective, case-by-case judgment. That's why I would prefer we > : didn't count them. > > How is that subjective? > > Either the app allows one click redirection to arbitrary sites w/o > warning, or it gives you a warning that you are leaving the site and > going to X in some fashion (logout page, leaving site splash page). > It's subjective in whether the site is supposed to warn you or not. The two given examples are pretty easy - no for Google, and yes for banks. If we're talking about a piece of off-the-shelf software that includes a search engine, it would be up to the end user web site admin to determine which behavior is appropriate. Since we only include software, and not customized websites, this is why I think there isn't much place in osvdb for this. If the context decides whether the function is acceptable, then I don't believe it can be objectively said to be a vulnerability. From str0ke at milw0rm.com Fri May 2 02:30:28 2008 From: str0ke at milw0rm.com (str0ke) Date: Thu, 01 May 2008 21:30:28 -0500 Subject: [VIM] Open redirects - yes or no? In-Reply-To: References: <200804301449.m3UEnPZm003600@faron.mitre.org> <481A40D8.8000608@vitriol.net> Message-ID: <481A7CC4.7010908@milw0rm.com> security curmudgeon wrote: > : > OSVDB typically adds these. > : > : I would prefer we didn't. > > I concur (no), waste of database space for a stepping stone vulnerability. Then again I could see this getting out of hand as well. http://www.google.com/codesearch?q=Location%3A%5C+%5C%24+file%3Aphp&btnG=Search&hl=en&lr= /str0ke From sullo at cirt.net Fri May 2 04:08:18 2008 From: sullo at cirt.net (Sullo) Date: Fri, 02 May 2008 00:08:18 -0400 Subject: [VIM] Open redirects - yes or no? In-Reply-To: <481A7CC4.7010908@milw0rm.com> References: <200804301449.m3UEnPZm003600@faron.mitre.org> <481A40D8.8000608@vitriol.net> <481A7CC4.7010908@milw0rm.com> Message-ID: <481A93B2.3010908@cirt.net> I'm going to side with Jericho on this one, and lobbied for inclusion in OSVDB back when we first discussed. If you work at a financial (or really any place), an open redirect is an open invitation to phishing. In the end, I think a VDB's job (much like a security scanner) is to list vulnerabilities, and let users of the software determine what is or is not acceptable. -Sullo From coley at linus.mitre.org Fri May 2 16:29:22 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 2 May 2008 12:29:22 -0400 (EDT) Subject: [VIM] Open redirects - yes or no? In-Reply-To: References: <200804301449.m3UEnPZm003600@faron.mitre.org> <481A40D8.8000608@vitriol.net> Message-ID: On Thu, 1 May 2008, security curmudgeon wrote: > Either the app allows one click redirection to arbitrary sites w/o > warning, or it gives you a warning that you are leaving the site and > going to X in some fashion (logout page, leaving site splash page). str0ke's excellent Google example notwithstanding, CVE-2008-2027 (RSA Auth Agent) had a blacklist that prevented http/https URLs but forgot ftp URLs. So clearly, in that case anyway, the vendor didn't want redirects to external sites. CVE-2008-0613 (XOOPS) and CVE-2007-6692 (Menalto Gallery) have vendor patches, indicating they didn't intend to allow URLs. So, I can see where it's a judgment call in some cases, but if the vendor says it's an issue, then that would definitely prompt inclusion. - Steve From rkeith at securityfocus.com Mon May 5 15:17:04 2008 From: rkeith at securityfocus.com (Rob Keith) Date: Mon, 05 May 2008 09:17:04 -0600 Subject: [VIM] V Vuln.IDs for Security Vulnerability in CDF Software (CORE-2008-0326)]] Message-ID: <481F24F0.5080506@securityfocus.com> Can you reserve a BID for this please. I need the BID # back too please. Thanks! -------- Original Message -------- Subject: Vuln.IDs for Security Vulnerability in CDF Software (CORE-2008-0326)] Date: Mon, 05 May 2008 11:04:40 -0300 From: Core Security Advisories Team (termo) Organization: Core Security Technologies To: Steven M. Christey , Rob Keith CC: CORE Security Technologies Advisories-publication Hello, Core Security Technologies is going to release this advisory soon. (I've attached a draft version) Could you send us an (Bugtraq & CVE) id number for it please? *IMPORTANT* This is advisory has not been released yet, I'll notify you when is public. Thank you in advance, Jose Orlicki CORE SECURITY TECHNOLOGIES http://www.coresecurity.com -- Rob Keith Symantec -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CORE-2008-0326-CDF-advisory.txt Url: http://www.attrition.org/pipermail/vim/attachments/20080505/9494390b/attachment-0001.txt From rkeith at securityfocus.com Mon May 5 15:25:07 2008 From: rkeith at securityfocus.com (Rob Keith) Date: Mon, 05 May 2008 09:25:07 -0600 Subject: [VIM] V Vuln.IDs for Security Vulnerability in CDF Software (CORE-2008-0326)]] In-Reply-To: <481F24F0.5080506@securityfocus.com> References: <481F24F0.5080506@securityfocus.com> Message-ID: <481F26D3.9030002@securityfocus.com> Please ignore the previous email, it was NOT meant to go to this list. Rob Keith wrote: > Can you reserve a BID for this please. I need the BID # back too > please. Thanks! > > -------- Original Message -------- > Subject: Vuln.IDs for Security Vulnerability in CDF Software > (CORE-2008-0326)] > Date: Mon, 05 May 2008 11:04:40 -0300 > From: Core Security Advisories Team (termo) > > Organization: Core Security Technologies > To: Steven M. Christey , Rob Keith > > CC: CORE Security Technologies Advisories-publication > > > > > Hello, > > Core Security Technologies is going to release this advisory soon. (I've > attached a draft version) > > Could you send us an (Bugtraq & CVE) id number for it please? > > *IMPORTANT* This is advisory has not been released > yet, I'll notify you when is public. > > > Thank you in advance, > > Jose Orlicki > CORE SECURITY TECHNOLOGIES > http://www.coresecurity.com > > > > -- Rob Keith Symantec From coley at linus.mitre.org Mon May 5 15:43:57 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Mon, 5 May 2008 11:43:57 -0400 (EDT) Subject: [VIM] V Vuln.IDs for Security Vulnerability in CDF Software (CORE-2008-0326)]] In-Reply-To: <481F24F0.5080506@securityfocus.com> References: <481F24F0.5080506@securityfocus.com> Message-ID: All, Please consider this thread to be non-public. Jericho will work on removing the related posts. - Steve From jericho at attrition.org Wed May 7 16:07:33 2008 From: jericho at attrition.org (security curmudgeon) Date: Wed, 7 May 2008 16:07:33 +0000 (UTC) Subject: [VIM] disclosure timeline (Core: Wonderware) Message-ID: http://seclists.org/fulldisclosure/2008/May/0095.html *Report Timeline* . 2008-01-30: Initial contact email sent by to Wonderware setting the estimated publication date of the advisory to February 25th. . 2008-01-30: Contact email re-sent to Wonderware asking for a software security contact for Wonderware InTouch. . 2008-02-06: New email sent to Wonderware asking for a response and for a software security contact for Wonderware InTouch. . 2008-02-28: Core makes direct phone calls to Wonderware headquarters informing of the previous emails and requesting acknowledgement of the notification of a security vulnerability. . 2008-02-28: As requested during the phone call, Core re-sends the original notification mail, stating that an advisory draft describing the vulnerability is available since January 30th. The publication of the advisory is re-scheduled to March 24th. . 2008-02-28: Vendor acknowledges the email notification. . 2008-02-28: Core sends the advisory draft to Wonderware support team. . 2008-02-29: Vendor acknowledges reception of the report and states that it understands the seriousness of the problem and that its development team will look into it. . 2008-02-29: Vendor asks for a copy of the proof of concept code used to demonstrate the vulnerability. . 2008-03-03: Core sends proof-of-concept code written in Python. . 2008-03-05: Vendor asks for compiler tools required to use the PoC code. . 2008-03-05: Core sends a link to http://www.python.org where a Python interpreter can be downloaded. . 2008-03-10: Vendor requests more information about the network and the firewall settings used during the tests and inquires about conformance (or lack thereof) of the tested network with the vendor's security policies and recommendations. . 2008-03-10: Vendor asks for details about how the advisory will be published. . 2008-03-12: Core responds that the workstation running the vulnerable service had no firewall activated in the tests, but since the Wonderware SuiteLink Service allows incoming connections it is assumed that the corresponding port should be allowed to receive inbound session establishment packets. Core offers the vendor the opportunity to include additional information in the "vendor information" section of the advisory. Core explains that the advisory will be published on Core's website and sent to security mailing lists. Core also reminds the vendor that the publication date of the advisory has been moved from February 25th to March 24th, and explains that it is willing to discuss a new publication date on the basis of having concrete plans, with a specific date for the fix release. . 2008-03-21: Vendor indicates that it will be unable to commit to releasing fixes by March 24th and requests publication of the advisory to be delayed to create a fix for vulnerable customers. The development team is investigating how long it will take to make such a fix available. The vendor indicates that the previous questions about firewall setup referred to the vendor's recommended practices to secure networks on which their systems run using firewalls and IPsec. . 2008-03-21: Vendor indicates that it is issuing a Tech Alert to its customers to address the issue. Details about the vulnerability have been minimized in the Tech Alert. The vendor expresses concern about the level of detail included in Core's advisory and requests that those details be removed from the advisory because they give more detail than what is needed to make people aware of the issue, and may lend itself to use by people who might want to exploit it. Early estimates put the delivery time for a fix at approximately three months, and the estimate is not final. Vendor asks Core to delay any publication until it is able to have a software fix ready. . 2008-03-21: Core asks if the three-month estimate should be assumed to have begun since the vendor's initial acknowledgement of Core's notification -- which puts the estimated date for the release of a fix at the end of May -- or since the date of the last email received (fix released at the end of June). Core indicates that as of today it still has no confirmation from the vendor that the vulnerability was replicated and identified, and that the fix is already under development or testing, and that is the information needed to re-schedule the publication date. Core is expecting to receive that information from the vendor, but in the meantime publication of the advisory is re-scheduled to March 31st 2008. With regards to the questions and requests about the contents of the security advisory, Core indicates that Core's technical publications are aimed at providing legitimate security practitioners worldwide with the technical details necessary to understand the nature of the security issues reported; so they are able to devise, by their own judgment, the risk mitigation approach that fits them the best. For that purpose, Core believes that it is fundamental that they have precise and accurate technical details about security issues -- as Wonderware itself has demonstrated with the request for further technical details and proof-of-concept code -- and that the whole reporting and disclosure process is transparent for scrutiny of all interested parties. . 2008-03-21: Vendor acknowledges Core's email and provides a copy of the issued Technical Alert 106 and indicates that will provide more information by March 25th 2008. . 2008-03-26: Vendor confirms to have replicated the issue reported and indicated that the Tech Alert 106 sent to customers confirms and recognizes the issue. The Tech Alert also points out what measures can be taken to mitigate risk. A project has been charter and is in progress to fix this issue and properly QA the fix. With regard to the contents of Core's report, it says that stating that a Denial of Service of SuiteLink communication can be created from a remote node sends a corrupted data packet seems to be sufficient to make people aware. The vendor says that is having trouble understanding what the value is in providing specific detail as to what technical issue is happening and asks for clarification to understand how this information would benefit organizations. The vendor acknowledges that the proof of concept code did help to replicate the issue and that without it, it would have needed more time to identify it from the report alone. The concern is that the details provided in the report may give a hacker a specific direction to look for the vulnerability. Finally, the vendor indicates that will have a better estimation for the rlease date of a fix by Friday March 28th, 2008. . 2008-03-27: Core acknowledges the vendor's email and indicates that is looking forward to having the new estimate by Friday. . 2008-03-28: Vendor informs that it has brought the estimated release date in to May 2nd. If things go well during QA, they may be able to bring that date in sooner and vendor requests that Core postpone publication until that time. . 2008-03-28: Core re-schedules publication of the advisory to May 2nd 2008 and says that it considers this date final unless the vendor indicates any deviation from the current estimate with at least a week in advance of the publication date, in which case Core would re-evaluate postponing publication up to 5 working days. With regard to the previous inquiry about the advisory's content, Core states that the purpose of publishing security advisories and the rationale used to define their content is simple and hopefully, once explained, both reasonable and understandable. Core publishes advisories not only to make users aware of the existence of a given vulnerability but also to facilitate its mitigation by either official or any other means that the security community and/or the vulnerable user population may devise. In order to do so, Core has learned over the course of 13 years working in this particular field that it is fundamental to provide precise and accurate technical information about problems. It is that information that can help other security practitioners to determine how to prevent exploitation, detect attacks or to verify that a fix or workaround is actually functioning properly. Thus, Core believes that it is necessary not only to indicate the mere existence of the bug, but also to explain how to uniquely identify it in the vulnerable software (to avoid confusion with all other known bugs or to differentiate it from others that may be discovered in the future). It is also important to determine how the vulnerability could be used by potential attackers so that proper detection mechanisms can be built, for example firewall rules, or IDS and antivirus signatures. While Core recognizes that this may provide some additional data to would-be attackers, clearly it also provides preciously needed information to the defenders thus, leveling a field on which Core believes the attackers are initially at advantage. . 2008-04-01: Vendor acknowledges previous email and indicates that it will provide a new update as soon as is available. . 2008-04-28: Vendor informs Core that a fix for the vulnerability in SuiteLink has been released. . 2008-04-28: Core acknowledges previous emails and requests an official vendor statement for the security advisory and more details about the vulnerable packages and versions. . 2008-04-29: Vendor provides an official statement and indicates that versions of SuiteLink prior to 2.0 patch 01 are vulnerable. Multiple products use SuiteLink. . 2008-04-30: The advisory is ready for release, but the publication date is re-scheduled to May 5th because May 1st is a public holiday in many countries (International Workers' Day) and Core does not usually publish advisories on Fridays (to avoid IT work on weekends). . 2008-05-05: CORE-2008-0129 advisory is published. From theall at tenablesecurity.com Wed May 7 16:11:01 2008 From: theall at tenablesecurity.com (George A. Theall) Date: Wed, 7 May 2008 12:11:01 -0400 Subject: [VIM] disclosure timeline (Core: Wonderware) In-Reply-To: References: Message-ID: <193E42C4-6E25-4BF4-AF60-82EA23745826@tenablesecurity.com> On May 7, 2008, at 12:07 PM, security curmudgeon wrote: > http://seclists.org/fulldisclosure/2008/May/0095.html > > *Report Timeline* You meant that this for funsec at linuxbox.org, didn't you? George -- theall at tenablesecurity.com From jms at bughunter.ca Wed May 7 16:20:42 2008 From: jms at bughunter.ca (JM Seitz) Date: Wed, 07 May 2008 10:20:42 -0600 Subject: [VIM] disclosure timeline (Core: Wonderware) In-Reply-To: <193E42C4-6E25-4BF4-AF60-82EA23745826@tenablesecurity.com> References: <193E42C4-6E25-4BF4-AF60-82EA23745826@tenablesecurity.com> Message-ID: <4821D6DA.2040209@bughunter.ca> My favourite thing out of this whole disclosure timeline is Wondeware asking for the compiler for the .py script :) JS George A. Theall wrote: > On May 7, 2008, at 12:07 PM, security curmudgeon wrote: > >> http://seclists.org/fulldisclosure/2008/May/0095.html >> >> *Report Timeline* > > > You meant that this for funsec at linuxbox.org, didn't you? > > > George From noamr at beyondsecurity.com Wed May 7 16:26:51 2008 From: noamr at beyondsecurity.com (=?utf-8?B?Tm9hbSBSYXRoYXVz?=) Date: Wed, 7 May 2008 16:26:51 +0000 Subject: [VIM] disclosure timeline (Core: Wonderware) In-Reply-To: <4821D6DA.2040209@bughunter.ca> References: <193E42C4-6E25-4BF4-AF60-82EA23745826@tenablesecurity.com><4821D6DA.2040209@bughunter.ca> Message-ID: <159006526-1210177419-cardhu_decombobulator_blackberry.rim.net-1470016983-@bxe140.bisx.prod.on.blackberry> Compiler isn't weird its weird they didn't think core was giving them a snake :) Thanks, Noam Rathaus Beyond Security -----Original Message----- From: JM Seitz Date: Wed, 07 May 2008 10:20:42 To:Vulnerability Information Managers Subject: Re: [VIM] disclosure timeline (Core: Wonderware) My favourite thing out of this whole disclosure timeline is Wondeware asking for the compiler for the .py script :) JS George A. Theall wrote: > On May 7, 2008, at 12:07 PM, security curmudgeon wrote: > >> http://seclists.org/fulldisclosure/2008/May/0095.html >> >> *Report Timeline* > > > You meant that this for funsec at linuxbox.org, didn't you? > > > George From sullo at cirt.net Wed May 7 18:12:48 2008 From: sullo at cirt.net (Sullo) Date: Wed, 07 May 2008 14:12:48 -0400 Subject: [VIM] disclosure timeline (Core: Wonderware) In-Reply-To: <159006526-1210177419-cardhu_decombobulator_blackberry.rim.net-1470016983-@bxe140.bisx.prod.on.blackberry> References: <193E42C4-6E25-4BF4-AF60-82EA23745826@tenablesecurity.com><4821D6DA.2040209@bughunter.ca> <159006526-1210177419-cardhu_decombobulator_blackberry.rim.net-1470016983-@bxe140.bisx.prod.on.blackberry> Message-ID: <4821F120.1030803@cirt.net> I think someone had just received their yearly review and got dinged for not providing enough details in their notes... :-) Noam Rathaus wrote: > Compiler isn't weird its weird they didn't think core was giving them a snake :) > > Thanks, > Noam Rathaus > Beyond Security > > -----Original Message----- > From: JM Seitz > > Date: Wed, 07 May 2008 10:20:42 > To:Vulnerability Information Managers > Subject: Re: [VIM] disclosure timeline (Core: Wonderware) > > > My favourite thing out of this whole disclosure timeline is Wondeware > asking for the compiler for the .py script :) > > JS > > George A. Theall wrote: > >> On May 7, 2008, at 12:07 PM, security curmudgeon wrote: >> >> >>> http://seclists.org/fulldisclosure/2008/May/0095.html >>> >>> *Report Timeline* >>> >> You meant that this for funsec at linuxbox.org, didn't you? >> >> >> George >> > > > > > From jericho at attrition.org Thu May 8 06:23:04 2008 From: jericho at attrition.org (security curmudgeon) Date: Thu, 8 May 2008 06:23:04 +0000 (UTC) Subject: [VIM] question about IRM advisory (fwd) Message-ID: And no reply since... ---------- Forwarded message ---------- From: security curmudgeon To: research at irmplc.com Date: Wed, 30 Apr 2008 02:46:16 +0000 (UTC) Subject: question about IRM advisory In regards to: http://www.irmplc.com/content/pdfs/WebSphere_MQ_Threats_Management_Summary.pdf First, it is extremely annoying that you make such "advisories" in a PDF format that does not allow cut-and-paste. Second, under "Unauthorized Queue Access", it is unclear if this is describing a vulnerability in the software, a client misconfiguration or a misconfiguration that ships by default. Third, you say that it is vulnerable to traffic sniffing, but then go on to say that it is vulnerable to "unauthorized decryption". Can you clarify if there is encryption available for traffic, but it is weak? Or is this in reference to encryption used on data not in transit? In short, OSVDB is trying to determine how many real vulnerabilities are covered in this advisory in order to create tracking numbers in our database. In addition, it would be appreciated if IRM could request CVE (http://cve.mitre.org/) candidate numbers for the vulnerabilities found, so that there is an external standardized tracking number to help avoid this type of confusion. Thank you, Brian OSVDB.org From rkeith at securityfocus.com Fri May 9 15:15:34 2008 From: rkeith at securityfocus.com (Rob Keith) Date: Fri, 09 May 2008 09:15:34 -0600 Subject: [VIM] fyi Milw0rm ActiveX controls insecure methods by t0pP8uZz Message-ID: <48246A96.70109@securityfocus.com> Hey, not sure if other VDBs discount these ActiveX controls when they aren't marked safe for scripting? But here were our findings: There were 5 ActiveX issues posted to Milw0rm today by t0pP8uZz: Secure File Delete Wizard <= 2.0.0 ActiveX Insecure Methods Exploit http://www.milw0rm.com/exploits/5573 Registry Pro (epRegPro.ocx) Remote Insecure Methods Exploit http://www.milw0rm.com/exploits/5572 EvansFTP (EvansFTP.ocx) Remote Insecure Methods Exploit http://www.milw0rm.com/exploits/5571 aaxRegistry (aaxRegistry.ocx) Remote Registry Deletion Exploit http://www.milw0rm.com/exploits/5570 Univeral HTTP Image/File Upload ActiveX Remote File Deletion Exploit http://www.milw0rm.com/exploits/5569 I have installed all of the ActiveX controls mentioned above and none of them was marked safe for scripting. Regards, Adrian -- Rob Keith Symantec From jms at bughunter.ca Fri May 9 15:24:46 2008 From: jms at bughunter.ca (JM Seitz) Date: Fri, 09 May 2008 09:24:46 -0600 Subject: [VIM] fyi Milw0rm ActiveX controls insecure methods by t0pP8uZz In-Reply-To: <48246A96.70109@securityfocus.com> References: <48246A96.70109@securityfocus.com> Message-ID: <48246CBE.2000300@bughunter.ca> Yeah not surprising, I doubt that str0ke wants to check each one of them as they come in :) Then again maybe a buffer overflow that gives you the same privileges as you already have is useful! :) JS Rob Keith wrote: > Hey, not sure if other VDBs discount these ActiveX controls when they > aren't marked safe for scripting? But here were our findings: > > There were 5 ActiveX issues posted to Milw0rm today by t0pP8uZz: > > Secure File Delete Wizard <= 2.0.0 ActiveX Insecure Methods Exploit > http://www.milw0rm.com/exploits/5573 > > Registry Pro (epRegPro.ocx) Remote Insecure Methods Exploit > http://www.milw0rm.com/exploits/5572 > > EvansFTP (EvansFTP.ocx) Remote Insecure Methods Exploit > http://www.milw0rm.com/exploits/5571 > > aaxRegistry (aaxRegistry.ocx) Remote Registry Deletion Exploit > http://www.milw0rm.com/exploits/5570 > > Univeral HTTP Image/File Upload ActiveX Remote File Deletion Exploit > http://www.milw0rm.com/exploits/5569 > > I have installed all of the ActiveX controls mentioned above and none > of them was marked safe for scripting. > > Regards, > Adrian > > From jericho at attrition.org Fri May 9 15:27:40 2008 From: jericho at attrition.org (security curmudgeon) Date: Fri, 9 May 2008 15:27:40 +0000 (UTC) Subject: [VIM] fyi Milw0rm ActiveX controls insecure methods by t0pP8uZz In-Reply-To: <48246CBE.2000300@bughunter.ca> References: <48246A96.70109@securityfocus.com> <48246CBE.2000300@bughunter.ca> Message-ID: : Yeah not surprising, I doubt that str0ke wants to check each one of them : as they come in :) : : Then again maybe a buffer overflow that gives you the same privileges as : you already have is useful! :) I think it is definitely good to track these, but more important to know details like Rob provided to help better evaluate the potential risk. From str0ke at milw0rm.com Fri May 9 15:53:34 2008 From: str0ke at milw0rm.com (str0ke) Date: Fri, 09 May 2008 10:53:34 -0500 Subject: [VIM] fyi Milw0rm ActiveX controls insecure methods by t0pP8uZz In-Reply-To: <48246CBE.2000300@bughunter.ca> References: <48246A96.70109@securityfocus.com> <48246CBE.2000300@bughunter.ca> Message-ID: <4824737E.1080001@milw0rm.com> Ya I didn't check these. Should have though. I am going to take them down from the main page, but they will stay up at their current urls. /str0ke JM Seitz wrote: > Yeah not surprising, I doubt that str0ke wants to check each one of them > as they come in :) > > Then again maybe a buffer overflow that gives you the same privileges as > you already have is useful! :) > > JS > Rob Keith wrote: > >> Hey, not sure if other VDBs discount these ActiveX controls when they >> aren't marked safe for scripting? But here were our findings: >> >> There were 5 ActiveX issues posted to Milw0rm today by t0pP8uZz: >> >> Secure File Delete Wizard <= 2.0.0 ActiveX Insecure Methods Exploit >> http://www.milw0rm.com/exploits/5573 >> >> Registry Pro (epRegPro.ocx) Remote Insecure Methods Exploit >> http://www.milw0rm.com/exploits/5572 >> >> EvansFTP (EvansFTP.ocx) Remote Insecure Methods Exploit >> http://www.milw0rm.com/exploits/5571 >> >> aaxRegistry (aaxRegistry.ocx) Remote Registry Deletion Exploit >> http://www.milw0rm.com/exploits/5570 >> >> Univeral HTTP Image/File Upload ActiveX Remote File Deletion Exploit >> http://www.milw0rm.com/exploits/5569 >> >> I have installed all of the ActiveX controls mentioned above and none >> of them was marked safe for scripting. >> >> Regards, >> Adrian >> >> >> > > > From coley at linus.mitre.org Fri May 9 16:06:17 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 9 May 2008 12:06:17 -0400 (EDT) Subject: [VIM] fyi Milw0rm ActiveX controls insecure methods by t0pP8uZz In-Reply-To: <48246A96.70109@securityfocus.com> References: <48246A96.70109@securityfocus.com> Message-ID: On Fri, 9 May 2008, Rob Keith wrote: > Hey, not sure if other VDBs discount these ActiveX controls when they > aren't marked safe for scripting? Thanks for bringing this up. I must admit to accidentally assuming that safe-for-scripting was required :) FYI this looks like a good post from Microsoft: http://blogs.technet.com/swi/archive/2008/02/03/activex-controls.aspx One question becomes, what steps did the researcher take to enable and exploit these controls in the first place? Is there still a chance where a user might activate the control somehow? - Steve From str0ke at milw0rm.com Fri May 9 16:13:38 2008 From: str0ke at milw0rm.com (str0ke) Date: Fri, 09 May 2008 11:13:38 -0500 Subject: [VIM] fyi Milw0rm ActiveX controls insecure methods by t0pP8uZz In-Reply-To: References: <48246A96.70109@securityfocus.com> Message-ID: <48247832.3090808@milw0rm.com> Steven M. Christey wrote: > On Fri, 9 May 2008, Rob Keith wrote: > > >> Hey, not sure if other VDBs discount these ActiveX controls when they >> aren't marked safe for scripting? >> > > Thanks for bringing this up. I must admit to accidentally assuming that > safe-for-scripting was required :) > Yep thanks Rob. > FYI this looks like a good post from Microsoft: > > http://blogs.technet.com/swi/archive/2008/02/03/activex-controls.aspx > > One question becomes, what steps did the researcher take to enable and > exploit these controls in the first place? Is there still a chance where > a user might activate the control somehow? > > The researcher stated that Rob was correct and that he had IE mis configured on his end. /str0ke From coley at linus.mitre.org Fri May 9 16:35:46 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 9 May 2008 12:35:46 -0400 (EDT) Subject: [VIM] fyi Milw0rm ActiveX controls insecure methods by t0pP8uZz In-Reply-To: <48247832.3090808@milw0rm.com> References: <48246A96.70109@securityfocus.com> <48247832.3090808@milw0rm.com> Message-ID: On Fri, 9 May 2008, str0ke wrote: > The researcher stated that Rob was correct and that he had IE mis > configured on his end. ... and probably an extremely common misconfiguration, I'd bet: 1) in the Internet zone, the user might have set "Enable" or "Prompt" for the "Initialize and script ActiveX controls not marked as safe for scripting" setting, e.g. to let some OTHER control work correctly. 2) In the Trusted zone, this is probably more likely to be set to prompt or enable. 3) Wouldn't malware think it was fun to change this setting? And, more importantly - if an AV product knew that malware did/does this, how would it know which value to set it back to? I bet that if someone somewhere did an investigation on browser settings for scripting, there would be a relatively high percentage that have unsafe values. So this seems to me like something similar to requiring that register_globals is enabled - yeah people shouldn't be doing that, but a lot of them do. Here's an example of a user who fixed an ActiveX problem by changing from disable to prompt, which at least gets "user-assisted": http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1210350698911+28353475&threadId=1005787 Ooooh, here's an AWESOME one! Set everything to enable! http://www.checktraining.com/docs/general/Tech%20Support%20Manual/PDF's/ARC%20Internet%20Security%20Settings.pdf and here: http://www.emolecules.com/doc/mcchem_installation.htm So anyone who uses that product would be automatically subject to other vulnerabilities. - Steve From coley at linus.mitre.org Fri May 9 16:56:08 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 9 May 2008 12:56:08 -0400 (EDT) Subject: [VIM] fyi Milw0rm ActiveX controls insecure methods by t0pP8uZz In-Reply-To: <48247832.3090808@milw0rm.com> References: <48246A96.70109@securityfocus.com> <48247832.3090808@milw0rm.com> Message-ID: oooh, found a better one for something called Microsoft Dynamics: http://blogs.msdn.com/crm/archive/2007/09/12/improve-the-outlook-experience-with-crm-part-four.aspx - Steve From str0ke at milw0rm.com Mon May 12 21:28:22 2008 From: str0ke at milw0rm.com (str0ke) Date: Mon, 12 May 2008 16:28:22 -0500 Subject: [VIM] PHP File Upload Vulnerability with extra Extension Message-ID: <4828B676.6000709@milw0rm.com> I have forgotten what caused the vulnerability where you upload a file such as somefile.php.jpg and it can be executed as a php script. I know this isn't a php vulnerability as much as an addon. I think in the past it was suexec that caused this but not sure. Anyone have a clue? Regards, /str0ke From coley at linus.mitre.org Mon May 12 21:37:43 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Mon, 12 May 2008 17:37:43 -0400 (EDT) Subject: [VIM] PHP File Upload Vulnerability with extra Extension In-Reply-To: <4828B676.6000709@milw0rm.com> References: <4828B676.6000709@milw0rm.com> Message-ID: On Mon, 12 May 2008, str0ke wrote: > I have forgotten what caused the vulnerability where you upload a file > such as somefile.php.jpg and it can be executed as a php script. I know > this isn't a php vulnerability as much as an addon. I think in the past > it was suexec that caused this but not sure. Anyone have a clue? In CVE we call this "unrestricted file upload." The application intends to allow uploads, e.g. for avatars in a bulletin board. The canonical example is just allowing .php (or .asp) files without any check; in many environments, you don't need an execute bit - the server will just invoke the interpreter directly. I see it mostly with .php and .asp but other extensions are also likely. In this particular variant, you'll usually have a case where the code looks for ".jpg" and assumes the file extension is safe. But Apache sees the ".php" first, and ships it off to the PHP interpreter. Wackiness ensues. Presumably this double-extension variant could apply in other servers that use some type of URL rewriting, but I don't know for sure. I suspect some researchers just automatically try "shell.php.jpg" without trying "shell.php" first, so you can't always be sure if it's the variant or the canonical example. - Steve From mmurphy_apple at mac.com Mon May 12 21:50:21 2008 From: mmurphy_apple at mac.com (Matthew Murphy) Date: Mon, 12 May 2008 14:50:21 -0700 Subject: [VIM] PHP File Upload Vulnerability with extra Extension In-Reply-To: <4828B676.6000709@milw0rm.com> References: <4828B676.6000709@milw0rm.com> Message-ID: <6A7E1A94-2D93-4AC8-BCEC-D24D059982D0@mac.com> On May 12, 2008, at 2:28 PM, str0ke wrote: > I have forgotten what caused the vulnerability where you upload a file > such as somefile.php.jpg and it can be executed as a php script. I > know > this isn't a php vulnerability as much as an addon. I think in the > past > it was suexec that caused this but not sure. Anyone have a clue? > > Regards, > /str0ke It's a design decision, according to ASF. The idea is that you can have multiple extensions, e.g: index.html.en Both of which affect the content processing in some way. The .html file tells the core that it is a static document, but the .en tells mod_negotiation that it is an English-language version of 'index.html'. The same processing is done for PHP content, e.g.: index.php.fr Will be processed if I request 'index.php' with an Accept-Language header including 'fr' or a subcode of it. - Matt From str0ke at milw0rm.com Tue May 13 02:14:34 2008 From: str0ke at milw0rm.com (str0ke) Date: Mon, 12 May 2008 21:14:34 -0500 Subject: [VIM] PHP File Upload Vulnerability with extra Extension In-Reply-To: <6A7E1A94-2D93-4AC8-BCEC-D24D059982D0@mac.com> References: <4828B676.6000709@milw0rm.com> <6A7E1A94-2D93-4AC8-BCEC-D24D059982D0@mac.com> Message-ID: <4828F98A.60903@milw0rm.com> Thank you both for the explanation. regards, /str0ke Matthew Murphy wrote: > > On May 12, 2008, at 2:28 PM, str0ke wrote: > >> I have forgotten what caused the vulnerability where you upload a file >> such as somefile.php.jpg and it can be executed as a php script. I know >> this isn't a php vulnerability as much as an addon. I think in the past >> it was suexec that caused this but not sure. Anyone have a clue? >> >> Regards, >> /str0ke > > It's a design decision, according to ASF. The idea is that you can > have multiple extensions, e.g: > > index.html.en > > Both of which affect the content processing in some way. The .html > file tells the core that it is a static document, but the .en tells > mod_negotiation that it is an English-language version of > 'index.html'. The same processing is done for PHP content, e.g.: > > index.php.fr > > Will be processed if I request 'index.php' with an Accept-Language > header including 'fr' or a subcode of it. > > - Matt > From str0ke at milw0rm.com Wed May 14 13:16:21 2008 From: str0ke at milw0rm.com (str0ke) Date: Wed, 14 May 2008 08:16:21 -0500 Subject: [VIM] [MIL] 5451 - BigAnt Server 2.2 PreAuth Remote SEH Overflow Exploit Message-ID: <482AE625.30500@milw0rm.com> The vendor BigAntSoft has released an update to fix this vulnerability. The latest version of BigAnt IM server and client is v2.35,it can be downloaded from the link below. http://www.bigantsoft.com/download/bigant.zip Regards, /str0ke From gmdarkfig at gmail.com Wed May 14 19:23:24 2008 From: gmdarkfig at gmail.com (GM darkfig) Date: Wed, 14 May 2008 21:23:24 +0200 Subject: [VIM] PHP File Upload Vulnerability with extra Extension In-Reply-To: <4828F98A.60903@milw0rm.com> References: <4828B676.6000709@milw0rm.com> <6A7E1A94-2D93-4AC8-BCEC-D24D059982D0@mac.com> <4828F98A.60903@milw0rm.com> Message-ID: Hi =) If the filename is a well-known extension (jpg, gif, etc...), it can be interpreted as a php file if there is a .htaccess file with this type of content: # backdoor.php.jpg AddHandler application/x-httpd-php .php If the extension is unknown (zzz, jpx, etc...), it can be interpreted as a php file if the module mod_mime is loaded: # backdoor.php.xxx LoadModule mime_module modules/mod_mime.so - darkfig 2008/5/13 str0ke : > Thank you both for the explanation. > > regards, > /str0ke > > Matthew Murphy wrote: >> >> On May 12, 2008, at 2:28 PM, str0ke wrote: >> >>> I have forgotten what caused the vulnerability where you upload a file >>> such as somefile.php.jpg and it can be executed as a php script. I know >>> this isn't a php vulnerability as much as an addon. I think in the past >>> it was suexec that caused this but not sure. Anyone have a clue? >>> >>> Regards, >>> /str0ke >> >> It's a design decision, according to ASF. The idea is that you can >> have multiple extensions, e.g: >> >> index.html.en >> >> Both of which affect the content processing in some way. The .html >> file tells the core that it is a static document, but the .en tells >> mod_negotiation that it is an English-language version of >> 'index.html'. The same processing is done for PHP content, e.g.: >> >> index.php.fr >> >> Will be processed if I request 'index.php' with an Accept-Language >> header including 'fr' or a subcode of it. >> >> - Matt >> > From str0ke at milw0rm.com Wed May 14 19:26:50 2008 From: str0ke at milw0rm.com (str0ke) Date: Wed, 14 May 2008 14:26:50 -0500 Subject: [VIM] PHP File Upload Vulnerability with extra Extension In-Reply-To: References: <4828B676.6000709@milw0rm.com> <6A7E1A94-2D93-4AC8-BCEC-D24D059982D0@mac.com> <4828F98A.60903@milw0rm.com> Message-ID: <482B3CFA.4010203@milw0rm.com> Thanks again dark. Thats what I was looking for. /str0ke GM darkfig wrote: > Hi =) > > If the filename is a well-known extension (jpg, gif, etc...), it can > be interpreted as > a php file if there is a .htaccess file with this type of content: > > # backdoor.php.jpg > AddHandler application/x-httpd-php .php > > If the extension is unknown (zzz, jpx, etc...), it can be interpreted > as a php file if > the module mod_mime is loaded: > > # backdoor.php.xxx > LoadModule mime_module modules/mod_mime.so > > - darkfig > > 2008/5/13 str0ke : > >> Thank you both for the explanation. >> >> regards, >> /str0ke >> >> Matthew Murphy wrote: >> >>> On May 12, 2008, at 2:28 PM, str0ke wrote: >>> >>> >>>> I have forgotten what caused the vulnerability where you upload a file >>>> such as somefile.php.jpg and it can be executed as a php script. I know >>>> this isn't a php vulnerability as much as an addon. I think in the past >>>> it was suexec that caused this but not sure. Anyone have a clue? >>>> >>>> Regards, >>>> /str0ke >>>> >>> It's a design decision, according to ASF. The idea is that you can >>> have multiple extensions, e.g: >>> >>> index.html.en >>> >>> Both of which affect the content processing in some way. The .html >>> file tells the core that it is a static document, but the .en tells >>> mod_negotiation that it is an English-language version of >>> 'index.html'. The same processing is done for PHP content, e.g.: >>> >>> index.php.fr >>> >>> Will be processed if I request 'index.php' with an Accept-Language >>> header including 'fr' or a subcode of it. >>> >>> - Matt >>> >>> > > From theall at tenablesecurity.com Wed May 14 19:52:42 2008 From: theall at tenablesecurity.com (George A. Theall) Date: Wed, 14 May 2008 15:52:42 -0400 Subject: [VIM] PHP File Upload Vulnerability with extra Extension In-Reply-To: <482B3CFA.4010203@milw0rm.com> References: <4828B676.6000709@milw0rm.com> <6A7E1A94-2D93-4AC8-BCEC-D24D059982D0@mac.com> <4828F98A.60903@milw0rm.com> <482B3CFA.4010203@milw0rm.com> Message-ID: <810945D1-4D68-4891-949C-C6928BBF9635@tenablesecurity.com> On May 14, 2008, at 3:26 PM, str0ke wrote: > Thanks again dark. Thats what I was looking for. Is this related to milw0rm 5600? That issue is actually in something called Postlet (http://postlet.com), which is included with CMS Made Simple, and looking at the SVN repository on SourceForge, it seems like it's still vulnerable: http://postlet.svn.sourceforge.net/viewvc/postlet/trunk/postlet/javaUpload.php?view=log I got a chuckle out of the comment at the top of the affected file, which reads: ----- snip, snip, snip ----- PLEASE NOTE, THIS FILES IN ITS PRESENT FORM IS A MASSIVE SECURITY RISK, AND SHOULD NOT BE USED WITHOUT DOING EITHER OF THE FOLLOWING: - PROTECTING THE ACCESS OF THE FILE BY THE USE OF SESSION VARIABLES (DO NOT PROTECT IT BY USING HTTP PASSWORDS) - ENSURING THAT UPLOADED FILES ARE NOT ACCESSIBLE TO THE WEB (UPLOAD FILES TO A DIRECTORY ABOVE THE DOCUMENT ROOT) ----- snip, snip, snip ----- Also, I haven't seen any mention of alternate attacks. By default, the application only checks for the extensions "php", "asp", and "pl", which means you don't need to use a double-extension and can instead just upload a file with the name ".php5" or something like that. George -- theall at tenablesecurity.com From jericho at attrition.org Tue May 20 03:42:37 2008 From: jericho at attrition.org (security curmudgeon) Date: Tue, 20 May 2008 03:42:37 +0000 (UTC) Subject: [VIM] SAXON news.php RFI Message-ID: SAXON news.php template Variable Remote File Inclusion 2006-06-13 http://archives.neohapsis.com/archives/bugtraq/2006-06/0242.html (no CVE?) This was challenged quickly and said to be a false report, noting the researcher is unreliable as well. Just noticed that the same program/script/variable was reported later: SAXON news.php template Variable Remote File Inclusion 2007-05-20 http://archives.neohapsis.com/archives/bugtraq/2007-05/0306.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=2007-2861 No one challenged it the 2nd time around. I wonder if no one noticed, no one cared (RFI saturation) or if it became vulnerable since the first report... From ascii at katamail.com Tue May 20 17:02:44 2008 From: ascii at katamail.com (ascii) Date: Tue, 20 May 2008 17:02:44 +0000 Subject: [VIM] Mantis Bug Tracker 1.1.1 Multiple Vulnerabilities Message-ID: <48330434.9050402@katamail.com> Mantis Bug Tracker 1.1.1 Multiple Vulnerabilities Name Multiple Vulnerabilities in Mantis Systems Affected Mantis 1.1.1 and possibly earlier versions Severity High Impact (CVSSv2) High 9/10, vector: (AV:N/AC:L/Au:N/C:C/I:P/A:P) Vendor http://www.mantisbt.org/ Advisory http://www.ush.it/team/ush/hack-mantis111/adv.txt Authors Antonio "s4tan" Parata (s4tan AT ush DOT it) Francesco "ascii" Ongaro (ascii AT ush DOT it) Date 20080520 I. BACKGROUND From the Mantis web site: "Mantis is a free popular web-based bug tracking system. It is written in the PHP scripting language and works with MySQL, MS SQL, and PostgreSQL databases and a webserver.". II. DESCRIPTION Multiple vulnerabilities exist in Mantis software (XSS, CSRF, Remote Code Execution). III. ANALYSIS Summary: A) XSS Vulnerabilities return_dynamic_filters.php (filter_target parameter) B) CSRF Vulnerabilities manage_user_create.php C) Remote Code Execution Vulnerabilities adm_config_set.php (value parameter) A) XSS Vulnerabilities We have found an XSS vulnerability in return_dynamic_filters.php. In order to exploit this vulnerability the attacker must be authenticated. Usually the anonymous user is allowed on typical installation, so the impact is a bit higher. The following url is a proof of concept: http://www.example.com/mantis/return_dynamic_filters.php?filter_target= B) CSRF Vulnerabilities There is a Cross Site Request Forgery vulnerability in the software. If a logged in user with administrator privileges clicks on the following url: http://www.example.com/mantis/manage_user_create.php?username=foo&realn ame=aa&password=aa&password_verify=aa&email=foo at attacker.com&access_lev el=90&protected=0&enabled=1 a new user 'foo' with administrator privileges is created. The password of the new user is sent to foo at attacker.com. C) Remote Code Execution Vulnerabilities Finally we present the most critical vulnerability. A Remote Code Execution vulnerability exists in the software, but it can be exploited only if the attacker has a valid administrator account, so it could be ideal if used in conjunction with the previous one. The vulnerability is in the file adm_config_set.php. On row 80 we have the following statement: eval( '$t_value = ' . $f_value . ';' ); where the $f_value is defined at row 34 of the same file: $f_value = gpc_get_string( 'value' ); the parameter $f_value is never validated, so we can exploit this issue with the following url which executes the phpinfo() function: http://www.example.com/mantis/adm_config_set.php?user_id=0&project_id=0 &config_option=cache_config&type=0&value=0;phpinfo() IV. DETECTION Mantis 1.1.1 and possibly earlier versions are vulnerable. V. WORKAROUND Proper input validation will fix the vulnerabilities. Upgrade to latest development version 1.2.0a1. VI. VENDOR RESPONSE It was a little surprise to find out that somebody issued CVE-2008-2276 during our responsible disclosure time-line. From an internal email with Glenn Henshaw: --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- # 8974 : XSS Vulnerability in filters - fixed for 1.1.2 # 8977 : Port 0008974: XSS Vulnerability in filters - fixed for 1.2.0 and future - this issue has been fixed by escaping the data in the error message. # 8976 : Remote Code Execution in adm_config - workaround in place in 1.1.2 - this page is only accessible to registered administrators # 8980 : Port: Remote Code Execution in adm_config - workaround in place in 1.2.0 and beyond - this page is only accessible to registered administrators # 8975 : CSRF Vulnerabilities in user_create # 8995 : Port: CSRF Vulnerabilities in user_create - this has been fixed by ensuring that action pages can only be accessed via POST commands. --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- So "CSRF Vulnerabilities in user_create" is an our finding. The vendor fixed by allowing only POST parameters that is obviously a non-fix. Our response: --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- This alone isn't enough since forms can be auto-submitted by js that are irrespective of the same-orgin policy. Proper remediation should include referer checking (has proved to be spoofable on the client side in the past so not a bulletproof technique) and token checking (a random string or an hash generated when the user requires the frontend, stored serverside - sessions are okay -, included in the frontend form and sent to and verified by the backend). These two protections ensure that an action cannot, hopefully, be CSRFed (at last in absence of an xss vuln that neutralize the same origin policy again). --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- Glenn response: --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- Thanks for the notice. The CSRF patch for rev 1.1.2 is in place using just a "POST" check. I have added a more sophisticated token based check to rev 1.2.0 (the patch is attached for review). I should be submitting this shortly. --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- Glenn final update about the patch not being incorporated upstream: --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- As a final update on this subject, the status of these issues has not changed. The token based CSRF implementation was rejected by the development team, and will not be implemented (at least by me). The consensus was that it was too complex to resolve a "rare" problem. --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- Since responsible disclosure didn't worked well with this vendor and turned out to be very resource expensive we will publish future issues affecting this product directly to independent security researchers, developers and users. The wrong attribution of CVE-2008-2276 before our official advisory strengthen our conviction that responsible disclosure isn't always fair. We discussed long with Glenn Henshaw about issues and how to fix them in mantis and we didn't expect to find a CVE credited to one of our interlocutors. He was surely aware of who was deserving credits and should have taken proper steps to prevent or fix this. nUE0p QbiY3q3ql55o3I0 qJWy YzAioF9 3LKEwnQ92 CIEhqzkE L0kIMy9S VII. CVE INFORMATION No CVE at this time. VIII. DISCLOSURE TIMELINE 20080121 Bug discovered 20080213 Vendor contacted -- LONG VENDOR SLOWNESS -- 20080512 Last vendor mail about development and compatibility issues 20080515 CVE-2008-2276 wrongly credited to Glenn Henshaw (thraxisp) 20080520 Advisory released (forced disclosure) IX. CREDIT Antonio "s4tan" Parata and Francesco "ascii" Ongaro are credited with the discovery of this vulnerability. Antonio "s4tan" Parata web site: http://www.ictsc.it/ mail: s4tan AT ictsc DOT it, s4tan AT ush DOT it Francesco "ascii" Ongaro web site: http://www.ush.it/ mail: ascii AT ush DOT it X. LEGAL NOTICES Copyright (c) 2007 Francesco "ascii" Ongaro Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without mine express written consent. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please email me for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. From str0ke at milw0rm.com Wed May 21 02:34:25 2008 From: str0ke at milw0rm.com (str0ke) Date: Tue, 20 May 2008 21:34:25 -0500 Subject: [VIM] cve down? Message-ID: <48338A31.80307@milw0rm.com> Anyone else having problems resolving mitre? /str0ke From jericho at attrition.org Wed May 21 02:36:34 2008 From: jericho at attrition.org (security curmudgeon) Date: Wed, 21 May 2008 02:36:34 +0000 (UTC) Subject: [VIM] cve down? In-Reply-To: <48338A31.80307@milw0rm.com> References: <48338A31.80307@milw0rm.com> Message-ID: : Anyone else having problems resolving mitre? Down this morning for a while, and down again now. I blame Steve for leaving the servers and taking the hamsters. I believe he is out of country at a conference, so it's clearly his fault. =) From str0ke at milw0rm.com Wed May 21 02:42:04 2008 From: str0ke at milw0rm.com (str0ke) Date: Tue, 20 May 2008 21:42:04 -0500 Subject: [VIM] cve down? In-Reply-To: References: <48338A31.80307@milw0rm.com> Message-ID: <48338BFC.4040402@milw0rm.com> security curmudgeon wrote: > : Anyone else having problems resolving mitre? > > Down this morning for a while, and down again now. > I demand the hamsters to be returned.. From noamr at beyondsecurity.com Wed May 21 05:42:17 2008 From: noamr at beyondsecurity.com (Noam Rathaus) Date: Wed, 21 May 2008 08:42:17 +0300 Subject: [VIM] cve down? In-Reply-To: <48338BFC.4040402@milw0rm.com> References: <48338A31.80307@milw0rm.com> <48338BFC.4040402@milw0rm.com> Message-ID: <200805210842.18117.noamr@beyondsecurity.com> On Wednesday 21 May 2008 05:42:04 str0ke wrote: > security curmudgeon wrote: > > : Anyone else having problems resolving mitre? > > > > Down this morning for a while, and down again now. > > I demand the hamsters to be returned.. Hi, It is not CVE but can be used as a backup :) http://nvd.nist.gov/ -- Noam Rathaus CTO noamr at beyondsecurity.com http://www.beyondsecurity.com "Know that you are safe." Beyond Security Finalist for the "Red Herring 100 Global" Awards 2007 From coley at linus.mitre.org Wed May 21 05:48:18 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 21 May 2008 01:48:18 -0400 (EDT) Subject: [VIM] cve down? In-Reply-To: <200805210842.18117.noamr@beyondsecurity.com> References: <48338A31.80307@milw0rm.com> <48338BFC.4040402@milw0rm.com> <200805210842.18117.noamr@beyondsecurity.com> Message-ID: Sorry all, I'm not close to the issue because I'm in Australia but it's a larger issue that MITRE is taking care of. - Steve From coley at linus.mitre.org Wed May 21 07:53:32 2008 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed, 21 May 2008 03:53:32 -0400 (EDT) Subject: [VIM] Mantis Bug Tracker 1.1.1 Multiple Vulnerabilities In-Reply-To: <48330434.9050402@katamail.com> References: <48330434.9050402@katamail.com> Message-ID: On Tue, 20 May 2008, ascii wrote: > The wrong attribution of CVE-2008-2276 before our official advisory > strengthen our conviction that responsible disclosure isn't always > fair. Just to let you know - we created the CVE after Secunia found a changelog entry (at the CONFIRM in our references section). We did not know anything else about the other issues, but there was enough information in the changelog to know that there was some vulnerability. Your advisory will provide additional details for CVE-2008-2276, and we'll be adding it as a reference... plus, adding the other issues that you mentioned as separate CVEs. - Steve From ascii at katamail.com Wed May 21 12:36:52 2008 From: ascii at katamail.com (ascii) Date: Wed, 21 May 2008 12:36:52 +0000 Subject: [VIM] Mantis Bug Tracker 1.1.1 Multiple Vulnerabilities In-Reply-To: References: <48330434.9050402@katamail.com> Message-ID: <48341764.8030308@katamail.com> Steven M. Christey wrote: > Just to let you know - we created the CVE after Secunia found a changelog > entry (at the CONFIRM in our references section). We did not know > anything else about the other issues, but there was enough information in > the changelog to know that there was some vulnerability. Your advisory > will provide additional details for CVE-2008-2276, and we'll be adding it > as a reference... plus, adding the other issues that you mentioned as > separate CVEs. Thanks Steven for the details, i never like when things with vendor goes wrong, unluckily this was one of them. Our first contact mail includes this sentence: We try to synchronize the disclosure time with the vendor, if the details of the vulnerability becomes public we will immediately disclose the advisory. and this was what happened. Add to this that the only vulnerability that was not going to be fixed (from our knowledge) was the one leaked and credited to Glenn that was the contact on the Mantis side that told us it was not going to be fixed but contemporaneously fixed it and made the changelog line. This confused me and Antonio a lot. Now i know that Glenn did not acted in bad faith and was mostly victim of the fate. For this i want to apologize on my side for the overreaction. The really sad thing is that this situation could have been avoided in a hundred of ways on the vendor side. Have a nice day, Francesco `ascii` Ongaro http://www.ush.it/ From theall at tenablesecurity.com Thu May 22 01:44:40 2008 From: theall at tenablesecurity.com (George A. Theall) Date: Wed, 21 May 2008 21:44:40 -0400 Subject: [VIM] Who's Right? Message-ID: <70FAAF26-0D38-4C9C-85B2-B7D27414440E@tenablesecurity.com> Looking at the ithe buffer overflow announced today in Domino, I noticed IBM suggests that exploitation only results in a denial of service while MWR, the researchers who are credited with discovery, talk about arbitrary code execution with local SYSTEM privileges, for which they claim to have a working PoC for Windows. I wonder who's right... George -- theall at tenablesecurity.com From jericho at attrition.org Thu May 22 01:49:43 2008 From: jericho at attrition.org (security curmudgeon) Date: Thu, 22 May 2008 01:49:43 +0000 (UTC) Subject: [VIM] Who's Right? In-Reply-To: <70FAAF26-0D38-4C9C-85B2-B7D27414440E@tenablesecurity.com> References: <70FAAF26-0D38-4C9C-85B2-B7D27414440E@tenablesecurity.com> Message-ID: : Looking at the ithe buffer overflow announced today in Domino, I noticed : IBM suggests that exploitation only results in a denial of service while : MWR, the researchers who are credited with discovery, talk about : arbitrary code execution with local SYSTEM privileges, for which they : claim to have a working PoC for Windows. I wonder who's right... Doesn't IBM have a history of downplaying overflows, only mentioning the DoS angle? From jms at bughunter.ca Thu May 22 02:08:07 2008 From: jms at bughunter.ca (JM Seitz) Date: Wed, 21 May 2008 20:08:07 -0600 Subject: [VIM] Who's Right? In-Reply-To: <70FAAF26-0D38-4C9C-85B2-B7D27414440E@tenablesecurity.com> References: <70FAAF26-0D38-4C9C-85B2-B7D27414440E@tenablesecurity.com> Message-ID: <4834D587.6020900@bughunter.ca> Is the vuln version still available for download from somewhere? JS George A. Theall wrote: > Looking at the ithe buffer overflow announced today in Domino, I > noticed IBM suggests that exploitation only results in a denial of > service while MWR, the researchers who are credited with discovery, > talk about arbitrary code execution with local SYSTEM privileges, for > which they claim to have a working PoC for Windows. I wonder who's > right... > > > George From jericho at attrition.org Thu May 22 20:29:03 2008 From: jericho at attrition.org (security curmudgeon) Date: Thu, 22 May 2008 20:29:03 +0000 (UTC) Subject: [VIM] Anyone have a contact at wirelessve.org / wve.org? Message-ID: Mail to them is bouncing, and the 'submit entry' form results in: An internal server error occurred. Please try reloading the page. If the problem persists, then please send an email describing what you were doing when this happened to the webmaster (webmaster at wirelessve.org). ---------- Forwarded message ---------- From: Mail Delivery System To: jericho at attrition.org Date: Thu, 22 May 2008 16:23:53 -0400 (EDT) Subject: Undelivered Mail Returned to Sender This is the mail system at host forced.attrition.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : host mail.arubanetworks.com[216.31.249.253] said: 550 5.7.1 Unable to relay for corrections at wve.org (in reply to RCPT TO command) From jericho at attrition.org Tue May 27 04:05:18 2008 From: jericho at attrition.org (security curmudgeon) Date: Tue, 27 May 2008 04:05:18 +0000 (UTC) Subject: [VIM] CORE-2008-0126: Multiple vulnerabilities in iCal In-Reply-To: <48347D22.6000906@coresecurity.com> References: <48347D22.6000906@coresecurity.com> Message-ID: CORE / SecurityFocus, The cross-references between BID, CVE and vulnerability seem to be wrong in both the advisory and BID database. From the advisory: : Multiple vulnerabilities in iCal : : Advisory ID: CORE-2008-0126 : Advisory URL: http://www.coresecurity.com/?action=item&id=2219 : Bugtraq ID: 28629 28632 28633 : CVE Name: CVE-2008-1035 CVE-2008-2006 CVE-2008-2007 : 1) Null pointer de-reference #1 (Bugtraq ID 28629, CVE-2008-2006) : : The 'COUNT' value causes an integer overflow, which leads to a null : 2) Null pointer dereference #2 (Bugtraq ID 28632, CVE-2008-2006) : : The 'TRIGGER' value causes a null pointer dereference when iCal tries : 3) Improper resource liberation (Bugtraq ID 28633, CVE-2008-2007) : : ATTACH;VALUE=URI:S=osumi Yet, looking at the current BID entries: http://www.securityfocus.com/bid/28632 CVE-2008-2006 Apple iCal 'TRIGGER' Parameter Denial of Service Vulnerability http://www.securityfocus.com/bid/28633 CVE-2008-2007 Apple iCal 'ATTACH' Parameter Denial Of Service Vulnerability http://www.securityfocus.com/bid/28629 CVE-2008-2006 Apple iCal 'COUNT' Parameter Integer Overflow Vulnerability -- No mention of CVE-2008-1035 in the advisory other than the header CVE name reference. BID seems to have split the three vulnerabilities, but given two of them the same CVE. CVE does not have descriptions open yet. Could someone from CORE, SecurityFocus or CVE confirm if CVE-2008-1035 is supposed to be in the mix, and if CVE-2008-2006 does correspond to two of the vulnerabilities listed? Brian OSVDB.org From rwann at enovatech.com Thu May 29 16:19:09 2008 From: rwann at enovatech.com (Robert Wann) Date: Fri, 30 May 2008 00:19:09 +0800 Subject: [VIM] Regarding "Enova hardware encryption: False sense of security" Message-ID: <01f401c8c1a7$baa12000$c40aa8c0@enovatech.net> Hello, This is Robert Wann and I am representing Enova Technology. I'd like to respond to your published article about the so called "False Sense of Security" for balanced review. My comments follow my signature line and I look forward to your publishing of our comments (Vendor Comments) to the same sites to balance the view and to give us an opportunity defending ourselves. Thank you and I look forward to hearing from you. Regards, Robert Wann CTO Enova Technology http://www.enovatech.com Office +886 3 577 2767 Fax +886 3 577 2770 -------------------------------------------------- Here Enova Technology comments Speaking of X-Wall not being able to hold the secret of the secret key, it is actually an intended engineering design and has been praised by many well known cryptographers. As X-Wall does not equip with any none-volatile memory and all the secret keys reside in the volatile memory, the security of data-at-rest is guaranteed as long as the power is shut down or the computer goes into hibernation state. The design was meant for the authentication part to hold the secret value as it makes sense that secret key will only be released upon correct authentication. Advantage in this design also guarantee there won?t be a risk of secret been extracted going through sophisticated semiconductor layer extraction method. Speaking of the Enova key fob, there is a reverse diode that safeguards the accidental insertion of the key fob into a real 1394 (firewire) port that carries voltage more than 18 Volts. As a result, damage to the key fob due to mismatch of the firewire port can be avoided. We would agree that a capable engineer would be able to apply electrical wire onto the serial bus and snoop the protocol to get to the secret key. But this is our simplest and basic design which was engineered to educate/show most of our customers how the X-Wall will be actually functioning. To show the exact opposite, we also engineered a sophisticated FIPS certified smartcard authenticated X-Wall design (to view more details, visit our website at http://www.enovatech.net/products/reference/secureusb_pro.htm). Being said, to snoop an electrical protocol maybe still a bit tougher than simply installing a key logger or camera for the password entry. Anyway, to conduct such hot plug electrical protocol attack, the attacker needs to get hold of the key fob as well as the circuit board and X-Walled hard drive. To prevent serial bus sniffing, apply the harden epoxy on the X-Wall such that it creates chemical effect with the molding compound of the X-Wall to effectively avoid such attack as the attempts to use special dissolvent would effectively destroy the molding compound of the X-Wall thus destroy the circuitry. Alternatively, use the FIPS certified authentication mechanism to hold the secret key, which can only be released upon correct authentication. ------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.attrition.org/pipermail/vim/attachments/20080529/314589df/attachment-0001.html From jericho at attrition.org Fri May 30 03:22:39 2008 From: jericho at attrition.org (security curmudgeon) Date: Fri, 30 May 2008 03:22:39 +0000 (UTC) Subject: [VIM] learning from the past (IBM AIX) Message-ID: http://aix.software.ibm.com/aix/efixes/security/ftpd_advisory.asc First Issued: Wed May 21 11:19:32 CDT 2008 CVE Number: CVE-1999-0201 -- http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0201 A quote cwd command on FTP servers can reveal the full path of the home directory of the "ftp" user.