Since I blogged ThinApp – Licensing Issues – Ethics do not ship with the code I have been thinking about the security aspects of VMware ThinApp and similar virtualization technologies such as Microsoft App-V.
I came up with a set of questions to which I searched for some answers:
- ThinApp creates a self contained application within its Bubble. Is it possible for this Bubble to contain a Virus, RootKit, or Worm that could then infect the system on which it runs?
- ThinApp contains a set of libraries that could be less secure than those on the operating system on which the ThinApp Bubble is running. Can the system libraries override those within the Bubble?
- ThinApp contains a mechanism to update the ThinApp Bubble called AppSync, what is the security surrounding AppSync? Could an attacker include a attack payload within such a download?
In essence could ThinApp be used to subvert existing system security?
ThinApp works by creating a self contained bundle of software that interacts through Windows APIs with the ThinApp Virtual Operating System (vOS). vOS interacts with the underlying operating system for you. In effect this is containerizing an application which is a common method to secure applications. In some cases a ThinApp can be built to include many of the system libraries that would normal constitute an API according to the vOS and this is a very important fact as it does not bypass vOS just uses different APIs that the vOS does know. Case in point is .NET.
Can a ThinApp be built with a RootKit embedded?
The answer to is No as many if not most RootKits are built using device drivers. ThinApps can not be built that include device drivers.
Can a ThinApp be built with a Virus or Worm?
Yes, these elements could be part of a ThinApp as ThinApp does not do Virus checking as the Bubble is built.
Can a ThinApp with a Virus or Worm Infect a Host System?
It may be possible that a Virus or Worm could infect the ThinApp Sandbox that is created when a ThinApp client is launched. This is the place in which temporary and local files are written. If a file was written to the sandbox with a Virus was then subsequently opened or accessed by another application within the Guest OS there is a possibility that the Virus or Worm could spread. However, if the sandbox is NOT accessed there is no chance. In addition, the sandbox can be deleted once a ThinApp closes. This possibility may not be much of a risk however.
Can the system libraries override those within the Bubble?
Yes the ExternalDLLs parameter for the resultant ThinApp Bubble can be set to a list of DLLs which will be loaded by the OS. Otherwise, if the DLL is included in the ThinApp it will get loaded within the Bubble.
Could an attacker include a attack payload within an AppSync download?
Yes. but only if they can get between the ThinApp and the AppSync server or subvert your AppSync web server or file server. The security of the AppSync web or file server is entirely within your hands as it is not a part of the ThinApp product suite. You use your own web or file server. If they are insecure then AppSync is insecure.
For non-SSL based AppSync servers such as CIFS or standard http it is possible that a MiTM could occur. After download the SHA1 hash is calculated for the file or blocks downloaded and if they do not match then the update is rejected. However when using SSL, there still could be weaknesses as AppSync depends on the standard Microsoft SSL implementation, with one exception AppSync does check to see if the domain you are accessing matches the domain of any certificate used for SSL.
Unfortunately a successful SSL MiTM attack would have all aspects of the certificate be identical except the fingerprint and perhaps the issuing authority. The possibility of this attack working is based on the fact that the clients do not fully verify the certificates given to them by the server and vice versa. Yet, to do this ThinApp must have the capability built into the vOS (perhaps we can plugin our own verification modules)?
Conclusion
There are security concerns surrounding the use of VMware ThinApp applications, but each risk can be mitigated by increased vigilance. If you are concerned about the sandbox being corrupted, place the Sandbox into a restricted writes container/directory so that other applications can not access it. The other major concern is AppSync, make sure you have good web and file server security.
After all securing your file and web servers is your business and not VMware’s (ThinApp) or Microsoft’s (App_V) responsibility.