background image
first XCP uninstaller was customized for each user so that it would only work for a limited time and only
on the computer on which the user had filled out the second form. This meant, for example, that if a user
uninstalled XCP but it was reinstalled later--say, if the user inserted an XCP CD--the user could not use
the same uninstaller again but would have to go through the entire process again to request a new one.
Customizing the uninstaller is more difficult, compared to a traditional uninstaller, for both vendor and
user, so it must benefit the vendor somehow. Probably the benefit is to the vendor's platform building
strategy, which takes a step backward every time a user uninstalls the software. Customizing the uninstaller
allows the vendor to control who receives the uninstaller and to change the terms under which it is delivered.
As user complaints mounted, Sony-BMG announced that unrestricted uninstallers for both XCP and
MediaMax would be released from the vendors' web sites. Both vendors chose to make these uninstallers
available as ActiveX controls. By an unfortunate coincidence, both uninstallers turned out to open the same
serious vulnerability on any computer where they were used.
8.1
MediaMax Uninstaller Vulnerability
The MediaMax uninstaller used a proprietary ActiveX control, called
AxWebRemove.ocx
, created and
signed by SunnComm. Users visiting the MediaMax uninstaller web page were prompted to install the
control, then the web page uninstalled MediaMax by invoking one of the control's methods. This method,
Remove
, took two parameters:
key
, and
validate url
. When
Remove
was called it issued an HTTP
GET to
validate url
to validate
key
. If
key
was valid, the server at
validate url
would respond
with the message
true,
<uninstall url>, where uninstall url was the URL of a DLL file containing code
to uninstall MediaMax. The control would retrieve this DLL file from the Internet and save it to a temporary
location, then call a function in the DLL named
ECF7
to perform the uninstallation. If the function returned
success, the control would issue a second HTTP GET request to
validate url
to report that the uninstall
was successful and that the single-use key should be retired.
This design is vulnerable because the control accepts an arbitrary
validate url
parameter and does
not check that the DLL supplied by the server at that URL is authentic. The ActiveX control is not itself
removed during the uninstallation process, so its methods can be invoked later by any web page without
further browser security warnings. An attacker can create a web page that invokes the
Remove
method and
provides a
validate url
pointing to a page under the attacker's control. This page can accept whatever
key is presented and return an
uninstall url
pointing to a DLL created by the attacker. When the
MediaMax control executes the uninstall function in this file, arbitrary attacker code will execute on the
user's machine.
8.2
XCP Uninstaller Vulnerability
The XCP uninstaller contains the same design flaw and is only slightly more difficult to exploit. XCP's
ActiveX-based uninstaller invokes a proprietary ActiveX control named
CodeSupport.ocx
. (Early ver-
sions of XCP's rootkit removal patch utilized the same control.) Usually this control is installed in the
second step of the three-step XCP uninstall process. In this step, a pseudorandom code generated by the
ActiveX control is sent to the XCP server. The same code is written to the system registry. Eventually the
user receives an email with a link to another web page that uses the ActiveX control to remove XCP, but only
after verifying that the correct code is in the registry on the local system. This check tethers the uninstaller
to the machine from which the uninstallation request was made. Due to this design, the vulnerable control
may be present on a user's system even if she never performed the step in the uninstallation process where
XCP is removed.
Matti Nikki first noted that the XCP ActiveX control contains suspiciously-named methods, including
InstallUpdate(url)
,
Uninstall(url)
, and
RebootMachine()
[25]. He demonstrated that
22