The Impact to the Enterprise of Blocking Out of Date ActiveX Controls


The push to get modern continues, and one big piece of news last week was our announcement that we are adding functionality to block really old versions of specific ActiveX controls, particularly Java.

http://blogs.msdn.com/b/ie/archive/2014/08/06/internet-explorer-begins-blocking-out-of-date-activex-controls.aspx

Now, this isn’t completely revolutionary. In fact, we’re not even the first ones to do it – Java itself currently tells you when it’s out of date. What it can’t do is tell you if it’s out of date on versions before they added this feature…

http://java.com/en/download/faq/expire_date.xml

And, even if you don’t get a warning, the Java site spells out in no uncertain terms that running old versions is a terrible idea, much like getting involved in a land war in Asia, or going in against a Sicilian when death is on the line.

http://www.java.com/en/download/faq/remove_olderversions.xml

As one of my friends likes to say (I’m pretty sure it’s Aaron who says this, but not positive – what I am certain of is that I totally stole it): if you don’t want to consider your organization a fully owned subsidiary of either the Russian Mafia or the Chinese Government, then don’t run anything other than the latest version of Java, if you have to run Java at all. Not that there’s some magic evil-attractant there, but because just about every organization in the world (by which I mean every organization I have ever spoken to, ever, in any medium) locks in on a specific version of Java and then doesn’t update it. And the bad guys know this, so when a new version comes out with security fixes, they figure out what was broken, build exploits, and then they work, nearly everywhere, for a really long time. Which makes exploiting those vulnerabilities for fun and profit entirely too easy.

So, naturally, when we announced that we want to help people avoid doing one of the most risky things they could possibly do, people immediately began demanding to know how we could stop helping them avoid that. By golly, they want their crusty old Java. Not because of some bizarre emotional baggage and separation anxiety, mind you, but because of app compat. They have stuff that still depends on the old versions of Java.

Which is, itself, a fascinating concept – allowing a software vendor to demand that, to get their support, you have to run unsupported on a framework component that puts you in one of the most vulnerable positions in all of computing. Rather like buying a new car radio that demands to be installed in a 1988 Yugo in order to prevent voiding the warranty, and oh, by the way, that Yugo has a bear in the back. A bear holding a shark.

But in the end, customers have to make a difficult choice, because no good one is left to them. They can have the software that actually helps them make or sell products, keep people alive, pay employees, etc. land in a supported state, or they can just have the platform supported but not have software that actually does what they need to do. And choosing to not go out of business is really a good choice, it’s just a shame that folks have to make the decision to risk catastrophically going out of business with a well-publicized exploit to avoid going out of business in a far less spectacular way. I don’t envy the folks who are put in this position. Particularly as most of the time, this choice is forced by nothing more than a version check – an app refusing to run on an unfamiliar platform like a petulant child, with no technical basis for that demand.

So, my inbox was of course flooded with requests for the KB number of the update so folks could block it from going out, and they could continue to run legacy versions of Java successfully.

Here’s the thing – this is designed as a consumer feature. It’s designed to help people like my mom, who is never, ever going to check for new versions of Java. Like, ever. And, for the enterprise, it’s designed to make it safer when surfing the big bad Internet.

For the enterprise, focus in on this particular part of the article:

“…but not the Local Intranet Zone and the Trusted Sites Zone…”

It bears repeating:

We don’t believe that blocking old versions of ActiveX controls will impact the enterprise because we’re excluding the two zones that enterprise apps live in: Local Intranet and Trusted Sites.

I phrase it as “we don’t believe” very deliberately, because it happens all the time that we have reasoned our way to some conclusion, and we haven’t seen a side of the problem that invalidates our conclusion. So, if you believe you have a reason why this impacts you, and you are an enterprise, then we’re curious to understand the scenario. But otherwise, our expectation is that we’ve built a feature that protects your users when you’re surfing the big bad internet, blocking potentially malicious sites from instantiating a vulnerable control on your users’ devices, while continuing to allow it for internal sites. This feature should make you safer without having a significant compatibility impact.

Comments (3)

  1. Kevin Johnston says:

    *Slow clap* The awesomeness of this blog post makes the reality of dealing with Java in the Enterprise hurt a little less…at least for today. Well done, sir.

  2. Bruce S. says:

    Here is the scenario you seek.  The problem is not all enterprises know which business websites their users use, because departments can (and do) go around IT to get 3rd party web services/apps.  This has made web browser upgrades more painful for us than it should be, and the same goes for Java upgrades.  So to enable this feature we run the real risk of breaking a web based Java applet we did not know about before.  This is kind of good because then we learn more about our own companies IT needs but bad because it puts the users out of commission potentially (or at least aggravates them).

    Over all I like this move because it will help get the message across that the Java JRE and the apps that need it are something to avoid, and it will help us learn more about our own environments.  But that step closer involves some growing pains and that is where the negative feedback regarding this change comes from.  

    My only complaint so far is the logging feature that was announced with this change seems to log to a local file, and I am not certain how to aggregate those logs into something usable so we can start adding sites to the trusted zone.

  3. DonPick says:

    Chris, glad to see you write this functionality up. (kind of waiting-holding-my-breath, actually).

    We do have a few worries about the slightly-ambiguous references for "LIZ-isn't-affected"- there is a reference to a KB, which says "FQDN != LIZ" – which isn't my experience in our auto-detected + proxy-auto-config environment, so I'll be testing that out this week.

    Also, that the new functionality seems to (perhaps not unreasonably) assume that it's ok to be offered a java update on an enterprise pc *if* the user hits an Internet site calling the plugin, the user loads the new java (perhaps the user has admin rights), then, returns to their Intranet enterprise application with their shiny new java version, and, boom, enterprise app is busted.

    Loads of bad things all mixed together.

    I do seem to have quite a large quantity of bears, sharks and petulant children, in my environment.