• Forum
  • Lounge
  • Is the Java security hole really a big i

 
Is the Java security hole really a big issue?

Pages: 12
I just read ResidentBuscuit's recent post on Hacking and it reminded me of this recent "epidemic" I heard about on the news. They said that Java has a big gaping security vulnerability that hackers target more often than not and most of these articles I read request that everyone disables Java until there is a patch. Knowing Java is a foundation to some of my programs I don't want to stop it. Does anyone know if this is a real issue or not?

Here is one article of many:
http://news.cnet.com/8301-1009_3-57563951-83/homeland-security-still-advises-disabling-java-even-after-update/
closed account (o3hC5Di1)
As I understand it, the danger comes from the web-plugin which can just be disabled in the browser.
It is through the web-plugin that malicious websites can make your machine execute unsafe code, because the plugin loads information from those websites.

I would like to add a question though, if I may, being whether interpreted languages, like java, entail extra security risks over a compiled language such as C++?

All the best,
NwN
Last edited on
closed account (3hM2Nwbp)
@NwN

It seems like a "serious security risk" pops up every few days with Java. Conversely I haven't ever heard of a time that users were to 'disable C++ until a patch comes out'. My guess would be that the fault lies in Java's slew of inherently brain-dead / broken facilities. Don't worry about fixing it correctly, just patch it up!

I'm really curious to see the Java fanatics' response.
Last edited on
lol +1 luc Lieber:)
Maybe they just want more young people to learn java, Script kiddie types will want to learn to hack and so will choose Java
@Luc, that's a ridiculous statement to make. I can't tell if you really mean it or if you just want attention. I'll stop at pointing out that it's a Java plugin (i.e. a piece of software that handles Java applets because Java, unlike C++, is good for that sort of thing) that's broken, not Java.
Last edited on
closed account (o3hC5Di1)
@Luc Lieber,

I was wondering more in general whether the additional interpreter-layer brings an additional security risk.
Does it allow more room for hackers to execute arbitrary code, or is it just Oracle who messed up?
It seems like C# has its share of security holes as well, but I'm not sure in how far that's down to the .NET framework or to the interpreted nature of the language.

C++ has had its share of buffer overflow attacks etc., although I was lead to believe that with the use of smart pointers and STL containers these would be a thing of the past - if used wisely.

I don't want to start a flame war here, just wondering :)

All the best,
NwN
@NwN, intuitively having more components means more places to make a bug. On the other hand, more components might give more abstraction which might help avoid and handle problems of all sorts. In general, I don't thing there's correlation in either direction.
We just had a meeting at work yesterday and this bug was talked about. It deals with the backend of Java using C to talk to the host machine (not the JVM) and a vulnerability there. It is partially patched, the recent Java function that allowed this to happen has been fixed, but the underlying issue with Java is still there.
closed account (3hM2Nwbp)
@hamsterman

While I somewhat over-exaggerated, I really do mean what I wrote. "Java" in the context that (I thought) we were discussing was Oracle's overall product (including their back-end binaries including javaws, etc) and not the language itself. If you're in doubt, check how many 'critical security fixes' were just recently applied to the JRE components since Java 7 was released. I really don't see how pointing out the magnitude of blunders is ridiculous in any way.

@NwN - I haven't followed this closely, but as Oracle is the one fixing it, I can only assume they're the ones that messed up (again). Oracle's position is much more delicate than most others. Basically, the security enforced by Oracle is the only thing that disallows websites from running arbitrary code on host machines...and as of late they've failed big-time. I'd expect any technology to be under more intensive attack pressure from malicious users if such technologies offered rewards as great as Java's security holes. So really I don't think it's the interpreter layer per-se, but rather how attractive (and easy in some cases [improperly set up security managers, # 1]) to exploit holes.
Last edited on
@Luc, I assumed your comment was somehow about Java, the language. If you meant that Oracle is doing a poor job, I won't argue with that. Although your comparison with C++ is still very much misplaced.
Java 7 Update 11 is the "partial" (-RB) patch, just so everyone knows.


Also, http://www.oracle.com/technetwork/topics/security/alert-cve-2013-0422-1896849.html
Last edited on
will it allways have this weakness
closed account (3hM2Nwbp)
hamsterman wrote:
If you meant that Oracle is doing a poor job, I won't argue with that.


To be fair, it's really not Oracle's fault. Sun didn't exactly hand them over a perfect creation to begin with. When I said "inherently broken" that was simply my opinion of what they keep building upon (continually introducing more vulnerabilities as they do so). Comparing Java to C++ might be misplaced if taken in the wrong context. The only thing that I said was that I can't recall a time when a cease and desist order went out for C++ like the ones we keep seeing with Oracle's products be it blamed on whatever excuse suffices at the time.


P.S.

Assuming that I was speaking about the language wasn't really a stretch, as the language itself also has a multitude broken spots of its own that I could rant on for pages about too!

I won't reply on this topic anymore as I'm not much more than a flame catalyst at this point.
in a way C++ can be more dangerous than java. however, not always. java does have web support and the web is hacker central. java is more dangerous in the hands of a hacker. C++ is more dangerous in the hands of an idiot. C++ can allow you direct access to memory via pointers. if someone doesn't know how to use these he can hurt his system

giving an idiot pointers is like handing a hyperactive monkey a chainsaw and a grenade
closed account (3hM2Nwbp)
I know I said that I wasn't going to reply again...but...

in a way C++ can be more dangerous than java


Java and C++ can be used seamlessly together. A program that started inside the JVM can do anything that a C++ program can launched outside of that JVM. You can actually also access specific memory locations from Java as well, but what's the point?

if someone doesn't know how to use these he can hurt his system


That might have been true in the 1950's, but not anymore. At least not on target systems that matter.

giving an idiot pointers is like handing a hyperactive monkey a chainsaw and a grenade


I'd rather do that then ask a job interviewee: "What's a pointer?" and getting a reply of "They're evil! Dangerous! DO NOT EVER USE THEM!" Not only would I not hire this person, but also reach across the desk and smack them up side the head.

That's it, I'm done posting! X'ing the window now.
Last edited on
If someone doesn't know how to use these he can hurt his system.

I'm curious what you mean by this. I know improper use of pointers can cause hard to find bugs or memory leaks.

Lasting damage to your system; how?
Last edited on
iseeplusplus wrote:
Lasting damage to your system; how?

Plenty of security holes come from pointer errors. Also, it's a long shot, but say you point your pointer at some memory owned by the disk driver* and then set it to the right value, you could, theoretically, accidentally instruct the disk driver to nuke your disk.

* I know most operating systems won't let you do that, but bear with me.
* I know most operating systems won't let you do that, but bear with me.

I have wondered about how this exactly works. My professor told us that you cannot point to memory outside of your application. And that your not really pointing to a memory location, but rather virtual memory addresses in a table that the operating system has provided your application (or something akin to that). He didn't get very specific; left it at "it's complicated", and you'll learn about it in an operating systems class.
Last edited on
He didn't get very specific; left it at "it's complicated", and you'll learn about it in an operating systems class.

What he described is pretty much right in laymen's terms. You would be hard pressed to find a pointer bug that causes real damage to a system anymore, at least one running in user space. Kernel space programs are a whole 'nother story. They're given much more access, but that's left up to kernel developers which are typically very smart individuals. But bugs do happen.
Pages: 12