Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Java Security Software IT

Oracle Responds To Java Security Critics With Massive 50 Flaw Patch Update 270

darthcamaro writes "Oracle has been slammed a lot in recent months about its lackluster handling of Java security. Now Oracle is responding as strongly as it can with one of the largest Java security updates in history. 50 flaws in total with the vast majority carrying the highest-possible CVSS score of 10."
This discussion has been archived. No new comments can be posted.

Oracle Responds To Java Security Critics With Massive 50 Flaw Patch Update

Comments Filter:
  • Too late (Score:5, Insightful)

    by Anonymous Coward on Friday February 01, 2013 @07:53PM (#42767125)

    The knee-jerk reaction of getting the patches for Java out now following public criticism is not going to make up for their previous apparent disinterest in supporting the platform. The damage they have done to the reputation of Java is incalculable, and I for one as a C++ programmer thank them for it!

    • Re:Too late (Score:5, Funny)

      by Maltheus ( 248271 ) on Friday February 01, 2013 @08:34PM (#42767515)

      No doubt, this evens the scales after decades of buffer overun exploits. Especially given the explosive popularity of applets.

    • Re:Too late (Score:5, Insightful)

      by sjames ( 1099 ) on Friday February 01, 2013 @10:00PM (#42768147) Homepage Journal

      It is good that they released the patches, but since they waited until DHS actually suggested uninstalling it (and all the implications of that) to do so, it doesn't inspire much confidence. If they want to rehabilitate their reputation, they're going to have to be MUCH more proactive about security and it will take a while to convince people.

      • Re:Too late (Score:5, Funny)

        by davester666 ( 731373 ) on Saturday February 02, 2013 @03:07AM (#42769649) Journal

        Well, they could use the exploits in older versions of Java to update to the new version automatically...

      • by smash ( 1351 )
        More to the point, the latest douche-baggery is that when you install the latest java security updates, they actually go back into your browser and re-enable java in there so that you can verify that java works when it directs your browser to a "Test page" that requires java enabled in the browser to operate. Dick move, oracle.
  • by jkrise ( 535370 ) on Friday February 01, 2013 @07:56PM (#42767147) Journal

    Supercop Oracle: I caught 50 powerful top grade thieves in my neighbourhood!! I am great!!!!

    Ordinary cop: Why did you allow 50 scoundrels in the first place?

  • Confused. (Score:5, Insightful)

    by Anonymous Coward on Friday February 01, 2013 @07:56PM (#42767151)

    I'm not sure how I feel about this;

    1. Good. It's awesome that Oracle are finally taking notice of java security issues and doing something positive.
    2. Bad. That's a lot of CVSS2.0 score 10 bugs they've been letting slide.
    3. Confused. How many more are there?

    • Re:Confused. (Score:5, Insightful)

      by _xeno_ ( 155264 ) on Friday February 01, 2013 @08:49PM (#42767637) Homepage Journal

      3. Confused. How many more are there?

      I'm sure there are enough that I feel fairly confident in my advice to just not install Java unless you really, really need it. Which, unless you're a developer or a Minecraft addict, you really don't.

      So I have the JDK installed, but the plugin disabled. (Well, I have the 64-bit JDK installed and use 32-bit Firefox, which works well enough on that front.)

      • Re: (Score:2, Informative)

        by Anonymous Coward

        Really? You don't need it?

        I need it to use the various financial calculators on my brokerage's website.

        I need it to use the VOIP software from my employer that lets me telecommute full time.

        I need it for countless open source utilities I use frequently.

        • The finance software I can understand, but they really should take that out of applets and give you full applications.

          Why your VOIP software needs to both be Java and run in a browser puzzles me. Not your fault of course, but that sounds... poorly designed.

          What countless open source utilities ONLY run via an applet?

        • Re:Confused. (Score:4, Interesting)

          by DMUTPeregrine ( 612791 ) on Saturday February 02, 2013 @05:01AM (#42769957) Journal
          So install a second browser, just for Java. Disable the plugin on your other browsers, and sandbox the browser with Java as well as you can.

          I use Chrome in a VM for Java (and some other probably insecure things, like viewing sites where I can't block ads.)
    • 4. Pissed. That Oracle waited and collected bug fixes, not releasing any until they'd collected 50 in total, so they'd look like heroes.

  • by Anonymous Coward on Friday February 01, 2013 @08:05PM (#42767235)

    I know Oracle didn't write Java to being with but they sure had a hard-on to acquire it, presumably so soak up profits by wedging themselves in to yet more enterprise services. I'd like them to take ownership of this issue and really hammer out these nasty problems. I know it's just the client side JVM-plugin-whatever but Oracle's behavior isn't really making me want to go out and seek other Oracle products.

    And fuck, if I can't escape this piece software at work. I've got client applications, and web applications that we rely on that absolutely require the full fat oracle JVM. I'd love to disable the plugin or do away with it all together but I can't.

    For that matter, deploying this supposedly enterprise piece of software is a massive pain in the ass. If you want to deploy it like usual (Published through AD) You've got to open the installer EXE, go to your temp folder to copy out the .msi, then use an .msi editor to create an .msp file to disable the really annoying and awful java auto-updater. (The auto updater requires admin privs to install.. And it will trigger on it's own without user intervention. It's really annoying to end users to have a UAC prompt pop up randomly out of nowhere when they're working)

    Oh yeah, and if you run the exe manually to install? Make sure you uncheck the yahoo toolbar! And this is supposed to be business software?

  • by mhotchin ( 791085 ) <<slashdot> <at> <hotchin.net>> on Friday February 01, 2013 @08:39PM (#42767561)

    Would it kill you idiots to post a direct link to the update in a story that is about nothing *but* the update?
    http://www.oracle.com/technetwork/java/javase/downloads/index.html [oracle.com]

    • Would it kill those (oracle) idiots to include the US JCE policy files in an installer so I don't have to fucking manually replace jarfiles every damn update?

      (this is not directed at you)

  • by mysidia ( 191772 ) on Friday February 01, 2013 @08:50PM (#42767653)

    There are probably 500 unaddressed.. you know...

    Oracle's you know... rearranging the deck chairs on the Titanic. plugging a few of the small leaks here in there. Doesn't mean the ship is saved:)

    Recall Cisco just released this big 2013 annual security report the other day, showing Java exploit as a #1 infection vector for malware.... :)

  • *sigh*.... Java... (Score:5, Interesting)

    by wierd_w ( 1375923 ) on Friday February 01, 2013 @08:50PM (#42767655)

    I like the *idea* of java.... but I don't like java.

    It has been my experience, even way back when the JVM was owned by SUN, and when MS tried their crazy IE only "not really a real JVM but we say it is!" Bull--- that the JVM was a festering turd, that was slow, carried around a lot of baggage, and was a vector through wich malicious programs could be executed in secret due to its bugs.

    Granted, that is just an anecdote. So, here's some old, tinned bugs from days of yore... clicky. [ait.ac.th]

    As far as I can tell, Java has always been a very attractive target for malefactors who want to run malicious executable code on remote systems, because the innate abstraction provided by the JVM makes it an ideal incubator for that malware. As such, malefactors have consistently looked for, found, and exploited holes in Java to accomplish their nefarious tasks, despite the JVM dev team's best efforts.

    In short, Java has always been a security risk. The question I have always asked myself is if the benefits of that security risk outweigh the benefits. So far, my answer has always been "no." When it comes to desktop computing. For the originally intended ecosystem that Java was made for, (things like portable computers, set top boxes, and custom computing devices) java is a godsend that makes development time get spent more efficiently. For a mostly monolithic desktop hardware space, java doesn't make nearly as much sense, and carries with it a very large attack surface.

    In short, I would rather do without your software, than expose myself to java's attack surface, if you refuse to write your software in a properly portable fashion, and choose to rely exclusively on the JVM.

      If you need cross platform support, use cross platform libraries, and compile platform appropriate executables from your codebase. Maintaining platform agnosticism through writing exclusively portable code will force you to write better code anyway.

    Leave Java in the ecosystem it belongs in: one off hardware implentations, novelty devices, and low power computing platforms. Bringing java kicking and screaming to the desktop ecosystem makes it too big of a target for malefactors, and only exposes your own unwillingness to practice best practices when writing your software.

    • by trims ( 10010 ) on Friday February 01, 2013 @09:26PM (#42767913) Homepage

      You forget the place that Java has had the most success: Enterprise computing.

      I'll agree that the sum total of the Java Plugin + JDK Libraries + JVM provides too much opportunity to attack on the desktop / web app space. There's simply too many flaws in the plugin and libraries. The JVM itself, though, is very solid (fewer than 10 major flaws over 15 years).

      However, Java as a middleware platform is simply far better than any of the alternatives, and that's where I expect it to remain. Insulated from the types of attacks that render Java dangerous on the desktop, middleware app servers play directly to Java's big strengths: speed, ease of development, and massive library support, plus a framework which helps discourage the types of coding flaws that hurt middleware computing the most. Java will likely remain king of middlewhere for a long time, and deservedly so.

      On the desktop or as a downloadable app, well, yes, Java is simply never going to measure up to the better cross-platform alternatives.

      -Erik

      • by LWATCDR ( 28044 )

        What better cross-platform alternatives? .Net????

        • Actually implementing best practices, and using portable libraries. (Like, not taking things like byte order for granted, not taking system behaviors for granted, etc.)

          Oh, but that means you need to learn C, and not some platform specific language. My bad. /snark

          • by LWATCDR ( 28044 )

            That is very limiting. Take for instance dealing with things like audio, video inputs, and so on. You do not have to learn C Qt works with C++ but that will not give you the run anywhere capability of Java.

          • Oh, but that means you need to learn C, and not some platform specific language.

            C is a very platform specific language (been there, done that). The only reason (non trivial) C programs work at all on different platforms is because the developers used copious amounts of defines and pragmas, and thus wrote the program for all platforms.

            This in contrast with Java where I can take a Jar created for one system/OS and run it on another system/OS without any changes at all (provided it doesn't deeply integrate with the host OS). This is of course because the Java VM is the actual system/OS.

      • No question. Java is a very valuable and useful tool.

        But it needs to stay away from the high risk environment of the desktop.

        Like I said, I like the idea of java. It really is a good idea, and if java was just more discrete about where it tried to dangle its little toes, I would have zero problem with it.

        But when it serves as a universal attack vector in the desktop space, there is a serious problem, and it needs to be dealt with. I feel the best solution there is to Just Say No.

        I refuse to install the JDK

        • But it needs to stay away from the high risk environment of the browser.

          FTFY. There's nothing wrong with Java on the desktop... but there's everything wrong with it running in the web browser.

          • Perhaps if there were better tools to see what is running inside the jvm, and being able to terminate processes, as well as being better able to restrict what priviledges and access methods the JVM can attempt. I don't like running a magic box that welds the lid on by default.

            Not being able to do those things, or worse, having the VM ignore settings you do set because the application asked realy nicely, is not going to make me trust the VM. Java integrates itself pretty deeply on the host environment to d

            • I'm pretty sure the JDK's debugger would do what you want, if you could figure out how to work it.

        • What's wrong with the JDK? I completely understand not wanting the browser plugins (those are where the majority of exploits come into play), but what in the hell sort of problems are you expecting the JDK to cause? It's the developer tools. Does the malware need to compile itself to bytecode (remember: this is Java)? To be honest, if malware is to the point where it can use the JDK on your box, you're pretty much hosed anyway, as local code execution is already required and the JDK doesn't run with special
          • ....you would be surprised at the number of java "desktop applications" that won't work with the standard JRE, and demand JDK functionality.

            Seriously.

            • As for what I expect it to do;

              I expect it to obey restrictions I put it under, and to not run constantly behind my back. Just like it isn't a good idea to leave unmonitored servlets open on standard ports, I don't feel it is trustworthy to leave a VM running all the time, and would expect that people who claim to be professional programmers would comprehend that, and let me put restrictions on when and how the VM runs.

              But no. Java wants to put hentai tentacles in, and I don't like that. That's for starter

              • I don't feel it is trustworthy to leave a VM running all the time

                It's really not a general-purpose VM like Linux, Windows, or $YOUR_OS_HERE on VMware, VirtualBox, Xen, or $YOUR_HYPERVISOR_HERE. It doesn't run an OS, just the one Java program it's given. One JVM instance only runs one program. Hell, the JVM works without any sort of kernel-level support, whereas everything moderately efficient requires kernel-level drivers to work properly. (Vanilla QEMU has no kernel-level drivers, but was so slow that KQEMU was developed, and QEMU was later tied with KVM to make it mor

                • No, locally.

                  I tested it even. Created a folder, set access privs to deny anyone access to it, except system.

                  The applet running was able to go inside the folder, and save a file just fine.

                  That is a nono. A big turd smelling nono.

                  • In another thread you mentioned that a JVM instance was running as SYSTEM. My statement that it was a buggy program that required admin privileges still stands. Unless you can show that the JVM elevated itself (somehow magically, bypassing all access control), it was a buggy program. The JVM is just another program; it only does what it is told (with bugs, just as any program has).
            • I know there are quite a few, but what security flaws does the JDK bring with it? My point wasn't that things need the JDK, it was that the JDK really won't help nasty things get on your box (if you count the JRE that's bundled with the JDK sure, but that's really the JRE not the JDK).
              • I distrust the jvm, because it is very difficult to lock it down.

                Desktop app developers want access to the local FS. This is because they want to do something useful, like being an office suite. You can't save files, if you don't have FS access, of course!

                I can't selectively authorize the JVM to have access to specific areas with real authority. Certainly not on a windows system, where the JVM runs with system level authority. (Basically at root!) Even without the browser plugin, a driveby download script t

                • You seem to be conflating the JDK and the JRE. They are different things. I'm talking about exclusively the JDK. You're talking about the JRE.

                  That being said, I've never had a Java program run as SYSTEM. It's always run as my user, and I have no idea how in the hell it would magically run as SYSTEM. You also seem to have a fundamentally mistaken view about how the JVM works, but that's a topic for another reply.
                  • Probably-- I find the environment that java applications run under to be opaque, and impossible to monitor or sanely control.

                    Granted, the last time I allowed myself to install the JRE was many many years ago. The application wasn't terribly important, but was necessary for what I needed, becaue there weren't any alternatives, and had the ability to open and save files. I noted that it could open and save files in places that my user did not have authority to do. When I checked the task manager, the jvm was

                    • When I checked the task manager, the jvm was running at a higher authority level than my user.

                      Then either 1) something got buggered with your JVM or 2) the application explicitly elevated itself somehow (a la UAC today). The JVM does not run as SYSTEM unless it is invoked by SYSTEM. Sounds like a buggy application.

                      The fact that I can't get a list of what is running insde in a painless fashion

                      Repeat after me: one JVM instance can only run one program. One process = one program. Just like anything else... If you have one java.exe running, you have one Java program running.

                      and can't give a global restriction on what the jre and jvm can touch

                      Use the same filesystem permissions that apply to every single other program ever made. Why is Java special

                    • The distinction between a buggy application, and a malicious application that "asks really nicely" to run as system, is moot. The malicious programmer will purposefully use buggy methods to get the jvm to run at system, exactly because he can then drop shit anywhere he wants. Qed.

                      I want the jvm to have a restriction that says it can NEVER be invoked above a limited super user I define.

                      As for the silent invokation, I again refer you to buggy browsers. IE is especially nasty this way. (I don't use it btw.) A

                    • The distinction between a buggy application, and a malicious application that "asks really nicely" to run as system, is moot. The malicious programmer will purposefully use buggy methods to get the jvm to run at system, exactly because he can then drop shit anywhere he wants. Qed.

                      Wrong kind of buggy. If you give the installer admin rights, and it installs a program that runs at admin level, that is buggy (perhaps I should have used "improper"?) behavior, but it's neither malicious nor caused by Java. I think we can agree that by granting a program admin rights (either directly or indirectly) it's not obtained improperly. As you said yourself, "This might have been because it needed to be installed as an actual admin, and the system automatically gave it admin privs." Couldn't have

    • by jafac ( 1449 )

      Java was Sun's last-ditch effort to preserve an ecosystem of different operating systems and different CPU platforms anyway. That didn't really work-out so well for Sun in the long run. Rather unfortunately.

      It's nice that we still have a diverse range of operating systems, but really, it kind of just boils down to Intel now.

      • Java still shines on handheld devices, like tablets and phones, and on settop devices, like DRVs and cable boxes. An application written for the JVM can theoretically run on any architecture that has a suitable JVM implementation. That's the whole point. A device maker can use whatever chip-du-jour is the cheapest that year, and at least in theory not break all their app support, because all they have to do is make sure the JVM works.

        This means a cable company can write a DVR applet for a cable box, and re

        • But most hackers aren't interested in your cable box, or your DVR. They want something they can use to brute force passwords with, send email to others through, force into a ddos, or just use to plain straight up steal personal data with.

          They should be. Those kinds of always-on always-connected low-demand systems would make perfect botnet zombies in great numbers, and I'd argue there are more of them out there than computers. Hell even if the botnet slowed the thing down, how many folks would you expect to notice? Even fewer than that are the amount who could/would do anything about it.

          • With the exception of a dvr, most of those devices are low RAM, and lack a persistent writable data store, meaning a simple power off would unzombify them.

            Last I checked, the desktop JVM will grant a writable datastore to appliations that request it, and even hold it persistently.

    • by ahabswhale ( 1189519 ) on Saturday February 02, 2013 @12:10AM (#42768889)

      ROFL...are you fucking serious? You can find a lot more security holes in C and C++ than you can in Java. The ONLY reason you see all this shit about Java security is that Java can be run client-side via a simple download by your browser. There are very very few languages that allow this and I can guarantee you that any other ones are thoroughly explored for security holes by hackers. Ever heard of Flash? They've had many many security holes too but that's because they are a target. There are no safe fucking languages. Get that ridiculous idea out of your head. It's about the language's ecosystem and when that ecosystem ends up getting quietly download by somebodies browser, it's gonna get fucking raped by every hacker worth a shit.

      I have to say that I'm pretty shocked about how utterly clueless the /. community is about this kind of technology. Sad stuff.

      • *sigh*.

        The very problem with java, is also its very reason for being. It is a universal machine, with a garanteed configuration inside it.

        A malware writer loves java for the same reasons you do: it is write once, run anywhere.

        The issue is insisting that everything be run from an unsecured end point, such as an internet connected environment. Putting java on the internet, and on everyone's desktop is what the very problem is.

        Flash has the exact same problem.
        Developers are suffering from battered wife syndro

        • I think my post made it clear that I understand why Java is attacked by hackers so 90% of your post is pointless. And for the record, I don't "love Java". I never have even when it was new. I write Java for a living and it makes me a shitload of money doing so.

          And please spare me this notion that being able to run anywhere is some kind of flaw. It has nothing to do with it. Client side execution by your browser is the significant variable.

          • Re: (Score:3, Interesting)

            by wierd_w ( 1375923 )

            Agreed! Client side execution is the problem! But, where would you expect it to run otherwise? On the server? Congrats, you just pointed a bullseye on big iron! One that can potentially run general purpose programs, and not just a simple script parser!

            The problem with java, is that it is standardized, and everywhere. This makes it desirable to target. It needs alternatives, and lots of them, with heavy market penetration.

            • 99.99% of all Java is server-side Java. Chances are, that the majority of the websites you visit are running Java server-side. For example, Google, Ebay, and Amazon all run server-side Java. Almost every bank and insurance company runs on Java. It's very ubiquitous. There's nothing wrong with Java except when run client-side but I would simplify it to say that any client-side browser product that isn't Javascript is potentially dangerous. In fact, I can guarantee it because every one of these technolog

    • Seriously? I think DirectX had a much longer running exploitable lifetime than the current Java debacle, and was much wider exploited.
      And don't talk to me about all those C viruses that we used to have to deal with. Blaming a language because of a plug in makes you look foolish.

      • My issue is not with java.

        My issue is with the demand for it t be ubiquitous, everywhere, on everything, and easily tapped.

        Keep it in a box. Please. Don't make me have to install it just because you didn't feel like learing any other architectures, when in reality, there are only 4 major ones in existence right now. (*nix, *bsd, Windows, and javaVM)

        I don't want it to be easy for you to run things on my computer. That's the whole fucking point.

  • Nostalgia (Score:3, Interesting)

    by mrbester ( 200927 ) on Friday February 01, 2013 @09:04PM (#42767757) Homepage

    I remember those halcyon days when Java had just emerged, acorn like if you will, from Oak. It promised a brave new world of write once, run anywhere programming that was to usher in a wonderful alternative to all that dangerous mucking about with C++ and flatten the disparate paradigms of software development from Microsoft, Apple and others. I went to trade shows and conferences with like minded souls all excited about this Next Big Thing. Hell, I even bought books and marvelled how easy it was to get Duke to cartwheel on any OS with a JVM.

    Then it all went to shit with internecine wars and disparate implementations.

    But it didn't stop there. It then carved out of the psyches of beleaguered programmers the world over a new level of hell just for itself.

    Adieu. At least it was fun in the beginning.

    • by jgrahn ( 181062 )

      I remember those halcyon days when Java had just emerged, acorn like if you will, from Oak. It promised a brave new world of write once, run anywhere programming that was to usher in a wonderful alternative to all that dangerous mucking about with C++ and flatten the disparate paradigms of software development from Microsoft, Apple and others. I went to trade shows and conferences with like minded souls all excited about this Next Big Thing. Hell, I even bought books and marvelled how easy it was to get Duke to cartwheel on any OS with a JVM.

      I was there too in the late 1990s. My company was C/Unix-oriented, and Java looked like a nice upgrade for a few months.

      Then I found that I couldn't get a free Java interpreter for my Linux box; that I couldn't write a standard Unix getopt(3) parser; that C++ had better data structures for vectors, linked lists and search trees ... and I passed on Java.

      But it didn't stop there. It then carved out of the psyches of beleaguered programmers the world over a new level of hell just for itself.

      It turned into a platform. You already had Windows programmers and Unix programmers who didn't talk to each other; now you had Java programmers too.

  • by gweihir ( 88907 ) on Friday February 01, 2013 @09:05PM (#42767767)

    I wonder how many are still open after this publicity stunt and how many they did patch badly (as before), but now the attackers know what to look at.

    Lets face it: Java is a mess. Use in anything but protected environment where the Java code and runtime cannot be attacked is highly unprofessional and borders on gross negligence.

  • Comment removed based on user account deletion
    • Oracle is really doing its best to kill Java. For them to even *THINK* auto-uninstalling 1.6 is a good idea at this point in time is like the Titanic's crew chopping holes in their lifeboats upon seeing the iceberg...

    • If you are installing Java 7, why would you need to keep 6? Do you have an example of something that works with 6 but not 7?

      How is it different from IE8 requiring that you uninstall IE7?

      • by JazzXP ( 770338 )
        We write an applet based trading platform, and due to the API adding a method with a name we were already using, we had to re-engineer heaps of our code (along with other Java issues). For them just totally discontinuing Java 6 as soon as Java 7 came out (and still had heaps of bugs) was a stupid mistake.
    • by thetoastman ( 747937 ) on Saturday February 02, 2013 @12:02AM (#42768841)

      On what screwed up platform is this?

      Seriously, I have 1.6.0_39 and 1.7.0_13 happily running together on all the platforms that I'm responsible for (Linux, Windows, UNIX of various flavors).

      This patch was rather important in that there are some server side security issues being patched as well as browser plugin issues.

      I'm seeing all of this hate, but you know what, I just don't get it. Software of any complexity has bugs. Microsoft used to be the champion of security exploits. Now it's Java. And lest anyone forget, there are myriads of PHP / Ruby / Python security bugs that allow systems to be exploited. I'm not even sure that there's a secure Ruby on Rails platform at this point, for example. I don't know for certain about Ruby, since the only Ruby platform I have right now is for Redmine.

      I guess though everyone likes the Faux News mentality of computer security reporting. It garners page clicks, makes people feel important and is a lot easier than actually doing any work. It's like the hit piece someone at InfoWorld did on a Spring Framework bug that could possibly be exploited (albeit not very easily). The sensationalist piece completely overlooked the fact that the issue had been addressed over a year ago. The "journalist" at InfoWorld was too busy jumping on the "all things Java are evil and insecure" bandwagon to do the tiny bit of research needed to write intelligently about the problem . . .

      Just like people are now doing about the current issue . . .

      My favorite comment so far has been along the following lines

      Sure, they may have fixed these security flaws, but there's no guarantee that this will fix future security flaws. It's better that you just go ahead and uninstall Java now.

      Sure, [insert-least-favorite-software-of-the-day] may be patched now, but will it remain patched?

      I thought at least professionals were a bit more intelligent than this. I guess not.

  • unpatched hole for you to get screwed through.
  • fix those vulnerabilities before someone installs a toolbar you don't want... oh wait. nevermind.

  • by JImbob0i0 ( 1202835 ) on Saturday February 02, 2013 @05:14AM (#42769995)

    This whole thing about Java being the issue annoys me - if you take a broader look at the whole ecosystem.

    Take a look at no more than 2 weeks ago with CVE-2012-4414 [mitre.org] for example...

    This is a MySQL security bug where any authorised DB user can arbitrarily inject SQL in the binlog used for replication...

    For those that don't know Oracle has recently (over the past year) moved the majority of their bugs database internal only so that inhibits discussions for a start and on top of that they no longer publish test cases for fixes ... it looks like they might be going into an internal/tests directory but that isn't provided in the GPL tarball they provide.

    However the curiousness doesn't stop there - if they are still writing test cases for code as opposed to just changing stuff willynilly they don't seem to be writing them very well.

    When the Percona guys were merging from the upstream code they used the test case that the MariaDB team put together for this CVE - since there is no test provided by Oracle as previously mentioned.

    They naturally expected the test to be fine seeing as Oracle claimed the CVE was fixed in 5.5.29 but shock horror it failed.

    They ended up merging the MariaDB fix instead [mysqlperformanceblog.com].

    Given that what makes you think the rest of the code is *really* like and why that Java fix recently introduced a new bug and so on...

    Ah well in the meantime FESCO has accepted the proposal to replace MySQL with MariaDB in Fedora 19 [fedoraproject.org] which is something that Oracle weren't too pleased with [fedoraproject.org]...

    That Oracle response was prior to the FESCO vote by the way - time to get the popcorn methinks!

BLISS is ignorance.

Working...