Oracle Releases Java 7 Update 13 to Address Security Issues, Reenable Web Plug-in on OS X

[Negritude]

Originally Posted by sseaton1971

If you had Java 6 from Apple on your system, I believe the command line will display that information even if you installed Java 7 from Oracle over the top. I think installing the JDK version of Java 7 will update the command line as well. Perhaps someone else here knows that information.

That's correct. The command line tools are for DEVELOPERS. To update the command line tools, you need to install the JDK, not just the JRE. If you only install the JRE, then the command line tools will remain the same.

----------

Originally Posted by mrkgoo

Is there an Apple update for Java 1.6.0_37 -> 1.6.0_39 for Mountain Lion?

Some stuff I did required Java and it got it from Apple. Is the only way to update now from Oracle?

There is no Java 6 update for Lion or Mountain Lion. Java 6 is EOL. Oracle and Apple will completely abandon it at the end of the month.

[1Alec1]

Originally Posted by fahlman

When will we get a proper Preference Pane? It's little things like this that tells me they are doing as little as possible to support Java on Mac OS X.

CTM I know. It's really sketchy.

[1Alec1]

Originally Posted by OrganMusic

Amen to that. Nice link too. Every time I have to fix someone's PC they usually have toolbars taking up half the screen.

How often do you see Babylon search? Have you ever seen Bonzi Buddy?
Once Babylon goes public, it's a sure victory to short sell it. They only make malware.

[MagnusVonMagnum]

Originally Posted by justperry

Several reasons I linked him to that page.
3. I am on OS X since the beginning and never had anything on my mac, so again why write in a post "naive" when the chance is soooooo low it won't affect you if you follow that page.

I've never had a virus or hack or most other malware (and only one trojan that AVG caught immediately that I shouldn't have downloaded from an untrusted source) on Windows in the past 14 years either. That alone doesn't mean threats don't or cannot exist. I'm not saying OSX isn't reasonably secure, but invulnerable? It's the attitude I don't like seeing. It doesn't hurt to be cautious and aware (if I had been either I wouldn't have downloaded a trojan in Windows that one time in 14 years either).

But hacking is another matter altogether. Despite someone pointing out Safari didn't get hacked the last time, it HAS been hacked several times before. Flash has had known vulnerabilities along with (obviously) Java. OSX itself has had numerous security patches over the years. Those were real vulnerabilities that could have been exploited. That doesn't mean YOUR computer will get hacked (if this were true, everyone's computer running Windows would be toast), but it does mean it's not invulnerable just because it hasn't happened yet.

A lot of hacking probably doesn't happen to OSX simply because hardly anyone uses OSX as a commercial web or file server so what incentive is there to hack it? You don't hack your neighbors Mac if you're a criminal (that's for phishing). You go after big fish like credit card companies and what not. They're not likely to be running Macs. If they were, they'd get targeted too.

One only need look to jailbreaking and other hacking tools that use exploits in iOS or OSX and its associated hardware (in the case of AppleTV Generation 1) in order to install custom software that Apple really doesn't want you installing (e.g. XBMC and other media programs that support more than just Apple codecs).

[munkery]

Originally Posted by MagnusVonMagnum

I've never had ....

A system can't be hacked if the runtime security mitigations prevent remote code execution. Mac OS X hasn't been hacked and no methods have been demonstrated to do so since the introduction of position independent executables (PIE), which Windows doesn't include.

Almost all patched vulnerabilities only allow denial of service (crash) but are not exploitable (code execution) even without runtime security mitigations. Runtime security mitigations make exploitable vulnerabilities not exploitable unless the mitigations can be bypassed. No methods have been demonstrated to bypass the runtime security mitigations in Lion and Mountain Lion.

The market share argument is invalid. For example, iOS only has slightly less market share than Android but iOS doesn't have any malware. The easier target is always targeted more.

There was the one example of adware for iOS but Apple quickly eliminated it. Recent audits have shown that 23 of the top 500 apps in Google Play do basically the same thing as that iOS adware but Google hasn't removed them. Apple cares about security more than its competition.

Microsoft and Google implicitly pay for the production of propaganda against Apple by funding the computer security industry via sponsorships of hacking contests and conferences. Researchers don't bite the hands that feed them. This is a common bias in all types of research.

The only reason iOS is still being jail broken is that the runtime security mitigations, specifically ASLR, in 32 bit operating systems can be defeated via brute force methods. Also, the bootrom exploits typically used to jailbreak iOS devices are not the type of exploits that can be leveraged via remote code execution so these exploits have no value in relation to malware and remote hacking. With the available runtime security mitigations, iOS wouldn't be jail broken if it was 64 bit.

[Tech198]

Originally Posted by munkery

iOS wouldn't be jail broken if it was 64 bit.

Well, maybe Apple should make it 64-bit. They have it in their desktop OS's, unless its a chip limitation they chose not go with in mobile devices.

[MagnusVonMagnum]

Originally Posted by munkery

A system can't be hacked if the runtime security mitigations prevent remote code execution.

Yes, that's like saying a Microwave can't cook something unless it's turned on. It's precisely the exploits present in computer systems that get around such provisions. Some hackers use other methods to get into systems as well like taking advantage of poor password protection. NOTHING is 100% secure. But keep on typing refutes over and over and over and over and over and over and over just to make yourself feel superior about something you're dead wrong about (i.e. implying OSX is 100% secure; the Java exploit alone proves OSX systems are vulnerable, let alone all the exploits Apple has addressed in OSX...oh, but someone didn't actually get to take advantage of one of those exploits so they don't exist? Yeah right. )

Mac OS X hasn't been hacked and no methods have been demonstrated to do so since the introduction of position independent executables (PIE), which Windows doesn't include.

Hacking is not just remote code execution, guy. I hacked my AppleTV to run XBMC. I jailbroke my Gen2 AppleTV to run XBMC. If Apple's operating systems were 100% secure, that would not have been possible. They are exploitable. PERIOD.

The market share argument is invalid.

Bullcrap. It's basic logic. If there are no OSX web servers, none can be attacked. If a bank is not running OSX, then OSX can't be attacked there. If there are no valuable targets running OSX, no one will bother to attack them. And again, I never was or am talking about viruses here. And if you're talking about malware, I can point to several recent trojans. But apparently Apple takes OSX security more seriously than you do (thank God).

I mean seriously, people like you just want to say smugly to your Windows friends that OSX doesn't have malware or viruses and is perfectly secure when only one of those is true (so far).

For example, iOS only has slightly less market share than Android but iOS doesn't have any malware. The easier target is always targeted more.

iOS has had several cases of apps getting approved that violated their conditions. A security exploit can be as simple as getting around Apple's approval team. I just downloaded MAME for iOS disguised as a single open game (Gridlee). If Apple cannot figure out that they've got an app available that breaks their rules and does things they do not want it to do, how easily might someone make an app that does one thing but has a hidden back door in it to allow something unscrupulous to go on? How long until Apple catches it? You act like all security risks are just remote executions. Bologna. Unless you encrypt your e-mails, ANYONE monitoring can read them, etc. etc. Nothing is 100% secure. Some brainiac always finds a way to break into systems formerly considered unbreakable. But I say again they won't bother if there's nothing of value there (i.e. your neigbhors house running a home server).

Microsoft and Google implicitly pay for the production of propaganda against Apple by funding the computer security industry via sponsorships of hacking contests and conferences. Researchers don't bite the hands that feed them. This is a common bias in all types of research.

Do you seriously think I give a crap who pays for what? If the exploits are there, they are there. Google and Microsoft didn't create those exploits. Frankly, Apple should kiss their hind ends for finding them for them since otherwise, some unscrupulous person might find it first.

The only reason iOS is still being jail broken is that the runtime security mitigations, specifically ASLR, in 32 bit operating systems can be defeated via brute force methods.

Ah, so the ONLY reason your iOS system is NOT SECURE AT ALL is that they can hack the living crap out of it!!!! Thank you for PROVING 100% your arguments are total crap.

Point. Score. Win.

Also, the bootrom exploits typically used to jailbreak iOS devices are not the type of exploits that can be leveraged via remote code execution so these exploits have no value in relation to malware and remote hacking. With the available runtime security mitigations, iOS wouldn't be jail broken if it was 64 bit.

Yes, because 64-bit software cannot be broken...EVER.

Seriously, dude, you encompass the entire reason I replied in the first place. People make some tiny minor point that it's naive to believe your system is 100% invulnerable to "bad guys" doing something to it (and yes that can involve breaking into your house, stealing your computer or iPhone and using brute force methods on it that aren't "remote"). You have admitted such methods can and do work and that exploits have been found via contests supposedly funded by Google and Microsoft in Apple's software in the past. How in the WORLD does equate to complete and total safety in the OSX environment?

I have not had my Windows machine exploited in 14 years and two computers, but that in NO WAY proves it cannot be done. I'm no hacker so I can't talk tit-for-tat about methods, but I do know that systems formerly considered secure (even defense department sites) have been hacked before by boy geniuses that find some way into their systems. China is constantly trying to attack our systems any way they can (even if that means funding moles/bribes/whatever) and I've had credit cards replaced by the parent company before because their servers were breached. Some states have had their tax records stolen (I got a notice about that before too) and I know of at least one defense computer that was stolen when the person took it out in public where it was not ever supposed to be in the first place and it was considered breached. These are not OSX, but they are supposed to be secure systems. The reason they are not OSX is that NO ONE USES IT in those industries. It's not really marketed as a business computer. It's FAR easier and safer to dupe Mac users (many whom know squat about computers and therefore are easy prey) with phishing scams anyway.

[sireShonBohn]

...

----------

Originally Posted by MagnusVonMagnum

I have not had my Windows machine exploited in 14 years and two computers, but that in NO WAY proves it cannot be done.

Such is your impression at least. For all you know you've been downloading spyware to your windows computer through "Windows Update" for the past decade.

It's interesting because you're very certain that OSX is insecure, but very certain that YOUR OS has been 100% secure. Interesting, interesting, interesting. Wait, hmm, no, not interesting actually, my bad. This is just more delusional fan boy nonsense, wake up to the real reality, we have all, I mean ALL been HACKED, spied on, compromised, whatever you want to call it if you make use of a computer it's been done.

[ulyssesric]

Confirmed. The new Java 7u13 passed security lock in both Safari and FireFox. A warning message will still pop-up though.

So there WAS a nasty exploits discovered last week.

[munkery]

Originally Posted by Tech198

Well, maybe Apple should make it 64-bit. They have it in their desktop OS's, unless its a chip limitation they chose not go with in mobile devices.

It's a chip limitation.

----------

Originally Posted by MagnusVonMagnum

Yes, that's like ...

Please read the following and my other posts in this thread this again:

1) Until Vista, the admin account in Windows did not implement DAC in a way to prevent malware by default. Also, Windows has a far greater number of privilege escalation vulnerabilities that allow bypassing DAC restrictions even if DAC is enabled in Windows.

Much of the ability to turn these vulnerabilities into exploits is due to the insecurity of the Windows registry. Also, more easily being able to link remote exploits to local privilege escalation exploits in Windows is due to the Windows registry.

Mac OS X does not use an exposed monolithic structure, such as the Windows registry, to store system settings. Also, exposed configuration files in OS X do not exert as much influence over associated processes as the registry does in Windows.

Mac OS X Snow Leopard has contained only 4 elevation of privilege vulnerabilities since it was released; obviously, none of these were used in malware. Lion has contained 2 so far but one of these vulnerabilities doesn't affect all account types because of being due to a permissions error rather than code vulnerability.

The following link shows the number of privilege escalation vulnerabilities in Windows 7 related to just win32k:

http://cve.mitre.org/cgi-bin/cvekey....yword=win32k+7

More information about privilege escalation in Windows 7:

http://www.exploit-db.com/bypassing-...vista7-mirror/ -> guide to develop exploits to bypass UAC by manipulating registry entries for kernel mode driver vulnerabilities.

https://media.blackhat.com/bh-dc-11/...nelpool-wp.pdf -> more complete documentation about Windows kernel exploitation.

http://mista.nu/research/mandt-win32k-paper.pdf -> more complete documentation about alternative methods to exploit the Windows kernel.

http://threatpost.com/en_us/blogs/td...net-bug-120710 -> article about the TDL-4 botnet which uses a UAC bypass exploit when infecting Windows 7.

2) Windows has the potential to have full ASLR but most software does not fully implement the feature. Most software in Windows has some DLLs (dynamic link libraries = Windows equivalent to dyld) which are not randomized.

http://secunia.com/gfx/pdf/DEP_ASLR_2010_paper.pdf -> article overviewing the issues with ASLR and DEP implementation in Windows.

Also, methods have been found to bypass ASLR in Windows 7.

http://vreugdenhilresearch.nl/Pwn2Ow...tExplorer8.pdf -> article describing bypassing ASLR in Windows 7.

Mac OS X has full ASLR implemented on par with Linux. This includes ASLR with position independent executables (PIE). DLLs in Windows have to be pre-mapped at fixed addresses to avoid conflicts so full PIE is not possible with ASLR in Windows.

Using Linux distros with similar runtime security mitigations as Lion for a model, client-side exploitation is incredibly difficult without some pre-established local access. Of course, this is self defeating if the goal of the exploitation is to achieve that local access in the first place.

See the paper linked below about bypassing the runtime security mitigations in Linux for more details.

http://www.blackhat.com/presentation...slr-slides.pdf

The author only manages to do so while already having local access to the OS.

3) Mac OS X Lion has DEP on stack and heap for both 64-bit and 32-bit processes. Third party software that is 32-bit may lack this feature until recompiled in Xcode 4 within Lion. Not much software for OS X is still 32-bit.

But, not all software in Windows uses DEP; this includes 64-bit software. See first article linked in #2.

4) Mac OS X implements canaries using ProPolice, the same mitigation used in Linux. ProPolice is considered the most thorough implementation of canaries. It is known to be much more effective than the similar system used in Windows.

http://www.blackhat.com/presentation...rman-paper.pdf -> article comparing ProPolice to stack canary implementation in Windows.

5) Application sandboxing and mandatory access controls (MAC) in OS X are the same thing. More specifically, applications are sandboxed in OS X via MAC. Mac OS X uses the TrustedBSD MAC framework, which is a derivative of MAC from SE-Linux. This system is mandatory because it does not rely on inherited permissions. Both mandatorily exposed services (mDNSresponder, netbios...) and many client-side apps (Safari, Preview, TextEdit…) are sandboxed in Lion.

Windows does not have MAC. The system that provides sandboxing in Windows, called mandatory integrity controls (MIC), does not function like MAC because it is not actually mandatory. MIC functions based on inherited permissions so it is essentially an extension of DAC (see #1). If UAC is set with less restrictions or disabled in Windows, then MIC has less restrictions or is disabled.

http://www.exploit-db.com/download_pdf/16031 -> article about Mac sandbox.

http://msdn.microsoft.com/en-us/libr...(v=VS.85).aspx -> MS documentation about MIC.

https://media.blackhat.com/bh-eu-11/...xes-Slides.pdf -> researchers have found the MIC in IE is not a security boundary.

6) In relation to DAC and interprocess sandboxing in OS X in comparison with some functionality of MIC in Windows 7 (see #5), the XNU kernel used in OS X has always had more secure interprocess communication (IPC) since the initial release of OS X.

Mac OS X, via being based on Mach and BSD (UNIX foundation), facilitates IPC using mach messages secured using port rights that implement a measure of access controls on that communication. These access controls applied to IPC make it more difficult to migrate injected code from one process to another.

Adding difficulty to transporting injected code across processes reduces the likelihood of linking remote exploits to local exploits to achieve system level access.

As of OS X Lion, the XPC service has also been added to implement MAC (see #5) on IPC in OS X. (http://developer.apple.com/library/m...CServices.html)

7) Security benefits of a UNIX foundation

Not all software vulnerabilities are exploitable. Vulnerabilities that are not exploitable only allow a denial of service condition upon being triggered. Exploitable vulnerabilities allow code execution when triggered.

There are two methods to achieve code execution in relation to buffer overflows:

1) RET overwrite -> control return address of instruction pointer

2) SEH (structured exception handler) overwrite -> control content of handler that will be executed upon an exception

To clarify:

Basically, SEH overwrites provide a second method to exploit a vulnerability in the event that a RET overwrite is unsuccessful or not exploitable. Obviously, more vectors being available to facilitate exploiting a vulnerability increases the number of vulnerabilities that are exploitable. SEH overwrites reduce the number of vulnerabilities that only produce a denial of service condition.

Mitigations have been developed to prevent SEH overwrites. These include SafeSEH and SEHOP. Methods are known that allow bypassing both mitigations.

SafeSEH is bypassed if only one component of the program doesn't implement this mitigation; it is common that not all components implement SafeSEH.

SEHOP is bypassed if ASLR is compromised via a memory disclosure vulnerability.

So, what does this have to do with the security benefits of a UNIX foundation?

UNIX and UNIX-like operating systems, such as Mac OS X and Linux, don't have structured exception handling. So, SEH overwrites, as a vector to increase the number of exploitable vulnerabilities, doesn't exist in these operating systems. The signalling system used in these operating systems isn't liable to this type of manipulation.

SEH overwrites do provide a plausible explanation for more vulnerabilities being exploitable in Windows.

http://www.i-hacked.com/freefiles/Ea...ploit_v1.3.pdf

http://www.sysdream.com/sites/defaul...s/sehop_en.pdf

8) Windows has far more public and/or unpatched vulnerabilities than OS X.

http://m.prnewswire.com/news-release...110606584.html -> article about 18 year old UAC bypass vulnerability.

9) Password handling in OS X is much more secure than Windows.

The default account created in Windows does not require a password. The protected storage API in Windows incorporates the users password into the encryption key for items located in protected storage. If no password is set, then the encryption algorithm used is not as strong. Also, no access controls are applied to items within protected storage.

In Mac OS X, the system prompts the user to define a password at setup. This password is incorporated into the encryption keys for items stored in keychain. Access controls are implemented for items within keychain.

Also, Mac OS X Lion uses a salted SHA512 hash, which is still considered cryptographically secure. It is more robust than the MD4 NTLMv2 hash used to store passwords in Windows 7.

http://www.windowsecurity.com/articl...ord-Part1.html -> article about Windows password hashing.

10) The new runtime security mitigation improvements to be included in Windows 8 have already been defeated.

http://vulnfactory.org/blog/2011/09/...op-mitigation/

To put this into perspective, methods to bypass the new runtime security mitigations in Mac OS X Lion are not yet available.

11)In regards to recent earlier version of Mac OS X:

The following article relates to varying levels of security mitigations in different Linux distros but it is applicable in revealing that the runtime security mitigations in some earlier versions of Mac OS X prior to Lion were far from inadequate.

http://www.blackhat.com/presentation...slr-slides.pdf

While Mac OS X Leopard/SL lack full ASLR, Windows Vista/7 have stack canaries (aka stack cookies) that are trivial to bypass.

The following link shows the issues with stack canaries in Windows. -> http://www.blackhat.com/presentation...rman-paper.pdf

So:

Windows Vista/7 = NX + ASLR
Mac OS X Leopard/SL = NX + stack cookies

These articles show that NX in combination with stack canaries is more difficult to bypass than a combination of NX and ASLR.

12) Mountain Lion only improves upon the security of Lion.

BTW, Safari on a Mac running Lion was not hacked at the last pwn2own.

[dvs]

I'm running Java 6 under OS 10.8 because I like to use Chrome, which conveniently warns me whenever I visit a page with a Java applet, asking me if I want to run the applet. Java 7 doesn't work with Chrome.

Apple's latest move disabled Java 6 for me as well, but I edited the XProtect.meta.plist file to undo it, and turned off further updates.

Honestly, I feel pretty safe with Chrome's warning, allowing Java to run only on sites that I trust.

My questions: Can I update my Java 6 and if so, how? And is there any compelling reason to ditch Chrome and switch to Java 7?

[dvs]

To those who are saying we should just abandon Java (or at least Java browser plugins)...

I use Java applets in a way for which there is no workable substitute: educational physics simulations. The best examples of these are on Paul Falstad's web site, though I've also made a few of my own. Most of them are far too computationally intensive to port to Flash or HTML5. They could be ported to native code on various platforms, but this isn't practical because (a) nobody has the resources to do multiple ports and maintain them all; and (b) it's not reasonable to expect students to install new software on their computers just for the sake of working one or two homework problems, especially when some of them are using shared computers where they don't even have the ability to install software.

It saddens me that such a useful tool, which has been available for nearly two decades, is now apparently going away when there is no workable substitute.

[Negritude]

Originally Posted by dvs

Can I update my Java 6 and if so, how? And is there any compelling reason to ditch Chrome and switch to Java 7?

No, Java 6 is obsolete and discontinued. It won't be getting any more updates (well, maybe one last one sometime around the 19th, and then that's it).

The only solution is to update to Java 7 and disable Java 6, if you care about security. If you want to take the risk, then continue using Java 6 with it's security holes. This isn't that complicated. It's not about features, it's about the security of your machine. Java 6 is dead. Just accept that.

This is an Oracle decision, not Apple's. In fact, on Windows, users are being upgraded from Java 6 to 7, automatically.

[C DM]

Originally Posted by dvs

I'm running Java 6 under OS 10.8 because I like to use Chrome, which conveniently warns me whenever I visit a page with a Java applet, asking me if I want to run the applet. Java 7 doesn't work with Chrome.

Apple's latest move disabled Java 6 for me as well, but I edited the XProtect.meta.plist file to undo it, and turned off further updates.

Honestly, I feel pretty safe with Chrome's warning, allowing Java to run only on sites that I trust.

My questions: Can I update my Java 6 and if so, how? And is there any compelling reason to ditch Chrome and switch to Java 7?

You can use Firefox, or Safari, (with Java 7) when you need to, for Java-related purposes.

[Rygaard]

Originally Posted by Northgrove

It's Java updates all the way down.

you are very clever young man, but its Java updates alle the way down

[podiki]

ehm, installed the latest update, still says 1.7.0_09...

ronin:~ podiki$ java -version
java version "1.7.0_09"
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)

[gnasher729]

Originally Posted by tlinford

Every-time Apple blocks, it shuts me out of my medical care, every-time Java update we have to wait for medical testing certification....

It has been an uphill struggle for a number of years to get medical companies to support Mac,

This situation is hardly going to help, is it?

This Java version isn't only insecure on the Mac, it is insecure wherever it runs. Normally, your computer downloads a Java applet, and the Security Manager inside Java keeps that applet from doing things that are deemed dangerous. The major problem with this Java version is that someone found a way that an applet can replace the Java Security Manager with their own. Which then lets the applet do whatever it wants to do. Which means your computer is absolutely, totally open. Worse, these exploits are openly for sale.

You may be unhappy if your app stops working. Many, many people would be a lot more unhappy if Apple didn't close this major risk and then their bank accounts got emptied as a result.

[podiki]

Originally Posted by gnasher729

This Java version isn't only insecure on the Mac, it is insecure wherever it runs. Normally, your computer downloads a Java applet, and the Security Manager inside Java keeps that applet from doing things that are deemed dangerous. The major problem with this Java version is that someone found a way that an applet can replace the Java Security Manager with their own. Which then lets the applet do whatever it wants to do. Which means your computer is absolutely, totally open. Worse, these exploits are openly for sale.

You may be unhappy if your app stops working. Many, many people would be a lot more unhappy if Apple didn't close this major risk and then their bank accounts got emptied as a result.

As a Java developer it shocks me most that people are still developing Java applets... I don't see the point. Keep Java on the server side it's safer for all of us.

[justperry]

Originally Posted by aprilfools

Kakatoa East of Java...

Totally unrelated and of topic but it's Krakatoa and it's West of Java.
(Yes, the book is wrong)

[Weaselboy]

Originally Posted by podiki

ehm, installed the latest update, still says 1.7.0_09...

ronin:~ podiki$ java -version
java version "1.7.0_09"
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)

That is just showing the version of the Java runtime you have, which is different that the Java web plugin. Turn on Java in your browser then go to this page and it will show your your Java plugin version.

[TechnoLawyer]

Originally Posted by RayK

I want a new Java 6 from Apple.

Is there a way to use Java 6 in Mountain Lion? We remain stuck with Lion and Safari 5.x for the time being. I don't mind Safari 5.x since I prefer the separate search area but I'd like to have the Reminders app on my Mac.

[Negritude]

Originally Posted by TechnoLawyer

Is there a way to use Java 6 in Mountain Lion?

You can install Java 6 in Mountain Lion, but it will be the out of date version with security holes. There is no updated and patched version for anything beyond Snow Leopard. There never will be. Apple and Oracle want you to use Java 7, period.

[Swift]

I've turned off Java in Safari preferences, and I haven't found any reason to turn it back on. If you want to execute code on my machine, the security has to be airtight.

Turn off your P'n'P, folks. At least on your WAN side.

[MagnusVonMagnum]

Originally Posted by munkery

Please read the following and my other posts in this thread this again:

Yeah you can re-read my posts again to infinity too, but you still won't get the basic premise that your Mac is not 100% safe no matter WTF you imagine in your head. And no I won't read ANY of your messages on the subject again because your basic premise is still wrong since NO computer on earth is 100% safe. Have a nice day.

[munkery]

Originally Posted by MagnusVonMagnum

Yeah you can re-read my posts again to infinity too, but you still won't get the basic premise that your Mac is not 100% safe no matter WTF you imagine in your head. And no I won't read ANY of your messages on the subject again because your basic premise is still wrong since NO computer on earth is 100% safe. Have a nice day.

Never said it was.

When not blocked, Java represents a risk in OS X. Luckily, Apple blocks vulnerable versions of Java. But, the damage from Java applets is limited due to the robust DAC in OS X. Protected data entry and storage isn't compromised without circumventing DAC. DAC in Windows has been circumvented by malware in the wild, such as TDL.

If the user turns off Gatekeeper, then the user is at much greater risk from trojans. But, at least Apple gives the option to be protected by the code signing provided by Gatekeeper. This relates to errors on the part of the user but not the OS.

I'm only stating that its better than the competition.

It seems pragmatic to use the OS with the most secure foundation if concerned about security.