On January 31, 2012, in the middle of the day for many users, Apple silently and stealthily blocked the Java web plugin on all Mac computers running 10.7 or 10.8.
This has not been getting that much news coverage, which is unfortunate given how serious this action actually is. And, of course, we all know that if Microsoft did something similar, it would be making national headlines on many news sites.
There’s a bit of history to be told here. Apple chose to maintain tight control over Java for their operating systems for many years. Even in the classic Mac days (OS 9 and prior), instead of allowing users to obtain versions of the Java runtime directly from Sun, Apple released their own builds of JRE through their Software Update service. Why this wasn’t considered anti-competitive is beyond me, especially considering that Microsoft is permanently prohibited from distributing copies of Windows 9x, even for free, because they included their own version of JRE with those operating systems.
At any rate, the release of OS X 10.7 (Lion) brought with it a major development in Java for Mac – Apple was withdrawing from the Java market and releasing control of JRE builds to Oracle. Users are no longer bound to Apple’s software release schedule when it comes to updating (or downgrading) Java.
So what exactly happened here?
On January 10, the United States Department of Homeland Security released a security advisory stating that there was a serious security flaw in Java 7, and users were recommended to disable the Java web plugin until Oracle patched the flaw. The next day, Apple disabled the Java web plugin using their built-in antimalware technology. The flaw found by DHS was confirmed to be exploited in the wild, and there was known, published code available to exploit the flaw. Much like what happened yesterday, Apple implemented this “fix” without warning and without an option to circumvent it.
Mozilla did something similar with their popular Firefox browser. However, instead of blanketly disabling the plugin without providing users with an alternative, Mozilla opted to simply enable “Click to Play”, which gives the user a one-click enable for Java the first time a website tries to use the plugin.
Oracle released an update for the Java plugin on January 13. Because Apple’s method of disabling the plugin just changed the minimum required version, the update automatically allowed Java to start working again in Safari (and Chrome, since it uses Safari’s plugin implementation).
Everything was happy again, right?
Wrong. A proof-of-concept vulnerability was found yesterday in the web plugin for Java 7. Unlike the previous security hole, which was announced by DHS as being knowingly exploited in the wild via malicious websites, this one appears to be theoretical only, with no known exploits. Apple’s response was to, yet again, block Java from all Internet-connected Macs.
It’s easy to understand why they did this. They saw a security hole and wanted to fix it until Oracle patched it. The problem is in how they decided to implement their fix.
It is never okay to disable core functionality in a user’s operating system without notifying that user and obtaining their consent to do so – or, at the very least, providing a workaround to re-enable that functionality. For home users, this action prevented people from playing certain browser-based games or using legitimate websites that require Java. This is an annoyance, but not disabling for most home users.
The problem here is with businesses and enterprise environments. Why was Apple able to take such a serious action without needing root access? Why was it possible for this update to be pushed to machines in managed environments where the logged-in user doesn’t have any elevated rights in OS X? The workaround requires root access, since it involves editing a plist file and changing a security setting that requires admin rights to change. With this being the case, does this mean that Apple has a root access backdoor that allows them to make system changes at their discretion, regardless of whether or not the user has that same administrative access?
If this assumption is true, we have a serious problem on our hands. Theoretically, Apple could silently push any changes they felt appropriate to thousands of business machines in environments where those changes haven’t been tested and approved for use in those enterprise environments. These changes that Apple deems necessary may break business-critical software. If they aren’t providing a way to revert these changes, what is their answer for businesses?
Why should any business, large or small, invest time, money, people, and other resources into implementing Macs if this is the risk that must be taken? This situation doesn’t even touch the myriad other reasons why Macs in enterprise IT are more trouble than they’re worth. Even if you’ve managed to make everything else work the way it should with your servers and software and infrastructure, all of that falls apart as soon as your operating system manufacturer decides it’s okay to push system changes to your managed machines without your knowledge or consent.
Then you turn around and look at Windows, which does system management through Group Policy. A simple change to how Windows Update works allows an IT admin to make sure that none of his machines are able to get any updates from Microsoft. This is critical in many business environments, where a seemingly innocuous Windows update can completely cripple legacy software a company may rely on to function.
Until Apple is able to recognize the very different needs of IT in the business world, and until Apple is able to learn to accommodate those needs in a truly uncompromising way, they are not going to gain traction in the most profitable sector of the computer hardware market. One would think that a company as big as Apple would be able to recognize this, but it appears that their continuing desire to maintain godlike control over their products has superseded their ability to address the needs of the enterprise.