Java Exploit Patched? Not So Fast

PCM2 writes "The Register reports that Security Explorations' Adam Gowdiak says there is still an exploitable vulnerability in the Java SE 7 Update 7 that Oracle shipped as an emergency patch yesterday. 'As in the case of the earlier vulnerabilities, Gowdiak says, this flaw allows an attacker to bypass the Java security sandbox completely, making it possible to install malware or execute malicious code on affected systems.'"

Comments

Arrrrrg

[Haawkeye]

Come on really! That's it java is coming off my machines!

Re:Arrrrrg

[Anonymous Coward]

Sandbox it externally. Don't rely on JRE to do it for you.

Re:Arrrrrg

[tqk]

Come on really! That's it java is coming off my machines!

Is it too soon for me to say, "I told you so"? Because I did. When it was released, it was a buggy, system security nightmare and even after all these years, it's continued in that vein. This is what corporations want running on their machines, and relying on the goodness of Oracle's/Ellison's heart for support? Why?

Re:Arrrrrg

[cbhacking]

Using what, a VM? That's probably the easiest and most cross-platform, but that hardly makes it easy (especially since VMs that are designed for easy use make extremely poor sandboxes). AppArmor or SELinux or some such? Well beyond the capabilities of most users. A dedicated low-privilege user account? That's possible on pretty much any platform, but will still leave a mess that you'll have to clean up afterward.

Besides, I'd really rather stop before the attacker gets arbitrary code execution on my machine. Java is disabled or simply not present on my machines, thank you.

Re:Arrrrrg

[Jeremiah Cornelius]

Oracle should be "patched" by Anonymous.

Re:Arrrrrg

[Anonymous Coward]

I personally use the sandbox tool part of the free Comodo Security Suite. It seems to pretty intuitive and easy to me. Anything out of the ordinary and it will prompt if I want to continue (it will automatically deny it, if I dont answer in the given time frame)

Re:Arrrrrg

[Nerdfest]

I may have this wrong, but isn't this exploit only possible if you have Java enabled in your browser, which you only need to run Java applets? When was the last time you saw a Java applet? Disable it. I'm surprised it's still enabled by default (I think it's actually disabled in Chrome).

Re:Arrrrrg

[whoever57]

When was the last time you saw a Java applet?

Try using Webex without Java enabled in your browser.

Re:Arrrrrg

[Nerdfest]

That product is pretty much a security exploit by its very nature.

Re:Arrrrrg

[reiisi]

Well, I've been recommending a sort-of simple procedure for *nix users, where you call your browser through a restricted, dedicated user account with no login privileges.

By no means is it a perfect solution, but every speed bump and low wall helps a bit.

One could (should?) basically set up such pseudo-users for specific required processes that will run a java vm, and refrain from using Java otherwise.

Of course, any architecture that allows a server to feed a client a class that the client's machine will instantiate is going to be vulnerable.

Re:Arrrrrg

[Anonymous Coward]

I thought WebEx ran as a Java Application, not a Java Applet. There is a difference.

Re:Arrrrrg

[Anonymous Coward]

Better idea. Don't use Webex, period.

Re:Arrrrrg

[LordLimecat]

Sandbox [Java VM] externally

Using what, a VM?

Yo dawg, I heard you liked virtual machines...

Re:Arrrrrg

[wkcole]

I may have this wrong, but isn't this exploit only possible if you have Java enabled in your browser, which you only need to run Java applets?

Or Java Web Start, which is basically downloaded (rather than embedded) applets

When was the last time you saw a Java applet?

The last time I needed to work in a single-user interactive shell on the console on one of our servers. It's been a few weeks, but when I need it, I NEED IT. The access mechanism that actually works is a dynamically generated JWS applet with embedded temporary auth tokens. A rather slick way to do safe working console access compared to some of the broadly dysfunctional and/or unsafe approaches I've seen.

Disable it. I'm surprised it's still enabled by default (I think it's actually disabled in Chrome).

I don't believe that any current browser+OS combination has Java installed and enabled by default. Chrome is slightly special, apparently because it is a 32-bit app and it takes some manual effort on a 64-bit OS to get a 32-bit plugin. For modern MacOS, there simply is no 32-bit plugin and so no Java for Chrome no matter what.

Re:Arrrrrg

[DarwinSurvivor]

Blackboard and Virtualmin are ones I'm forced to use on a regular basis.

Re:Arrrrrg

[Decker-Mage]

When VMWare Workstation was very, very young (2000) and had that beta new-software smell, the very first thing I did with it was create a dedicated browser appliance. Given that security has always been one aspect of what I do, it was extremely nice to have a machine that I could "nuke" after cruising the underground looking at existing (and sometimes upcoming) threats. If that doesn't do anything for your situation (use-case, blech!), Sandboxie or another sandbox software package might do the trick. Now that it's a more mainstream feature, security suites are demonstrating the capability. Still, I'd much rather have the nuke-able machine with a Golden-image locked up elsewhere than necessarily rely on any one program or suite. Then again, I'm paranoid-in-depth here. Yes, they really are out to get me! ;-).

Re:Arrrrrg

[lindi]

Since you allow Java to talk to your X server it is trivial to break out of that sandbox. It can just simulate a few key presses to open a terminal and then inject whatever commands it wants. Or am I missing something here?

Re:Arrrrrg

[Anonymous Coward]

I'm leaning this way too (removing Java everywhere). Can we kill all Flash and Adobe virusware too please? PDF "Reader", I'm lookin at ya!

Q: So who trusts Java now?
A: my ex-boss, and his boss, and ... (which is why I left)

Re:Arrrrrg

[Anonymous Coward]

I may have this wrong, but isn't this exploit only possible if you have Java enabled in your browser, which you only need to run Java applets? When was the last time you saw a Java applet? Disable it. I'm surprised it's still enabled by default (I think it's actually disabled in Chrome).

The last time I saw a Java applet? Every time I need to do Internet banking, which usually is several times a week. Switching to another bank is not only difficult and undesirable with my current mortgage, but most banks in my country (and many e-commerce sites) use the same Java-based standard for login. There are a few that don't, but they happen to be less desirable for a number of reasons, including mortgage terms.

Re:Arrrrrg

[reiisi]

As I said, it's a speed bump, to be used in combination with other techniques, not a perfect solution.

Relative to X11, the attack has to be aware that the user that the browser is running under is restricted and not a login browser, and decide to attack X11 instead of just dropping a keylogger and adding a line to the user's .bashrc to invoke it. Just buys you a little time, but that's not a bad thing.

Re:Arrrrrg

[mortonda]

Kinda hard, if your employer uses it, and it's the only way to join a remote meeting.

Re:Arrrrrg

[EvilIdler]

Denmark uses NemID, which is a Java applet-based login system for all sorts of official things. Norway uses it for many banks. It's not nearly as bad as South-Korea's over-reliance on ActiveX, but there are quite a few services you can't use fully without frickin' client-side Java. I can't even get a bank statement without going through that Java login, as the mobile banking doesn't support more than looking at what's on the account and transferring money.

Re:Arrrrrg

[Anonymous Coward]

Never heard of it, your argument is invalid.

Re:Arrrrrg

[gtall]

DoD is filthy with java applets, that stuff won't get rewritten any time soon.

Re:Arrrrrg

[Bryansix]

So you are saying that Fastsupport.com is not secure. I think Citrix might want to know about that if its true.

Re:Arrrrrg

[antdude]

My employer's time card system and online courses/classes still uses Java. :( I hope v6 is OK.

Re:Arrrrrg

[LordLimecat]

iDRAC uses it, as does (IIRC) Equallogic SAN.

Not surprising

[cbhacking]

They've patched 6 of the 19 vulns that were reported back in April. Three were patched a couple months back as part of their usual 4-month patch cycle. As far as I know, those were never used in the wild. Three more were patched just recently, in response to rampant in-the-wild use and inclusion in exploit kits, etc.

Of course, that leaves 13 still unpatched, and while apparently quite a few of them are defense-in-depth (insufficient, on their own, for full compromise), when you've got that many unpatched vulns it is totally unsurprising that somebody can chain a few of them together into a working exploit.

WORE

[tobiasly]

Oracle should be commended for finally bringing their "Write Once, Run Everywhere(tm)" vision to the exploit community.

Re:WORE

[cbhacking]

Ah, but ActiveX only ever ran on Microsoft platforms. With Java, you can exploit OS X, Linux, BSD, and so on through any browser with the Netscape plugin API (a.k.a. almost all of them)! Truly, a great day for the blackhats of the world.

On a more serious note, this does highlight two problems with modern computing:
1. Write-once-run-everywhere is convenient for developers, but puts a huge security purden on the platform developer (a burden which Oracle seems either unwilling or unable to bear). If you want to become the universal execution platform, you better make damn sure you aren't allowing universal exploitation too.
2. Yes, Macs and Linux users and anybody else who can load a Java applet in their browser is vunlerable to malware, even 0-day (well, 0-day for patches, more like 120-day since the vendor was notified) exploits. If nobody bothers to attack your system, it's simply because the value they can get from it isn't worth the cost of developing the payload (which is hardly difficult). If you want to be a success in the market, though, you're going to have to take the scrutiny that comes along with it. Don't be complacent; you're far from immune.

Re:WORE

[sjames]

Honest to God, when I glanced at the subject, I read it as "WHORE" which seems somewhat apt for Java these days.

Re:WORE

[medv4380]

I don't believe there is all that much of a security burden that Oracle needs to bear. The problem is that Java is in essence executable code. It really is too powerful to be embedded into a web page and just trusted. Running Java in a web page is like running native executable and expecting the sandbox to work every time. If Java only ran when you wanted it to run then the exploiters wouldn't have such an easy attack vector. The user could still be hit but they'd have to do more then pull up a page.

Re:WORE

[cbhacking]

Normally I'd agree with you, but the exact same thing is true of JavaScript and yet very, very few people are calling for a universal end to that. Now, a handful of people (relative to the global computer userbase) use NoScript, but even among NoScript users most realize that it's either too complex or too difficult for most people to use correctly all the time.

As it happens, I do block plug-ins (especially Flash and Java) by default, permitting them only on a case-by-case basis, except where I can remove them entirely. However, even to my (highly technical; he's been coding since he was in high school) father, that's too much of a hassle. He expects (rightly, if not wisely) that software vendors will keep their software as secure as possible, and respond quickly to any threats. That's the standard to which I'm holding Oracle here, and they're failing to meet it.

Re:WORE

[SplashMyBandit]

Yes, but you can also attack through images (eg. the various JPEG attacks) and JavaScript. Should these be universally banned too?

Re:WORE

[SplashMyBandit]

> With Java, you can exploit OS X, Linux, BSD, any ...
I know you say "Java applets" later on, but it is important to qualify this at every stage (since even the techie Slashdot readers appear to be horribly ignorant that there are differences between JavaScript, Java applets and Java applications).

Readers should take note:

1. 1) In general Java applications and web services are secure (in fact, more secure than C++ etc)
2. 2) It is malicious Java applets that pose a potential risk to users (just like malicious buffer-overrun inducing JPEG images do).

Now cue the hundreds of Java-hating posts that don't know the difference between JavaScript, Java applets and Java applications/servlets but still think that some other technology is more secure (hint: it is not - every tech out there has holes that get discovered from time to time - including your operating system).

Re:WORE

[Anonymous Coward]

Hey, remember back when IE4 was still new, and *Perl* was (briefly, thank ${deity}), a first-class scripting language that could be embedded in a web page? :-D

I still get chills thinking about it.

Re:WORE

[Tanktalus]

Briefly, thank[fully]? Really? As opposed to a security-vulnerable closed source Java app, as so many seem to be nowadays? At least the perl community seems to try to fix their security issues in a relatively timely manner, and, being open source, theoretically someone else can come out with a patch if the perl devs were too slow to fix it.

(PHP and Python obviously suffer from the same benefits as Perl, though I don't know their communities as well.)

And perl couldn't be embedded in a web page - it could only produce them (CGI and CGI-like, such as mod_perl and FastCGI, though this allows them to serve as AJAX/REST servers/servlets as well).

Re:WORE

[cbhacking]

Correct, but slightly missing the point I was trying to make. The Java vulns being discussed here are all ways to break out of the applet sandbox. Java applets *are* Java - they're exactly the same language, executing in exactly the same runtime - but there's supposed to be restrictions on the APIs that allow Java code to modify the system it runs on. These restrictions form the applet sandbox, and breaking them allows a website to gain arbitrary code execution on your system.

The important point that I was trying to make is that, unlike your typical browser bug or image rendering bug, these Java exploits are platform agnostic. A malformed JPEG may successfully execute shellcode on one broken image decoder/renderer, simply crash another, and be caught and thrown out by a third. Which thing happens to any given client (visitor to the page hosting it) will depend on the client's software environment: their browser, their OS, whether they use 32-bit or 64-bit, etc. If you want to make it cross-platform, you'll need to not only have an exploit that works on multiple image libraries (or a suite of exploits that together cover all libraries, and some way to tell which one to use), you'll need shellcode that executes on all those platforms (and shellcoding is hard, especially in the face of the exploit mitigations found in most modern OSes).

A Java applet sandbox-break like these exploits is almsot totally platform-agnostic. It may care what JRE you're using, but pretty much everybody uses the official one from Oracle. Even if you don't though, if your third-party JRE allows applets to access the same APIs as the official one, you're screwed too. Implementation differences between the JREs are unlikely to save you; the exploits are legitimate Java code calling official APIs that just really shouldn't be callable from an applet. Exploit mitigations are of no use at all; once out of the sandbox, the Java code can run any payload it wants, still entirely within the proper behavior of the JRE. True, the payloads will be platform specific (due to differences in filesystem layout, names and locations of installed software, and so on, plus obviously if you want to download a native payload it will need to have been compiled for the target platform) but compared to writing even a single working shellcode, writing a payload for every single major OS platform out there (or more likely, simply using your favorite one from Metasploit or similar) is trivial.

The tricky part of writing a Java applet exploit is just figuring out the sequence of function calls to break out of the sandbox. Once you've done that, everything else is trivial; it's just Java code like any other. This is a flaw in the Java applet feature more than in the language itself, but that doesn't remove the fact that the language's write-once-run-everywhere nature significantly increases the impact of security vulns and correspondingly requires much greater vigilance on the part of the developer.

Re:WORE

[Anonymous Coward]

How many malicious buffer-overrun JPEG images are there? I haven't see one in 5 years.

Re:WORE

[Anonymous Coward]

Java is also open source- the proprietary components are deprecated since Java 6. Somewhat surprisingly, Oracle even switched to using OpenJDK for Java 7, instead of the Sun code base.

Re:WORE

[Anonymous Coward]

The difference the poster was trying to point out is that these attacks mostly focus on a case where you can instruct the JVM to execute arbitrary code (such as Java applets). In such a case, the same problem exists for most other languages. As 1543257 was saying, Java itself is pretty secure (that is, against attacks on running Java applications). You're talking about exploiting Java as a browser vulnerability, but this is inherent to the functionality they're trying to provide. Which is why Java applets are a Bad Idea®, just like ActiveX, Flash* and so on.

*: sidenote; unlike these, Java wasn't developed for web applets.

Re:WORE

[cbhacking]

Java spplets aren't a browser vulnerability, they're a Java vulnerability. The entry vector is through the browser, but that's beside the point - Java is supposed to provide a sandbox for applets and that sandbox's walls are awfully low. The problem isn't that the attacker can tell Java to execute arbitrary code, it's that Java will obey even when that code violates the security guarantees it is supposedly making.

Also, you should brush up on your computing history. Java applets are explicitly designed as a feature of the language and the runtime (including, in theory, the applet sandbox). They're nothing like ActiveX in that regard, which is simply compiled code (COM objects, more precisely) that IE (and a handful of other apps) will allow you to load into the browsing session (or document, or whatever). In the days before JavaScript could be used for anything powerful, and Flash was only for animations with almost no interactive capability, Java applets were how you did rich content on the web. There was a time when applets were viewed as *the* reason to learn Java, and the platform was marketed on the power of applets.

Re:WORE

[cbhacking]

JPEG fuzzing is relatively easy, so the popular parsers of the format have become quite safe over time. As a general class of exploit, though, such things definitely still exist. They're nothing like the Java vulns under discussion here, except for the insignificant similarity that they can be used for remote attacks though a browser, but similar attacks targeting various complex binary formats (*cough*PDF*cough*) are still being developed.

Re:WORE

[Anonymous Coward]

Seen what, a vulnerability? They still show up from time to time.
E.g.:
CVE-2012-0247
CVE-2012-1149
CVE-2012-2806
CVE-2012-2814
CVE-2012-2840

Re:WORE

[PCM2]

Oracle should be commended for finally bringing their "Write Once, Run Everywhere(tm)" vision to the exploit community.

Funny, but it brings up an important point. These have all been Java bugs that allow attackers to execute malicious code. The malicious code itself, though, is not Java -- it's a binary payload. So while the vulnerabilities are cross-platform, and hence so are the exploits, the actual exploits that have been discovered in the wild so far would only really harm Windows systems. They actually included a little branching JavaScript that said, essentially, "Got Windows? Download payload.exe. Else Do Nothing." It would absolutely not be impossible to craft a cross-platform exploit that sent different payloads for Mac OS X and Linux, too, but so far nobody has done that.

Re:WORE

[medv4380]

But unlike Applets JavaScript and JPEGs are actually used. Applets serve no valid purpose on the web any more. Letting them sit there rarely used except for off case uses and exploits is foolish. When was the last time you saw an applet being used productively in a web page that couldn't have been solved by using WebStart or just prompting the user for permission to run?

Re:WORE

[SplashMyBandit]

> There was a time when applets were viewed as *the* reason to learn Java, and the platform was marketed on the power of applets.
... and that time was around 1998. It's been nearly a decade and a half since then. Personally, I prefer Java WebStart to applets. Yes, there is a problem with the Oracle's implementation of Java sandboxing - the concept was sound though (and how many other development environments have this concept?).

Re:WORE

[SplashMyBandit]

> How many malicious buffer-overrun JPEG images are there? I haven't see one in 5 years.
You haven't been looking?

Re:WORE

[SplashMyBandit]

> A malformed JPEG may successfully execute shellcode on one broken image decoder/renderer, simply crash another, and be caught and thrown out by a third. Which thing happens to any given client (visitor to the page hosting it) will depend on the client's software environment: their browser, their OS, whether they use 32-bit or 64-bit, etc. If you want to make it cross-platform, you'll need to not only have an exploit that works on multiple image libraries (or a suite of exploits that together cover all libraries, and some way to tell which one to use), you'll need shellcode that executes on all those platforms (and shellcoding is hard, especially in the face of the exploit mitigations found in most modern OSes).

JPG, or PDF, or PNG, or Flash, or ActiveX, or Javascript or browser or TCP stack implementation ... etc vulnerabilities are pretty common. Yes, you have to do more work than put up a single malicious applet, but it is not that much harder to put up half-a-dozen 1x1 pixel background-colored JPEGs each crafted for the target platform (let's see: Win32, Win64, Mac OS X, Android, iOS, Linux 64 and we're done!). My point is that while Java applets are pretty holey at the moment, vulnerability to data received from a remote site is not unique to them.

Re:WORE

[SplashMyBandit]

Applets are legacy. I agree with you, WebStart is a vastly better solution (plus, I've noticed that when I converted a heavily-used applet I had written to WebStart it ran around an order of magnitude faster; the browser plugin for applets is relatively slow).

It's okay, Oracle should be used to it by now.

[Anonymous Coward]

And, by ' it ', I mean Oracle should be used to failing by now.

Is Oracle's "proprietary" attitude the problem?

[reiisi]

We know that the license (for Oracle's release) is a charade.

Isn't the whole problem here derived from Oracle's attitude that they own this thing?

I don't think it's possible to keep a closed/proprietary attitude and make secure software. I don't mean that the form of the license guarantees anything, there are always exceptions where the license and the community attitude are out of sync, but I think it's clear that software products have to be open to the end user to be secure.

Re:Is Oracle's "proprietary" attitude the problem?

[jhol13]

Utter bullshit.

I use (X)Ubuntu 12.4. There is not a day without updates, usually somewhere 10-20 updates per day (mostly not security though).

This has gotten worse, never before has Ubuntu been so bad. If this is a trend, next year I will bee using more time patching my system than using it for work.

Re:Is Oracle's "proprietary" attitude the problem?

[Forty Two Tenfold]

Ubuntu 12.4. There is not a day without updates

Utter bullshit.

Re:Is Oracle's "proprietary" attitude the problem?

[thsths]

Ubuntu 12.04 had a lot of updates, that is true. Mostly kernel and libraries though, and the occasional Java update, of course.

However, now we have Ubuntu 12.04.01, and it is much more mature (as announced). We should see updates going back to the usual level of maybe once a week, and less for a base system.

There is not much Ubuntu can do about - the bugs are in the software used to make Ubuntu, and unless you prefer old (stale) versions like in Debian stable, you will get frequent updates.

RMI WORE

[reiisi]

.. Remote Method Invocation ..

I simply cannot imagine what Sun was smoking when they added this to Java. Even without an exploit, setting up the security manager/context is not something the end-user is going to do, so it is going to get left to the server-side, which is basically offering root to the vm to the server.

Re:RMI WORE

[binarylarry]

Good thing no one uses RMI ;)

Re:RMI WORE

[Anonymous Coward]

What nonsense are you talking about. I typically code with C# (for all intends and purposes a better ripoff of Java). In its early days I use RMI (or .Net Remoting) all the time in my code. I don't want to use it; the project requirements dictate it is necessary.

Re:RMI WORE

[SplashMyBandit]

So you are saying your C# application is possibly insecure? since the article is about Java the parent's post stands: no one uses Java in modern apps - instead they use REST or SOAP webservices (much more secure - assuming you know what you are doing).

about:addons

[Anonymous Coward]

Use case : 1 site (banking, 2-factor) that must have Oracle Java, used infrequently.

Solution: disable Java in about:addons in Firefox and only enable it after clearing cache and all else and then only during the duration of the visit to the single site. Disable Java again afterwards (and clear cache and all else).

Protip: if you enjoy flash games make manual (and edited) copies of your ~/.macromedia/Flash_Player/#SharedObjects/

That's what I'll be doing from now on. Might do more since other interesting ideas are given in other comments.

Re:about:addons

[Runaway1956]

Protip, your ass.

The real protip? If your bank requires you to enable java or flash to use their site, you're banking in the wrong place.

Now, pull your head out of your ass, and thing "security" instead of "convenience".

Re:about:addons

[BlackThorne_DK]

Oh well, welcome to my world. In Denmark, not only does the bank require Java. The _state_ require you to use the same braindead java-infested login (NemID), not only on all banks, but also on every public accessible site (Pensions, Healthcare, Unemployment benefits, Student benefits...).
No matter what I do, and which bank I choose, I need to use NemID, and Java.

I just disabled Java on my work machine. Now I need to make a virtual machine or something, if I actually want to pay my bills. :-(

Re:about:addons

[west]

Now, pull your head out of your ass, and think "security" instead of "convenience".

I cannot help but notice that you posted this on Slashdot, indicating that you have chosen to connect to the Internet instead of using pen and paper, thus choosing "convenience" over "security". Where does this place your head?

Every user must choose the *tradeoff* between convenience and security, and it will differ depending upon needs and desires. Claiming that anyone whose particular choice in this trade-off doesn't match your own has their head up their backside is not only insulting,but indicative that you have no real concept of the wider concept of security and the costs in incurs.

(Okay, you probably have a very good concept of the cost, where it applies to you. Perhaps you might consider extending the same consideration to others.)

Re:about:addons

[Runaway1956]

That's all so very politically correct, and so all-inclusive - I almost feel like calling for a group hug or something.

Meanwhile, there are tens, maybe hundreds of thousands of computer users who have NEVER had their computers compromised - and perhaps a billion others who have had their computers compromised. There are millions upon millions whose computers are routinely compromised.

Now, I'll admit to something here, that is somewhat embarrassing. I used to belong to the club whose computers were routinely compromised. I was raising sons who demanded to be allowed to play games, and to be on the internet. At the time, many of the current games demanded administrator privileges. It seems that about once per month, I was repairing some infection. That could be an exaggeration - but I definitely spent to much time repairing stupid problems.

I reached a point where enough was enough. I told the boys that all the computers that I own were being locked down tight. All of my computers became Linux boxes, and I simply stopped working on their machines.

Eldest son learned to do his own formatting and reinstallations, and he seems content with the state of things on his machine.

Middle son just uses strictly locked down accounts on my machines, or guest accounts on other people's machines. He doesn't even own his own machine.

Youngest son did the research to learn Windows thoroughly, AND to learn Linux thoroughly. His Windows machine has been compromised a couple times in the past few years, but he was on top of things, and fixed it himself. His Linux machine has never been compromised.

As I see it - my eldest son has his head up his ass, because he deems his gaming as being more important than security. He is quite happy to run an infected machine while doing online banking - as long as it doesn't slow his gaming. At the point where gaming gets difficult, is where he takes an infection seriously.

In the business world, those businesses that insist on Java and Flash are comparable to my eldest son. They have their heads up their asses. Those of you who are understanding and supportive of that position? I guess you're a little like drug pushers. Stop enabling self destructive behaviour. Tell it like it is: Java and Flash are poison to a business environment!!

Re:about:addons

[west]

Well, I'm certainly not going to criticize your parenting skills: If you can get a teenager to do his own formatting and re-installation, you're miles above most of us :-).

As for your son's decision to value convenience over security, if he's willing to pay the price, I'd have a hard time arguing. (Okay, since he'd be bringing the infection inside *my* firewall, I would be arguing...)

Anyway, whenever I'm starting to get a bit huffy about users not willing to learn anything more than the bare minimum to do what they want, I try to remember how I must look to the person who services my car, who repeatedly begs me to take better care of it when all I care about is that it gets me from A to B occasionally without actually exploding. (He claims my car is safe, but it *should* be purring, All it would take is n hours of my time.)

Anyway, fair enough, for what it's worth, I apologize for my snarky tone (and I'll try not to be too envious about having *two* sons who actually fix their machines themselves - my sons chose locked down machines over having to actually spend a few hours going through the effort of learning how to repair them).

Not so fast

[MobileTatsu-NJG]

Not so fast.

Isn't that Java's mission statement?

Re:Not so fast

[MROD]

No, Java is an exceptional language: At the slightest provocation is throws one.

Why would I run Java on my browser?

[NicknamesAreStupid]

I've had no need for it. Who does?

Re:Why would I run Java on my browser?

[isorox]

I've had no need for it. Who does?

Lights out management of servers?

Classic slashdot

[Anonymous Coward]

Oracle patched some, but not all the bugs. Congratulations. What do you think other companies are doing? Do you know how many times Apache got caught with its pants down releasing software with known exploits?

There is no such thing as bug-free software. You can definitely bash Oracle for not doing a better job, but expecting them to ship with no known bugs is plain unrealistic.

Re:Classic slashdot

[cbhacking]

No, I don't know how many times Apache got caught for such stupidity. Care to share some references?

There's a huge difference between "ship with no known bugs" and "ship with no externally known security exploits". The former is unrealistic of any major piece of software. The latter is (or should be) mandatory of any major software vendor. The folks who reported the 19 vulns originally also sent Oracle 12 distinct POCs for those vulnerabilities. To date (over four months later), Oracle has patched only 6 of those vulnerabilities, and broken at least two of the POCs... but that still leaves an awfully large number of them unaddressed, and it's not as if they haven't had time to address them.

Oracle, and unfortunately by extension Java, is shit. Even Microsoft isn't nearly so bad.

The total FAIL of Norway

[fluor2]

In Norway, all banks use a common login-system called BankID (a joint-developed PKI solution).

This solution requires Java to be installed at client.

It's quite hilarious.
This basically leaves a complete country vulnerable when these exploits go wild.

Re:The total FAIL of Norway

[TheLink]

Solution: use a different browser running as a different user for banking. Or run it in a VM. Then make sure Java does not work on the browsers you use for other stuff.

In fact you should do this for your banking stuff even if your bank doesn't require Java. Keep a separate banking browser+user account or VM for that.

Re:The total FAIL of Norway

[fa2k]

In Norway, all banks use a common login-system called BankID (a joint-developed PKI solution).

It's nothing new that banks require insecure technology. Remember things like "this page only runs on IE"? Anyway, what you say is incorrect, I have an account with Storebrand and they only have a key generator dongle, not a smart card. I would also argue that moving an entire country to two-factor authentication is a net security *win*.

perlscript, I think

[reiisi]

I think the gp was talking about perlscript.

1.7, I'm still on 1.6

[Anonymous Coward]

Who's in the enterprise world using Java 1.7 anyway?

Some specific ERP software such as Oracle Financials are thankfully not yet 1.7 compliant.

Re:1.7, I'm still on 1.6

[Miamicanes]

> Who's in the enterprise world using Java 1.7 anyway?

Enterprise applications requiring Java 7 are rare. Enterprise applications requiring Java 6 or better are not.

Unfortunately, Java 6 doesn't exist for OS X (ie, Macintosh). Java 7 is the first real version of Java Mac users have had in literally *years*.

For Mac users, the next step down from Java 7 isn't Java 6... it's Apple's broken, obsolete, Steve-shackled Java 5. If a Mac user wants to run Netbeans 7, in particular, he has exactly two choices: install Java 7, or run it under Windows or Linux using VMware.

OpenJDK vs. Oracle Java?

[someones]

I switched to OpenJDK a while back.
In its early days it was bugged and crashed all the time, but that time seems long forgotten past.

Is there a reason to favor Oracle's Java over OpenJDK?

Re:OpenJDK vs. Oracle Java?

[Anonymous Coward]

A thought Java 7 was OpenJDK.

RMI is excellent

[Anonymous Coward]

in a trusted environment. Fast enough for HD video, complete type safety, and remote exceptions turn into stack frames that let you trace execution through the client AND the server.

Of course we run it through a SSL tunnel.

OK, getting it through firewalls is a bit of a pain.

Fortunately not a TM anymore!

[Anonymous Coward]

The new version installs as "Java 7 Update 7" while all previous versions installed as "Java(TM) 7 Update 5" etc.
So apparently the (TM) part has been dropped.

Send security reports to RH/Canonical

[David Gerard]

White hats who discover Java exploits should also send a security report to the Java teams at Red Hat and Canonical (the latter do Java on Ubuntu and Debian). Oracle might sit on a 'sploit for months, but Debian isn't going to.

... in a trusted environment

[reiisi]

I don't believe in trusted environments, not when the end-user can change his IP and/or MAC, etc.

The effort you have to go through to set up the certificates the chain-of-trust, the execution context, constantly checks, etc., and I tend to think the out-of-band solutions work better.