Message-ID: <795651f40809160909q7559df5fo869785b505bccb73@mail.gmail.com>
Date: Tue, 16 Sep 2008 12:09:13 -0400
From: "Brian Dowling" <bjd@...plicity.net>
To: bugtraq@...urityfocus.com
Subject: InstallShield Update Agent - Downloads and executes "Rule Scripts" insecurely.

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

Powered by blists - more mailing lists