-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SUMMARY InstallShield Update Agent - Remote "Rule Script" Code Execution Vulnerability. OVERVIEW InstallShield Update Agent uses insecure methods of retrieving operational script code from unauthenticated, unverified external sources over HTTP. Arbitrary remote code execution is possible on all known product versions. DESCRIPTION InstallShield Update Agent connects to and communicates with centralized Acresso (formerly Macrovision) FLEXnet Connect servers for updates and other product information on a periodic basis. From the vendor's site: FLEXnet Connect lets you electronically deliver applications, patches, updates, and messages directly to your users' systems. When connecting with this service, the client agent reports its product GUID, current version information and finds out what updates for relevant installed software are available. The client can also receive special instructions (Rules) to help it evaluate if an update is relevant. These rules are in the form of an active scripting language, such as VBScript. Unfortunately, these rules are delivered insecurely, over HTTP, both unencrypted and unsigned as they are blissfully executed by the client. Exploitation by injecting code into these rules can result in completely arbitrary execution on the client side, and could thusly perform any action such as installing or downloading additional malicious code and instructions from an arbitrary source. This execution could potentially happen completely transparently and go unnoticed by users. Such exploitation could take place by a number of mechanisms. For example: a) Compromising the FLEXnet Connect servers directly. b) Filtering client system traffic through malicious proxy. d) Utilizing DNS insecurities to cause any of the above. e) Also, by directing clients to malicious website, ActiveX objects can be used to trigger the exploit on the attacker's schedule, (but MiTM mechanisms may still be needed to support this). (Note this list is by no means exhaustive.) Due to the purpose of these products, it has been observed that systems will check for updates unattended and thus could be compromised without any intervention needed on the client side. Systems often check for these updates on reboot (autorun) and on configurable periodic basis. Note that updates DO NOT need to be installed to provoke this issue. This flaw takes effect when the system is evaluating if updates are relevant. It has also been observed that the recent versions of the InstallShield will contact the server, download and execute this "Rule information" even if you have disabled all automatic updates for your installed products. Presumably this is part of the "compulsory updates" feature of the product. This obviously is cause for additional concern. Some vendor products may also include methods that call the update mechanisms internally. This may happen at program startup or through the "Check for Updates" link often provided in the Help menu of such applications. Note also, that in addition to the above flaw. There also appear to be flaws in the implementation and use of these services. It has also been noted that vendors largely appear to ignore the apparent signature capabilities of the product to provide cryptographic signatures for the actual executable update files that are downloaded and executed -- largely over HTTP. This implies additional paths of code execution using the MiTM techniques mentioned. These paths have not been explored in depth, but appear to exist due to the lack of signature information in updates. The update information itself is not signed, so it is not clear what trust chains are used to verify this information if it was provided. This problem of course is not isolated to this product, but many online update mechanisms in general. IMPACT Any client system using products that have update mechanisms built on the InstallShield/FLEXnet Connect product line are vulnerable. This includes many Microsoft Windows systems that often ship with software pre-installed by the OEM. For example, some popular CD burning software appears to use the IS update services pointed at their own servers and is a very widely-deployed application. Any vendor or provider hosting the FLEXNet update services should also be concerned of this issue. As a result of this flaw, the security of their servers is critical as it could impact the of all client systems, and thus represents a liability to any customers dependant on their services. Due to the broad reach of these products, there are many software vendors that must be informed of this issue and provide some form of remediation to protect their installed customer base from these issues. Unfortunately it was impossible to know everyone who uses this product at the time of this release. It is assumed that the vendor has/will taken the actions they deem appropriate to notify its customer base. SOLUTION No vendor provided solution is known at this time. The vendor largely discounts the issue, implying that it may be difficult to exploit and that following best practices to secure the server systems would prevent this from being exploited. They have provided a brief document to this effect, unfortunately they also tagged it as confidential and I cannot release it. The vendor said they will release it when this information is published. With the addition of the Kaminsky attack, this is just another reason why you must be sure your DNS is update to date, and be proactive as new protection mechanisms come out for DNS. WORKAROUND Unfortunately, there is no good workaround to prevent this issue while still allowing critical updates for other products dependant on this platform for distribution. Enterprises that have proxy capabilities could disable access to the GetRules.asp URLs that are used to download the script instructions, however this may have consequences to programs that depend on the rules for determining patch applicability. The only way to be comfortable that you fully prevent the risk of this issue for users that are concerned with the security of their systems is to disable this automatic update program for the time being. For InstallShield, this includes removing any Autorun entries for ISSCH.EXE, ISUSPM.EXE, and possibly setting the Kill bit for any related ActiveX controls (isusweb.dll), that remain enabled (See references for one patch related to this -- it is not clear to me they covered all GUIDs with these patches). Some users may wish to rename the "\Program Files\Common Files\InstallShield\UpdateService" or related UpdateManager folders of other products to prevent automated execution of these programs until a fix is provided. Unfortunately this workaround is clearly a catch-22 as other critical updates to products that depend on these services may now be overlooked as well. Use this information at your own risk. Absolutely no warrantees expressed or implied! REFERENCES This issue has been assingned CVE-2008-1093 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1093 Also published at http://www.simplicity.net/vuln/CVE-2008-1093.txt http://www.kb.cert.org/vuls/id/837092 These prior issues are related, but are distinct from this bulletin. http://www.kb.cert.org/vuls/id/524681 http://www.kb.cert.org/vuls/id/847993 http://www.kb.cert.org/vuls/id/181041 CREDIT This issue was discovered and disclosed following responsible disclosure procedures by Brian Dowling of Simplicity Communications. HISTORY This time-line is mostly here to keep track of work and progress on this issue. However it does highlight one important thing. Vendors need to provide valid, secure, contact information that can get security issues reported to the proper individuals within their organization. This contact information should be clearly published on their public facing web sites. 12/05/2007 - Initial Discovery 12/12/2007 - Contacted Cert Coordination Center to attempt to obtain appropriate vendor contact information. 12/17/2007 - Additional work on details, proof of concept interim - No response from Macrovision either directly or through Cert (who kept in constant contact with me). 01/02/2008 - Posted to product request site for security contact information. 01/08/2008 - Automated sales response, asking how "Product Evaluation" is going. 01/18/2008 - In contact with sales representative @ Macrovision 02/05/2008 - Attempted to contact Product Technical Support 02/06/2008 - Technical Support call back - forwarded me back to "Product Coordinator" (local Sales Contact). 02/07/2008 - Contacted by Director of Product Management for Macrovision 02/08/2008 - Sent vendor vulnerability details 02/21/2008 - Resent information, vendor was unable to decrypt 03/03/2008 - Vendor responds "We are reviewing the materials and will provide a public response shortly." 03/10/2008 - Inquired if they have been able to reproduce. Similar response to above, "..public response in the coming days" 03/21/2008 - Inquired, was told they were crafting a public response. 04/01/2008 - Product vendor splits off software business, InstallShield now owned by Acresso Software. 04/24/2008 - Vendor provided "Acresso's official response" which they do not appear to have yet published publicly, and I feel I cannot due to the following legal tagging: "This document contains proprietary trade secrets of Acresso Software Inc. Receipt or possession does not convey any right to reproduce, disclose its content, or to manufacture, use, or sell anything that it may describe. Reproduction, disclosure or use without specific authorization of Acresso Software is strictly forbidden." 07/01/2008 - Given the lack of further vendor response and the duration that I had known about this vulnerability, I was starting to prepare to release. 07/08/2008 - Critical Kaminsky DNS Vulnerability came to light, re-ignited my concern over release of this information. 09/03/2008 - Contacted vendor again, requesting URL for their public response, informed them of my intent to publicly disclose. 09/05/2008 - I was told that vendor will publish their response when my findings are published. 09/16/2008 - Public disclosure. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFIz8B5iIA5Ggt0XiYRAtLHAJ4l/9s/MQftoE7oHjpGs9ZBmiqlBwCggKh6 J2HYOa0X7hYEOsgz3RFbjAs= =HG3Q -----END PGP SIGNATURE-----