Slashdot Mirror


Security Researcher Says Oracle Slow to Fix Flaw

Billosaur writes "A report by Robert Lemos of SecurityFocus in The Register states that Oracle is being criticized by David Litchfield of Next-Generation Security Software for failing to rapidly patch a known flaw in its database software. Litchfield had made Oracle aware of the flaw last October and is now taking them to task for their slow response to the exploit. Oracle, in turn, has attacked Litchfield: 'We are always disappointed when researchers feel the need to publish details of vulnerabilities before a fix is available... What David Litchfield has done is put our customers at risk.'"

10 of 91 comments (clear)

  1. Really a problem? by PlayCleverFully · · Score: 4, Insightful

    What if they CANT fix the problem immediately.

    I am a programmer and when I find bugs in my code "pre-release" I find it benefitial. However, some of the bugs I have to spend a substantial amount of time debugging to finally find a fix.

    With the code as large as Oracle's code is.. it could take an extremely long time.

    This is unfortunate.

    --
    Windows? I haven't used that since 1999. Fix the Slashdot Problems
  2. Who put their customers at risk!!?! by SillySlashdotName · · Score: 2, Insightful

    Oracle sold crap software, did not fix it when told about a problem.

    So tell me again, Oracle, WHO put their customers at risk?

    --
    Acts of massive stupidity are almost never covered by warranty. --me.
  3. who is to blame? by jwegy · · Score: 2, Insightful

    What David Litchfield has done is put our customers at risk
    Isn't Oracle the one who has put their customers at risk?

  4. Who's putting customers at risk? by Todd+Knarr · · Score: 4, Insightful

    Litchfield is putting Oracle's customers at risk? I don't think so. Oracle put their customers at risk, Litchfield merely told those customers they were at risk and in what way. He gave Oracle 3 months to either fix the problem or inform their customers, Oracle did neither, I'd say the problem's all of Oracle's making. If they'd placed their customer's security over their own PR in a reasonable timeframe, Litchfield wouldn't have had to embarrass them this way.

    Another example of why "reasonable disclosure" doesn't work well.

  5. It's the other way around.. by deep44 · · Score: 5, Insightful
    We are always disappointed when researchers feel the need to publish details of vulnerabilities before a fix is available...
    We (consumers) are always disappointed when vendors postpone a patch for a critical vulnerability to the point where a researcher must release the details of said vulnerability in order to motivate the vendor.
  6. Huh? by Realistic_Dragon · · Score: 2, Insightful

    He gave them more than 3 months to fix it. They didnt. He releases the information so that admins can take steps to protect themselves... ...and they call HIM the dick? Right...

    --
    Beep beep.
  7. Recall product by Anonymous Coward · · Score: 1, Insightful

    If a vulnerable product cannot be patched in a reasonable timeframe ..

    RECALL THE PRODUCT!

    That's what car makers do.

    And yes, software is critical.

  8. It's not a fundamental bug by Anonymous Coward · · Score: 2, Insightful

    While the posing doesn't explain the vulnerability in detail, you can see from the fix that it's inadequate input validation, which is easy to add. There's an access control mechanism that's supposed to prevent access to certain features from the web interface, and it's not doing its job.

    While sometimes there are fundamental design problems, this doesn't look like such a case.

    (And in such a case, you should explain to the problem reporter why this is an exceptionally difficult bug and ask for an exceptionally long time before disclosure.)

  9. Re:ever heard of regression testing? by morzel · · Score: 2, Insightful
    I mean, gee, it's not like they have to test it on a huge number of platforms or anything right? Much better to rapidly fix the bug and then break a bunch of running code, bringing large businesses down to their knees.
    If you would have read the fine article, you would have known that flaws in this particular piece of code have been discovered over the past few years, with each patch being inadequate in actually fixing it securely. You should think that 4 years would be enough for some regression testing.
    Yes, the bug puts their customers at risk, but detailing the exploit for everyone to see REALLY DOES HELP THE BAD GUYS. Otherwise they have to figure it out for themselves, which is quite a bit harder.
    The author of the report detailing the exploit also includes a workaround, which enables administrators to have some kind of protection. The bad guys as you call them were already all over this due to the history of security issues in that piece of code. In this case, I see more value in letting the customers know that their machines are at risk than telling something that the bad guys most probably already knew.
    --
    Okay... I'll do the stupid things first, then you shy people follow.
    [Zappa]
  10. Re:Blame it on the messenger, again by dmeranda · · Score: 2, Insightful

    What a lame analogy. Trying to compare those two is practially meaningless, unless of course you have a particular extremist political agenda and are looking for any reason at all to try to convince yourself that you must be right.

    Since you brought it up though, lets analyze the analogy. And only in terms of "security", which is what this /. thread is all about.

    Intercepting communications from foreign people believed to be terrorists or connected to them:

      * This activity's purpose is to prevent future "security breaches" (e.g., learning of a terrorist plot).
      * Without this activity, citizens are certainly less safe (meaning this activity has a positive security benifit)
      * The activity itself is not unsafe nor pose a "security hole" (regardless of your opinions on other non-security effects like liberty)
      * It's effectiveness is in large part subject to it remaining covert
      * Publically reveiling the activity makes it non-covert, and therefore reduces its effectiveness.
      * Result: the "risk" to our safety was increased (again ignoring any other effects for this analogy). There is no obvious way to "undo" this increase in risk (e.g., no forthcoming "patch" which will make it covert once again)
      * If the public exposure had not happened: risk would have remained unchanged (which already was lower than if this activity was not even occuring)

    Exposing Oracle bug publically:

      * The "activity" in this case was a security flaw in deployed software.
      * Thus the "activity" was unsafe.
      * The risk it poses is was dependent upon it remaining undiscovered and without an implemented exploit, or until fixed.
      * Publically reveiling it makes it undiscovered.
      * Result: the risk is temporarily increased--its a race to whether an exploit or a patch is developed first. The risk will actually be decreased when a patch is available and installed.
      * If bug was not publically reveiled: flaw remains in software (proven for at least 3 months); probability of being discovered by "black hats" increases with time, thereby gradually increasing risk.

    Oh, and one other big difference: in the former there were other ways to attempt change without full public disclosure (congressional oversight, etc.) that were not used. In the later other non-public methods of affecting change were attempted first.

    So yes, both acts of publicity result in at least temporary increased risk. But the analogy is otherwise completely broken.

    Sorry, but please save your political arguments to a political topic.