Apple blocks Java 7 Mac plugin in OS X | Hacker News Reader

Apple blocks Java 7 Mac plugin in OS X

9to5mac.com

48 pointstcskeptic51 comments

Seems like people on this thread are OK when Apple remotely fiddle with what they can and can't run on their own machine without a notice. Interesting times.

"Screw your rights and liberties to run what you want on OUR OS X!" -Apple

This is why I chose Ubuntu over Mac OS X. I have a Macbook and OS X 10.7 on it, I got tired of being restricted and locked out. Then I found that Ubuntu was more open and less restrictive. I replaced Windows 8 on my PC with Ubuntu 12.10 and my Acer laptop no longer runs Windows 7 but Ubuntu 12.10 (I won it at a church raffle) and my Macbook now gathers dust, I'll only use it when I get around to developing iOS apps or something. For everything else it is useless to me now.

Seeing how nice the new ultrabooks are in general is really attractive. I'm sure Ubuntu runs pretty well on a Macbook Air as well?

I'm not tied to OSx as much as the build and form factor of my machine.

Truth. At least once a week (sometimes more) I'm tempted to install Arch on my MBP.

Truthfully though, there are some truly incredible tools for developers on Apple… not all are without comparable tools in the Linux world, but it always makes me question myself.

I love my MBA but am due for an 8GB one. I'd be open to dual booting into Ubuntu. There's not much I need from any OS anymore that I can think of, it would be an interesting experiment.

I put Arch on my MBA a while back. I used it exclusively for a while, but ended up going back to OS X. The trackpad drivers just aren't there yet, and with such a limited keyboard I really need the support for 2-, 3-, 4-, and 5-finger gestures.

I just installed Slackware on my 2007 17" MBP because Leopard was EOL'd and I'm not enamoured with Mountain Lion as a development environment. I wish I had done it sooner.

You can run anything you want in OS X. This block for Java is part of a (easily deactivated) security system to prevent malware or critically vulnerable software from compromising your system.

I think you missed his point. :)

Quite possibly! Have re-read, but only see a misinformed comment. What was the point?

Nope not when Apple has the ability to block anything on OS X remotely. You unblocked it, and then they do another check and block it again.

What is to stop Apple from blocking free and open source software in the same way? Say they want you to buy iWork, not use LibreOffice for free, so they put in a block for LibreOffice. Now let's say they don't want you using Firefox or Chrome and they want you to use Safari instead, so they block Firefox and Chrome. Citing that they are all 'security risks' because they are code Apple does not control. BTW LibreOffice and OpenOffice.Org are Java based, and this Java block would stop them from working in the web browser to display documents.

There will come a time with Mac OS X that Apple will lock it down like they did to iOS, and you'll have to jailbreak it to run what you want on it. This will be done for security reasons, of course, to protect the user.

Just turn off the auto update for the blacklist (IIRC, it's in the Security prefpane). "Problem" solved?

Could you elaborate on exactly what you are restricted and locked out from?

For those answering this: when answering, consider this post by patio on the recent rails vulnerability: http://news.ycombinator.com/item?id=5035886

"[...]when this was announced I pushed the Big Red Button and pushed three emergency patches to my servers at 3 to 5 AM Japan time. My perception was "This just can't wait." I went to sleep with the vague feeling that I had probably broken something (there's always something that slips when you're tired and hasty) but that it was almost certainly acceptable given the alternative. [...]"

I know that was not about the machine you own, but frankly, does it matter whether you own or rent a box and whether it is in your or in somebody else's server room? In both cases, it is about third parties with the power to (partially) disable the code you run.

They are also OK with Apple stopping other people from running code on their machines.

What you see as "Apple is remotely fiddling", my grandmother likely sees it as "Apple fixed something for me" (if she were to become aware of what they did).

Don't assume your perspective or belief is shared by vast majority of users.

Is a slippery slope the concern here, or is it just a matter of principle that nobody should be allowed to mess with your machine unless you give them permission to?

In this specific case, I don't have a problem with this security fix/decisions. I'm also they glad they did this for my parents since they use Mac's at home, and I'd rather things like this be fixed silently rather than me having to explain some complicated popup that showed up asking they to turn off "Java".

Mozilla is blocking Java as well, keeping hundreds of millions of Firefox users safe.

Mozilla Security Blog: Protecting Users Against Java Vulnerability

https://blog.mozilla.org/security/2013/01/11/protecting-user...

It appears that Mozilla has changed Java applets to "Click to Play". On the other hand, Apple has completely blacklisted the current version of Java. This may affect corporate users where they need access to Java applets for internal intranet applications. In FF, they would still be able to use the applet if needed. I think the Mozilla method strikes the better balance between protecting the end users and allowing them to use the browser as intended.

Those same corporate apps nearly always require IE.

And, realistically, those corporate apps probably work perfectly fine with Apple's depreciated JVM. Oracle's JVM has been in the wild for about 5 months.

This link is awful. This [1] is a much better link, and the source of this news according to 9to5mac.

[1] http://www.macrumors.com/2013/01/11/apple-blocks-java-7-on-o...

Apple has blocked only Java applet browser plugin from Safari. Java can still be run on OS X.

That's little comfort for the hundreds of universities whose business logic and data is tied up in Banner, which is a horrible Oracle Forms mess on the client ("Internet Native Banner"), which requires a web browser with a working Java plug-in...

(Imagine your company held a contest to design the worst CRUD application that uses the Web somehow but isn't actually a web application. That's Internet Native Banner.)

So organisations that rely on Java applets (such as some online banks and others) can expect a lot of support calls around now.

Difficult to know what to suggest in such a circumstance, do you give the customer instructions about how to override this and let them risk getting pwned by some random site?

Or do you just tell them they can't use the service anymore until they do a full rewrite?

I'm wondering what happens to corporate Macs where the users require Java in the browser to do their job. Is there any kind of trouble Apple could get into for removing this without warning when corporations have specifically installed what they need to work?

Yeah, my last employer did all their accounting in an Oracle ERP system that was built on Java Applets. They would be screwed right now if they were using Mac machines.

I could be wrong about this, but it sounds like if you go in and edit Xprotect.plist manually to remove the Java plugin from the blacklist, Apple will just update it again and blow out your changes within a day or so.

Safari (the only one getting the block) isn't even the most popular browser on OSX. Chrome + Firefox have 10x more users than Safari on Macs.

Thank you for the clarification. I was wondering how Apple blocks plugins from other browsers. Both articles I saw did not care to mention that only Safari plugins (and probably third party browsers that use the mac webview like Fluid.app) are blocked.

We have a Java applet used by many large companies and we have found there are very few corporate Macs out there.

Unfortunately while they may be rare, they do exist. My company has a hundred or so. We're a Java shop, and most of our stuff is home-grown (so it might not be on the list of sales for corporate Java packages). I'm not sure if we had any fallout from this or not.

Well well well! Great job at blocking Java, Apple. Stop those bastard virus writers from spreading their malicious code. On the other hand, I assume this happened silently since I didn't notice a thing. Would be good to show an extra forced popup message saying, look, we disabled Java for you because it's a total shitstorm outside at the moment. But if you really need it, do x y z to (temporarily) disable the block or to whitelist certain applications/sites. Now that'd be a sweet security system! Arggghh!

I'm not sure I agree that Apple should try to explain to the users what they did. It is really hard coming up with one message to communicate something to tens of millions of people. The end result is often confusion or panic--both of which I would not want to see in my users if I am Apple.

What if you need to enable access to Java 7 again on your Mac machine? Is there a setting you click that says, "I know the risks, let it run anyway."?

I find it hard to believe that a consumer desktop PC can be remotely controlled like that and leave NO input to the user.

Overall: This is interesting, because of how huge of a Java/Tomcat house Apple is in-house.

In a browser: Java, like anything has it's bugs. Hopefully the stewards of Java for the browser keep it current.

The current vulnerability affects environments where untrusted code already executes. Since applets can be used to upload arbitrary code, it makes sense to block it.

This isn't a political move I don't think, just a common sense mitigatory move to protect people. Web apps running Java are safe from this vulnerability, unless they're accepting user-supplied code and running it.

That's a great clarification and fact that sadly may be lost in the dramatics of the headline, either done on purpose or someone didn't understand before submitting.

I thought the same thing too… I only read "Apple blocks Java 7…"

The "…Mac Plugin" part was completely lost in my skimming.

Sucks for people with VPNs that are java applet based.

I was able to get my java-applet-based VPN working again by temporarily re-enabling Apple's Java SE 6 applet plugin: http://support.apple.com/kb/HT5559

Did they already push the blacklist file update to all Mac machines? Or is it bundled in a software update that OS X is going to ask me to install when I get home from work and wake my MacBook up?

This is not distributed via Software Update, but via Apple's XProtect malware protection system and should be updated silently in the background. You can check /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist to see if it's up to date. To force an update, run "sudo /usr/libexec/XProtectUpdater" or "sudo launchctl start com.apple.xprotectupdater".

Well, Java sucked, Apple blocked it.

If you pretend your technology to be secure, but constantly fail in that aspect, you'd expect this kind of result.

It also seems like a big failure of the OS/browser that it can't be sandboxed effectively.

The point of Java is that it has access to things at system level. If you don't need that, use HTML.

That is the point of trusted java applets that you opt in to, but not to standard applets that do something like animate a scientific model.

Java handles sandboxing, but there is no reason the OS couldn't provide a backup. When something wants to run with elevated permissions you would get a prompt from Java, and then a prompt from the OS/browser. If Java had an exploit bypassing its own prompt, the OS and/or/in-conjunction-with browser would still prompt as soon as it tried to do something that required elevated permissions.

Chrome does its own back-up sandboxing for Flash, even though Flash is supposed to do it itself, but Chrome lets other plugins slide (because Chrome doesn't have a notion or interface for user-controlled elevated permissions in its sandbox):

http://productforums.google.com/forum/#!topic/chrome/err6mfb...

This is the failure I'm referring to. It is a concious decision and not an unintentional mistake, but it is still full of fail.

Chrome used to have a --safe-plugins option that is mentioned in the linked thread and could have attempted to prevent something like this exploit and still allowed something like a Java-animated lava lamp or whatever.

Well, Java in its very core idea is supposed to be safe in the first place, because of the restrictive programming model that leads also to problems in efficiency. And if the entire idea of abstraction and safety does not work, what's the point of Java overall? I'd better use C++ then.

What's being exploited is an insecure API. Can you explain how this is different than finding a bug in a browser's JS implementation, or finding a kernel bug that lets you perform local escalation of privilege?

It's simple. Java inventors/developers once said: this new language is entirely safe because it runs on a virtual machine and prohibits any insecure operations, maybe a bit slow, but now we will finally get rid of all the buffer overruns and similar security breaches that we were so used to with the good old C/C++. It's safe now! And here we go again, exploits are routinely found in what used to be the totally safe and isolated environment. C/C++ can be safe and reliable as well, except infrequent bugs and exploits — you cannot absolutely get rid of bugs, because what involves the humans will never be solved at 100%. But in this case Java and native code appear the same from the security perspective: exploits are found here and there. What's the point of Java then entirely? What does it give except slowdown, memory consumption and restrictions?

Personally I believe the only proper way to implement security isolation is with hardware support. Native/sandboxed/virtual machine — does not matter, It is proven now by Java's fail.

Did you notice the part where this affects every OS and browser?

This is a flaw in Java, not any operating system or browser. Java, across all platforms, provides a way to execute native code if you have the correct permissions to do so. A way was found to exploit this by getting access to a raw classloader using MBeans. Once you have access to that classloader you can do whatever you want.

Please do not try and turn this into an OS war.

I wasn't making this an OS war, as I didn't recommend any alternative OS/browser. See my later comment, since I wasn't very detailed in the initial one.

Reply on news.ycombinator.com