|
|
|
|
| |
Credit:
The information has been provided by Brian Dowling.
The original article can be found at: http://www.simplicity.net/vuln/CVE-2008-1093.txt
|
| |
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 dependent 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 dependent 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.
CVE Information:
CVE-2008-1093
|
|
|
|
|
