VM Junkie

January 5, 2009

Why ThinApp is revolutionary from a security perspective

Filed under: thinapp, vmware — ermac318 @ 1:28 pm

Hi everyone, I hope you all had a great holiday break and a happy new year. I took some time off myself, so in hindsight maybe I should have started the blog post-holiday! But them’s the breaks.

Today I wanted to make a post about ThinApp, and one reason why I think it’s so incredibly important for the desktop; one that few people seem to be pointing out. I’m going to take a leap of faith at this point and assume you’re somewhat familiar with ThinApp. If you aren’t, I highly recommend looking at some of the product info at the previous link, or the product documentation. There’s also an official ThinApp Blog at VMware.

Among ThinApp’s many strengths are surprise, fear application/OS independence, easy application updates and regression testing, and app compatibility. But I think one of the most important points about ThinApp is, somewhat by accident, it changes the permission paradigm for applications to talk to each other. Traditionally, in Windows and pretty much any OS, if you’re running an application, it has access to the other applications you have running. The simplest example of this is I want to cut and paste text from one program to another. Every program has access to the clipboard. What if my computer gets infected with a trojan and that trojan constantly monitors my clipboard for a number resembling a SSN or a Credit Card number?

There’s also much more sinister examples. It’s possible for any application you run to overwrite the memory of any other application you’re running (assuming one’s not a system process or running in another user context). This can be great – it allows applications to talk to each other directly and can give you some cool integration between different applications. But the security implications of it are that every app has full permission to every other app by default, with no real way to deny permission. This is why we run into many of the security problems (and for that matter, compatibility and stability problems) on modern desktops. When we see application vulnerabilities today, usually they scope of the vulnerability is everything the application has access to is potentially compromised. This means that browser remote code execution vulnerability can’t take over the entire machine (because it wasn’t the OS itself that was compromised) but there’s plenty of damage that can be done because for an application, the whole user session is the sandbox.

ThinApp changes this because each application gets its own Virtual OS (VOS) sandbox to play in. Depending on how you build your packages, you can make it so applications can’t see each other, and don’t even see their files. You can even isolate certain parts of the underlying OS from the application so it has no visibility into those areas. This is important because we are now limiting the scope of infection in the case of a security problem. The VOS is now the sandbox, as opposed to the entire user session. And even better, if you build your packages correctly, the infection can be removed simply by deleting the ThinApp sandbox.

The other implication of this is that ThinApp changes permissions between applications to deny by default. By bundling each app in its own ThinApp package, they can’t talk to each other anymore, potentially preventing many malicious or compromised applications for doing their dastardly deeds. Now, I say this changes things to deny by default, not just deny, because with AppLink what we’re essentially doing is granting permission for one application to talk to another.

This is really an important concept to grasp, I think, because from a security perspective this can mean a whole new world of permission granularity. Do I ever need this app to talk to this other app? If not, why do I leave that hole open for someone to potentially exploit? ThinApp reduces your exposure at the desktop in a way that just hasn’t been possible without application virtualization.

Advertisements

1 Comment

  1. Thanks for this really fascinating exploration of ThinApp’s (pre-pun apology) deeper implications. Since you wrote this more than a year ago, I might be too late to ask you this, but I was wondering about the possibilities for a malicious use of this software. Just as a user deploying ThinApp on his own machine could prevent a trojan from establishing a foothold, could a ThinApp-based trojan deployed on a non-ThinApped machine also create an infection that could never be eradicated? Turn the computer back on, and the trojan is back. Just wondering…

    Comment by Craig — February 4, 2010 @ 11:19 am


RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Create a free website or blog at WordPress.com.

%d bloggers like this: