Wednesday, September 26, 2012

Java: Unsafe At Any Version:
Sandboxing is essentially gone

According to the latest testing, there is no safe version of Java available. This affects Java versions 5, 6 and 7 in entirety. The latest version of Java from Apple, v1.6 update 35, is included.

The problem: Sandboxing in Java is no longer reliable. Methods of bypassing the sandbox are being consistently discovered. As a result, website malware applets are able to break through into victim's computers and zombie/bot/PWN them with the user's privileges. If the user is running as Administrator, the machine is entirely controlled.

Conclusion: Turn Java OFF when surfing the web.

I've covered how to turn Java off on OS X in previous posts. You can either:

1) Use the Java Preferences app in your Utilities folder, which is what I recommend.


2) Turn Java off within each individual web browser, which is better than nothing, but prone to user failure.

Only turn Java on when you have already gone to a trusted website that REQUIRES Java. Turn it off again BEFORE you leave that website.

Another approach is to use one specific browser, with Java turned on, for browsing ONLY trusted websites that require Java. Quit the browser before you leave those websites.


All of the recent Java sandbox vulnerabilities are being reported by a Polish software security firm named Security Explorations. Yesterday's Java vulnerability was announced at They provide a timeline of their vulnerability announcements HERE.


Below is a set of links to various articles describing the situation. This issue is best discussed via an interview with Security Explorations CEO Adam Gowdiak in an article by Darlene Storm of Computerworld, which I placed at the top of the list:


Oracle will begin this year's JavaOne 2012 conference on September 30th. That would be the soonest we would see another Java update. The next 'scheduled' update for Java is October 16th. Presumably Apple is poised to release the OS X rendition of that update soon thereafter. (Apple and Oracle have made the OS X JRE, Java Runtime Engine, an open source project).


If all of Security Exploration's reports are correct, I consider sandboxing in Java to be fundamentally broken and unreliable. That this has been the case way back to Java 1.5.x (aka 'Java 5') is a stunner. I haven't kept up with changes in Java over the past several years as I had given up on it as a superior programming language. Clearly, Java has fallen down on its fundamental security goals. I'm not sure it is ever going to get back up. Oracle has proven that they don't have the interest or stamina to provide Java with the serious attention it requires. As I've pointed out frequently, when a company creates a standard periodic security update schedule, you know they're not being realistic. This has been the case with Microsoft and Adobe for years and is repeating itself with Oracle.

I'm not ringing a death knell, but the situation does indicate that there must be a fundamental rewrite of the JRE foundation code for sandboxing. It's not working. It's time for Java 2.0.

Wednesday, September 5, 2012

Apple Releases Patched Java 6, v1.6 Update 35

For the moment, Java is 'safe' again. Apple has provided for Mac users the latest patched version of Java 6, which apparently does not include any of the drive-by infection security holes found plentiful in recent versions of Java 7 as well as older versions of Java 6.

There are two different Java updates:

I) For OS X 10.6 Snow Leopard you'll want to install 'Java for Mac OS X 10.6 Update 10'. You can read about it and download it HERE.
This update configures web browsers to not automatically run Java applets. Java applets may be re-enabled by clicking the region labeled "Inactive plug-in" on a web page. If no applets have been run for an extended period of time, the Java web plug-in will deactivate. 
Please quit any web browsers and Java applications before installing this update.
II) For OS X 10.7 Lion and 10.8 Mountain Lion you'll want to install 'Java for OS X 2012-05'. You can read about it and download it HERE.
This update configures the Java plug-in to deactivate when no applets are run for an extended period of time. If the prior update named "Java for OS X 2012-004" was not installed, this update will disable the Java web plug-in immediately. Java applets may be re-enabled by clicking the region labeled "Inactive plug-in" on a web page.
Please quit any web browsers and Java applications before installing this update.
Again Note: There is NO safe version of Java 7 (v1.7) available for OS X at this time. If you have installed it, you might as well uninstall it and instead install the appropriate Java 6 update from above.

I've noted a lot of confusion on the net about the Java drive-by infection problems. They do NOT affect your use of software on your Mac as long as that software is not accessing the Internet. The only way you can become infected is by browsing the Internet with the Java plug-in activated. To entirely avoid this situation, simply turn Java OFF using the Java Preferences app found inside your Utilities folder. I have covered this subject previously.

If you have Java installed and you must use Java somewhere on the Internet, here is the best strategy:

1) Be sure Java is ON in the Java Preferences app, found inside your Utilities folder.

2) Be sure Java is OFF inside your web browser's preferences for normal web surfing.

3) Visit the website where you must use Java.

4) Turn Java ON using your browsers preferences.

5) Reload the web page and go to work.

6) When you have finished working with that website, turn Java OFF again using the browser's preferences.

I note that Apple discuss how installation of today's Java updates automatically turns Java off. Apple recommend "clicking the region labeled "Inactive plug-in" on a web page" when you need to run Java on that website.

I do NOT like Apple's idea at all as it leaves Java running when we leave that website and surf elsewhere. We do NOT want to go wandering around the web with Java enabled, specifically due to the possibility of yet-another Java drive-by infection security hole being discovered and exploited. My method above is a bit more annoying, but it is SAFE, unlike Apple's potentially dangerous method.

If at some point Apple automatically disable Java every time we leave a website, then we will be safe. Until that time, we're going to have to re-disable Java ourselves.

Just to be clear: No, Apple is not saying they are disabling Java on every new web page. All Apple is doing is deactivating Java "if no applets have been run for an extended period of time." That is all. That is NOT good enough. Please take this warning seriously.

At least we can now go back to using Java. But Java's reputation has become so incredibly poor, thanks to crapcoding at the Java project, that it is well worth remaining wary of using it on the Internet. Using Java while not on the Internet should be fine at this time. There are currently no Trojan horses for OS X that exploit Java security holes.

I hope this helps. If there are questions, please comment below or check out the links I provided in my previous article about this ongoing problem.

Saturday, September 1, 2012

'Legal' Spyware Abuse In World Dictatorships.
And Elsewhere? ->The FinFisher Spyware


While I catch my breath from the Java scandals and we wait for me to finish my yearly Mac malware review...

This was too good to pass up:

Google engineer finds British spyware on PCs and smartphones
FinSpy turning up in dictatorships across the world
By Iain Thomson in San Francisco • 31st August 2012 23:30 GMT • The Register
Two security researchers have found new evidence that legitimate spyware sold by British firm Gamma International appears to be being used by some of the most repressive regimes in the world. 
Google security engineer Morgan Marquis-Boire and Berkeley student Bill Marczak were investigating spyware found in email attachments to several Bahraini activists. In their analysis they identified the spyware infecting not only PCs but a broad range of smartphones, including iOS, Android, RIM, Symbian, and Windows Phone 7 handsets...
Parallel research by computer investigators at Rapid7 found command and control software servers for the FinSpy code running in Indonesia, Australia, Qatar, Ethiopia, the Czech Republic, Estonia, Mongolia, Latvia, and the United Arab Emirates, with another server in the US running on Amazon's EC2 cloud systems. Less than 24 hours after the research was published, the team noted that several of these servers were shut down.
The gritty code details can be found here:

August 29, 2012 • The Citizen Lab
It was developed for Arm7, built against iOS SDK 5.1 on OSX 10.7.3 and it appears that it will run on iPhone 4, 4S, iPad 1, 2, 3, and iPod touch 3, 4 on iOS 4.0 and up... 
This application appears to provide functionality for call logging...
And here:

Analysis of the FinFisher Lawful Interception Malware
Posted by Claudio Guarnieri, Aug 8, 2012 6:31:35 AM • Security Street, RAPID7
It's all over the news once again: lawful interception malware discovered in the wild being used by government organizations for intelligence and surveillance activities. We saw it last year when the Chaos Computer Club unveiled a trojan being used by the federal government in Germany, WikiLeaks released a collection of related documents in the Spy Files, we read about an alleged offer from Gamma Group to provide the toolkit FinFisher to the Egyptian government, and we are reading once again now with the same one being delivered to human rights activists in Bahrain along with some spearphishing attacks. 
We all are very aware of a rising market of Western companies developing and selling malware for the use of government organizations all around the world, but whenever one of these products is found in other geographical areas, the potential political and ethical implications tend to generate interest...
Uh oh.

The method of infecting devices/computers with this 'legal' spyware is not clear. Theoretically, it has to be physically installed onto the devices, either by hand or over a network by someone with administrative access. But it has been used via a Trojan horse.

We've seen FinFisher before on the OS X platform. In the past, FinFisher infected OS X machines via a security hole in the iTunes updater that allowed FinFisher to fake itself as a Trojan horse iTunes Update. That security hole existed for YEARS in iTunes before Apple patched it at the end of 2011. Not Apple's finest security hour.

I've written about 'legal' spyware previously. The one application dedicated to detecting and removing spyware on the Mac platform is MacScan. Unfortunately, MacScan does NOT at this point in time, detect FinFisher. I suspect this will be corrected ASAP, because I will be pestering them. ;-) The MacScan/SecureMac folks have a spyware list and discussion available HERE. I'm no big fan of MacScan as it requires repeated scans in order to catch everything on your system. But for detecting spyware, this is THE application. They provide a free demo version. The program is easy to use.

Some other anti-malware apps are also capable of finding and removing spyware. Check the developer's website for details. I know that Intego's OS X and iOS anti-malware apps scan for and remove related spyware. Because of this iOS spyware revelation, I'm going to begin testing Intego's VirusBarrier iOS for review. Apparently, Intego's VirusBarrier for iOS has not yet been optimized to detect actual spyware FOR iOS. I'll be chatting with Intego about this situation, now that we know about the abuse of the FinFisher spyware.

No doubt there will be further revelations about the abuse of FinFisher and other 'legal' spyware applications. I'll post when something directly relevant to all OS X and iOS users appears.

C U soon with the other half of my 2012 malware summary. Fur shur. No doubt. Not kidding. Count on it. Be seeing you.