Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Java Security Software IT News Technology

New Java 0-Day Vulnerability Being Exploited In the Wild 193

An anonymous reader writes "Here we go again. A new Java 0-day vulnerability is being exploited in the wild. If you use Java, you can either uninstall/disable the plugin to protect your computer or set your security settings to 'High' and attempt to avoid executing malicious applets. This latest flaw was first discovered by security firm FireEye, which says it has already been used 'to attack multiple customers.' The company has found that the flaw can be exploited successfully in browsers that have Java v1.6 Update 41 or Java v1.7 Update 15 installed, the latest versions of Oracle's plugin."
This discussion has been archived. No new comments can be posted.

New Java 0-Day Vulnerability Being Exploited In the Wild

Comments Filter:
  • by cbreak ( 1575875 ) on Saturday March 02, 2013 @10:57AM (#43053939)
    Executing random C code from somewhere on the net in a Browser is even dumber than doing the same with Java. Java at least has a security model, even if it's broken anew every week, and has more holes than a sieve. C on the other hand has nothing. It really is more or less like a portable Assembly Language as it was developed for.
  • by pipatron ( 966506 ) <pipatron@gmail.com> on Saturday March 02, 2013 @10:58AM (#43053947) Homepage
    Yes, C is secure. You can however use C to write buggy software, for example a java virtual machine.
  • by Murdoch5 ( 1563847 ) on Saturday March 02, 2013 @11:01AM (#43053961) Homepage
    Just to quote the EXCELLENT comment below, it really is the most true statement I've heard in a while.

    Yes, C is secure. You can however use C to write buggy software, for example a java virtual machine.

  • by putaro ( 235078 ) on Saturday March 02, 2013 @11:05AM (#43053989) Journal

    Unfortunately there is no "stupid" moderation. The issue is the Java sandbox which has the goal of letting you run untrusted code (e.g. applets) on your system without any worries. Unfortunately the attack surface of the sandbox is huge because there are so many different API's that are usable and all it takes is a bug in one of them to give you an exploit.

    Turn off Java in your browser and you'll be a happy camper. Stop spreading FUD. The Linux kernel still has exploits (http://www.zdnet.com/linux-kernel-exploit-gets-patched-7000011844/).

    Oh, and I spent 10 years as a kernel developer in C and another 10 years as a Java developer so I guess I'm a Real Hipster Programmer.

  • by putaro ( 235078 ) on Saturday March 02, 2013 @11:08AM (#43054003) Journal

    Well, then you would both be wrong. C doesn't have a security model to exploit. The security model for loading untrusted code into your C application is "Don't do that" which isn't such a bad idea, really. However, if you remove the stupid idea of trying to run untrusted code in a sandbox within your application, Java is quite secure which is why people write server code in Java. No buffer overflows to start with (a classic exploit of server code written in C)

  • by egr ( 932620 ) on Saturday March 02, 2013 @11:13AM (#43054023) Journal
    I think what he means is that C-security is solely dependent on your code, while Java-security is depended on JVM security in addition to your code security. And the developer has no control over JVM security.
  • Re:why they don't (Score:2, Insightful)

    by Anonymous Coward on Saturday March 02, 2013 @11:36AM (#43054177)

    just set a team of 10-15 experienced programmers to review the code in a period of 3-4 months instead of just-wait-to-see-the-next-exploit-and-fix-just-that-rinse-and-repeat ?

    They've probably invested considerably more man-months into the problem than that. The problem is that such a procedure will not find all the bugs in a complicated code base. Another way of saying that is, every time you do this, you'll probably find at least one more bug and the same thing happens when the bad guys do it. Welcome to the world of an impossible task that is never the less very important.

  • by Anonymous Coward on Saturday March 02, 2013 @11:55AM (#43054283)

    > Yes, C is secure.

    The comment is nonsensical. Security is about vectors. The language itself, is really not "secure" because it has to operate within an environment. By integration, it's no more or less secure than the environment AND the program the language was used to write. You really don't understand the implications of the discussion if you think that comment was "excellent".

  • by cbreak ( 1575875 ) on Saturday March 02, 2013 @12:38PM (#43054483)
    No, honestly, writing evil code in C is easy. You can open files without restrictions, modify them without restrictions, and so on, all with the power of the running user. Executing untrusted C code is NOT SECURE.
  • Comment removed (Score:4, Insightful)

    by account_deleted ( 4530225 ) on Saturday March 02, 2013 @01:07PM (#43054673)
    Comment removed based on user account deletion
  • by gtall ( 79522 ) on Saturday March 02, 2013 @01:26PM (#43054815)

    And who writes their whole program in using just their own code? We have massive C libraries because we cannot reinvent the wheel every time. And it isn't possible to exhaustively check the code in those libraries due to time constraints and sheer complexity.

  • Re:why they don't (Score:2, Insightful)

    by semi-extrinsic ( 1997002 ) <asmunder@nOSPAm.stud.ntnu.no> on Saturday March 02, 2013 @02:26PM (#43055217)
    It's simple. Java was teh hawtness roughly ten years ago. It took four years for university CS departments to catch on, then four years for the first Java-loving graduates to start "entrepreneuring", and then two years for this to significantly influence Java usage. It's a basic convolution-type feedback.
  • Re:why they don't (Score:5, Insightful)

    by hjf ( 703092 ) on Saturday March 02, 2013 @02:27PM (#43055223) Homepage

    I'm a hobby microcontroller programmer. I've made stuff with PICs that runs flawlessly. Written in C and assembly. One is a fan controller (switches 5 different relays and shows the output on a 7-segment display), and it's been running for probably 8 years non stop (well, the fan stops but the controller never does).
    Another project was a simple "street block counter" for taxis, which I sold to a friend and he's made hundreds if not thousands of them (i should have asked more money!).

    And tens of little projects that more or less work as supposed.

    For all those projects, it's easy to validate all inputs and outputs, and follow all code. Since they're simple to understand. Right now my project is a weather station with ethernet and data logging. It's simple on the outside but it's so hard when you realize how much sanitizing you need for all values, and when you test it for different values of VDD and start getting weird readings, and when you deal with a memory chip which can (and will) be interrupted mid-write with a power outage and your data will be corrupted. It's really incredibly hard how you find more and more potential flaws after just a few hundred lines of code (and reasoning).

    So while i understand your point, comparing java to a few small systems isn't really fair. Java is a huge monster with a target painted on its back. No system is really secure, and even Mac OS (which was claimed "secure") was proved to be as flawed as anything else. Mac OS used to be something no one cared about, but now that it's gaining a user base, it's being targeted more and more. It's the same with java. And it could be the same with any other language, tool (PDF), OS, SCADA, PLC, anything.

    Any system that accepts uncontrolled (by the user) inputs is subject to exploiting.

  • Re:why they don't (Score:1, Insightful)

    by Anonymous Coward on Saturday March 02, 2013 @05:58PM (#43056433)

    Another dumb shit that cannot discern the difference between Java the language and a browser plugin. Shit's like you probably also think Javascript is Java. amirite?

We are each entitled to our own opinion, but no one is entitled to his own facts. -- Patrick Moynihan

Working...