Friday, April 24, 2009

A Peek at the Compatibility Future

Users enjoy the broad compatibility Windows has. Even 20 year old 16-bit DOS based applications still run on Windows 7. However, the flip side of this is that it has made Windows very hard to maintain for Microsoft and very hard for developers to use.

That is, targeting multiple version of Windows is very difficult. Bugs present in one version and not another meant different run-time behavior for the application. Add to that the complexity that earlier versions of Windows were also fundamentally different depending on which version of Internet Explorer was installed, even the kernel was touched, meant you add a significant number of operating systems to test and debug. Ultimately, the best solution for portable applications for Windows was to use some kind of layer between your application and the operating system, most notably Java. Sun, or whoever, does the heavy lifting and you target one platform.

If you're familiar with Microsoft however, there's one very interesting technology that you just know is the future. The future of compatibility that is. That technology is called MED-V. Yes, it's a stupid name but the technology is far from stupid. MED-V is based on Virtual PC but instead of running a different operating system with a different desktop it runs your applications side by side.

What is stupid however, other than the name of course, is that this technology is currently only for enterprise customers who have volume licensing. This is a very sad state of affair considering that this would allow for a much more streamlined user experience for people who only want the latest and greatest and much greater compatibility for those who do not. What I mean by that is that ever since Vista shipped, Windows is a considerably more modular operating system with the capability to turn various features on or off. The potential still isn't realized today but Windows 7 goes a step further by allowing various applications to be "turned off".

Now, with MED-V, you could go that extra step, on your brand spanking new machine, you could, say, no 32-bit application, so that entire part of the OS goes missing. No resources no nothing. It also means that even if you're running these compatibility modules, it doesn't mean they're running all the time or at the same time. Furthermore, since these are full virtual environments, they're actually a copy of the target OS that the legacy application was designed for. What's also very interesting is even if these are virtual environment, they're running on the bare metal which means you still have the full power of your actual machine unlike actually using a virtual box.

Well everyone who knows about MED-V knows it's the future, well, at least the technology if not the name. This technology would allow for Windows to grow at a faster pace and cut off deprecated APIs and SDKs without breaking compatibility with older applications.

Which brings me to today, Microsoft has unveiled Windows XP Mode (XPM) for Windows 7. This is the same technology that powers MED-V but what it means is that every copy of Windows 7 will ship with a fully licensed copy of Windows XP SP3 for compatibility mode. So if you're a large enterprise with poorly written line of business (LOB) applications, all of them really, you'll be able to depend on this Windows 7 module to run all those applications. If you just happen to not care about this and just consider it bloat, that's fine too, just turn it off. In fact, if you don't really care about any of this, XPM doesn't actually run unless you use something that needs it.

Reviews of pre-release versions of Windows 7 praise how lean it is compared to its predecessor. That you agree with that or not doesn't really matter, thanks to XPM and eventually the full MED-V, you'll be able to turn off huge, gigantic portions of the operating system and developers and users alike will be able to enjoy new versions of Windows that are free from binary compatibility with older applications but nonetheless offer full compatibility which will mean a much leaner, more secure operating system for all.

Monday, April 13, 2009

Google Updater

Google has been very busy this past week making new release after new release. The release however of Google Updater as open source is definitely very interesting.

One of the most annoying aspect of the modern Windows XP/Vista desktop is keeping your applications up to date. That is, you have an auto-update for Windows and other Microsoft software. You have one from Adobe for your Adobe applications, one from Mozilla for Firefox and the same software but yet another instance for Thunderbird. You have one for Vuze, you have one for any number of applications. Keeping all your software up to date today just requires too much work.

It was hoped that with Windows Vista, Windows Update would be opened to 3rd parties beyond the driver space but that hasn't happened.

The availability of a high quality open source application updater for Windows doesn't guanrantee it will become the de-facto standard nor that all companies that end up using it will share the same instance/server on the back end but it may pressure Microsoft to finally open up Windows Update to 3rd parties.

Anyway, I see this as good news and just hope that we will finally see some progress in this area.

Wednesday, April 8, 2009

Let there be Light! (or Java)

Google has just added Java support to their AppEngine framework. Obviously, the main selling point here for using this system besides free resources for up to 5 million page views a month is the database.

AppEngine uses the Big Table database which is a fully distributed, replicated database and you just get it for free.

Now, if Google would just support NetBeans out of the box already.

Monday, April 6, 2009

Secure IPC in OS X - Part 2

I wrote the first of what was intended to be a set of Secure IPC in OS X posts. Instead, Part 2, will be The End.

The idea is fundamentally flawed. The easiest way to see this is to consider that what I was trying to achieve was an escalation to root privileges for a particular operation without any user interaction. This is a security hole with a few easily exploitable vectors:

First, the dynamic validation of code signatures does not work as you might expect - it is only shorthand for validating the files on disk.

Second, I was assuming that the IPC system is secure, as pjulien points out here, any process can inject arbitrary code into any other process of the same privilege level. This means that your process can, without needing to modify any files on disk, be made to execute code that was not written by you.

Third, assuming dynamic validation worked like I wanted it to, then the first two problems would be solved. The third problem is that this option is exposed to a user via a GUI. The GUI of any application can be programatically controlled (for instance, by a unit testing tool).

I'm sure there are other attack vectors that I haven't thought of. The point is, when escalating privilege, you need to implement some kind of barrier to entry that asks a user for permission, otherwise it can circumvented programatically.

It turns out this type of mistake is not uncommon. Microsoft recently committed a similar error with their more friendly UAC system for Windows 7. This article explains how the UAC whitelist in a Windows 7 Beta can be trivially subverted by the second problem (code injection).