I met with a client earlier this week who asked me to go over their vulnerability scans for a bit of a sanity check. He asked some important questions, but one in particular seems worth sharing. What can we do with Java? Can we solve the Java problem?
One of the best things you can do to improve your security in a corporate environment is to limit the use of Java, or whitelist Java. Undoubtedly there will be one or more legacy web applications your company uses that require Java, and it’s almost inevitable that at least two of them will be certified for one and only one version of the JRE, and it won’t be the same one.
Believe it or not there’s a solution to the problem of conflicting JREs, but it took me years to find it, because I had no idea that Oracle called it “Deployment Rule Set.” The secret’s out now. If you run Java, and you want security, you need Deployment Rule Set.
Last week Adobe issued an out-of-band Flash patch, and once again Brian Krebs urged people to ditch Flash, noting that he’s done so and hasn’t missed it.
We decided to try ditching Flash at work a few months ago, but it didn’t go quite so smoothly for us. I thought I’d share my experience.
The Java Runtime Environment is one of the nastiest pieces of software ever foisted upon mankind. It’s difficult to secure when people have the will, and few people have the will to even try. So nasty ancient versions of the JRE live forever.
That’s not to say I’ve completely given up on the Quixotic quest to get rid of it. Earlier this week, I exhorted, “Can we please not use the JRE that Ada Lovelace wrote for Charles Babbage?”
That stopped everyone dead in their tracks with a laugh. “That’s good.”
Hopefully they think it’s a good idea too. Because with all the hacks they would have had to do to get Lovelace’s JRE running on a Von Neumann architecture machine, there’s no way the thing can be stable, let alone secure.
Sometimes, especially on Windows servers, it’s difficult to check to verify what version of Java you’re running while you’re making your rounds. If you don’t have a scanning tool to check it, here’s how to check your Java version by hand, even if the Java control panel doesn’t show up:
I was actually surprised at who the top three were. They weren’t the three usual suspects. But in the case of the top two, they did, to their credit, roll out fixes within 30 days of disclosure.
So now that I’m killing you with suspense….
I’ve been seeing the same question over and over in my search logs lately: Is Java safe to run in 2013?
Generally speaking, the answer is no.
I have little choice but to run Java right now, though. I’m studying for a certification exam, and the best quiz program that I know of is written in Java. Its user interface is in Polish, a language I don’t speak, but that bothers me less than it being written in Java. Google Translate can help me with the Polish, but it can’t make Java safe. That’s up to me.
So here’s what I did.
Firefox is advising users to disable vulnerable Java versions on Windows. I actually saw this in action on a machine yesterday–a machine that has to run a slightly dated version of the JRE because a vendor hasn’t certified their product with the current version yet. Read more
Under some circumstances when installing an app from a Packagefortheweb archive, such as Sun’s JRE, I get a goofy error message like “Cannot run 16-bit Windows Program” or a message about a failure to find a path with long filenames in it.
It’s a bit of a pain but you can fix it.The trick is to extract the file rather than run it. I found PowerArchiver can do it. Winzip may also be able to. I wish I had a command-line utility to do it but I don’t.
Extract it to a short directory name, then move it to the root drive. Then run your setup.exe. That should be the end of your problems. Clean up afterward to eliminate directory clutter.