Recent Apple Java Update Doesn't Fix Critical Java Flaw Claims Researcher 102
hypnosec writes "Just yesterday Apple released updates to fix Java vulnerabilities, but it seems the patch doesn't actually target the recently discovered high-profile Java bug that has been the talk of the web during the last two weeks. The two updates – Java for OS X 2012-005 for OS X Lion and Java for Mac OS X 10.6 Update 10 for Mountain Lion, are meant to tackle the vulnerability described in CVE-2012-0547. But according to KerbsOnSecurity, it seems Cupertino hasn't addressed the recent mega-vulnerabilities in Java as described in CVE-2012-4681."
Update: 09/07 12:00 GMT by S : As readers have pointed out, these updates address flaws in Java 6, which is the version Apple maintains. The recently-reported Java vulnerabilities primarily affect Java 7, the patching of which is handled solely by Oracle. Nothing to see here.
Huh? (Score:1)
Isn't it Oracle's job to maintain Java on OS X now that Apple kicked it to the curb?
Re: (Score:2, Troll)
Re:Huh? (Score:5, Interesting)
How is it hyperbole? Look at Secunia. There are more than 1000 vulnerabilities between the combined versions of the JVM. They average around 200 per version which is actually worse than Flash player.
Re: (Score:2, Insightful)
Re: (Score:3)
That's not a fair comparison. Users don't realistically have a choice about whether to run an OS. They do have a choice whether to add additional vulnerabilities by tacking on an unnecessary abstraction layer like Flash or Java.
Re: (Score:2)
Re: (Score:2)
Except that users cannot choose a less vulnerable OS. All OSes have significant numbers of vulnerabilities in that database.
Actually, that's exactly what I'm arguing. You should not install Flash. Or Adobe Reader (at least the plug-in version of it). Or Java.
In theory, yes. In practice, web bro
Re: (Score:2)
I understand your point of view. One of my points was that "Java" is more than the Java Applet, so care has to be made to differentiate the terms. The other thing is I have written Java applets and were forced to because HTML/CSS is just not functional enough at the moment. Sure, you can do simple form-based stuff with it (and get fairly advanced even using the wonderful Google Web Toolkit and vaadin), even do some graphics with Canvas and the (not yet universal) WebGL, but unfortunately the Web experience
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
a single program with over 200 vulnerabilities per version
I count 20+ programs in a typical Windows Java installation.
Also, how does this 200+ compare to other frameworks, like Flash or Silverlight?
Re: (Score:2)
your.
Re: (Score:2)
Not sure what you mean by "kicked to the curb", but OS X Java is still maintained by Apple.
Re:Huh? (Score:4, Informative)
Not sure what you mean by "kicked to the curb", but OS X Java is still maintained by Apple.
Not completely. Apple maintains Java for Mac OS X through version 6. Oracle took over starting with version 7. It's not clear how long Apple will continue to provide updates for version 6, though.
Apple stopped including it as a default install with Lion (Mac OS X 10.7), I believe.
Re:Huh? (Score:4, Interesting)
I stand corrected, About 18 months ago, I was writing the installation docs for a Java application that had to run on Mac, and I went to rather a lot of trouble to find out how to configure Java on the Mac. (The main reason I got the job: they'd had bad experiences with users on various platforms who didn't understand Java runtime idiosyncrasies.) I was actually quite impressed by the way OS X support for Java worked — very elegant and carefully thought out,
Now I suppose my work will have to be thrown out and replaced by the cruder procedures Oracle uses. Oh well.
Re: (Score:3)
Re: (Score:3, Informative)
Funny, I just attempted to play the battlestar galactica web MMO, and Unity3d is not supported on Linux..
Re: (Score:3)
I'm writing a jet combat flight simulator and C++ and C# simply are too much effort to make truly cross-platform; eg. Mac, Linux, Window, Android
Care to elaborate on the specifics? Because it sounds a bit ... exaggerated. The difference between the platforms is in the UI and I do not think any sensible developer would subject its users to the horrors of AWT or Swing (none of which IIRC is available on Android). If you take the platform-specific UI out of the question, then the rest of the code would be pretty portable - regardless of the programming language. Except of course for the Android where IIRC you need different paradigm for an application
Re: (Score:3, Interesting)
What would you like to know, specifically? Note that the 2D UI is a minor part of the application, and a "Filthy Rich Client" (Google if you don't understand this term) Swing startup is perfectly fine to start the JoGL/OpenGL main UI.
> Because it sounds a bit ... exaggerated.
This is why I am taking to point out that Java is more than adequate for 3D gaming (since all the important stuff runs on the GPU anyway). I find it lamentable that Slashdotters are so anti-Java (and have out of date perspective
Re: (Score:1)
What would you like to know, specifically? Note that the 2D UI is a minor part of the application, and a "Filthy Rich Client" (Google if you don't understand this term) Swing startup is perfectly fine to start the JoGL/OpenGL main UI.
> Because it sounds a bit ... exaggerated.
This is why I am taking to point out that Java is more than adequate for 3D gaming (since all the important stuff runs on the GPU anyway). I find it lamentable that Slashdotters are so anti-Java (and have out of date perspectives) they simply cannot comprehend that modern JVMs are not only as good as C++ for gaming, they are superior in my experience as a indie game developer (for a hard-core simulation; eg. multi-threaded resource sharing in Java is so much easier than in C++ when you are targetting multiple-platforms). I understand that existing game devs with existing C++ pipelines and assets aren't interested in Java, but new games development should seriously consider it - expecially if you want to be as massively profitable as Java games like Minecraft are.
What? No one was claiming that java was inadequate in any way. Your comment seems unwarranted and very defensive.
The GP merely stated that what you mentioned could be done in almost ANY language, and did not criticise your use of java specifically.
Your original claim was "because it is the best cross-platform solution for rich clients out there" and the GP answered that by saying that for what you want to do, there doesn't seem to be any clear or obvious reason to choose java over any other modern language.
Re: (Score:3)
>"I do not think any sensible developer would subject its users to the horrors of AWT or Swing"
personally I disagree and find Swing to be one of the most powerful and productive rich client toolkits out there. If you know what you are doing you can do just about anything (although Swing has plenty of flaws still). It was based on that parent comment that I decided to "defensively" elaborate why I consider Java suitable - and IMHO, particularly suitable for massive multi-threading
Re: (Score:3)
You said you're doing a game. Most game engines or graphics engines contain UI classes as part of the SDK. Some even have UI designers to help build your UI.
I think Swing looks ugly, and doesn't blend in with the native OS (not exactly the spirit of cross-platform), and I suspect that is the common opinion too.
Still, feel free to use it. If it's your strongest toolkit (ie. the one you know best), then it's the best toolkit for you to use.
Re: (Score:2)
> I think Swing looks ugly, and doesn't blend in with the native OS
Many people I've made gaming utilities for rather like the Nimbus Look n' Feel (L&F). Perhaps your perception of Swing of the the rather ugly and outdated Metal L&F. I guess with most stuff moving to browser based apps its hard to find modern Swing apps, so it is easy to only think of Swing as the old apps you used to get.
> I think Swing looks ugly, and doesn't blend in with the native OS (not exactly the spirit of cross-pl
Re: (Score:2)
I think Swing looks ugly, and doesn't blend in with the native OS (not exactly the spirit of cross-platform), and I suspect that is the common opinion too.
Native swing widgets looks horrific but you can theme them to make the widgets look and behave as if they were native ones. Just google mac widgets and you'll see what I mean.
Re: (Score:2)
It's literally a one-line block of code to make Swing use (what it thinks is) the native GUI look.
...and probably some exception handling. It's been a while since I've had to write Swing code in Java.
However, despite looking like native widgets, they really aren't and they behave differently in non-subtle ways (you mean my IME settings don't work in Swing?!). You need SWT for that.
Re: (Score:2)
"I do not think any sensible developer would subject its users to the horrors of AWT or Swing"
personally I disagree and find Swing to be one of the most powerful and productive rich client toolkits out there.
Being horrible and being powerful are two totally different orthogonal things. Being a Asm/C/C++/Perl guy, I did actually code with Java/Swing for several months. Oh, yeah it's very very powerful. But at the same time it is totally platform agnostic (making user of any OS feel out of place), it doesn't conform to behavioral standards of the OS it runs on, and lastly it is f***ing slow. Developing large interactive, stutter-free UI in Swing in the past (my past, something like 7 years ago) proved to be frui
Re: (Score:2)
Thanks for taking the time to make interesting comments. With regard to your performance woes have you attached the JVisualVM to your running application? It comes as a standard part of the Sun/Oracle/OpenJDK. There you'll be able to see whether your performance issue is caused by: memory thrashing (when near the limit of the allocated heap), synchronization problems (threads locking/blocking each other), resource contention (eg. database row locks), or stuck in a loop somewhere. I'd be very interested to
Re: (Score:3)
If you would please suggest a useful alternative to Java that was cross-platform and I didn't have to go through all the awful porting nonsense of C++ or C#/Mono (been there done that, don't want to do it again) for my flight sim then I'm all ears.
What 'awful porting nonsense' did you have with c++ code?
Re: (Score:3)
Re: (Score:2)
FlightGear [flightgear.org] is a multi-platform (Windows, OS/X, Linux) written in C++ and QT. Seems to work well enough for them.
That's what i was thinking, writing portable c++ code isn't complicated, the obvious thing that is difficult is if you use platform-specific toolkits rather than something cross-platform like Qt.
Re: (Score:3, Interesting)
Sorry, QT is vile and unnatural, IMHO. Effective sure, but unnatural for those used to proper Object Oriented UI toolkits (eg. back in the day Borland's OWL, Swing etc).
The C++ code itself is nothing. What matters is that for each platform you target you need different libraries, and each library has its own idiom. Then you end up contorting your architecture for each set of libraries you are trying to integrate. This is not impossible (I've written lots of portable, complex C++ in the last two decades)
Re:Java blows (Score:4, Insightful)
Sorry, QT is vile and unnatural, IMHO.
If you don't like it that's fine, that's not really any kind of objective criticism though. If you don't like Qt there's always other options like wxWidgets, FLTK, etc...
Effective sure
Which is why so many people use it.
The C++ code itself is nothing.
Which is why your post was so baffling.
What matters is that for each platform you target you need different libraries, and each library has its own idiom.
But you don't, there are so many cross-platform libraries. You get the same when targeting Android with Java anyway, you can't just use Swing like on other platforms.
Then you end up contorting your architecture for each set of libraries you are trying to integrate.
Do you have a specific example of why you did this?
This is not impossible (I've written lots of portable, complex C++ in the last two decades) but I can tell you it is *vastly* easier, more consistent, and I would argue more performant (since the time I save not fixing dumb C++ loopholes I instead spent optimizing my Java) to use Java.
This all depends on your proficiency, not sure what these 'dumb C++ loopholes' you're referring to are, could you be specific?
Flightgear is an admirable bit of software. I looked at extending it but realized after two decades of C++ and a decade of Java I knew which language to base a new *reliable* multi-player, multi-core product on.
So what specifically makes Java more reliable?
So I understand your advocacy for C++.
What advocacy for C++?
Java becomes the better choice for new heavily multi-threaded stuff, IMHO.
Why is that?
Re: (Score:2)
> So what specifically makes Java more reliable?
A combination of factors, like Java always ensuring everything is initialized, like the garbage collector ensuring that resources shared between multiple threads are eventually cleaned up, or not cleaned up too soon, and by setting references to null (aiding the gc) you can avoid the dangling pointers you get in C++ (which gets horrifically difficult in complex multi-threading programs in C++). The other thing is that Java has certain practices and tools
Re: (Score:2)
So, on Slashdot it seems very fashionable to 'dis' Java as not 'l337' enough (and hence crufty and outmoded C++ is considered more leet), but I find Java an excellent go-to language for a very wide range of problems (webapp using GWT, embedded, and even my rich-client flight simulator).
I certainly don't have an issue there, for example i certainly wouldn't be writing a basic webserver in c++ over using something like node.js. I also don't see any problem with Java for client-side applications (i'd naturally avoid it for webapps given the amount of nasty security issues
Re: (Score:2)
Have you ever seen the Google Web Toolkit (GWT) or vaadin? These are both Java technologies (almost no one uses the 'browser plugin' Java applets for new projects).
With regard to the "awful porting nonsense" I'm afraid I have to stand by my comment. Apart from trivial applications and even with good libraries it is still fairly painful to port a large application between Linux, Windows and Mac OS X.
> There are plenty of strategies for dealing with memory management (smart points, basic ref counting,
Re: (Score:2)
With regard to the "awful porting nonsense" I'm afraid I have to stand by my comment. Apart from trivial applications and even with good libraries it is still fairly painful to port a large application between Linux, Windows and Mac OS X.
You can stand by those comments all you want, but since you can't explain specifically what you mean they are just baseless.
It is possible to leak memory even using these in a long running application.
It's possible to leak memory in Java too, you're always reliant on the JVM, like the memory leak with File.deleteOnExit, the memory leak in the Apple JVM with BufferedImage or probably the worst ones being ClassLoader leaks. The ignorant attitude towards Java memory leaks is a problem, everyone reckons 'oh it's ok, Java cleans up all the memory and can't have memory leaks', which is ru
Re: (Score:2)
Re: (Score:2)
Why the vitriol?
What vitriol? Pointing out that you're citing issues with one language while ignoring those in the other is not vitriol.
Java is not perfect, I just happen to consider it better than its competitors for soe of the reasons I have outlined.
You still haven't said what those issues are, just used ambiguous terms like 'awful porting nonsense' and 'dumb loopholes' and 'vile and unnatural', those aren't reasons used to justify something by people who know what they are talking about.
So, by all means, please continue using and advocating C++ rather than more modern solutions :)
I'm not using or advocating C++, i'm just pointing out that you clearly have no idea what you're talking about.
Re: (Score:2)
So you don't use C++? well I do, as well as Java. It is laughable you think that I "clearly have no idea
Re: (Score:2)
So you don't use C++?
use != using, try to keep up.
It is laughable you think that I "clearly have no idea ..."
Then why are you so ignorant of things like memory leaks in Java? Why can you not specify all these C++ horrors you refer to ( 'awful porting nonsense' and 'dumb loopholes' and 'vile and unnatural' and need to re-architect because of unspecificed porting issues with libraries)? What is abundantly clear is that you have no idea what you're talking about, prove me wrong if you can, what libraries did you have to re-architect for? what porting nonsense? what dumb loopholes? what do
Re: (Score:2)
> use != using, try to keep up.
All I can go on is what you write. Since you are am ambiguous communicator (and it appears an arrogant prick to boot) that is not my problem. So no need for the attitude. k? If you want to make a point try and explain clearly and unambiguously, thanks.
> Vile and unnatural
Well, the fav C++ GUI toolkit around here seems to be QT. When I started playing with QT I was astounded by how horrible it was to use. Slots and macro madness abounded. Meta Object compilation - no
Re: (Score:2)
Since you are am ambiguous communicator
I'm not the one making ambiguous comments with no explanation, that'd be you. All i've asked for is specificity in your comments, you make claims that you've worked with c++ for decades yet you can't provide any specific examples, one could do the exact same for Java and you'd simply arrive at an impasse.
Fortunately they have cleaned somewhat and it has become more OO like, say, Swing. But why settle for the imitation when I can have the real thing?
You specifically mentioned Android in your original post, are you running Swing on Android? If you don't like Qt that's fine, but that's not an objective criticism.
As in, moving C++ code between the same compiler. I remember using STL with g++ 2.7.2 back in the day (that version was stable for a long time) and then a patch-level release broke the tens of thousands of lines of code I'd been working on. Had to go and fix it all up.
What was that? In any case g++ is just one
Re: (Score:2)
> You specifically mentioned Android in your original post, are you running Swing on Android? If you don't like Qt that's fine, but that's not an objective criticism.
There is a small piece of code to load a different type of parent window on Android - detected using the normal Java mechanism. Once it hands over to the JoGL code then there is nothing really to do, since JoGL supports Android the same as any other platform.
> So then why do you have so much difficulty writing non-leaking code in c++?
Re: (Score:2)
There is a small piece of code to load a different type of parent window on Android - detected using the normal Java mechanism. Once it hands over to the JoGL code then there is nothing really to do, since JoGL supports Android the same as any other platform.
And if you extensively use Swing or AWT you have to port all of that to Android's XML-based UI.
Actually, what I'm trying to discern is you reason for arguing. Is your argument that it is perfectly possible to write massively multi-threaded, cross-platform real-time applications in C++ in a manner that is easier than doing it in Java?
No - and in fact if you recall you said cross-platform solution for rich clients [slashdot.org] - i'm not arguing at all, again i'm not advocating one way or the other, try to comprehend that, I'm just trying to work out what your justification is. With your 'decades' of experience you can't even come up with any specific examples to back up your comments. With all these problems with all different platform-specific libraries i
Re: (Score:2)
> Except to say that you go to the trouble of using JVisualVM to examine your running code Java for memory leaks - which makes sense in most applications but certainly not in a non-deterministic highly parallel application.
Ok, this is bullshit right here. With a highly non-deterministic application the first approach is to look at the statistical overall expectation behaviour of the application, for which this tool is awesomely suited.
> I use a lot of GPGPU for offloading massively parallel tasks,
Re: (Score:1)
QtJambi http://qt-jambi.org/ [qt-jambi.org] project exists and allows the best of both world. The Qt API for Java.
Re: (Score:2)
Re: (Score:2)
Ummm, because it is the best cross-platform solution for rich clients out there. If there was something better I would use it, but there isn't (I'm writing a jet combat flight simulator and C++ and C# simply are too much effort to make truly cross-platform; eg. Mac, Linux, Window, Android). If you would please suggest a useful alternative to Java that was cross-platform and I didn't have to go through all the awful porting nonsense of C++ or C#/Mono (been there done that, don't want to do it again) for my flight sim then I'm all ears.
How about using the unity3d or corona sdk? Then you can add iPhone to the list of supported platforms as well.
Re: (Score:2)
Re: (Score:3)
A lot of their solutions work on Java.
Example: New kids to campus want to get their laptop on the university wireless system. All they have to do is have java and know their e-mail user name and password and this 3rd party solution takes the machines MAC address - registers it on the network and logs it in a back end database and automatically switches the student from the setupwireless to the WPA2 university wireless network. This saves a ton on help
Story is misleading. (Score:5, Informative)
Except that Apple have never even installed Java 7 to be vulnerable.. this is update to their Java 6, so the story is bogus.
It's oracles job to handle Java 7 on mac, Apple are only dealing upto 6.
Mega vulnerability is for Java v7 - Apples is v6 (Score:5, Informative)
Garbage story (Score:4, Informative)
Apple doesn't ship Java installed by default... but if you do install it, it's Java 6. The "unpatched" vulnerability in the summary only affects new Java 7 functionality and does not affect Java 6.
My understanding... (Score:2)
...is that CVE-2012-4681 uses a vulnerability during Applet execution.
Apple's Java for OS X 2012-005 [apple.com] disables all browser Applet support, and if re-enabled by the user, will automatically disable it again if it goes unused for 35 days. The Java for Mac OS X 10.6 Update 10 [apple.com] release appears to go a step further, and disables applets in browsers until they are clicked on explicitly by users, along with disabling the applet plug-in if unused for 35 days.
So while I'm presuming the vulnerability does still exist
Re: (Score:3)
You can't take advantage of the vulnerability if you can't run any applets
Not true.
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136112.html [oracle.com]
Re: (Score:3)
...is that CVE-2012-4681 uses a vulnerability during Applet execution.
Not quite. Applets are the most likely infection vector, but the vulnerability exists in any Java code.
Basically, what CVE-2012-4681 does is let untrusted Java code turn off the Java sandbox. Applets are about the only Java code where the sandbox is likely to be enabled by default, but there are scenarios where the sandbox is used by non-applet code. (As an example, in a Java servlet environment (think Java CGI), the individual pages might be run in the Java sandbox.)
Which means that, for the most part, th
Re: (Score:2)
As an example, in a Java servlet environment (think Java CGI), the individual pages might be run in the Java sandbox.
Java servlets are running on the server side, which makes this a moot point. The client side isn't running any Java code for a servlet and the client's JVM (if present) is never invoked.
Unless, or course, the page hosts an applet, but you already discussed applets.
Re: (Score:2)
Java servlets are running on the server side, which makes this a moot point.
Not if it's your server. For example, say you're a hosting provider, and offer hosting of Java servlets. Tomcat provides an option to enable the Java sandbox for embedded servlets, and the vulnerability being discussed would allow them to bypass it. If the servlets are being provided by potentially hostile sources, that's a problem.
I can't really think of any other scenarios where the Java sandbox is enabled (other than Java Web Start, I suppose, which are basically "applets" by another name). The point rem
Stop Trolling us Slashdot (Score:5, Informative)
Hey Editors, you've been trolled. The "mega-vulerabilites" described in CVE-2012-4681 don't even apply to the version of Java Apple ships. Do some homework before jumping on the bandwagon next time.
You must be new here (Score:2, Insightful)
The janitors running this site can't even be bothered to read submissions over for spelling and grammar mistakes.
Re: (Score:2)
Apple missed a lot of serious issues with this Java patch. The JRE7 security flaw. iOS text message spoofing. The Pentium FDIV bug. The Prius stuck accelerator problem. PHP's inherent design flaws. Unity.
I salute the efforts of Mr. What'shisname to warn us of Apple's disastrous negligience. Now if you'll excuse me, I'm off to demonstrate against the Vatican for not having achieved break-even with fusion power yet.
Of course they didn't fix CVE-2012-4681! (Score:5, Informative)
CVE-2012-4681 is a vulnerability that affects Java 7. Apple has only ever provided Java 6 with OS X, and with recent OS X versions, it's not even included by default. So it's pretty silly to make a sensational story that calls out Apple for not addressing CVE-2012-4681 in their update to Java, since they're not even affected by it.
For more details, see: http://www.kb.cert.org/vuls/id/636312 [cert.org]
OS X uses Java SE 6 not Java SE 7 (Score:3)
Re:OS X uses Java SE 6 not Java SE 7 (Score:5, Informative)
Re: (Score:3, Informative)
http://www.oracle.com/technetwork/topics/security/alert-cve-2012-4681-1835715.html [oracle.com] It effects Java 6 u34 and below but the impact is not as severe. I believe malicious code can still change the value of private fields but the Java 6 version of the sandbox is implemented differently, so the list of permissions can't be replaced with "AllPermissions"
According to the risk matrix at the bottom of the page, the problem of vulnerability under Java 6 u34 and below is identified as CVE-2012-0547 - which is exactly what Apple's fix fixes as said in TFS. IOW TFA is still uninformed at best.
Who cares, Java is dead. (Score:1)
Why would anyone want to use Java anyway?
It was all promises, and now we know they were lies.
There are better alternatives like perl, python and ruby.
Re: (Score:2)
Errr...because some of us don't have a choice, Einstein?
Re: (Score:1)
Re: (Score:1)
I'd pick Einstein over Java any day.
Re: (Score:1)
Yeah, ever since the apple logo lost the rainbow colours, they've become totally un-gay :(
Re: (Score:1)
The project you cites have zero downloads (this week). Come back when you've fixed all the bugs and the rest of the world is onboard.
Until then I'll keep using Java as I don't seem to run into the same difficulties you seem to have.
I'm sure realtime does matter but I can stil code in C/C++ for that and the resulting work can still run inside the Java VM in complete harmony. I'm sure you will find it hard to find people suggesting you write your video codecs in Java.
For the bigger picture where a collectiv
They did Snow Leopard as well (Score:2)
Finally they did Snow Leopard as well! You know, that OS that most Mac users are currently using?
They still haven't released Safari 6 for Snow Leopard or released Safari 5.1.8 etc to address the 121 fixes that Safari 6 brought to Lion. That's a huge problem. I'm very happy they fixed Java but why did they bother when Safari 5 is loaded with so many other flaws they won't bother fixing?