Polish Researcher: Oracle Knew For Months About Java Zero-Day

dutchwhizzman writes "Polish security researcher Adam Gowdiak submitted bug reports months ago for the current Java 7 zero-day exploit that's wreaking havoc all over the Internet. It seems that Oracle can't — or won't? — take such reports seriously. Is it really time to ditch Oracle's Java and go for an open source VM?"

Comments

No

[ExE122]

This is not a sign that you need to start ditching Oracle. The reason more security loopholes are discovered in Oracle are because it is the most widely used JVM. Other VMs will still have a ton of issues, they just don't get attacked as much (yet).

A similar argument used to be debated years ago with Apple v Microsoft... Apple toted it's superior security over MS when in reality, nobody gave a crap about attacking Mac users which only made up 10% of the market. Once they gained popularity, they started getting hit more as well.

The real scary part is that MS at least takes its security flaws somewhat seriously. Oracle seems to have smugly ignored Mr. Gowdiak. He can now smugly turn around and give them a big "I told you so!"

Re:No

[pointyhat]

Dear Blakey Troll,

Java desktop application guy here

Last place I worked, I was the lead architect for a real-time patient care system deployed to 120,000 users across 2500 hospital sites around western Europe across Windows, Linux and Solaris platforms.

It stopped the users' patients from dying, so they are quite happy with it as are their patients. It is incredibly fast (2 orders of magnitude faster than the C++ based MFC native Windows app our competitor was throwing out), it has had no downtime (ever!) by nature of the architecture which must not go down under any circumstance (everything was fully distributed), the UI definitely does not suck and it's certainly not bloated at 52Mb including the JVM (our competitor hit 2Gb including the local SQL server instance installation).

What do you propose we use instead and how do you propose we start rewriting the 1.9 million lines of code we've already got?

Re:No

[pointyhat]

No - you are actually totally clueless here and are just trying to get karma by jumping on the anti-Java bandwagon.

No our application is not contributing any such risk whatsoever:

1. We shipped the JVM with the application in its own standalone directory. No applets, no browser plugins. It's launched by a wrapper exe on windows and a script on Linux+Solaris. Basically it runs java[.exe] -jar application.jar. There is no target vector for this exploit.

2. we ship JVM 1.6 which is not vulnerable.

3. It uses SWT which looks native on all platforms - look it's not ugly at all: http://www.eclipse.org/swt/

Re:No

[pointyhat]

Seeing as I made a claim, I'll explain further.

No it's definitely faster if you know what you are doing. The reason C++ is "fast" is that you can easily sacrifice clean interfaces and modularity for raw performance i.e. by using raw memory and pointers etc. The moment you throw that away to build clean interfaces and modularity in (which is essential on larger projects like ours), your performance advantage goes out of the window. We're not doing it wrong - we're leveraging the right technology. It's easier to make serious mistakes in C++ as well and the additional checks required to verify that they are not being made are expensive. In Java, most of this is handled at compile time (g++ checks+valgrind are not sufficient btw).

Regarding downtime. Consider CAP theorem. We use a PAXOS consensus algorithm based protocol between nodes and our own event driven message-oriented container which runs inside the client process. Effectively the system, per-installation is a big message bus. There is no central point of failure. There are no servers to fail. If a single node is up, the system is operational. Scalability comes from CAP theorem - we sacrificed C (consistency) yet apply P (partition tolerance) and A (availability). We have unique reliability requirements which means we don't use a COTS container like Tomcat, Glassfish or Jetty which is what you are most likely used to.

1.9 million lines is due to the complexity of the product - the task it is required to do is not easy to visualize, is processing heavy and is complex. We also have about 2.9 million lines of jUnit and selenium RC tests. It's modular and well maintained as it's built by people who know what they're doing.

I earn plenty thank you.

This is a proper software engineering project, not a startup, internet fad, cost cutting low-rate business.

Re:Why are people still using this?

[KlomDark]

Have you worked with C# under the .NET 4.x framework now that they've added Entity Framework to it?

It is so much more efficient that any other data access abstraction I've ever seen. It even makes Hibernate/NHibernate look like a lame hack.

I am able to do extremely complex things with 10% of the amount of code I used to have to write.

Microsoft might be making a LOT of mistakes lately, but Entity Framework is not one of them. I don't know if I'll ever have the patience to use another language again - C# with Entity Framework is that much better.