Oracle to Block JAR Files Signed with MD5 Starting In April (bleepingcomputer.com)
An anonymous reader quotes BleepingComputer:
Oracle says that starting with April 18, 2017, Java (JRE) will treat all JAR files signed with the MD5 algorithm as unsigned, meaning they'll be considered insecure and blocked from running. Oracle originally planned MD5's deprecation for the current Critical Patch Update, released this week, which included a whopping 270 security fixes, one of the biggest security updates to date. The company decided to give developers and companies more time to prepare and delayed MD5's deprecation for the release of Oracle Java SE 8u131 and the next Java CPU, scheduled for release in April...
Oracle removed MD5 as a default code signing option from Java SE 6, released in 2006. Despite this, there will be thousands of Java apps that will never be resigned. For this, Oracle will allow system administrators to set up custom deployment rule sets and exception site lists to allow Java applets and Java Web Start applications signed with MD5 to run. Sometimes in the second half of 2017, Oracle also plans to change the minimum key length for Diffie-Hellman algorithms to 1024 bits. These updates are part of Oracle's long-standing plan for changes to the security algorithms in the Oracle Java Runtime Environment and Java SE Development Kit.
Oracle removed MD5 as a default code signing option from Java SE 6, released in 2006. Despite this, there will be thousands of Java apps that will never be resigned. For this, Oracle will allow system administrators to set up custom deployment rule sets and exception site lists to allow Java applets and Java Web Start applications signed with MD5 to run. Sometimes in the second half of 2017, Oracle also plans to change the minimum key length for Diffie-Hellman algorithms to 1024 bits. These updates are part of Oracle's long-standing plan for changes to the security algorithms in the Oracle Java Runtime Environment and Java SE Development Kit.
BUT WHAT ABOUT SOLARIS
Just kill Java already. It's become the IE6 of programming languages with its insecure and bug-ridden VM and web plugin.
The article suggests only 1.8, but will this also be pushed to 1.6 and 1.7 too?
...write a code-signing infrastructure instead.
Bad for the power grid, or some such shit
Presumably they mean that they wont accept RSA signatures over MD5 hashes.
It seems to me that the stewardship of Java in the past few years, particularly it's security aspects, have rendered it useless and undesirable.
I must use java in my employment with well - let's just say "a lot" - and all over the world. It is not simply my own conclusion, but the conclusion of many people I consider more facile and accomplished than myself that Java is undesirable. My employer has gone to the point of shutting down a planned services introduction. That product, instead of launching, was shut down and the teams re-assigned to other tasks.
The workarounds to use Java in the current environment are such that we commonly create VM images to spin up and destroy for tasks requiring Java.
Going forward, I will carefully review employment offers - if it deals with Java, they're going to have to work very hard for me to accept it. I don't need the pain and heartache dealing with it causes if there are alternatives.
I am being intentionally careful not to give out details, and I'm sure there are many that will start off a reply "You stupid idiot, you can do X!" - again, these are not solely my own conclusions, but shared with many people I consider to be very, very good. I assure you, anything you may think of has surely been considered if not by myself, then by others in the same situation. Please do suggest if you wish, but also consider that a lot of other, very smart people, have looked at this same situation for more than a few years.
Like all opinions, this may or may not fit your situation and exact needs. It can even be quite wrong.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
Is there any secure virtual machine around? Because I have yet to see one.
Avantgarde Hebrew science fiction
Ever since Dobbertin found a hash collision in 1996 RSA labs themselves were already recommending alternatives such as SHA-1. This was just around the time Java 1.0 was released.
Those who can't write a secure virtual machine
stupid human is too stupid to realize that humans are too stupid to accomplish such a task
These security changes make just make it tougher and tougher to support "legacy" Java applets that are unsigned. Forget Java 8... even the newer versions of Java 7 can't run them anymore.
I guess that it's good that they fix these issues, but they need to offer workarounds or I'm going to have to keep installing Java 6 on some customer machines to keep their legacy crap running.
"the current Critical Patch Update, released this week, which included a whopping 270 security fixes,"
Remember when Java was touted as the super-secure language that was supposed to be nearly impossible to exploit? I do.
It was gonna be the "write-once, compile anywhere" language that was going to make all other languages obsolete. It was basically going to take over the world and *everything* was going to be written in Java, "Everything, you'll see!" they said.It was going to be the Uber Language for all time, the Final Solution.
Oh, the Java early adopters sneered at anyone who didn't jump on the Java Train and they kept crowing about how it was going to be the end of sloppy programming and uncertain coding, and vulnerable executables would be a thing of the past...
I didn't believe it then and I (obviously) don't believe it now.
Just cruising through this digital world at 33 1/3 rpm...
Well one could always hope
http://saveie6.com/
It's more about licensing fees on the new way of doing it.
Some versions of java are _already_ blocking as invalid or untrustworthy any certificates *served over https* when they have http OCSP URIs, at least in firefox and chrome under Linux (where it is run through icedtea).
Now, try explaining *that* to the idiots taking care of homebanking sites, which test their unsafe crap using outdated versions of said browsers on utra-outdated versions of Linux distros, or only IE under Windows...
I know it's fashionable to dump on the Java ecosystem around here. However, given the tools and libraries that are available, I find it incredibly easy to write apps quickly and efficiently. Personally, I've started to use Kotlin and it rocks. Between it and Groovy and the massive wealth of libraries in the Java ecosystem, I haven't found anything else that lets me be as productive.
That said, some of the frameworks out there just plain suck. My employer is building a Spring/Hibernate Servlet system, and while there are a few things that are kinda cool about Spring, I think it's mostly a clusterf**k of an over-bloated framework. I guess you have to use it when you are communicating with a bunch of disparate systems, but I'm certain that it's killing our team's productivity hugely.
I've tried Go, and I like it but there is not very much of a community around it, and the database package was designed by morons. I've tried Rust. I think it has potential, but it's really hard to spin up your head around it. And again, not much of a community.
Browser vendors seem confident enough in their JavaScript execution engine to enable it by default even though none of the JavaScript is signed. Instead of locking down unsigned Java applets, Oracle could have written a VM for them in JavaScript and Oracle's part would have been secure since any exploit would be the browser vendor's responsibility to fix.
Anyway, who is using that old Nokia S40 phone?
to collect the IDs of Java haters so that they don't have to worry about hiring them into jobs where they might be forced to lower themselves to using Java and sabotaging the company. They should only be allowed to work on the flavor of the month so their feelings are not hurt.
I knew that Java had holes like a sieve, but still using MD5 as a signature that proofs something (not just for checking unintentional transmission errors) is still a surprise. We are removing all uses of the JRE, for example switching from Sikuli to Lackey for all GUI scripting/automation.
It is a joy for IT to keep around a bunch of old java client environments to access old printers, NAS, switches, kvm switches, motherboard controllers (iLO etc), blade server management all "conveniently" accessed through a web browser (and requiring an old obsolete java and old insecure java features).
This is a legitimate question, as I am confused about the remarks people make.
What is so inherently bad about Java security? I understand that the JVM is itself a piece of software that may have vulnerabilities outside of our control, but is that it?