Windows 7: Windows Vista Lite?

There's no denying that Vista was a failure. A complete and utter disappointment. An unmitigated disaster. Microsoft have even essentially admitted it themselves, finally accepting what users, reviewers and wary businesses have been saying since before it even hit the shelves. It just didn't bring enough benefit for its significant cost (early estimates were talking about $5k per seat to upgrade by the time you deliver new hardware, support it and train users), users hated it and some have even called it the most serious technical misstep in computing history. The fluff (transparent windows et al) exacted a heavy toll on the hardware and the delicate minimum requirements 'balance' was way off - set it too high and nobody can afford your software; too low and those who do complain about inadequate performance. Plus the long overdue security system was invasive and yet still largely ineffective.

The reality is that while XP has been 'good enough' for most users, Google and friends have been quietly the playing field from the corpse littered battlefields of operating systems and file formats to (now) mostly standardised browsers. It simply doesn't matter now what your operating system is, and between Firefox's rise to fame and so many heterogeneous mobile devices converging on the Internet it's long since been impossible for webmasters to deny admittance to non-IE (and therefore non-Windows) clients.

In arriving at this point Free & Open Source Software (FOSS) has proven itself a truly disruptive force. Without it there would be no Google and no Amazon Web Services (and quite possibly no Amazon!). While Linux on the desktop may be a pipe dream, it's carved a large slice out of the server market (powering the vast majority of cloud computing infrastructure) and its adoption is steadily rising on connected devices from mobiles and netbooks to television sets. There are multiple open source browsers, multiple open source scripting engines (to power web based applications), a new breed of client architecture emerging (thanks in no small part to Google Chrome) and even Microsoft are now talking about unleashing IE on the open source community (for better or worse).

So how did we get to Windows 7 (and back onto a sensible version numbering scheme) anyway? Here's a look from an architecture point of view:

• Windows 1/2: Rudimentary text based environment, didn't introduce mouse/arrow keys until 2.x. Something like XTree Gold (which was my preference environment at the time).
• Windows 3: A revolutionary step and the first version of Windows that didn't suck and that most people are likely to remember.
• Windows 95/98/ME: Evolution of 3.x and the first real mainstream version of Windows.
• Windows NT 3.5x/4.0: Another revolutionary step with the introduction of the vastly superior NT ('New Technologies') kernel.
• Windows 2000/XP: Refinement of NT and the result of recombining separate development streams for business and home users.
• Windows Vista: Bloat, bloat and more bloat. Available in at least half a dozen different (expensive and equally annoying) versions, but many (most?) of its sales were for downgrade rights to XP.
• Windows 7: Tommorow's Windows. Vista revisited.

Before I explain why Windows 7 is to Vista what Windows Millennium Edition (WinMe) was to Windows 98 (and why that isn't necessarily such a bad thing), let's talk quickly about the Microsoft's MinWin project. Giving credit where credit is due, the NT kernel is really quite elegant and was far ahead of its time when unleashed on the world over a dozen years ago. It's stable, extensible, performant and secure (when implemented properly). It's also been steadily improved through 3.51, 4.0, 2000, XP and Vista releases. It must be quite annoying for the bearded boffins to see their baby struggling under the load heaped on it by their fellow developers, and therein lies the problem.

That's why the MinWin project (which seeks to deliver the minimum set of dependencies for a running system, albeit without even a graphics interface) is interesting both from a client, and especially from a cloud computing point of view. While MinWin weighs in at forty-something megabytes, Vista is well over a thousand (and usually a few gigabytes), but the point is that Microsoft now know how to be slim when they need to be.

Now that the market has spoken with its feet Microsoft are paying attention and Windows 7 lies somewhere on the Vista side of the MinWin to Vista bloat scale. The interface is a significant departure from Vista, borrowing much from other wildly successful operating systems like OS X, and like OS X it will be simpler, faster and easier to use. This is very similar to Windows ME's notoriously unsuccessful bolting of the Windows 2000 interface onto Windows 98, only this time rather than putting a silk shirt on a pig we should end up with a product actually worth having. This is good news, especially for business users who by this time will have already been waiting too long to move on from XP.

Conversely, Azure (their forthcoming cloud computing OS) is on the MinWin side of the bloat scale. It is almost certainly heavily based on the Windows 2008 Server Core (which follows Novell's example by evicting the unwanted GUI from the server), needing to do little more than migrate the management functions to a service oriented architecture. If (and only if) they get the management functions right then they will have a serious contender in the cloud computing space. That means sensible, scalable protocols which follow Amazon and Google's examples (where machines are largely independent, talking to their peers for state information) rather than simply a layer on top of the existing APIs. Unfortunately Microsoft Online Services (MOS) feels currently more like the latter (even falling back to the old school web management tools for some products), but with any luck this will improve with time.

Provided they find the right balance for both products, this is good for IT architects (like myself), good for Microsoft, and most importantly, good for users. Perhaps the delay was their strategy all along, and why not when you can extract another year or two of revenue from the golden goose of proprietary software? In any case we're at the dawn of a new era, and it looks like Microsoft will be coming to the party after all.

HOWTO: Reverse engineer the iPhone protocols

A few months back ('Apple iPhone 2.0: The real story behind MobileMe Push Mail and Jabber/XMPP Chat') I analysed how the iPhone interacted with the new MobileMe service with a view to offering the same features to Google Apps customers. Unfortunately this is not yet possible (the APIs don't exist on both sides of the fence) but we learnt a lot in the process.

For those of you who have been living under a rock, MobileMe (previously known as .Mac) is Apple's faure into cloud computing. It offers some impressive synchronisation and push services, but for a relatively steep annual subscription. One of the most coveted features is push mail, which makes e-mail behave more like instant messaging; as soon as the mail hits Apple's servers they notify the clients which then retrieve the item. Technically that's 'pull' with notifications rather than 'push' per se, but the result is the same; the user experience for email improves dramatically. They do similar things with contacts and calendar items. Due to popular demand (and making good on my promise to elaborate), here's a brief explanation of how it was I got 'under the hood' of the iPhone's encrypted communications with the MobileMe servers.

The first problem was to see what it was talking to. We've got a Mac household and a bunch of VMs (Windows, Linux and some other strange stuff) so I set up internet sharing on one of them and installed Wireshark. This allowed me to capture the (encrypted) traffic, which was terminating at aosnotify.mac.com:5223. Although we couldn't decipher the traffic itself we already knew a fair bit from the server name, port number and traffic patterns; whenever a test mail arrived there was a small amount of traffic on this connection followed immediately by an IMAP poll and message retrieval. 'AOS' presumably stands for 'Apple Online Services' (a division that's at least 15 years old assuming it still exists) rather than Australian Online Solutions (which is what I translate 'AOS' to) and 'notify' tells us that they have a specific notification service, which reconciles with what we observed. Most importantly though, network port tcp/5223 was traditionally used by Jabber (XMPP) chat servers for encrypted (SSL) traffic; that reconciled too because Wireshark dissectors were able to peer into the SSL handshakes (but obviously not the data itself, at least not without the private keys stored safely on Apple's servers and/or SSL accelerators).

The next problem was to tell the iPhone to talk to us rather than Apple. There's a number of ways to skin this particular cat but if I remember well I went with dnsmasq running in a Linux VM and simply configured the DHCP server to use this DNS server rather than those of the ISP. Then it was just a case of overriding aosnotify.mac.com's IP with the address of the VM by adding a line to the /etc/hosts file. That worked nicely and I could not only see the iPhone hitting the server when it started up, but could see that it still worked when I wired port 5223 up to the real Apple servers using a rudimentary Perl/Python proxy script. At this point I could capture the data, but it was still encrypted.

I now needed to convince the iPhone that it was talking to Apple when in fact it was talking to me; without a valid certificate for aosnotify.mac.com this wasn't going to work unless Apple programmers had foolishly ignored handshake failures (that said, stranger things have happened). Assuming this wasn't the case and knowing that this would be easily fixed with a patch (thereby blowing my third-party integration service out of the water) I started looking at the options. My iPhone was jailbroken so I could have hacked OS X or the iPhone software (eg by binary patching aosnotify.apple.com with aosnotify.<mydomain>.com) but I wanted a solution that would work OOTB.

Conveniently Apple had provided the solution in the iPhone 2.0 software by way of the new enterprise deployment features. All I needed to do was create my own certification authority and inject the root certificate into the iPhone by creating an enterprise configuration which contained it. I'd already played with both the iPhone Configuration Utility for OS X and the official Ruby on Rails iPhone Configuration Web Utility so this was a walk in the park. Deploying it was just a case of attaching the.mobileconfig file to an email and sending it to the iPhone (you can also deploy over HTTP I believe). Now I just needed to create a fake certificate, point the proxy script at it and start up the iPhone.

Sure enough this worked on the first attempt and I was even able to peer into the live, cleartext connection with Wireshark. Although I was surprised with the choice of XMPP's publish/subscribe functionality, it makes a good deal of sense to use an existing protocol and what better choice than this one (though I wonder if Cisco's acquisition of Jabber will have any effect). This discovery would have come as a disappointment for those touting the discovery of the private XMPP libraries (who naturally assumed that this translated to an Instant Messaging client like iChat), but it is interesting for us cloud architects.

Critical 0-day exploits in Enomaly ECP released... by Enomaly!?!

In what could well be the single most crass act of stupidity of the year (giving even Dell's attempted trademarking of 'Cloud Computing' a run for its money), small Canadian outfit Enomaly's "Founder and Chief Technologist" Reuven Cohen released a draft advisory for critical vulnerabilities on his company blog this weekend, including exploits but failing to provide a fix:

CVE-2008-4990: Enomaly ECP insecure temporary file creation vulnerabilities

Synopsis

All versions of Enomaly ECP/Enomalism use temporary files in an insecure
manner, allowing for symlink and command injection attacks.

2. Impact Information

Background

Enomaly ECP (formerly Enomalism) is management software for virtual machines.

Description

Sam Johnston of Australian Online Solutions reported that enomalism2.sh uses
the /tmp/enomalism2.pid temporary file in an insecure manner.

Impact

A local attacker could perform a symlink attack to overwrite arbitrary files
on the system with root privileges, or inject arguments to the 'kill' command
to terminate or send arbitrary signals to any process(es) as root.

Exploits

a. ln -s /tmp/target /tmp/enomalism2.pid
b. echo "-9 1" > /tmp/enomalism2.pid

While claiming it to be the fruit of a vendetta 'fueled on a potent mix of rage and red bull', he downplayed the vulnerability as 'relatively minor', exhibiting a stunning display of cluelessness and blatant disregard for Enomaly ECP's users' safety (assuming they actually have any). Furthermore, saying that it 'should not effect anyone with decent dom0 access rules' is like a safe manufacturer claiming that it's ok if their safes have a default '12345' code (while publishing that code) because people should be locking their doors and windows anyway. Let's be clear; vulnerabilities like this are extremely serious even when there are no local users, as a flaw in any system (like the Moodle vulnerability a few weeks back) can be turned into an absolute nightmare by an attacker, who would be able to overwrite arbitrary files and send 'kill' signals to arbitrary processes, with root privileges.

I hate to disappoint, but the vulnerability was discovered purely by accident while (unsuccessfully) trying to make the software work for the (since abandoned) freenomalism fork. When viewing the startup script (enomalism2.sh) the flaw stands out like a dog's crown jewels, in the third define and before the first line of active code. No doubt there are many others if this chestnut is sitting 3 lines in, so until such time as the company develops an interest in securing their products anyone using them in production needs to have their head examined. Security is of paramount importance in a virtualised environment where a myriad untrusted applications run alongside each other on common hardware.

Fortunately the one-line fix for those of us who do care about security is trivial:

22c22
< PIDFILE=/tmp/enomalism2.pid
---
> PIDFILE=/var/run/enomalism2.pid

Anyway, so long as Enomaly persist with doing more damage than good to the cloud computing revolution (for example, by running closed 'interoperability' forums, convincing others to write a hopelessly biased book for them - and O'Reilly to publish it, bashing anything that doesn't fit their own limited view of the world, etc.) I'll continue to have very little positive to say about them.

Update: InfoWorld apparently didn't do much research before writing 'Startup Of The Week: Enomaly'. "There are about 15,000 users of Enomaly's platform" *cough*BS*cough* - I haven't been able to find one production user (nor get any of its releases working at all for that matter) and their ~150 user community is choked with spam (yes, that's a full 2 orders of magnitude embellishment!). They did get this right though: "Potential customers should try before they buy. Download its free software first, then sign an enterprise license if all goes well". Don't forget to patch it too - three weeks have passed since they were notified of this critical vulnerability and still nothing except this lame attempt to make me look like an idiot for finding it - apparently they're too busy talking abroad to put the fires out at home. Class act Reuven; did you learn how to behave like a child from your ex-employee?

Virtual Google Search Appliance is here...

I've been quiet of late as I've been busy racking up the frequent flier miles last month or two, but I'm back (albeit busy) and will endeavour to work through a backlog of posts, even if that means spending less time on them and leaving the Pulitzer Prize to someone else. While I wait for it to download I thought I'd let you know about today's announcement of a Google Search [Virtual] Appliance (which I've been hanging out for, under NDA, since 2006!):

Ever wanted to write code against Google search technology, test your apps, and see how it all integrates into your development environment without having to pay a thing? If you're an IT administrator, you'll have that chance with the new virtual edition of the Google Search Appliance. The Google Search Appliance virtual edition is for non-commercial, development purposes only, and gives developers the opportunity to test against the features of the physical Google Search Appliance.

The Google Search Appliance virtual edition provides a free test bed for the Google Search Appliance - our solution for securely searching enterprise content behind the corporate firewall - helping ensure a smooth transition to the production-ready hardware. If your organization is considering adopting an enterprise search solution, the virtual edition platform gives your team the flexibility to build applications against the Google Search Appliance, try different configuration scenarios, explore proofs-of-concept and test the APIs supported by Google enterprise search technology. As part of testing with the virtual edition, you can:

• Index up to 50,000 documents
• Use the Connector Framework to index proprietary document repositories
• Use the Feed API and metadata search to index information with unique formats
• Use Onebox to retrieve information from real-time services
• Take the authentication and secure search capabilities for a test drive
• Customize the search results page, or extract it in XML format for use on another web site

These features might come in handy, particularly if your existing environment contains the array of legacy systems, databases, servers and integration architecture typical of most large organizations. And because it's free, your boss might give you an extra week's vacation just for trying it out (don't quote us on that). You can download Google Search Appliance virtual edition software onto any server that is supported by VMWare virtualization. To learn more and get started, click here. And since we always love feedback, feel free to drop by our developer community or send your thoughts to enterprise-gsa-virtual@google.com.

Well it's almost done, but I'm not holding my breath as it wants 3Gb of RAM and I didn't have the patience for Apple to custom build a 4Gb MacBook for me the other week so I've only got 2Gb. I wonder what it would take to get it up and running on a large instance of EC2?

Update: It works (albeit slowly), and it looks surprisingly standard (Linux 2.6.20 - CentOS 5 I think); maybe EC2's not out of the realm of possibility after all:


Update 2: Having kicked the tires for a while I'm already thinking about the possibilities. Now that the GSA has broken its shackles to expensive, proprietary hardware the world is its' oyster, and while the license prohibits production use, that's an administrative rather than a technical hurdle. Locking down the licensing (currently the MAC address is mashed up and digitally signed along with various feature and URL count restrictions, but MAC addresses are malleable with virtual machines) and ensuring performance meets acceptable standards on uncontrollable (virtual) hardware are two obvious (if optional) hurdles. That said, expect to see something happen in this area as the competition is already offering free, downloadable search solutions; indeed I wouldn't be surprised if there were already virtual GSAs in production.

I'd really like to see Google supported for Australian Online Solutions' upcoming CloudSearch product, so getting it up and running on EC2 would be nice even if only to prove the concept. Assuming there's no non-standard kernel hacks then migration shouldn't be that hard, and even if there were they would have to be released under the terms of the GPL per my thus far unanswered public request. That said, user selectable kernels (AKIs) and ramdisks (ARIs) on Amazon's EC2 are currently only available to Amazon and a select few others so said modifications (if any) would have to be injected via a loadable module for now.

Watch this space...