Apple updates Safari, gives better control over Java applets

Filed Under: Apple, Apple Safari, Featured, Java

Apple has pushed out a Safari update to go along with this week's Java Tuesday fix.

Apple's browser goes to version 6.0.4 on OS X 10.7 and 10.8 (Lion and Mountain Lion), and to 5.1.19 on Macs that are still running 10.6 (Snow Leopard).

The key change that the new version brings to the party is finer-grained control over Java applets in the browser.

At this point, you're probably asking yourself, "Why?"

After all, as regular Naked Security readers will know, we've been suggesting for nearly a year that you should turn Java off in your browser altogether, unless you are certain that you need it.

We even recorded a dedicated Techknow podcast entitled All about Java to help you make up your own mind on how to manage the risks.

We weren't alone in proposing such a blunt-edged tool to deal with the threat from browser-based Java exploits.

Homeland Security's US-CERT team in the United States said something similar, and so did our chum Brian Krebs.

But our advice hasn't been universally popular.

Some readers and listeners hit back at us for being unworldly, pointing out that an all-or-nothing approach to Java in the browser just isn't practical in their world.

→ One reader, a contractor to an aerospace company that relies on website Java for outsiders to upload their work, pointed out that for him it was a choice between getting paid and following our advice. Other readers told us that their financial institutions insist on browser-based Java for internet banking. And some sysadmins noted that they were required to support in-house applets that wouldn't work with the latest Java versions, forcing them not only to enable Java but also to leave it unpatched.

Even users who were keen to take our advice were stuck at the thorny question, "How do I know whether I need Java or not?"

So Apple has headed towards a middle ground in which Safari allows you to authorise some applets, blocks others outright, and asks you what you want to do with all the rest.

The feature appears in the Security tab in Safari's Preferences pane:

The Allow Java tick-box isn't an all-or-nothing option any more, sporting as it does a shiny new Manage Website Settings... button next to it.

When you first enable Java, all applets on all sites are in an "ask me" state, provoking a question like this when you come across them:

Annoying though this may seem, it's actually a good way of helping you answer that question, "What do I need Java for, if anything?"

Once you've encountered an applet-serving web page, you can click into the Manage Website Settings... window and choose one of four options for the future:

There's a subtle difference between Allow and Allow Always, and it's important to understand it.

The former option will run the relevant applet next time you visit the page, provided that you've kept your Java installation up-to-date; if you haven't, you'll get a handy warning:

The latter option, Allow Always, overrides the version check, and is obviously intended for use only in stubborn cases, such as legacy applets that require an older, insecure Java version.

As Apple advises:

This setting is only recommended for trusted websites that require the Java web plug-in, such as websites that are only accessible on your company's intranet.

For sysadmins who support OS X users on a corporate network, or for contractors like our aerospace worker above, this feature is a good starting point for a "have your cake and eat it" approach to Java in the browser.

But it is far from perfect, not least because there's no easy way to pre-populate the allowlist, and no way to lock down the blocklist.

So, even in an environment where users are keen to do the right thing, mistakes are not only possible, but likely, especially when it comes to the free-for-all Allow Always option.

Intrepid sysadmins, however, might be willing to knit their own scripts for pre-configuring the allowlist (for example, to pre-authorise a set of intranet applets) after taking a look Safari's plist file.

Use the plutil (property list utility) command to dump your Safari configuration in human-readable form:

If you've added any applets to the control list via Safari's warning dialogs, you'll see how they are recorded near the end of the XML data:

The four possible values of the Manage Website Settings options shown above are encoded into the PluginPolicy key as one of four strings:

The plist is usually in binary format, but if you convert it to XML and edit it, Safari itself will happily load the XML version next time you start it.

With that, a determined sysadmin should have enough information to write a script that automatically populates users' WhitelistedBlockedPlugins settings with an appropriate applet list.

And that, in a nutshell, is the new "control Java in your browser" feature in Safari, at least on OS X.

Windows users of Safari, assuming there are any left, are out of luck: as far as we can tell, Safari for Windows is still back on version 5.1.7, which came out last year.

, , , ,

You might like

One Response to Apple updates Safari, gives better control over Java applets

  1. David Pottage · 907 days ago

    This looks to be a good step in the right direction, that I wish other browsers such as firefox would implement, however I think there is room for improvement,

    Firstly I don’t think that there should be a modal dialog box that the user has to click on. We know in security that if you present the user with an OK/Cancel dialog box then they will often click quickly on the wrong thing from a security point of view without engaging critical thinking.

    A better approach would be to have a more subtle information bar notification like most browsers do with popups these days along the lines of “Safari has blocked an applet from from running. To enable it click here”. That way when the average user visits their online banking site it will be obvious that it is not working, and they will look for a fix and click on enable, but if their favorite web forum gets hacked then they are less likely to notice the dialog and enable the applet.

    The other improvement I would suggest is that the whitelist of allowed applets should be done via the signing key on the applet rather than the origin domain, as if a site that you have already whitelisted gets hacked then the bad applet will also be allowed to run, but hopefully applet authors are more protective of their private signing keys (they don’t need to be on the webserver), so hackers are unlikely to be able to sign their malware using a trusted key. It would still be possible to whitelist individual unsigned applets by their checksum, so the user would only have to reauthorize an applet if the website replaces it with a new version.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog